Managing config files for many systems

[wrkcrw00]

This question is perhaps tangentially related to SystemLink. I'm using SL to deploy SW packages a bunch of systems. In a couple of cases, it's the same SW deployment to many copies of a system. The mass deployment of SL is great for this. However, each system requires it's own config file (there are a couple of unique pieces of data in the config file based on system). I'm fishing for ideas on how to manage so many config files. I see a couple of options, neither of which excites me. 

1) Create a package for each physical system that includes the deployment SW and the appropriate config file. Bummer about this is then I have to add every package to SL and deploy unique packages to each system. Cumbersome. 

2) Manually create, deploy, and update config files. Config files won't change very often...but they will change over time as I add features to the SW. This path is prone to mistakes and missed updates. It's 20 systems now, likely 50 by the end of the year and many have multiple config files. 

Ultimately, what I would like is to have one place I can manage the config files and deploy updates as they are released. The deployment should be automatic.

Ideas?

[JoshuaP]

 We don’t have a super eloquent solution right now.  We actually have a feature in our backlog to add “Application Configuration Support” to SystemLink.  Our backend is clearly capable of deploying and modifying configuration files, but need a new customizable application configuration view that can be added to the systems detail view.

You can certainly go the package route and create unique packages for each configuration file, but I agree that it could be a real headache to keep them all strait.

You could also do something with Tags and Dashboards or WebVIs.  When your application starts up create some tags with default values for your configuration if they don't already exist.  Then periodically read the configuration tag values to see if the last updated timestamp has changed.  If they have been updated restart you application loop or do whatever you need to to apply them.  In addition, create an interface using Dashboard Builder, a WebVI, or a LV desktop application for viewing and modifying the configuration via tags.

You could also use the SystemLink File service and API if you really wanted to stick with files.  Upload the configuration file using the File Viewer of LV Skyline File API and specify keywords or properties to define which systems they should apply to.  Then have each system use the LV Skyline File API to query using some sort of keyword/property filter for the configuration files for that system and then download the files locally to the target using the API as well.  The downside to the File API is you don't get a nice Dashboard or WebVI for modifying them.

[wrkcrw00]

I have to use files because we version control them. The idea of using SystemLink files API may work. I still intend to build a VI (web likely) to view the config files but I could extend that to deploying them based on station name or something like that. 

Well, I'll come up with something. I'll be interested to see what you guys cook up that might help this type of situation.

[JoshuaP]

I have to use files because we version control them.

---

That makes sense.  I'll try to keep that in mind when we come up with our solution. 

What source code control solution do you use (git, p4, TFS, etc.)?  Would you want a solution where the target just pulled the latest file directly out of source code control? 

I ask, because we are also looking at adding a user interface and workflow for git, which our Salt-based backend already supports.

• https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.git.html
• https://docs.saltstack.com/en/latest/ref/states/all/salt.states.git.html

[wrkcrw00]

We use SVN for all of the LabVIEW code. Many of the other software groups have moved to GIT. I would like to make that move, but we have 10 years of history in SVN for all the test system code. I've been sowing some seeds about moving to GIT for LabVIEW...

Direct integration with SCC would fall into the awesome category!

And for way more than just config files. Being able to draw packages from SCC TAGs and deploy them would be sweet. Right now it's a rather manual process - write code, test and verify, create builds and packages, dump into SCC, get approval, pull approved version out of SCC, upload to SystemLink, deploy. If I could setup deployments to pull from a specific tag, or the latest tag, or a set of tags based on what's needed for a system would be great. If you're interested we can PM about more details on how our process goes and how I as a user would like to interact with the system. 

[viScience]

Please add my vote for such a feature.  I have a similar use case where it would be nice to be able to download individual configuration files to a large collection of targets.

[Lab_It_Studio]

We also use SVN and it would be great is Sistem Lynk could have that direct connection feature.