DX Unified Infrastructure Management

 View Only
  • 1.  Promoting probe profiles from test to prod...Change Management

    Posted Jul 18, 2011 07:04 PM

    I am curious how other customers develop and promote monitoring profiles from a dev environment to a production environment.  For example, promoting a profile from url_response from a test server to a prodution server.  I realize I can take the entire cfg from one robot, isolate the profile, then install to the production robot, but I'm looking for a simplified solution I can give to our Change Management team.  

    Thoughts? 



  • 2.  RE: Promoting probe profiles from test to prod...Change Management

    Broadcom Employee
    Posted Aug 20, 2019 01:11 AM
    You may achieve this by using Superpackage. See the following KB for cdm superpackage.

    Article title: Create a cdm Superpackage for Multiple Operating Systems
    https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=35030


  • 3.  RE: Promoting probe profiles from test to prod...Change Management

    Posted Aug 20, 2019 11:34 AM
    Change management is a serious lack in the UIM product - granted there are significantly larger issues to correct first but it's still a biggie.

    Super packages are the method we use too. Note that in order to create and edit these packages you will need to use IM - this functionality was deemed unnecessary to port to the web based tools though I am hopeful that attitude will change at some point.

    There are three identifiers that a package gets - name, version, and build. Build increments every time you save a package but gets ignored. So, if you run multiple distsrv probes and rely on forwarding to keep them all in sync, you will want to look for a script on this forum named "sync distsrv" - it addresses the issue where you edit a package and save it but because only the build number changes, it doesn't propagate.

    Version number is a much misused field - it is textual in nature but when comparisons happen they are a seemingly random mix of text or numeric comparisons. The general rule here is that you want to make sure that whether the version is looked at as a number or text, the comparison behavior is the same. So, consider how many changes are going to happen and give yourself room in the version then always use the same format for versions - so never create version 1, followed by version 1.1, followed by 1.2,.... followed by 1.10. Because numerically 1.1 and 1.10 are the same version but textually 1.1 and 1.10 are different but then 1.10 sorts before 1.2. Creates a real mess. So always keep the same format: 1.00, 1.01, 1.02,..., 1.10. I've also seen some behavior where the version string is assumed to have only two digits to the right of the decimal point but that was a long time ago and I have just avoided using anything other than two digits.

    Names are just that - Unique identifiers when combined with version. Avoid any case dependency - "logmon" and "LOGMON" may or may not be considered the name of the same package. We have taken the approach of naming everything starting with the base package. "logmon" and "logmon_MyConfigurationChanges" for instance. This way all the packages sort into the same geographic area in the UI.

    In the package itself, there's no place to put comments or change info. We create a tab in the package that has an OS specification that will never match (OS type Windows but OS selection of AS400 for instance) and then you can put a text file in that to contain your change log - ugly but it works.

    Use the dependency tab - there's no ability to search package content and so after a while it will become impossible to find all the places you might have made a specific setting which needs to be changed. We have 1200 packages for instance and keeping it straight is impossible. If a setting is only in one place and you use package dependencies to include that wherever it is needed then you only need to find the one location to make the change happen everywhere.

    That brings up one nigglling issue with package dependencies - they don't propagate. So if you have dependencies three layers deep, deploy the set of packages, then change the version number on one of the lowest tier packages and redeploy, nothing will happen. The top level package will get pushed out because you forced that manually but then the second layer of package versions will be checked and they will all match what was installed and so the third layer will never get evaluated to find the difference with the updated package. The obvious solution is that when you changed the version in the third layer, you need to change the version on the second layer package that includes that dependency. Again, ugly but you get used to it.

    The final comment on package is that people tend to thing of them containing the configuration. They do not. They contain the instructions on how to modify the existing system's configuration. So if you are only changing the log level of the cdm probe, you don't need the whole cmd config, just the <setup> section with one line loglevel = 5 in it: 

    <setup> overwrite
    loglevel = 5
    </setup>  

    And sections can repeat.

    And in case you didn't know the directives are "blank/nothing", overwrite, edit, and clear. 

     That all said, it you are not using MCS (we don't/can't) then when you edit packages in the archive, they just stay in the archive until you push them out. 

    So, when someone is making edits to an existing package we append _DONTUSE to the end of the package - Makes it obvious if someone is manually picking a package to deploy and won't match any of the dependencies in the existing packages. When it's tested and ready, just rename it.

    Because of the number of systems we manage we use scripts to deploy packages - you can look at the callbacks to the distsrv probe - job_add in particular.

    Hope this helps.

    -Garin