openstack team mailing list archive

["Dan Prince" <dan.prince@xxxxxxxxxxxxx>]

Jim,
 
Okay. I'm still a bit fuzzy on the order of operations we'd need to make in order to get branch in when a config file changes.
 
Take this review for example:
 
 https://review.openstack.org/#change,2919
 
Based on what I understand devstack needs to support both version of the nova config file in order for the branches to land smoothly? That seems like something we wouldn't want to do. Am I misunderstanding something?
 
Also, in order to coordinate these types of changes shouldn't all core members on gated projects have core privileges on devstack as well? This would allow us to coordinate making these types of changes?
 
Dan


-----Original Message-----
From: "James E. Blair" <corvus@xxxxxxxxxxxx>
Sent: Wednesday, January 4, 2012 12:09pm
To: "OpenStack Mailing List" <openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Integration test gating on trunk



"Dan Prince" <dan.prince@xxxxxxxxxxxxx> writes:

> Hi Jim,
>  
> A couple of questions for you:
>  
> 1) You mentioned how to coordinate changes between glance and nova but
> what about devstack. Does that same process apply to devstack as well?
> For example if there were a configuration file change (api-paste
> changes often and can cause failures) would I push the required change
> to devstack first and then nova? Or would we need to make devstack
> handle multiple versions of the configuration files?

Yes, the same is true for coordinating changes across all of the
projects, including devstack (one change at a time in sequence).

> 2) Where are the devstack instances running (public cloud, private
> Openstack cloud, etc.). If the public cloud is down for maintenance
> does that mean code can't land? Are there any plans to run this on a
> private or OpenStack backed cloud? Regardless of what we are doing is
> there a backup plan in place so that code can land?

They are currently running in the Rackspace public cloud.  There is a
cache of N machines (N==5 currently) running and ready to receive
devstack installs for this test, with new ones being added by a frequent
Jenkins job[1] to replace those consumed.  That helps smooth over
operational errors and short outages.  If all of those are consumed, the
job will fail, and we won't be able to land patches.  Considering the
importance of RS public cloud availability, I think that waiting until
it's up again is probably going to be a viable option.  If there is some
sort of extended outage, we can discuss disabling the job.

In the medium to long term, we plan on mitigating this risk by consuming
VMs from multiple cloud providers.  HP has offered its public cloud for
this purpose.  I'd like the normal mode of operation to launch VMs on
both (all?) of the cloud providers participating to balance load and
resource usage, and of course that gets us higher availability, at least
for the kind of scenario you described.

> 3) Are there any plans on making this run on branches in merge prop
> (before we approve them)? I would love to know that devstack passes
> ahead of time before I approve a branch.

Yes, running tests when patchsets are uploaded is in the plan.  With the
new gerrit trigger plugin we installed last week, we have the technical
capability to run Jenkins jobs on proposal, approval, or merge.  I
believe we will start working on that soon, after we address some
security concerns.

-Jim
[1] https://jenkins.openstack.org/job/devstack-launch-vms/

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp