StefanS

Nimsoft Packagemanagmenet

Discussion created by StefanS on Aug 12, 2014
Latest reply on Aug 13, 2014 by 1_keithk

Hi nimsoft users,

I'd like to know what you think of the current package editor / configuration management. We currently use the package editor to build packages that basically consist of two sections:

  1. a dependency to the real probe package
  2. one or more section for each OS we want to support with the package

But in my opinion these configuration packages have multiple issues:

When changed? You don't know when a package was last updates (unless you check the modification time at OS level), so if anyone complains that something is not working anymore, I have no idea to correlate that to possible changes on the package What changed? If you make changes to a package and only increase the build number all old versions are lost. Who changed? Sometimes it would be nice to know which person changed a cfx file Why changed? This is in my opinion the most important one. The description does only allow a few letters but not a whole documentation about the purpose of the package. Also it's hard to tell why a specific *.cfx file has been changed. Some people may also like to link a change in a cfx file with a Change Request ID

While nimsoft could offer a proper version control system for packages, I'd prefer nimsoft to open up the package format. What I mean by that is, I'd like to place a *.cfx file in a directory together with meta-information like package author, dependencies, etc and have a way to build a package from that. I suppose if you own the password to the ZIP archives, you'll be able to build your own packages already. In my opinion these would make our lives easier, because

  1. If you already have a VCS like SVN or git you can just stick to your favorite tool and not have to learn something new. In general I think it is a bad idea to try to build your own VCS if stuff like SVN or git already exist
  2. It would make it a lot easier to build packages, because you can use a proper editor (the nimsoft editor has basically zero usability)
  3. It should be fairly easy for nimsoft to open up the packacke building (a lot easier than implementing their own version control system at least)
  4. You may be able to build configuration packages on the fly or with input from other sources (e.g. from a database that already holds inventory data or an external service you can provide to your customers, for example a Web interface to define ntevl exclude rules that automatically build a new ntevl config and package

What do you think of the idea? Do you use solely the package editor or do you have an external source where you keep all your configuration files? Would you like to be able to build your configuration through external means (outside the nimsoft package editor)?

Outcomes