Re: [Crowbar] Quantum fixes for Mesa-1.6 - Pebbles has similar issues
Le jeudi 01 août 2013, à 23:11 +0200, Vincent Untz a écrit : > Hi, > > Le jeudi 01 août 2013, à 09:05 -0500, john_terps...@dell.com a écrit : > > Vincent, > > > > The pull request Arkady mentioned on the community call this morning is: > > https://github.com/crowbar/barclamp-quantum/pull/108 > > This pull request does many different things. Would it be possible to > know the exact error we're trying to fix? (With logs :-)) Any news? It's hard to work on a fix if we don't know what the issue is. And it's really blocking everything since we don't merge pull requests because of this. FWIW, I don't think we're seeing any issues in quantum on SLES. But again, knowing the exact error would help know this :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
[Crowbar] Migration of proposals/roles on schema updates
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
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
Re: [Crowbar] Migration of proposals/roles on schema updates
Vincent Untz (vu...@suse.com) wrote: > 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. [snipped] Looks good to me except for the point I already made: > - 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). https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923 ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Migration of proposals/roles on schema updates
Le lundi 05 août 2013, à 12:39 +0100, Adam Spiers a écrit : > Vincent Untz (vu...@suse.com) wrote: > > 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. > > [snipped] > > Looks good to me except for the point I already made: > > > - 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). > > https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923 Ah, I had forgotten about that one :-) As the migration scripts will be provided by the barclamp, and most barclamps won't need more than one migration script per revision, such a requirement on the naming of the migration scripts is, imho, not needed. People can do it, but forcing this is a bit too much to my taste. Don't know how others feel, though? Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Migration of proposals/roles on schema updates
Vincent Untz (vu...@suse.com) wrote: > Le lundi 05 août 2013, à 12:39 +0100, Adam Spiers a écrit : > > Vincent Untz (vu...@suse.com) wrote: > > > 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. > > > > [snipped] > > > > Looks good to me except for the point I already made: > > > > > - 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). > > > > https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923 > > Ah, I had forgotten about that one :-) > > As the migration scripts will be provided by the barclamp, and most > barclamps won't need more than one migration script per revision, such a > requirement on the naming of the migration scripts is, imho, not needed. > People can do it, but forcing this is a bit too much to my taste. Don't > know how others feel, though? I agree it's not pretty. I was just worried about engineering ourselves into a corner with no obvious way out. If we were ever in a position where we originally thought only one script xxx_foo.rb would be required for a given (barclamp, revision) combination, and then we realised we needed more than one, and the order mattered, then I guess we could rename xxx_foo.rb to xxx_01_foo.rb before introducing xxx_02_bar.rb? ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Quantum fixes for Mesa-1.6 - Pebbles has similar issues
Vincent, Do you have the ability to run a smoketest on an Ubuntu deployment? Here is the condition that produces the failure: #> ./dev fetch && ./dev sync #> ./dev switch pebbles/openstack-os-build #> ./dev build --os Ubuntu-12.04 --test develop-mode When the admin node and the 4x compute nodes have fully deployed: #> ssh root@192.168.124.10 $> cd /opt/dell/bin $> smoketest swift When the swift deployment completes: $> smoketest tempest All Barclamps will deploy up to and including nova. The nova smoketest fails at the point of allocation of floating IPs. The problem is centered on the quantum deployment. Victor's patches solve the problem on Mesa-1.6, however the quantum code in Pebbles has significantly changed and we are still trying to identify the needed changes to enable to Allocation of floating IPs to proceed. If you can provide an upload address I can provide detailed log files. One full log collection is 70MB the other is 110MB. Please let me know how you wish to proceed. - John T. -Original Message- From: crowbar-bounces On Behalf Of Vincent Untz Sent: Monday, August 05, 2013 3:45 AM To: crowbar Subject: Re: [Crowbar] Quantum fixes for Mesa-1.6 - Pebbles has similar issues Le jeudi 01 août 2013, à 23:11 +0200, Vincent Untz a écrit : > Hi, > > Le jeudi 01 août 2013, à 09:05 -0500, john_terps...@dell.com a écrit : > > Vincent, > > > > The pull request Arkady mentioned on the community call this morning > > is: https://github.com/crowbar/barclamp-quantum/pull/108 > > This pull request does many different things. Would it be possible to > know the exact error we're trying to fix? (With logs :-)) Any news? It's hard to work on a fix if we don't know what the issue is. And it's really blocking everything since we don't merge pull requests because of this. FWIW, I don't think we're seeing any issues in quantum on SLES. But again, knowing the exact error would help know this :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/ ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Migration of proposals/roles on schema updates
Le lundi 05 août 2013, à 13:03 +0100, Adam Spiers a écrit : > Vincent Untz (vu...@suse.com) wrote: > > Le lundi 05 août 2013, à 12:39 +0100, Adam Spiers a écrit : > > > Vincent Untz (vu...@suse.com) wrote: > > > > 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. > > > > > > [snipped] > > > > > > Looks good to me except for the point I already made: > > > > > > > - 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). > > > > > > https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923 > > > > Ah, I had forgotten about that one :-) > > > > As the migration scripts will be provided by the barclamp, and most > > barclamps won't need more than one migration script per revision, such a > > requirement on the naming of the migration scripts is, imho, not needed. > > People can do it, but forcing this is a bit too much to my taste. Don't > > know how others feel, though? > > I agree it's not pretty. I was just worried about engineering > ourselves into a corner with no obvious way out. > > If we were ever in a position where we originally thought only one > script xxx_foo.rb would be required for a given (barclamp, revision) > combination, and then we realised we needed more than one, and the > order mattered, then I guess we could rename xxx_foo.rb to > xxx_01_foo.rb before introducing xxx_02_bar.rb? Sure, the names can be changed and things will still work perfectly fine. Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Quantum fixes for Mesa-1.6 - Pebbles has similar issues
Le lundi 05 août 2013, à 08:49 -0500, john_terps...@dell.com a écrit : > Vincent, > > Do you have the ability to run a smoketest on an Ubuntu deployment? I don't, but... (see below) [...] > All Barclamps will deploy up to and including nova. The nova smoketest fails > at the point of allocation of floating IPs. I've been running the beginning of the commands of the nova smoketest on my dev environment running on SLES, and things work fine here. I stopped after the snapshot-related commands because the smoketest script doesn't run on SLES and I had to manually replicate the commands; but the first calls related to floating IP part are earlier. Or was the issue in the later part of the smoketest that also plays with floating IPs? > The problem is centered on the quantum deployment. And again, I would ask: what is the exact issue? Does it just fail to allocate floating IPs? Is this because quantum is not running? Or is quantum running but failing to allocate floating IPs? Btw, you do not need to run smoketest from scratch every time to reproduce the issue, I guess. You could very well reproduce the issue from the OpenStack Dashboard, right? > Victor's patches solve the problem on Mesa-1.6, however the quantum code in > Pebbles has significantly changed and we are still trying to identify the > needed changes to enable to Allocation of floating IPs to proceed. > > If you can provide an upload address I can provide detailed log files. One > full log collection is 70MB the other is 110MB. > > Please let me know how you wish to proceed. I'm pretty sure you can remove most logs. As a first step, we really only need the logs from /opt/dell/crowbar_framework/log as well as maybe the logs from /var/log/quantum and /var/log/nova on all nodes. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
Re: [Crowbar] Quantum fixes for Mesa-1.6 - Pebbles has similar issues
Le lundi 05 août 2013, à 18:22 +0200, Vincent Untz a écrit : > Le lundi 05 août 2013, à 08:49 -0500, john_terps...@dell.com a écrit : > > The problem is centered on the quantum deployment. > > And again, I would ask: what is the exact issue? Does it just fail to > allocate floating IPs? Is this because quantum is not running? Or is > quantum running but failing to allocate floating IPs? Being completely blind on this issue, I tried to guess and submitted https://github.com/crowbar/barclamp-quantum/pull/109 But I have no idea if this fixes what's broken. Vincent -- Les gens heureux ne sont pas pressés. ___ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
