Ideas, comments, questions anyone? All feedback is much appreciated.
I'm not sure exactly what you are trying to achieve, but if you have
1. A component template that defines all the config items you are interested in (parameterised against local properties)
2. A component for each combination of server / property setting that you have.
Then you should be able to create a package from a component that inherits the local property settings defined for the component, without having to re-set the properties.
So, if you have a release1.0 component, then you should be able to create a release1.0 package from that component without changing any properties.
If I don't understand the problem correctly, let me know.
Thanks for your reply. What I try to achieve is to have a configuration file (of type nvp.gm) have different values for different stages. A different stage is a different server like QA and Production.
Trying your suggestion to use the local properties at the component template level results in error in the BL-Package:
- I added the property definition (not the instance) at the local properties part of the component template.
- I added 1 configuration entry parameterized based on the just added property. This results in a warning, but that should be ignored I was told.
- The component was discovered on the development server.
- The now created component is used to create the BLPackage.
- When looking into the Creation log of the properties of the BLPackage the message is: "Warning 05/29/2007 15:30:50 Server Config Definition Object Not Found"
- When looking into the package the configuration entry is not there at all.
I expected to get a BLPackage and when deploying this package the configuration entry should have been set to the value defined in the property definition at the local properties part of the component template.
Can you point me in the right direction as I did something wrong here.
In my next attempt I do the same as stated above with the one change.
- I added the property definition and now also the instance at the local properties part of the component template.
Exactly the same result. The BLPackage complains like: "Warning 05/29/2007 16:37:15 Server Config Definition Object Not Found"
And the configuration entry is not in the BLPackage.
What am I doing wrong here?
Any suggestions, question etc are welcome!
So, is the path to the configuration file parameterised?
It sounds like the config file location cannot be found.
I tried to replicate what you did.
I created three name=value files: /c/dir1/a.properties, /c/dir2/a.properties, /c/dir3/a.properties
First of all, I created a component template, and added a string local property APP_DIR and 3 instances APP_1, APP_2 and APP_3 pointing to /c/dir1, /c/dir2 and /c/dir3. I added the file ??APP_DIR??/a.properties as a file.
I created 3 components on one server, and then created a package from each of these. In all cases, the blpackage was created automatically, containing the property value for APP_DIR embedded within it.
I then did a similar thing for a config file.
In this case, you have to first create three entries in the config object dictionary for each possible location of a.properties. This is a bit of a pain, but is made easier with 7.2,7.3's ability to copy these config files.
Once again this worked fine, although I got the error message:
"No match for the file '??APP_DIR??/a.properties' can be found in Configuration File Administration. This part may be invalid if noassociated grammar can be determined.
Do you want to continue?"
This is OK, as we happen to know that APP_DIR will be correctly defined.
Just as in the last case, the package is created with the correct value for the local property APP_DIR.
Does this accurately reflect what you were trying to do?
Thanks for the quick response and the examples! Unfortunately this is not what I want to achieve. I know how to fiddle with the directory structure to a file/directory.
What I want to do is set the values of "key value pairs" inside a configuration file.
The following would define the configuration file to suit my needs:
In your example I would expect only one configuration file, let's call it /c/dir1/a.properties
a.properties would need to be defined in the Configuration Object Dictionary.
a.properties is defined as type nvp.gm
Now the question is how to create a BLPackages that has different "key value pairs" inside a.properties for different target machines. Where target machines are QA and production, so one BLPackage for each of the two target types.
Note: the location (path) to a.properties can (and is in my case) the same for all servers.
Did using parameterized values from the target Server work, e.g. ??TARGET.RELEASE_LEVEL?? or ??TARGET.CUSTOM_CLASS.RELEASE_LEVEL?? in the Value property of the CONFIGKEY node? That's what I ended up having to do.
However, that does raise two points that we've brought with support:
1) How / why can't one easily reference Component properties (not Server Properties) in a BLPackage (especially one created from a Component Template); Maybe we should be able to target Components from Deploy Jobs?
2) Why can't you include / exclude values / paths from a configuration file in a Component Template?
As far as mandating values for configuration entries in a Component Template, your best bet is to setup Compliance rules that test the values; remediation becomes trickier if the values aren't defined at the server level as well...
Hope that helps,
Using the property dictionary for a large amount or complex packages is a dead end in my experience. I've tried various ways to store configuration items in Bladelogic. That, in itself, is no problem at all. Managing and using the configuration items is a total pain.
I ended up with storing configuration items in a CVS and building BlPackages from snapshots and CVS exports using BLCLI. Now I'm able to manage and maintain the packages including having automated deploy batch jobs that stop the audit of an old package and deploy, snapshot and audit the new version.
Managing the configuration items and server settings is all done in plain test files stored and maintained by a CVS repository.
I will have to check out doing something similar; I've just starting exporting BLPackages and storing them in our SubVersion repository. I found that the only reliable way I could easily update files in a BLPackage (we've had some issue with soft-linked Depot Files) is to import the package after modifying the appropriate hash-keyed file.