Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only
  • 1.  Shared SLS across MAS instances vs upgrade process

    Posted Thu February 27, 2025 07:55 AM
    Multiple instances of Maximo Application Suite can share an SLS and the corresponding license file (link).
    One scenario could be a test MAS and a pre-production MAS, where the former points to the latter's SLS.
    When a customer wants to upgrade to version X+1 of the MAS, they typically want to test on the test environment first and upgrade to pre-production later. However, the upgrade might also affect the SLS or other elements shared by the two MASs (e.g. a MongoDB version change). 
    Is there a technical way to avoid problems with the preproduction system remaining on version X?
    More importantly, is there an IBM document or web page that certifies that there are no problems (if the correct steps are followed) when do an upgrade in this scenario?


    ------------------------------
    Diego Visentin
    ------------------------------


  • 2.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Fri February 28, 2025 03:18 AM

    That's very interesting question Diego!
    I would like to know the consequences myself as well.

    One thing which obviously comes to my mind is simply to give it a try. Of course it's always better to have it officially confirmed but it's still one of the ways to find out.
    I wonder if @Witold Wierzchowski has an input on this one...?



    ------------------------------
    Andrzej Więcław
    Maximo Technical Consultant
    AFRY
    Wrocław, Poland
    ------------------------------



  • 3.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Fri February 28, 2025 12:00 PM
    Edited by Diego Visentin Fri February 28, 2025 12:01 PM
    I can confirm that in the same OCP system with one MAS v9.0.8 and one with v9.1.0-pre.stable (so SLS v3, updated MongoDB, etc.), everything works fine.
    But I am looking for some official confirmation that this should always be the case.
    Technically, I think IBM needs to be committed to ensuring that the APIs exposed by SLS and DRO do not change from version X to X+1. 

    PS:
    IMHO the problem lies in the idea of counting registered users on non-production OCP/MAS systems (dev, test, quality, etc). 
    Or at least make no-cost the mandatory premium admin user (=15 AppPoint) for that systems.
     



    ------------------------------
    Diego Visentin
    ------------------------------



  • 4.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Mon March 03, 2025 02:48 AM

    Diego, Andrzej,

    I will ask this question during the weekly MAS9 Design Team Meeting this week.  IMHO I think that this is a very obvious and common situation, since from a client DTAP strategy, you will logically update DEV, TEST and ACC first with the latest updates (all Non-Production) before updating and deploying to PRD (production).  I don't expect a reversed deployment strategy (PATD), since this is highly unusual and not recommended at all.  If this standard approach is not supported / covered by IBM's own rules than I expect a lot of clients won't upgrade (because of unnecessary costs / non-compliance). WDYT?




    ------------------------------
    Jan-Willem Steur
    Manager Business Development
    ZNAPZ b.v.
    Breda
    +31 6 25639950
    Jan-Willem
    ------------------------------



  • 5.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Mon March 03, 2025 03:24 AM

    Thanks Jan-Willem.
    I think IBM should make it as easy (and affordable) as possible for customers to adopt MAS, and even more so for it to evolve both in terms of versioning and additional functionality beyond the canonical EAM features. I am therefore very interested in the feedback from those who attend the weekly product meeting.



    ------------------------------
    Diego Visentin
    ------------------------------



  • 6.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Mon March 03, 2025 04:53 AM

    Personally i use the SPCR to check the compatibility of MAS releases with all the prerequisites - example for 9.0 https://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=DFE9761E3B364DC4B17FADF7045C341D&osPlatforms=spcrAllValues&duComponentIds=spcrAllValues&mandatoryCapIds=spcrAllValues&optionalCapIds=spcrAllValues

    According to IBM there should be no deprecations between different z-stream versions (i'm reffering to x.y.z release numbering). For different y releases that might be different, but that is usualy quite well documented in both SPCR and the release notes for each MAS catalog here: https://ibm-mas.github.io/cli/catalogs/



    ------------------------------
    Witold Wierzchowski
    Solution Architect
    Cohesive Poland
    ------------------------------



  • 7.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Tue March 04, 2025 02:55 PM
    The shared SLS/MongoDB/DRO is doable, but how you implement it depends on whether your design is a single OCP or multiple OCP setup.
     
    For a single OCP, you can install as many instances of MAS Core/Manage as your hardware allows and have a single Mongo/SLS/DRO. The multiple MAS Core/Manage instances will connect to the same Mongo/SLS/DRO.
     
    For multiple OCPs, you can decide which OCP instance should be your "hub" to run Mongo/SLS/DRO. The other OCP instances can then connect as spokes to the Mongo/SLS/DRO running on the hub instance.
    You may have other matters to consider, given that Mongo may or may not be your LDAP.
    The upgrade/update is a separate topic but relevant to your above design.  Maximo prefers that you not change Operator subscription to manual. 


    ------------------------------
    Arif Ali
    ------------------------------



  • 8.  RE: Shared SLS across MAS instances vs upgrade process

    Posted Wed March 05, 2025 04:25 AM

    As already mentioned by others, technically it's doable and possible as long as SLS API stays compatible but I'm not aware of any official documentation from IBM about the upgrade process in this setup. So we should take it under control by establishing a reliable upgrade process:
    - Analyzing the release notes of IBM MAS catalog to see potential compatibility issues
    - Using a proper backup strategy to safeguard against possible issues
    - Testing it on non-critical environment first before doing on customer environments
    - In addition, it's a good idea to install the shared SLS in the more critical environment as you already have it. So if you share SLS between test and pre-production environments, SLS should better be installed in the pre-production environment while the test one should connect to it. In this case upgrading the test environment first (without upgrading the shared parts like SLS) will not affect the pre-production environment in any way. Moreover, it will reveal the SLS API incompatibility. If such incompatibility is identified or the connection to the shared SLS is broken, in my experience the test environment will stay functional without license consumption monitoring and it will still allow testing Manage.



    ------------------------------
    Ivan Lagunov
    Head of R&D
    ZNAPZ B.V.
    ------------------------------