so you want to replace the entry in a config file w/ something like:
maxconnections = 100
maxconnections = 2 * ??CPU_COUNT??
I don't believe you can perform math inside the blpackage itself.
you could maybe do something like creating a custom property class that has properties for each of the settings you want. then create an instance of the class for each cpu count.
then create a local property in the blpackage that is of type propertyclass that points to your custom class. when you deploy the package you set the value of the class (# cpus).
that's one option... i'm not sure how dynamic we can make this
Thanks for the response...
I don't think that this would give me the desired functionality I am looking for. I don't thing I would gain the ability to logically decide which values to set, but it might.
Let me throw this your way...
Could I define local properties to for the BLPackage for each of the parameters that has to be set based on the # of CPUs, then run an nsh script at the begining of the package to calculate the values and populate the local properties of the BLPackage deploy job? These values could then be used later in the BLPackage to modify the config file?
I guess my question is...When do the local properties of a job get loaded? Are they loaded at the beginning when the job is initially started, or are they only loaded when referenced within the job/BLPackage? I guess if they are loaded at the start, this still doesn't solve my problem.
that may work - i don't think the properties get loaded until the blpackage starts to deploy, which shouldn't be until after the nsh job finishes modifying the package. unless when you run the batch job, we make a copy of everything right there, in which case this won't work.
so use the BlPackage.setLocalParameterDefaultValue in the nsh script to change the properties of the package before it gets deployed.
So, I think we are on the right track.
How would this play with deploying the package to several servers in parallel?
ah...that's going to be a problem because when the nsh job runs, it updates the package but then if another job runs, it updates the package again and could not set the right parameters.
dynamically setting the number is the problem i think. we might be able to do this better using a component template, a compliance job, and a bunch of blpackages.
the component template has rules that says "if CPU = n" then "setting = y"
each rule is tied to a blpackage that sets the setting (or group of settings) to y. so then you can do a 'remediation' that deploys the right package. but all your blpackages are pre-made, you have 1 for 1cpu, 2cpu, 4cpu, etc.
So, I thought of splitting the rules within the component template...
Currently it looks like
(CPU = n, setting = y) OR (CPU = m, setting = z)
If I split that into 2 different rules, wouldn't a compliance check always report non-compliance since one rule will always fail? Then, wouldn't that rule attempt to remediate, even if the part that failed was CPU = m NOT that the setting = z?
i think you'd say cpu !=n OR setting=y in each rule.
That sounds like it will work.
Let me try that...
I will post my results.
That worked like a champ! Outstanding!