11 Replies Latest reply on Mar 17, 2008 11:12 AM by Thomas Trias

    Parameterizing at different level then in the BL package

      Hi,

       

      I have a BL package and when I edit this package I can link the configuration entries (from a defined configuration file) to the values I defined in the local properties. In the local properties there is an instance of a set of properties I defined in the Custom Property Class in the property dictionary.

       

      My question is: I don't want to go into the BLPackage for editing every time I create a full or delta package. I would like to have the relationship between the configuration entries and the values set preferably once like for example in the component. The values for the configuration entries are defined in the

      Custom Property Class

      instance (two instances for QA and one instance for production).

       

      More info of what I did so far.

      - Created the definition of the configuration file in the Configuration Object Dictionary. The new config file is called xins1.conf and is based on nvp.gm

      - Created a subclass in the Custom Property Class for myapp1 and created a subclass in there for release1.0

      - Created an instance and defined all values for the release1.0 for QA1

      - in a component template

      -- Added directory containing the application to the items

      -- Added the configuration entries to the items

      - Created a component by executing a discovery on the component template

      - created a BL package from the component

      - Had to edit the BL package to set the new values for the configuration entries

       

      If for every new version full or delta the BL package has to be edited for all 2 stages we have there is a huge possibility that there will be an error by manually selecting a wrong value. The configuration file has 25+ entries.

       

      We run BL version 7.3.0.57

        • 1. Re: Parameterizing at different level then in the BL package

          Ideas, comments, questions anyone? All feedback is much appreciated.

          • 2. Re: Parameterizing at different level then in the BL package

            Hi Bert,

             

            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.

             

            Mark.

            • 3. Re: Parameterizing at different level then in the BL package

              Hi Mark,

               

              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.

              • 4. Re: Parameterizing at different level then in the BL package

                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!

                • 5. Re: Parameterizing at different level then in the BL package

                  So, is the path to the configuration file parameterised?

                  • 6. Re: Parameterizing at different level then in the BL package

                    like ??TOMCAT_DIR??/database.properties

                     

                    Mark.

                    • 7. Re: Parameterizing at different level then in the BL package

                      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?

                       

                      Mark.

                      • 8. Re: Parameterizing at different level then in the BL package

                        Hi Mark,

                         

                        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.

                        • 9. Re: Parameterizing at different level then in the BL package

                          Bert,

                           

                          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,

                           

                          Tom

                          • 10. Re: Parameterizing at different level then in the BL package

                            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.

                            • 11. Re: Parameterizing at different level then in the BL package

                              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.

                               

                              Thanks,

                               

                              Tom