This post is like a bonus one aka. how you could optimize your OSDCloud daily jobs.
On the top of the previous blog series posts. It’s about changing the OSDCloud scripts more centralised, either to change the OSDPad profiles one by one.
All of our customers are using more than one OSDCloud profile:
- They want to use different naming conventions for the devices.
- They want to use different Autopilot profiles.
- They want to use different Autopilot settings.
- They want to have some OSD testing scenarios, like OS and driver tests.
If we have the script structure, like in these ones, and we want to change and extend some function, we need to copy these changes all over the other scripts. To make failures on that way, the probability is quite high.
So, we’ve decided to build a separate and central module for each of our customers where we can manage all of the OSDCloud logic and script structure. This module can be placed as a secure gist and can be imported into the OSDPad scripts.
You can find some examples in this GitHub folder: here the customer wanted to have different computer prefixes. “BE” for computers in Bern and “ZH” for the Zurich ones. The logic for this request has been integrated into this module and the OSDPad script will be called with the computer prefix parameter from this OSDLogic module. So in this case, the Autopilot import will be done with the correct computer names.
On that way, you can think about the next possibility: why are you using different OSDPad files? These changes, you can “outsource” and use parameters for a central module. Like we did with computer prefixes.
Summary
This post is definitely not a rocket science one. But in these days, you should prevent to do these kind of periodical tasks. I hope this method can help the #OSDCloud community to standardize the OSDPad scripts.
Happy OSDClouding!