Hi, A few weeks ago, I started the work on allowing schema changes in pebbles, without breaking existing proposals. In short, there's a migration rake task that will update the proposal (and its matching role, if committed) to the updated schema.
The need for this stems from the fact that we might very well add required attributes to schemas during the pebbles lifecycle (to allow setting some configuration option in an openstack config file, for instance), and we cannot tell people to recreate a new proposal to get this. Their existing setup must continue to work. With the patch, you can do the following: rake crowbar:schema_migrate_prod[keystone nova] and this will do all the migration magic for keystone and nova. If you just run "rake crowbar:schema_migrate_prod", it will migrate all proposals. It's worth mentioning that it has absolutely no impact on anything else so far because it doesn't touch the code that crowbar uses when running. It simply adds a rake task for now. The missing piece is to find when to run this rake task -- I'm considering adding this to the crowbar init script, or simply letting the rpm packages do this. All the details about how it works is in https://github.com/crowbar/barclamp-crowbar/pull/613 Here's a paste of the pull request description: ============================== There are two new tasks: - crowbar:schema_migrate -- this migrates data bags / roles to the current revision of the schema - crowbar:schema_migrate_prod -- this is a convenience wrapper task to call crowbar:schema_migrate with the production environment By default, this will migrate data bags / roles for all barclamps. It's possible to restrict this to one or several barclamps: ``` rake crowbar:schema_migrate_prod[nova] rake crowbar:schema_migrate_prod[keystone nova] ``` The migration works the following way: - it supports upgrades and downgrades. - schemas supporting migration must have a schema-revision int attribute in the deployment part; the template will contain the version of the schema revision in this attribute. (Reason this is in the deployment part: this will be available in the committed role too) - there are migration scripts in /opt/dell/chef/data_bags/crowbar/migrate/$barclamp/. The scripts must be named $rev_$somedescription.rb; the filename can have 0 (001_foobar.rb will work as well as 1_foobar.rb). There can be multiple scripts per revision; they will be executed by alphabetical order (or reverse alphabetical order in case of downgrades). - a script can provide two functions (they are optional): - an upgrade function - a downgrade function The functions must take as parameters: - the barclamp attributes of the template - the barclamp deployment information of the template - the barclamp attributes of the proposal / role - the barclamp deployment information of the proposal / role The functions must return: - the updated barclamp attributes of the proposal / role - the updated barclamp deployment information of the proposal / role We are explicitly restricting acces to the barclamp attributes and barclamp deployment information to forbid the migration scripts to change anything outside of the perimeter of each barclamp. As an example, for nova, we could have /opt/dell/chef/data_bags/crowbar/migrate/nova/001_add_vuntz_attribute.rb with the following content: ```ruby def upgrade ta, td, a, d a['vuntz'] = ta['vuntz'] return a, d end def downgrade ta, td, a, d a.delete('vuntz') return a, d end ``` This will update the attributes.nova.vuntz attribute in the proposal data bag, and the default_attributes.nova.vuntz attribute in the role. ============================== Any comment? Vincent -- Les gens heureux ne sont pas pressés. _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
