Re: [Openstack] Glance, libvirt/kvm snapshots

[Ahmed El Gamil]

Hi Guys,

So The guys over at IRC convinced me that posting that to the mailing list
would be cooler to solve/discuss, so don't let me down :).

Basically i'm working on launching an instance via the openstack API, using
the Bexar release and the python-novatools (the novatools command), The
hypervisor is KVM and Glance is used for
Imaging(image_service=nova.image.glance.GlanceImageService).

After using the boot subcommand in novatools, the instance is marked as
"build" and i get the following errors in the logs:

 2011-02-16 09:23:23,535 ERROR nova.compute.manager [F--YCJOZ14LY9LTFHYH1
> c9er openstack] instance 7: Failed to spawn
> (nova.compute.manager): TRACE: Traceback (most recent call last):
> (nova.compute.manager): TRACE:   File
> "/usr/lib/pymodules/python2.6/nova/compute/manager.py", line 211, in
> run_instance
> (nova.compute.manager): TRACE: self.driver.spawn(instance_ref)
> (nova.compute.manager): TRACE:   File
> "/usr/lib/pymodules/python2.6/nova/exception.py", line 122, in _wrap
> (nova.compute.manager): TRACE: raise Error(str(e))
> (nova.compute.manager): TRACE: Error: Unexpected error while running
> command.
> (nova.compute.manager): TRACE: Command: /usr/bin/curl --fail --silent
> http://:/_images/2/image -H 'Date: Wed, 16 Feb 2011
> 14:23:23 GMT' -H 'Authorization: AWS
> ba97af70-24cf-4054-9185-ecf925d71385:openstack:sIAZBh7GJ7dE8urnZhvwla7upgY='
> -o /var/lib/nova/instances/_base/2
> (nova.compute.manager): TRACE: Exit code: 22
> (nova.compute.manager): TRACE: Stdout: ''
> (nova.compute.manager): TRACE: Stderr: ''
> (nova.compute.manager): TRACE:
> libvir: QEMU error : Domain not found: no domain with matching name
> 'instance-0007'
>

ttx on IRC told me that it shouldn't fetch a : URL, but that was fixed
in a bug at https://bugs.launchpad.net/nova/+bug/708673

Any hints on what could cause that ? did anybody work with novatools against
kvm/glance ?

Thanks in advance.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Review days for nova-core members

[Thierry Carrez]

Paul Voccio wrote:
> Not sure what the etiquette is for removing someone. Michael Gundlach is
> still listed but is no longer participating. 

There is no process proposed/decided for removing someone from a core team.

At this point people that are no longer involved day-to-day with the
project and code reviews should step down considerately, so that the
team reflects active reviewers.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Brian Schott]

One thing we saw in the list and experienced first hand is that your Hudson 
server uses a pre-configured environment and ours pulls virtual env every time. 
 We had failures on trunk that yours missed because of new pip pulled versions.

A fresh run_tests.sh -f needs to work.  It is the only guaranteed sanity test 
everybody can replicate.  It might pull upstream bugs, but better to be ahead 
of that curve than behind.

We are now triggering on trunk commit emails and running Hudson on both trunk 
and our hpc-trunk.  We can forward to a list or autogenerate bug report 
somehow.  

Suggestions:
1. Let other teams setup their own trunk Hudson servers with preferred configs 
(os, virt, db, net) and doc how to forward results up (new list?). This way you 
quickly find commits that break mysql or Xen before you forgot what you did.
2. Jay already listed my other suggestions...

Sent from my iPhone

On Feb 16, 2011, at 11:44 PM, Paul Voccio  wrote:

> Jay,
> 
> Thanks for throwing this out. How would we build this with Hudson? What
> would a "standard deploy" of Nova even look like for integration tests?
> We've also bounced the idea within our team of not allowing code commits
> if the code to test ratio decreases but I'm not sure if that would work
> for such a large project like this one.
> 
> pvo
> 
> On 2/16/11 4:27 PM, "Jay Pipes"  wrote:
> 
>> Hey all,
>> 
>> It's come to my attention that a number of folks are not happy that
>> Nova's trunk branch (lp:nova) is, shall we say, "less than stable". :)
>> 
>> First, before going into some suggestions on keeping trunk more
>> stable, I'd like to point out that trunk is, by nature, an actively
>> developed source tree. Nobody should have an expectation that they can
>> simply bzr branch lp:nova and everything will magically work with a)
>> their existing installations of software packages, b) whatever code
>> commits they have made locally, or c) whatever specific
>> hypervisor/volume/network environment that they test their local code
>> with. The trunk branch is, after all, in active development.
>> 
>> That said, there's *no* reason we can't *improve* the relative
>> stability of the trunk branch to make life less stressful for
>> contributors.  Here are a few suggestions on how to keep trunk a bit
>> more stable for those developers who actively develop from trunk.
>> 
>> 1) Participate fully in code reviews. If you suspect a proposed branch
>> merge will "mess everything up for you", then you should notify
>> reviewers and developers about your concerns. Be proactive.
>> 
>> 2) If you pull trunk and something breaks, don't just complain about
>> it. Log a bug immediately and talk to the reviewers/approvers of the
>> patch that broke your environment. Be constructive in your criticism,
>> and be clear about why the patch should have been more thoroughly or
>> carefully reviewed. If you don't, we're bound to repeat mistakes.
>> 
>> 3) Help us to write functional and integration tests. It's become
>> increasingly clear from the frequency of breakages in trunk (and other
>> branches) that our unit tests are nowhere near sufficient to catch a
>> large portion of bugs. This is to be expected. Our unit tests use
>> mocks and stubs for virtually everything, and they only really test
>> code interfaces, and they don't even test that very well. We're
>> working on adding functional tests to Hudson that will run, as the
>> unit test do, before any merge into trunk, with any failure resulting
>> in a failed merge. However, we need your help to create functional
>> tests and integration tests (tests that various *real* components work
>> together properly).  We also need help writing test cases that ensure
>> software library dependencies and other packaging issues are handled
>> properly and don't break with minor patches.
>> 
>> 4) If you have a specific environment/setup that you use (Rackers and
>> Anso guys, here...), then we need your assistance to set up test
>> clusters that will pull trunk into a wiped test environment and ensure
>> that a series of realistic calls to the Nova API are properly handled.
>> I know some of you are working on getting hardware ready. We need help
>> from the software teams to ensure that these environments are
>> initialized with the exact setups you use.
> 
> Still working on this. We're hoping to have something built out in the
> next couple of weeks. Man, someone should write some hardware emulation
> stuff so I don't have to wait on real gear. ;)
> 
>> 
>> The more testing we fire off against each potential merge into trunk,
>> and the more those tests are hitting real-life deployment
>> environments, the more stable trunk will become and the easier your
>> life as a contributor will be.
>> 
>> Thanks in advance for your assistance, and please don't hesitate to
>> expand on any more suggestions you might have to stabilize trunk.
>> 
>> -jay
>> 
>> ___
>> Mailing list: https://launchp

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Paul Voccio]

Jay,

Thanks for throwing this out. How would we build this with Hudson? What
would a "standard deploy" of Nova even look like for integration tests?
We've also bounced the idea within our team of not allowing code commits
if the code to test ratio decreases but I'm not sure if that would work
for such a large project like this one.

pvo

On 2/16/11 4:27 PM, "Jay Pipes"  wrote:

>Hey all,
>
>It's come to my attention that a number of folks are not happy that
>Nova's trunk branch (lp:nova) is, shall we say, "less than stable". :)
>
>First, before going into some suggestions on keeping trunk more
>stable, I'd like to point out that trunk is, by nature, an actively
>developed source tree. Nobody should have an expectation that they can
>simply bzr branch lp:nova and everything will magically work with a)
>their existing installations of software packages, b) whatever code
>commits they have made locally, or c) whatever specific
>hypervisor/volume/network environment that they test their local code
>with. The trunk branch is, after all, in active development.
>
>That said, there's *no* reason we can't *improve* the relative
>stability of the trunk branch to make life less stressful for
>contributors.  Here are a few suggestions on how to keep trunk a bit
>more stable for those developers who actively develop from trunk.
>
>1) Participate fully in code reviews. If you suspect a proposed branch
>merge will "mess everything up for you", then you should notify
>reviewers and developers about your concerns. Be proactive.
>
>2) If you pull trunk and something breaks, don't just complain about
>it. Log a bug immediately and talk to the reviewers/approvers of the
>patch that broke your environment. Be constructive in your criticism,
>and be clear about why the patch should have been more thoroughly or
>carefully reviewed. If you don't, we're bound to repeat mistakes.
>
>3) Help us to write functional and integration tests. It's become
>increasingly clear from the frequency of breakages in trunk (and other
>branches) that our unit tests are nowhere near sufficient to catch a
>large portion of bugs. This is to be expected. Our unit tests use
>mocks and stubs for virtually everything, and they only really test
>code interfaces, and they don't even test that very well. We're
>working on adding functional tests to Hudson that will run, as the
>unit test do, before any merge into trunk, with any failure resulting
>in a failed merge. However, we need your help to create functional
>tests and integration tests (tests that various *real* components work
>together properly).  We also need help writing test cases that ensure
>software library dependencies and other packaging issues are handled
>properly and don't break with minor patches.
>
>4) If you have a specific environment/setup that you use (Rackers and
>Anso guys, here...), then we need your assistance to set up test
>clusters that will pull trunk into a wiped test environment and ensure
>that a series of realistic calls to the Nova API are properly handled.
>I know some of you are working on getting hardware ready. We need help
>from the software teams to ensure that these environments are
>initialized with the exact setups you use.

Still working on this. We're hoping to have something built out in the
next couple of weeks. Man, someone should write some hardware emulation
stuff so I don't have to wait on real gear. ;)

>
>The more testing we fire off against each potential merge into trunk,
>and the more those tests are hitting real-life deployment
>environments, the more stable trunk will become and the easier your
>life as a contributor will be.
>
>Thanks in advance for your assistance, and please don't hesitate to
>expand on any more suggestions you might have to stabilize trunk.
>
>-jay
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


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

Re: [Openstack] Steps that can help stabilize Nova's trunk

[Matt Dietz]

These are all great points Jay.

I'd like to re-echo the comment about unit tests. Obviously they aren't
the panacea, but they can protect against some of the dumber errors that
have made their way into trunk. One particular bug stopped one developer
on my team dead in his tracks, and it ended up being a semi-colon in place
of a colon. There's a lot of utility in simply "exercising" code...

I think we may want to consider everyone's favorite topic of code coverage
as well in all of this. Specifically, we may want to take note of code
coverage on any given merge, and if subsequent merges reduce that number,
we throw a fit/reject the patch. I know that won't be a popular solution,
but it would definitely put a stop to the lack of unit tests.

On 2/16/11 4:27 PM, "Jay Pipes"  wrote:

>Hey all,
>
>It's come to my attention that a number of folks are not happy that
>Nova's trunk branch (lp:nova) is, shall we say, "less than stable". :)
>
>First, before going into some suggestions on keeping trunk more
>stable, I'd like to point out that trunk is, by nature, an actively
>developed source tree. Nobody should have an expectation that they can
>simply bzr branch lp:nova and everything will magically work with a)
>their existing installations of software packages, b) whatever code
>commits they have made locally, or c) whatever specific
>hypervisor/volume/network environment that they test their local code
>with. The trunk branch is, after all, in active development.
>
>That said, there's *no* reason we can't *improve* the relative
>stability of the trunk branch to make life less stressful for
>contributors.  Here are a few suggestions on how to keep trunk a bit
>more stable for those developers who actively develop from trunk.
>
>1) Participate fully in code reviews. If you suspect a proposed branch
>merge will "mess everything up for you", then you should notify
>reviewers and developers about your concerns. Be proactive.
>
>2) If you pull trunk and something breaks, don't just complain about
>it. Log a bug immediately and talk to the reviewers/approvers of the
>patch that broke your environment. Be constructive in your criticism,
>and be clear about why the patch should have been more thoroughly or
>carefully reviewed. If you don't, we're bound to repeat mistakes.
>
>3) Help us to write functional and integration tests. It's become
>increasingly clear from the frequency of breakages in trunk (and other
>branches) that our unit tests are nowhere near sufficient to catch a
>large portion of bugs. This is to be expected. Our unit tests use
>mocks and stubs for virtually everything, and they only really test
>code interfaces, and they don't even test that very well. We're
>working on adding functional tests to Hudson that will run, as the
>unit test do, before any merge into trunk, with any failure resulting
>in a failed merge. However, we need your help to create functional
>tests and integration tests (tests that various *real* components work
>together properly).  We also need help writing test cases that ensure
>software library dependencies and other packaging issues are handled
>properly and don't break with minor patches.
>
>4) If you have a specific environment/setup that you use (Rackers and
>Anso guys, here...), then we need your assistance to set up test
>clusters that will pull trunk into a wiped test environment and ensure
>that a series of realistic calls to the Nova API are properly handled.
>I know some of you are working on getting hardware ready. We need help
>from the software teams to ensure that these environments are
>initialized with the exact setups you use.
>
>The more testing we fire off against each potential merge into trunk,
>and the more those tests are hitting real-life deployment
>environments, the more stable trunk will become and the easier your
>life as a contributor will be.
>
>Thanks in advance for your assistance, and please don't hesitate to
>expand on any more suggestions you might have to stabilize trunk.
>
>-jay
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpa

Re: [Openstack] Review days for nova-core members

[Paul Voccio]

Not sure what the etiquette is for removing someone. Michael Gundlach is still 
listed but is no longer participating.

pvo

From: Joshua McKenty mailto:j...@piston.cc>>
Date: Wed, 16 Feb 2011 16:51:56 -0800
To: Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: Soren Hansen mailto:so...@ubuntu.com>>, Jay Pipes 
mailto:jaypi...@gmail.com>>, 
"openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Review days for nova-core members

Yup - we approved a new process for adding team members to core a few weeks 
ago, I haven't seen any applications yet but I may have missed one.

Joshua

On Wed, Feb 16, 2011 at 4:28 PM, Paul Voccio 
mailto:paul.voc...@rackspace.com>> wrote:
Have we considered pruning and expanding the core team to help speed the
reviews along? There are some people who are no longer day-to-day active
in Nova and some that are that could help in this process.

On 2/16/11 3:54 PM, "Soren Hansen" mailto:so...@ubuntu.com>> 
wrote:

>2011/2/16 Jay Pipes mailto:jaypi...@gmail.com>>:
>> Lots of coding and bug fixing has been done in the past weeks. As a
>> result, we've got a big backlog of code reviews to do.
>>
>> If you have some cycles, please do participate:
>>
>> https://code.launchpad.net/nova/+activereviews
>>
>> Nova-core members, remember, it's you responsibility to do code
>>reviews! :)
>
>Yes!
>
>I've considered if nova-core people should take turns in having a review
>day.
>Their top priority for the day should be doing branch reviews and bug
>triaging.  Anything else that day would be second to this.  Every member
>of
>the team should be part of the rotation. The only member of nova-core
>exempt from this responsibility would be Jenkins. :)  f you cannot accept
>this
>responsibility, you don't get to be a member of the team. Of course
>there has to be room for holiday and being ill, but every day, people
>should know who they can bug for reviews and members of the team should
>generally be available for this rotation.
>
>The goal is to ensure that we don't drop good work on the floor due to
>bitrot and to distribute the review load better than we do now.
>
>
>--
>Soren Hansen
>Ubuntu Developerhttp://www.ubuntu.com/
>OpenStack Developer http://www.openstack.org/
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : 
>openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


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



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Sandy Walsh]

Thanks for the feedback Soren.

I agree that caching can be error prone. When I first read your email I started 
to panic that we were taking the wrong tack. But, the more I think about it, 
it's probably not that bad.

For basic routing operations, I *think* the caching should be fine. 

"Do you have any instances for customer X?"
"Do you have GPU-based hosts?"
"Are you in North America?"
"Do you have Ubuntu 10.10 images?"

These capabilities are largely static, so caching should be fine. 

But at provisioning time, we need to bypass the cache and go direct to the 
zone. Particularly the create_volume() and create_instance() operations. Then, 
we need to go to each child zone and ask things like:

"Do you have 512M ram, 20G disk and 300GB bandwidth available now?"

Or, am I over-simplifying this scenario?

-S



From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Eric Day [e...@oddments.org]
Sent: Wednesday, February 16, 2011 6:21 PM
To: Soren Hansen
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

Good points Soren, and this is why I was suggesting we not solve this
problem with a cache, but instead an eventually consistent replication
stream of the aggregate data.

-Eric

On Wed, Feb 16, 2011 at 11:12:50PM +0100, Soren Hansen wrote:
> 2011/2/16 Ed Leafe :
> > This was one of the issues we discussed during the sprint planning. I 
> > believe (check with cyn) that the consensus was to use a caching strategy 
> > akin to DNS: e.g., if zone A got a request for instance ID=12345, it would 
> > check to see if it had id 12345 in its cache. If not, it would ask all of 
> > its child nodes if they knew about that instance. That would repeat until 
> > the instance was found, at which point every upstream server would now know 
> > about where to reach 12345.
>
> Has any formal analysis been done as to how this would scale?
>
> I have a couple of problems with this approach:
>
>  * Whenever I ask something for information and I get out-of-date,
> cached data back I feel like I'm back in 2003. And 2003 sucked, I
> might add.
>  * Doesn't this caching strategy only help if people are asking for
> the same stuff over and over? It doesn't sound very awesome if 100
> requests for new stuff coming in at roughly the same time causes a
> request to be sent to every single compute node (or whereever the data
> actually resides). I'm assuming breadth-first search here, of course.
>
>
> --
> Soren Hansen
> Ubuntu Developerhttp://www.ubuntu.com/
> OpenStack Developer http://www.openstack.org/
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


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

Re: [Openstack] Review days for nova-core members

[Paul Voccio]

Have we considered pruning and expanding the core team to help speed the
reviews along? There are some people who are no longer day-to-day active
in Nova and some that are that could help in this process.

On 2/16/11 3:54 PM, "Soren Hansen"  wrote:

>2011/2/16 Jay Pipes :
>> Lots of coding and bug fixing has been done in the past weeks. As a
>> result, we've got a big backlog of code reviews to do.
>>
>> If you have some cycles, please do participate:
>>
>> https://code.launchpad.net/nova/+activereviews
>>
>> Nova-core members, remember, it's you responsibility to do code
>>reviews! :)
>
>Yes!
>
>I've considered if nova-core people should take turns in having a review
>day.
>Their top priority for the day should be doing branch reviews and bug
>triaging.  Anything else that day would be second to this.  Every member
>of
>the team should be part of the rotation. The only member of nova-core
>exempt from this responsibility would be Jenkins. :)  f you cannot accept
>this
>responsibility, you don't get to be a member of the team. Of course
>there has to be room for holiday and being ill, but every day, people
>should know who they can bug for reviews and members of the team should
>generally be available for this rotation.
>
>The goal is to ensure that we don't drop good work on the floor due to
>bitrot and to distribute the review load better than we do now.
>
>
>-- 
>Soren Hansen
>Ubuntu Developerhttp://www.ubuntu.com/
>OpenStack Developer http://www.openstack.org/
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Jorge Williams]

I like idea of scheduling actions overall.  The idea of a generic scheduling 
service also appeals to me a lot.  The question is how do you generalize the 
service.  I'd love to see your write up.
-jOrGe W.


On Feb 16, 2011, at 4:35 PM, Adrian Otto wrote:

Glen,

I definitely recognize the value in having scheduling capability. I wrote a 
high level draft of a REST API for a generic scheduler to be used for batch job 
processing. Scheduled events are discussed regularly by users of queue systems 
that want certain things to happen on regular intervals. Considering that a 
scheduler function is useful, and could be used for many different services 
within the OpenStack system, I suggest thinking about a separate service that's 
dedicated to executing scheduled jobs that may need to interact with multiple 
services within OpenStack. This way it could be used to act upon not only 
/severs, but any other resource(s) in any service(s). Imbedding the 
functionality within nova is probably an architectural mistake. Filing a 
blueprint for a separate scheduler service sounds like a good idea.

Adrian

On Feb 16, 2011, at 2:02 PM, Glen Campbell wrote:

The proposed compute API 1.1 has a specification for server actions (Sec. 4.4) 
with the endpoint:

   /servers/{id}/action

The actual action is specified as the body of the POST request, and the 
implication is that the action is performed immediately, or as soon as possible.

I'd like us to consider changing this "action" resource into a "calendar" or 
perhaps "schedule" resource:

   /servers/{id}/schedule{/year{/month{/day{/hour{/minute}

This would provide a generalized way of performing actions on a scheduled basis.

For example, instead of having to wake up at 2AM to reboot a server (for 
whatever reason), the administrator could schedule that event:

   /servers/{id}/schedule/2011/2/17/02/00

By using the default resource (without the day or time specified), the meaning 
would be synonymous with the proposed "/action" resource; i.e., perform it NOW, 
or as soon as possible.

The schedule resource could have additional uses; for example, a GET request 
could return the currently-scheduled actions for a particular server.

Glen


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


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


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


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

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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Ed Leafe]

On Feb 16, 2011, at 5:11 PM, Michael Mayo wrote:

> I like this idea, but I would suggest going with a unix timestamp in GMT 
> instead of /2011/xx/xx/etc.

Whether you use a timestamp or MM... format, *always* use GMT. We 
all know how much fun it is when someone in Europe sends a request to reboot 
their server at 2am, and the data center in Chicago does just that, except that 
it's now 8am for the requester.



-- Ed Leafe




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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

On Wed, Feb 16, 2011 at 11:20:31PM +0100, Soren Hansen wrote:
> 2011/2/16 Sandy Walsh :
> >> Hmmm... I am not sure about exposing internal structure to customers in 
> >> this
> >> way.  Would you really want the more 'internal' zones exposed?
> > To Jay's point, the "control panel" would hide all that switching.
> 
> I agree with this. It's an API, not a UI. Doing redirects or other
> standard HTTP-y sorts of things seems perfectly reasonable to me.

If this is the case, we should be clear that we are only supporting
open, meaningful zone names. In another thread there was concern
about exposing internal zone structure and topology, and that some
deployments may want to keep it a block box. They may only want to
expose a single API endpoint, which means Nova would need to proxy
and route internally.

Another reason to not rely on redirects is efficient aggregation. If
we have a huge public cloud with hundreds of zones, and my
instances are spread across them all, I don't want to query each one
independently. It would be nice to get answers from one API. At the
same time, I realize this scale-up aggregation will not work forever,
but for our initial target numbers (10s of millions of instances)
I don't think the amount of data will be an issue.

One last thing, your comment about 'It's an API, not a UI': API's are
becoming (or already are) more important than traditional UIs these
days. Their ease of use does matter, so we should certainly consider
the UX for APIs. I want a simple, fast APIs to use with my Android
apps. :)

-Eric

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Ed Leafe]

On Feb 16, 2011, at 5:12 PM, Soren Hansen wrote:

> * Whenever I ask something for information and I get out-of-date,
> cached data back I feel like I'm back in 2003. And 2003 sucked, I
> might add.

The other side of that coin was the implementation of pub/sub. 
New/deleted/changed instances would publish these events, and the zones would 
update accordingly. So there should be no time travel back to 2003.

We had debated doing a regular polling to update, but pretty much 
everyone agreed that that would be especially sucky.

> * Doesn't this caching strategy only help if people are asking for
> the same stuff over and over? It doesn't sound very awesome if 100
> requests for new stuff coming in at roughly the same time causes a
> request to be sent to every single compute node (or whereever the data
> actually resides). I'm assuming breadth-first search here, of course.

Well, if we get 100 requests to spin up instances, each zone will know 
which hosts or sub-zones it needs to query, which is the information being 
cached. If the request is to spin up a new instance, the multi-cluster/zone 
traversal part will be the fastest part of the determination. What will be more 
time-consuming is the scheduler logic to determine the host for that instance, 
and that isn't dependent on how zones are arranged or how information about 
them is tracked and updated.



-- Ed Leafe




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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Adrian Otto]

Glen,

I definitely recognize the value in having scheduling capability. I wrote a 
high level draft of a REST API for a generic scheduler to be used for batch job 
processing. Scheduled events are discussed regularly by users of queue systems 
that want certain things to happen on regular intervals. Considering that a 
scheduler function is useful, and could be used for many different services 
within the OpenStack system, I suggest thinking about a separate service that's 
dedicated to executing scheduled jobs that may need to interact with multiple 
services within OpenStack. This way it could be used to act upon not only 
/severs, but any other resource(s) in any service(s). Imbedding the 
functionality within nova is probably an architectural mistake. Filing a 
blueprint for a separate scheduler service sounds like a good idea.

Adrian

On Feb 16, 2011, at 2:02 PM, Glen Campbell wrote:

The proposed compute API 1.1 has a specification for server actions (Sec. 4.4) 
with the endpoint:

   /servers/{id}/action

The actual action is specified as the body of the POST request, and the 
implication is that the action is performed immediately, or as soon as possible.

I'd like us to consider changing this "action" resource into a "calendar" or 
perhaps "schedule" resource:

   /servers/{id}/schedule{/year{/month{/day{/hour{/minute}

This would provide a generalized way of performing actions on a scheduled basis.

For example, instead of having to wake up at 2AM to reboot a server (for 
whatever reason), the administrator could schedule that event:

   /servers/{id}/schedule/2011/2/17/02/00

By using the default resource (without the day or time specified), the meaning 
would be synonymous with the proposed "/action" resource; i.e., perform it NOW, 
or as soon as possible.

The schedule resource could have additional uses; for example, a GET request 
could return the currently-scheduled actions for a particular server.

Glen


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


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



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.

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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Jay Pipes]

On Wed, Feb 16, 2011 at 5:29 PM, Brian Waldon
 wrote:
> -Original Message-
> From: "Jay Pipes" 
> Sent: Wednesday, February 16, 2011 5:09pm
> To: "Glen Campbell" 
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
>
> On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
>  wrote:
>> The proposed compute API 1.1 has a specification for server actions (Sec.
>> 4.4) with the endpoint:
>>
>>    /servers/{id}/action
>>
>> The actual action is specified as the body of the POST request, and the
>> implication is that the action is performed immediately, or as soon as
>> possible.
>
> Hmm, do you mean the GET request? The above URL implies the action is
> part of the GET URL...
>
> /servers/{id}/action only accepts POST requests with an action entity as the
> body, "action" is not a replaceable string

OK.

>> I'd like us to consider changing this "action" resource into a "calendar"
>> or
>> perhaps "schedule" resource:
>>
>>    /servers/{id}/schedule{/year{/month{/day{/hour{/minute}
>>
>> This would provide a generalized way of performing actions on a scheduled
>> basis.
>>
>> For example, instead of having to wake up at 2AM to reboot a server (for
>> whatever reason), the administrator could schedule that event:
>>
>>    /servers/{id}/schedule/2011/2/17/02/00
>>
>> By using the default resource (without the day or time specified), the
>> meaning would be synonymous with the proposed "/action" resource; i.e.,
>> perform it NOW, or as soon as possible.
>
> Why not /servers/{id}/{action}/schedule/2011/2/17/02/00 instead? That
> way no POST would be required.
>
> Changing a POST to a GET may seem convenient, but to me GET != POST and
> should never be used that way.

Hmm, I suppose, yes, you're right.

> Why not add a "schedule_at" property to the
> action entity and keep the url short?

++ that would work, too.

-jay

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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Brian Waldon]

 
 
-Original Message-
From: "Jay Pipes" 
Sent: Wednesday, February 16, 2011 5:09pm
To: "Glen Campbell" 
Cc: "openstack@lists.launchpad.net" 
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
 wrote:
> The proposed compute API 1.1 has a specification for server actions (Sec.
> 4.4) with the endpoint:
>
>    /servers/{id}/action
>
> The actual action is specified as the body of the POST request, and the
> implication is that the action is performed immediately, or as soon as
> possible.

Hmm, do you mean the GET request? The above URL implies the action is
part of the GET URL...
 
 
/servers/{id}/action only accepts POST requests with an action entity as the 
body, "action" is not a replaceable string
 


> I'd like us to consider changing this "action" resource into a "calendar" or
> perhaps "schedule" resource:
>
>    /servers/{id}/schedule{/year{/month{/day{/hour{/minute}
>
> This would provide a generalized way of performing actions on a scheduled
> basis.
>
> For example, instead of having to wake up at 2AM to reboot a server (for
> whatever reason), the administrator could schedule that event:
>
>    /servers/{id}/schedule/2011/2/17/02/00
>
> By using the default resource (without the day or time specified), the
> meaning would be synonymous with the proposed "/action" resource; i.e.,
> perform it NOW, or as soon as possible.

Why not /servers/{id}/{action}/schedule/2011/2/17/02/00 instead? That
way no POST would be required.
 
 
Changing a POST to a GET may seem convenient, but to me GET != POST and should 
never be used that way. Why not add a "schedule_at" property to the action 
entity and keep the url short?
 


> The schedule resource could have additional uses; for example, a GET request
> could return the currently-scheduled actions for a particular server.

Sure. So, GET /servers/{id}/schedule would return a list of scheduler actions?

-jay

> Glen
>
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of
> the
> individual or entity to which this message is addressed, and unless
> otherwise
> expressly indicated, is confidential and privileged information of
> Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> If you receive this transmission in error, please notify us immediately by
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Steps that can help stabilize Nova's trunk

[Jay Pipes]

Hey all,

It's come to my attention that a number of folks are not happy that
Nova's trunk branch (lp:nova) is, shall we say, "less than stable". :)

First, before going into some suggestions on keeping trunk more
stable, I'd like to point out that trunk is, by nature, an actively
developed source tree. Nobody should have an expectation that they can
simply bzr branch lp:nova and everything will magically work with a)
their existing installations of software packages, b) whatever code
commits they have made locally, or c) whatever specific
hypervisor/volume/network environment that they test their local code
with. The trunk branch is, after all, in active development.

That said, there's *no* reason we can't *improve* the relative
stability of the trunk branch to make life less stressful for
contributors.  Here are a few suggestions on how to keep trunk a bit
more stable for those developers who actively develop from trunk.

1) Participate fully in code reviews. If you suspect a proposed branch
merge will "mess everything up for you", then you should notify
reviewers and developers about your concerns. Be proactive.

2) If you pull trunk and something breaks, don't just complain about
it. Log a bug immediately and talk to the reviewers/approvers of the
patch that broke your environment. Be constructive in your criticism,
and be clear about why the patch should have been more thoroughly or
carefully reviewed. If you don't, we're bound to repeat mistakes.

3) Help us to write functional and integration tests. It's become
increasingly clear from the frequency of breakages in trunk (and other
branches) that our unit tests are nowhere near sufficient to catch a
large portion of bugs. This is to be expected. Our unit tests use
mocks and stubs for virtually everything, and they only really test
code interfaces, and they don't even test that very well. We're
working on adding functional tests to Hudson that will run, as the
unit test do, before any merge into trunk, with any failure resulting
in a failed merge. However, we need your help to create functional
tests and integration tests (tests that various *real* components work
together properly).  We also need help writing test cases that ensure
software library dependencies and other packaging issues are handled
properly and don't break with minor patches.

4) If you have a specific environment/setup that you use (Rackers and
Anso guys, here...), then we need your assistance to set up test
clusters that will pull trunk into a wiped test environment and ensure
that a series of realistic calls to the Nova API are properly handled.
I know some of you are working on getting hardware ready. We need help
from the software teams to ensure that these environments are
initialized with the exact setups you use.

The more testing we fire off against each potential merge into trunk,
and the more those tests are hitting real-life deployment
environments, the more stable trunk will become and the easier your
life as a contributor will be.

Thanks in advance for your assistance, and please don't hesitate to
expand on any more suggestions you might have to stabilize trunk.

-jay

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Soren Hansen]

2011/2/16 Eric Day :
> This doesn't help the 'list all instances' search. This would be
> very expensive when dealing with a large number of accounts and
> instances. We need a more active caching policy, which ends up being
> more of a replication subset than a cache.

Did we ever discuss a gossip protocol approach?

> These are all things we discussed at the last design summit, if folks remember
> those discussions. :)

I'll readily admit that in spite of attempts to commit this stuff to
permanent memory, I always seem to have the same questions. This
thread seems delightfully practical that it might actually stick this
time :)

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

Good points Soren, and this is why I was suggesting we not solve this
problem with a cache, but instead an eventually consistent replication
stream of the aggregate data.

-Eric

On Wed, Feb 16, 2011 at 11:12:50PM +0100, Soren Hansen wrote:
> 2011/2/16 Ed Leafe :
> > This was one of the issues we discussed during the sprint planning. I 
> > believe (check with cyn) that the consensus was to use a caching strategy 
> > akin to DNS: e.g., if zone A got a request for instance ID=12345, it would 
> > check to see if it had id 12345 in its cache. If not, it would ask all of 
> > its child nodes if they knew about that instance. That would repeat until 
> > the instance was found, at which point every upstream server would now know 
> > about where to reach 12345.
> 
> Has any formal analysis been done as to how this would scale?
> 
> I have a couple of problems with this approach:
> 
>  * Whenever I ask something for information and I get out-of-date,
> cached data back I feel like I'm back in 2003. And 2003 sucked, I
> might add.
>  * Doesn't this caching strategy only help if people are asking for
> the same stuff over and over? It doesn't sound very awesome if 100
> requests for new stuff coming in at roughly the same time causes a
> request to be sent to every single compute node (or whereever the data
> actually resides). I'm assuming breadth-first search here, of course.
> 
> 
> -- 
> Soren Hansen
> Ubuntu Developer    http://www.ubuntu.com/
> OpenStack Developer http://www.openstack.org/
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Soren Hansen]

2011/2/16 Sandy Walsh :
>> Hmmm... I am not sure about exposing internal structure to customers in this
>> way.  Would you really want the more 'internal' zones exposed?
> To Jay's point, the "control panel" would hide all that switching.

I agree with this. It's an API, not a UI. Doing redirects or other
standard HTTP-y sorts of things seems perfectly reasonable to me.

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Soren Hansen]

2011/2/16 Ed Leafe :
> This was one of the issues we discussed during the sprint planning. I believe 
> (check with cyn) that the consensus was to use a caching strategy akin to 
> DNS: e.g., if zone A got a request for instance ID=12345, it would check to 
> see if it had id 12345 in its cache. If not, it would ask all of its child 
> nodes if they knew about that instance. That would repeat until the instance 
> was found, at which point every upstream server would now know about where to 
> reach 12345.

Has any formal analysis been done as to how this would scale?

I have a couple of problems with this approach:

 * Whenever I ask something for information and I get out-of-date,
cached data back I feel like I'm back in 2003. And 2003 sucked, I
might add.
 * Doesn't this caching strategy only help if people are asking for
the same stuff over and over? It doesn't sound very awesome if 100
requests for new stuff coming in at roughly the same time causes a
request to be sent to every single compute node (or whereever the data
actually resides). I'm assuming breadth-first search here, of course.


-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Michael Mayo]

I like this idea, but I would suggest going with a unix timestamp in GMT 
instead of /2011/xx/xx/etc.

Also, how would this effect error handling?  It seems like you'd basically need 
to have some sort of way to query all the server actions you've ever done 
before with their HTTP responses.



On Feb 16, 2011, at 2:02 PM, Glen Campbell wrote:

> The proposed compute API 1.1 has a specification for server actions (Sec. 
> 4.4) with the endpoint:
>  
>/servers/{id}/action
>  
> The actual action is specified as the body of the POST request, and the 
> implication is that the action is performed immediately, or as soon as 
> possible.
>  
> I'd like us to consider changing this "action" resource into a "calendar" or 
> perhaps "schedule" resource:
>  
>/servers/{id}/schedule{/year{/month{/day{/hour{/minute}
>  
> This would provide a generalized way of performing actions on a scheduled 
> basis.
>  
> For example, instead of having to wake up at 2AM to reboot a server (for 
> whatever reason), the administrator could schedule that event:
>  
>/servers/{id}/schedule/2011/2/17/02/00
>  
> By using the default resource (without the day or time specified), the 
> meaning would be synonymous with the proposed "/action" resource; i.e., 
> perform it NOW, or as soon as possible.
>  
> The schedule resource could have additional uses; for example, a GET request 
> could return the currently-scheduled actions for a particular server.
> 
> Glen
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Mike Mayo
901-299-9306
@greenisus



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

Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions

[Jay Pipes]

On Wed, Feb 16, 2011 at 5:02 PM, Glen Campbell
 wrote:
> The proposed compute API 1.1 has a specification for server actions (Sec.
> 4.4) with the endpoint:
>
>    /servers/{id}/action
>
> The actual action is specified as the body of the POST request, and the
> implication is that the action is performed immediately, or as soon as
> possible.

Hmm, do you mean the GET request? The above URL implies the action is
part of the GET URL...

> I'd like us to consider changing this "action" resource into a "calendar" or
> perhaps "schedule" resource:
>
>    /servers/{id}/schedule{/year{/month{/day{/hour{/minute}
>
> This would provide a generalized way of performing actions on a scheduled
> basis.
>
> For example, instead of having to wake up at 2AM to reboot a server (for
> whatever reason), the administrator could schedule that event:
>
>    /servers/{id}/schedule/2011/2/17/02/00
>
> By using the default resource (without the day or time specified), the
> meaning would be synonymous with the proposed "/action" resource; i.e.,
> perform it NOW, or as soon as possible.

Why not /servers/{id}/{action}/schedule/2011/2/17/02/00 instead? That
way no POST would be required.

> The schedule resource could have additional uses; for example, a GET request
> could return the currently-scheduled actions for a particular server.

Sure. So, GET /servers/{id}/schedule would return a list of scheduler actions?

-jay

> Glen
>
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of
> the
> individual or entity to which this message is addressed, and unless
> otherwise
> expressly indicated, is confidential and privileged information of
> Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> If you receive this transmission in error, please notify us immediately by
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>

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

[Openstack] OpenStack Compute API 1.1 ‹ server actions

[Glen Campbell]

The proposed compute API 1.1 has a specification for server actions (Sec. 4.4) 
with the endpoint:

   /servers/{id}/action

The actual action is specified as the body of the POST request, and the 
implication is that the action is performed immediately, or as soon as possible.

I'd like us to consider changing this "action" resource into a "calendar" or 
perhaps "schedule" resource:

   /servers/{id}/schedule{/year{/month{/day{/hour{/minute}

This would provide a generalized way of performing actions on a scheduled basis.

For example, instead of having to wake up at 2AM to reboot a server (for 
whatever reason), the administrator could schedule that event:

   /servers/{id}/schedule/2011/2/17/02/00

By using the default resource (without the day or time specified), the meaning 
would be synonymous with the proposed "/action" resource; i.e., perform it NOW, 
or as soon as possible.

The schedule resource could have additional uses; for example, a GET request 
could return the currently-scheduled actions for a particular server.

Glen



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

On Wed, Feb 16, 2011 at 04:33:06PM -0500, Jay Pipes wrote:
> > While I would agree with this most of the time, there are some cases
> > where "optimizing later" just doesn't work. Or, "optimizing" means
> > rewriting everything you've done and replacing it with something
> > that will scale seamlessly. I've done this a fair share myself over
> > the years, and many of us have probably done it or seen it happen
> > elsewhere. I was hoping to use past experiences and foresight to
> > prevent a similar outcome with Nova.
> >
> > I'm not confident the current Nova database and messaging foundations
> > will hold up (even with optimizations) for the scale, security, and
> > user experience we are targeting. Spending more time on reworking those
> > foundations before diving right into implementing the distributed
> > aspects (multi-zone) is what I was trying to do and advocate. I
> > recognize I'm in the minority with this opinion and it doesn't seem
> > to be the route we'll take, so I hope to be proven wrong. :)
> 
> And I also raised concerns about performance of having Nova not
> understand the relationships of multi-tenancy. ;)

Yeah, understood, and I was thinking of that when writing my last
email. I understand sometimes we just need to defer to the more
popular opinion, no matter how strongly we feel. :)

> Unfortunately, I am still unclear as to what precisely you are
> proposing that Sandy change before going any further in his work.
> Could you be specific on what steps you feel Sandy et al should take
> that would eliminate your worry about scalability? What specifically
> are the foundations that you want to rework? And are these realistic
> to get done in Cactus?

The list of things was discussed at the design summit (which I know
not everyone was part of) and is outlined in the 'Design' section of:

http://wiki.openstack.org/DistributedScheduler

I mostly finished the first bullet point in Bexar and was working
on two, but with the addition of features and DB schema changes it
was becoming a never-ending battle. Focusing on features is a bit
premature for the project, we should be focusing on foundation and
scalability, which I know Cactus is doing to some degree.

I consider the multi-zone and distributed scheduler features a bit
premature still, I believe we should first focus on full request
marshaling (not relying on DB to pass details), not writing to the DB
from workers or API code, and creating a data aggregation channel/API
to use once we get to the zone work. The zone and distributed scheduler
issues we're discussing today would be pretty different (and I believe
easier) if this foundation work was in place.

This may mean the zone/scheduler work is not finished for Cactus,
but I believe in the long run the investment will be worth it. As I
stated in my last email though, I'll defer to the larger group since
this doesn't seem to be the preferred route. :)

-Eric

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

[Openstack] Review days for nova-core members

[Soren Hansen]

2011/2/16 Jay Pipes :
> Lots of coding and bug fixing has been done in the past weeks. As a
> result, we've got a big backlog of code reviews to do.
>
> If you have some cycles, please do participate:
>
> https://code.launchpad.net/nova/+activereviews
>
> Nova-core members, remember, it's you responsibility to do code reviews! :)

Yes!

I've considered if nova-core people should take turns in having a review day.
Their top priority for the day should be doing branch reviews and bug
triaging.  Anything else that day would be second to this.  Every member of
the team should be part of the rotation. The only member of nova-core
exempt from this responsibility would be Jenkins. :)  f you cannot accept this
responsibility, you don't get to be a member of the team. Of course
there has to be room for holiday and being ill, but every day, people
should know who they can bug for reviews and members of the team should
generally be available for this rotation.

The goal is to ensure that we don't drop good work on the floor due to
bitrot and to distribute the review load better than we do now.


-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Jay Pipes]

On Wed, Feb 16, 2011 at 4:25 PM, Eric Day  wrote:
> On Wed, Feb 16, 2011 at 03:59:10PM -0500, Jay Pipes wrote:
>> But, as I mentioned to Sandy on IRC, caching and performance should be
>> a secondary concern. The primary concern, right now, is just making
>> this all work. In other words, getting multiple zones up and running,
>> each knowing about their little slice of the pie, and communicating up
>> and down the scheduler levels properly.
>>
>> Optimization can come later.
>
> While I would agree with this most of the time, there are some cases
> where "optimizing later" just doesn't work. Or, "optimizing" means
> rewriting everything you've done and replacing it with something
> that will scale seamlessly. I've done this a fair share myself over
> the years, and many of us have probably done it or seen it happen
> elsewhere. I was hoping to use past experiences and foresight to
> prevent a similar outcome with Nova.
>
> I'm not confident the current Nova database and messaging foundations
> will hold up (even with optimizations) for the scale, security, and
> user experience we are targeting. Spending more time on reworking those
> foundations before diving right into implementing the distributed
> aspects (multi-zone) is what I was trying to do and advocate. I
> recognize I'm in the minority with this opinion and it doesn't seem
> to be the route we'll take, so I hope to be proven wrong. :)

And I also raised concerns about performance of having Nova not
understand the relationships of multi-tenancy. ;)

Unfortunately, I am still unclear as to what precisely you are
proposing that Sandy change before going any further in his work.
Could you be specific on what steps you feel Sandy et al should take
that would eliminate your worry about scalability? What specifically
are the foundations that you want to rework? And are these realistic
to get done in Cactus?

-jay

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

On Wed, Feb 16, 2011 at 03:59:10PM -0500, Jay Pipes wrote:
> But, as I mentioned to Sandy on IRC, caching and performance should be
> a secondary concern. The primary concern, right now, is just making
> this all work. In other words, getting multiple zones up and running,
> each knowing about their little slice of the pie, and communicating up
> and down the scheduler levels properly.
> 
> Optimization can come later.

While I would agree with this most of the time, there are some cases
where "optimizing later" just doesn't work. Or, "optimizing" means
rewriting everything you've done and replacing it with something
that will scale seamlessly. I've done this a fair share myself over
the years, and many of us have probably done it or seen it happen
elsewhere. I was hoping to use past experiences and foresight to
prevent a similar outcome with Nova.

I'm not confident the current Nova database and messaging foundations
will hold up (even with optimizations) for the scale, security, and
user experience we are targeting. Spending more time on reworking those
foundations before diving right into implementing the distributed
aspects (multi-zone) is what I was trying to do and advocate. I
recognize I'm in the minority with this opinion and it doesn't seem
to be the route we'll take, so I hope to be proven wrong. :)

-Eric

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

[Openstack] ATTENTION: Code reviews needed

[Jay Pipes]

Hi all,

Lots of coding and bug fixing has been done in the past weeks. As a
result, we've got a big backlog of code reviews to do.

If you have some cycles, please do participate:

https://code.launchpad.net/nova/+activereviews

Nova-core members, remember, it's you responsibility to do code reviews! :)

Thanks much!
jay

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Jay Pipes]

On Wed, Feb 16, 2011 at 2:17 PM, Eric Day  wrote:
> On Wed, Feb 16, 2011 at 01:02:22PM -0500, Jay Pipes wrote:
>> >> [Sorry, yes the instance name is passed in on the request, but the 
>> >> instance ID is what's needed (assuming of course instance ID is unique 
>> >> across zones.)]
>> >
>> >        The ID is determined early in the process; well before the request 
>> > to create an instance is cast onto the queue, and is returned immediately.
>>
>> The instance ID is constructed in nova.compute.api.API.create(), which
>> is called by nova.api.openstack.servers.Controller.create().
>>
>> In other words, Sandy needs to find an appropriate zone to place an
>> instance in. Clearly, this logic must happen before the instance is
>> created in the database.
>
> On top of this, the instance is created in the DB before being passed
> to the scheduler too, which is obviously a problem since the scheduler
> may proxy this to another zone, and this old instance row in the
> DB is abandoned. We need to not touch the DB until we get to the
> compute node, which was what I was working on as a prerequisite for
> this blueprint during Bexar. This, as well as some other fundamental
> changes, are required before we can move too far along with multi-zone.
>
> We never want to generate the ID any other place besides the final
> zone. We should be using a zone-unique ID + zone name for instance
> (and other object) naming.

++, and your URI naming scheme may work out here...

But, as I mentioned to Sandy on IRC, caching and performance should be
a secondary concern. The primary concern, right now, is just making
this all work. In other words, getting multiple zones up and running,
each knowing about their little slice of the pie, and communicating up
and down the scheduler levels properly.

Optimization can come later.

>> >        I know that. I'm just stating that this is a natural consequence of 
>> > the decision not to use a centralized db.
>>
>> The data set queried in the database used for a zone only contains
>> information necessary for the scheduler workers in that zone to make a
>> decision, and nothing more.
>
> ++
>
>>  One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone 
>>  query operations.
>> >>>
>> >>>        I don't really like this approach. It requires the requester to 
>> >>> know too much about the implementation of the service: e.g, that there 
>> >>> are zones, and that an instance will be placed in a particular zone. I 
>> >>> would prefer something more along the lines of:
>> >>>
>> >>> a. User issues a create-instance request, supplying the name of the 
>> >>> instance to be created.
>> >>> b. The top-level zone that receives the request does a zone-best-match 
>> >>> and/or host-best-match call to determine where the instance will be 
>> >>> created.
>> >>> c. The top-level zone then passes the create-instance request to the 
>> >>> selected zone/host.
>
> ++
>
>> Why are we assuming a requester doesn't know much about the
>> implementation of the service? I mean, the requester is going to be an
>> application like the Cloud Servers console, not just some random user.
>
> But it can be some random user, many folks script against the public API.

I wasn't saying it *couldn't* be a random user, just that in many
cases, it is a "user" like a Control Panel, that can have a better
understanding of the underlying environment setup...

>>  Of course the requester knows something about the implementation of
>> the service, and if they don't, the work Sandy did in the first phase
>> of this blueprint allows the requester to query the admin API for
>> information about the zones...
>
> Pushing the zone list out to the client just punts on the whole routing
> issue. That means the client needs to do the work instead, and need to
> either scan or track the zone for each instance they create. Some folks
> have said they don't want to expose any of their topology and would
> most likely want everything routing through a top-level API endpoint.
>
> For ease of use for the API user, and to accommodate deployments that
> don't expose topology, we need to support routing of all requests
> inside the parent zones.

Sure, I don't disagree here. I was just suggesting to Sandy that some
*future* optimization might entail a set of clients that had a bit
more knowledge about the underlying environment, that's all.

>> >> [But what about subsequent actions ... the same zone-search would have be 
>> >> performed for each of them, no?]
>> >
>> >        This was one of the issues we discussed during the sprint planning. 
>> > I believe (check with cyn) that the consensus was to use a caching 
>> > strategy akin to DNS: e.g., if zone A got a request for instance ID=12345, 
>> > it would check to see if it had id 12345 in its cache. If not, it would 
>> > ask all of its child nodes if they knew about that instance. That would 
>> > repeat until the instance was found, at which point every upstream 

Re: [Openstack] Queue Service

[Eric Day]

On Tue, Feb 15, 2011 at 01:18:46PM -0800, David Strauss wrote:
> Regardless of whether the system uses AMQP, I am a fan of AMQP's
> flexible routing model. Please don't build a service that lacks fanout
> and other non-1:1 distribution patterns. Non-1:1 routing is useful for
> web cache invalidation and other cluster management.
> 
> If the queue service is only 1:1, we'll still end up running RabbitMQ
> for our own needs.

Agreed, AMQP like routing can be very useful. Initially there will
only be native support for 1:1 and pubsub, but it is trivial to add
more sophisticated routing to 1:1 by writing a worker to pull messages
and reinsert into other specific queues (replication can be done this
way too). Once we have a solid foundation I certainly want to look
at providing this functionality closer into the core for performance
reasons (basically built-in router workers that you can control via
an API). So, yes, but not for version 1. :)

-Eric

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

On Wed, Feb 16, 2011 at 01:02:22PM -0500, Jay Pipes wrote:
> >> [Sorry, yes the instance name is passed in on the request, but the 
> >> instance ID is what's needed (assuming of course instance ID is unique 
> >> across zones.)]
> >
> >        The ID is determined early in the process; well before the request 
> > to create an instance is cast onto the queue, and is returned immediately.
> 
> The instance ID is constructed in nova.compute.api.API.create(), which
> is called by nova.api.openstack.servers.Controller.create().
>
> In other words, Sandy needs to find an appropriate zone to place an
> instance in. Clearly, this logic must happen before the instance is
> created in the database.

On top of this, the instance is created in the DB before being passed
to the scheduler too, which is obviously a problem since the scheduler
may proxy this to another zone, and this old instance row in the
DB is abandoned. We need to not touch the DB until we get to the
compute node, which was what I was working on as a prerequisite for
this blueprint during Bexar. This, as well as some other fundamental
changes, are required before we can move too far along with multi-zone.

We never want to generate the ID any other place besides the final
zone. We should be using a zone-unique ID + zone name for instance
(and other object) naming.

> >        I know that. I'm just stating that this is a natural consequence of 
> > the decision not to use a centralized db.
> 
> The data set queried in the database used for a zone only contains
> information necessary for the scheduler workers in that zone to make a
> decision, and nothing more.

++

>  One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone 
>  query operations.
> >>>
> >>>        I don't really like this approach. It requires the requester to 
> >>> know too much about the implementation of the service: e.g, that there 
> >>> are zones, and that an instance will be placed in a particular zone. I 
> >>> would prefer something more along the lines of:
> >>>
> >>> a. User issues a create-instance request, supplying the name of the 
> >>> instance to be created.
> >>> b. The top-level zone that receives the request does a zone-best-match 
> >>> and/or host-best-match call to determine where the instance will be 
> >>> created.
> >>> c. The top-level zone then passes the create-instance request to the 
> >>> selected zone/host.

++

> Why are we assuming a requester doesn't know much about the
> implementation of the service? I mean, the requester is going to be an
> application like the Cloud Servers console, not just some random user.

But it can be some random user, many folks script against the public API.

>  Of course the requester knows something about the implementation of
> the service, and if they don't, the work Sandy did in the first phase
> of this blueprint allows the requester to query the admin API for
> information about the zones...

Pushing the zone list out to the client just punts on the whole routing
issue. That means the client needs to do the work instead, and need to
either scan or track the zone for each instance they create. Some folks
have said they don't want to expose any of their topology and would
most likely want everything routing through a top-level API endpoint.

For ease of use for the API user, and to accommodate deployments that
don't expose topology, we need to support routing of all requests
inside the parent zones.

> >> [But what about subsequent actions ... the same zone-search would have be 
> >> performed for each of them, no?]
> >
> >        This was one of the issues we discussed during the sprint planning. 
> > I believe (check with cyn) that the consensus was to use a caching strategy 
> > akin to DNS: e.g., if zone A got a request for instance ID=12345, it would 
> > check to see if it had id 12345 in its cache. If not, it would ask all of 
> > its child nodes if they knew about that instance. That would repeat until 
> > the instance was found, at which point every upstream server would now know 
> > about where to reach 12345.
> 
> Agreed. Each "level" or zone in the overall architecture would cache
> (in our case, cache means a record in the zone's database) information
> about its subordinate nodes (nodes being instances or other zones,
> depending on the "level" of the zone in the overall architecture).

This doesn't help the 'list all instances' search. This would be
very expensive when dealing with a large number of accounts and
instances. We need a more active caching policy, which ends up being
more of a replication subset than a cache. Initially we can just
fanout the query to just make it work, but to be usable in any large
capacity, we need a much smarter data model underneath. These are
all things we discussed at the last design summit, if folks remember
those discussions. :)

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to 

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Eric Day]

Hi Sandy,

On Wed, Feb 16, 2011 at 06:19:52PM +, Sandy Walsh wrote:
>  Hmm.  You wouldn't really need to re-marshall the request. Just
>  copy  the needed headers & url, and pass along the body as you received
>  it.  Basically you are just
>  acting as a sort of http proxy.
> 
>Yup, that's what I was proposing. I guess I wasn't clear.

Agreed, we should never assume HTTP request outside of
nova/api. Anything could be consuming the internal nova/compute,
nova/volume, ... API, so you need to proxy using only the information
given via those API calls. Likewise, down the road, the zones could
possibly be connecting in some other way and it may not just be HTTP,
so a given scheduler may be written to send via some other queue
system. Of course just use the simplest, sane defaults like building
a HTTP request object for now in the scheduler and proxy it using
the configured zone URIs.

>Yes. The proxying will have to occur in the scheduler where the decision
>making is done, correct?

Yes. It's more difficult too, and relates to the other issues. Right
now the compute API writes a DB record and simply passes an ID to
the scheduler that's only local to the zone. The prerequisite work
I was doing was working towards changing this so instead the entire
request (in the form of a python dict) would be passed around until
it reached the final zone. We still need to do this before going much
further, otherwise we'll have a mess of unused instance records in
the top-level zone.

>  Basically there needs to be some notification (pub sub, rest call,
>  whatever) that gets passed back up the chain to the 'higher'
>  schedulers.  They use this to replicate basic info on the  higher zones
>  (possibly as a cache).  This could also drive an event feed to the end
>  user. 
>  The alternative is to pull from zones and cache that.  But the
>  notification approach seems  more efficient.
> 
>I like the notification scheme as well. We may want to revisit once that
>gets in place.

What are we notifying exactly? Just status for child zones? I think
this is better off being a poll from the parent zone, allowing the
child to function knowing it doesn't even have a parent zone.

>Seems impractical if *every* command has to do a zone search every
>time.
> 
>  Besides the zones having replicated info on the instances (I'm assuming
>  each zone has it's own db) the instance_id's could have structure to
>  them (i.e. a URI) which could indicate which zone they live in.

Agreed, and this is something I've been trying to discuss for a
while. :)  All objects (instances, volumens, networks, ...) need
globally unique IDs. I tried pushing for UUIDs but that was rejected. I
think now that we should leave it up to the zone. I think each zone
name should be globally unique, and my opinion is using a DNS name
(although I know some folks disagree on other threads). An instance
name could then be a zone-level unique ID + zone name. Be using DNS, we
can do simple routing without having to cache where every instance is
either just by doing object suffix matching on the list of child zones.

If we don't want to expose this detail (which I know some folks were
opposed to), we basically need to do the same thing but instead add
a layer of abstraction around it, so we can can still have arbitrary
globally unique IDs for zones and objects, and need to consult the
encoding plugin to either route them, or simple cache every object/zone
mapping at the higher level zones.

-Eric

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Sandy Walsh]

Thanks Dragon!

Had another conversation with Jay on this as well. I think the caching with the 
smart use of instance/customer naming will go a long way to helping the search.

More comments below ...

-S

From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Monsyne Dragon [mdra...@rackspace.com]

Hmm.  You wouldn't really need to re-marshall the request. Just copy  the 
needed headers & url, and pass along the body as you received it.  Basically 
you are just
acting as a sort of http proxy.

Yup, that's what I was proposing. I guess I wasn't clear.
Rather than modify all the *service/api.py methods to accept a request 
parameter, can anyone think of cleaner solution? I debated piggy-backing on the 
Context, but that's ugly.
I think just  proxying the request is cleaner. Otherwise you have two different 
ways of calling an api method.

Yes. The proxying will have to occur in the scheduler where the decision making 
is done, correct?
Problem 2.

Basically there needs to be some notification (pub sub, rest call, whatever) 
that gets passed back up the chain to the 'higher' schedulers.  They use this 
to replicate basic info on the  higher zones (possibly as a cache).  This could 
also drive an event feed to the end user.

The alternative is to pull from zones and cache that.  But the notification 
approach seems  more efficient.
I like the notification scheme as well. We may want to revisit once that gets 
in place.
Seems impractical if *every* command has to do a zone search every time.
Besides the zones having replicated info on the instances (I'm assuming each 
zone has it's own db) the instance_id's could have structure to them (i.e. a 
URI) which could indicate which zone they live in.
+1
One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query 
operations.
My above use-case would look like this:
Hmmm... I am not sure about exposing internal structure to customers in this 
way.  Would you really want the more 'internal' zones exposed?

To Jay's point, the "control panel" would hide all that switching.
-S


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.



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




--

--
-Monsyne Dragon
work: 210-312-4190
mobile210-441-0965
google voice: 210-338-0336

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Monsyne Dragon]

On 2/16/11 9:26 AM, Sandy Walsh wrote:

Hi y'all

Like they say "The devil is in the details". I'm at the stage where 
the parent zones will talk to the child zones and there are some 
interesting implementation issues:


*Problem 1.* I'd like to pass the incoming HTTP Request object along 
to the Scheduler so I don't have to remarshall the command to send to 
the child zone.
Hmm.  You wouldn't really need to re-marshall the request. Just 
copy  the needed headers & url, and pass along the body as you received 
it.  Basically you are just

acting as a sort of http proxy.

Rather than modify all the *service/api.py methods to accept a request 
parameter, can anyone think of cleaner solution? I debated 
piggy-backing on the Context, but that's ugly.


I think just  proxying the request is cleaner. Otherwise you have two 
different ways of calling an api method.


*Problem 2.* I'm assuming only events that get routed through the 
scheduler should be candidates for being relayed to child zones. 
Currently, these are only volume/create_volume() and 
compute/create_instance().


But this introduces a problem. Consider this use-case:

a. I issue a "create-instance" via the top-level API in zone-A
b. the request is relayed down to zone-C
c. the instance is created some time later
   Q1. How does the user learn what the instance is named? For 
example, I want to issue a "pause-instance" but don't know what to 
give as an instance ID?

   Q2. If I do "instance-list", do I have to search all zones again?

Basically there needs to be some notification (pub sub, rest call, 
whatever) that gets passed back up the chain to the 'higher' 
schedulers.  They use this to replicate basic info on the  higher zones 
(possibly as a cache).  This could also drive an event feed to the end 
user.


The alternative is to pull from zones and cache that.  But the 
notification approach seems  more efficient.



Seems impractical if *every* command has to do a zone search every time.
Besides the zones having replicated info on the instances (I'm assuming 
each zone has it's own db) the instance_id's could have structure to 
them (i.e. a URI) which could indicate which zone they live in.


One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone 
query operations.


My above use-case would look like this:
a. I issue a "find-best-zone" command to the top-level API in zone-A
b. I get an API URL to zone-C
c. I do my "create-instance" on zone-C, as well as all related 
operations.


Yes, there is a potential race-condition if the zone changes radically 
in the time between operations. But anything could happen during that 
time, so it has to be anticipated. In this case the user should just 
start again at Step-A.


Also, this approach:
* keeps the code clean/small
* solves problem 1

Thoughts?

Hmmm... I am not sure about exposing internal structure to customers in 
this way.  Would you really want the more 'internal' zones exposed?



-S

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


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



--

--
-Monsyne Dragon
work: 210-312-4190
mobile210-441-0965
google voice: 210-338-0336



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Jay Pipes]

On Wed, Feb 16, 2011 at 12:16 PM, Ed Leafe  wrote:
> On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:
>>>        Isn't the instance name usually supplied by the user/originator?
>>
>> [Sorry, yes the instance name is passed in on the request, but the instance 
>> ID is what's needed (assuming of course instance ID is unique across zones.)]
>
>        The ID is determined early in the process; well before the request to 
> create an instance is cast onto the queue, and is returned immediately.

The instance ID is constructed in nova.compute.api.API.create(), which
is called by nova.api.openstack.servers.Controller.create().

AFAICT, Sandy is referring to actions that must happen *before* the
instance is created in the database, no? I mean, the top-level API
node receives a request containing a number of requirements for the
creation of an instance. One of those requirements may be a zone, or a
set of policy attributes for the zone that the eventual instance will
be created in.

In other words, Sandy needs to find an appropriate zone to place an
instance in. Clearly, this logic must happen before the instance is
created in the database.

   Q2. If I do "instance-list", do I have to search all zones again?
>>>
>>>        If the db is not centralized/replicated, yes. Caching could 
>>> certainly be an option, especially in situations where instances tend to 
>>> persist for long periods.
>>
>> [The db is not centralized. One per Zone.]
>
>        I know that. I'm just stating that this is a natural consequence of 
> the decision not to use a centralized db.

The data set queried in the database used for a zone only contains
information necessary for the scheduler workers in that zone to make a
decision, and nothing more.

 One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone 
 query operations.
>>>
>>>        I don't really like this approach. It requires the requester to know 
>>> too much about the implementation of the service: e.g, that there are 
>>> zones, and that an instance will be placed in a particular zone. I would 
>>> prefer something more along the lines of:
>>>
>>> a. User issues a create-instance request, supplying the name of the 
>>> instance to be created.
>>> b. The top-level zone that receives the request does a zone-best-match 
>>> and/or host-best-match call to determine where the instance will be created.
>>> c. The top-level zone then passes the create-instance request to the 
>>> selected zone/host.

Why are we assuming a requester doesn't know much about the
implementation of the service? I mean, the requester is going to be an
application like the Cloud Servers console, not just some random user.
 Of course the requester knows something about the implementation of
the service, and if they don't, the work Sandy did in the first phase
of this blueprint allows the requester to query the admin API for
information about the zones...

>> [But what about subsequent actions ... the same zone-search would have be 
>> performed for each of them, no?]
>
>
>        This was one of the issues we discussed during the sprint planning. I 
> believe (check with cyn) that the consensus was to use a caching strategy 
> akin to DNS: e.g., if zone A got a request for instance ID=12345, it would 
> check to see if it had id 12345 in its cache. If not, it would ask all of its 
> child nodes if they knew about that instance. That would repeat until the 
> instance was found, at which point every upstream server would now know about 
> where to reach 12345.

Agreed. Each "level" or zone in the overall architecture would cache
(in our case, cache means a record in the zone's database) information
about its subordinate nodes (nodes being instances or other zones,
depending on the "level" of the zone in the overall architecture).

So, just like DNS.

-jay

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Ed Leafe]

On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:

> Thanks for feedback Ed. Comments in [] below ...

Yeesh - that makes for ugly quoting. :) Let me try to reformat the 
quoting.


>>Isn't the instance name usually supplied by the user/originator?
> 
> [Sorry, yes the instance name is passed in on the request, but the instance 
> ID is what's needed (assuming of course instance ID is unique across zones.)]

The ID is determined early in the process; well before the request to 
create an instance is cast onto the queue, and is returned immediately.

>>>   Q2. If I do "instance-list", do I have to search all zones again?
>> 
>>If the db is not centralized/replicated, yes. Caching could certainly 
>> be an option, especially in situations where instances tend to persist for 
>> long periods.
> 
> [The db is not centralized. One per Zone.]

I know that. I'm just stating that this is a natural consequence of the 
decision not to use a centralized db. 

>>> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone 
>>> query operations.
>> 
>>I don't really like this approach. It requires the requester to know 
>> too much about the implementation of the service: e.g, that there are zones, 
>> and that an instance will be placed in a particular zone. I would prefer 
>> something more along the lines of:
>> 
>> a. User issues a create-instance request, supplying the name of the instance 
>> to be created.
>> b. The top-level zone that receives the request does a zone-best-match 
>> and/or host-best-match call to determine where the instance will be created.
>> c. The top-level zone then passes the create-instance request to the 
>> selected zone/host.
> 
> [But what about subsequent actions ... the same zone-search would have be 
> performed for each of them, no?]


This was one of the issues we discussed during the sprint planning. I 
believe (check with cyn) that the consensus was to use a caching strategy akin 
to DNS: e.g., if zone A got a request for instance ID=12345, it would check to 
see if it had id 12345 in its cache. If not, it would ask all of its child 
nodes if they knew about that instance. That would repeat until the instance 
was found, at which point every upstream server would now know about where to 
reach 12345. 



-- Ed Leafe




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

Re: [Openstack] wiki.openstack.org broken in IE

[Josh Kearney]

Out of curiosity -- are we *really* concerned about IE6?

On Wed, Feb 16, 2011 at 10:54 AM, Colin Nicholson <
colin.nichol...@iomart.com> wrote:

> Not sure about StartingPage - it's not all that bad, and could easily
> just be IE6, haven't ever looked at it in IE6 before.
>
> As for the releasestatus page, I'd point my finger at the  href="."> at the top. That doesn't seem to be handled properly, stopping
> all the css, js and image files from loading.
>
>
> Colin
>
> On 16/02/11 16:28, Thierry Carrez wrote:
> > Ewan Mellor wrote:
> >> Has someone changed Javascript or stylesheets on wiki.openstack.org
> >> recently?  It’s broken in IE now, in a way that it wasn’t yesterday.
> > Note that the releasestatus page and the rest of the wiki don't have any
> > stylesheet in common, so that would rather point to a local issue...
> >
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] wiki.openstack.org broken in IE

[Ewan Mellor]

Ah, IE had switched into Compatibility View.  It's fine with that turned off.

Sorry for the noise.

Ewan.

> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Colin Nicholson
> Sent: 16 February 2011 16:54
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] wiki.openstack.org broken in IE
> 
> Not sure about StartingPage - it's not all that bad, and could easily
> just be IE6, haven't ever looked at it in IE6 before.
> 
> As for the releasestatus page, I'd point my finger at the  href="."> at the top. That doesn't seem to be handled properly,
> stopping
> all the css, js and image files from loading.
> 
> 
> Colin
> 
> On 16/02/11 16:28, Thierry Carrez wrote:
> > Ewan Mellor wrote:
> >> Has someone changed Javascript or stylesheets on wiki.openstack.org
> >> recently?  It's broken in IE now, in a way that it wasn't yesterday.
> > Note that the releasestatus page and the rest of the wiki don't have
> any
> > stylesheet in common, so that would rather point to a local issue...
> >
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Sandy Walsh]

Thanks for feedback Ed. Comments in [] below ...

From: Ed Leafe [e...@leafe.com]

On Feb 16, 2011, at 10:26 AM, Sandy Walsh wrote:


Isn't the instance name usually supplied by the user/originator?

[Sorry, yes the instance name is passed in on the request, but the instance ID 
is what's needed (assuming of course instance ID is unique across zones.)]

>Q2. If I do "instance-list", do I have to search all zones again?

If the db is not centralized/replicated, yes. Caching could certainly 
be an option, especially in situations where instances tend to persist for long 
periods.

[The db is not centralized. One per Zone.]

> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query 
> operations.

I don't really like this approach. It requires the requester to know 
too much about the implementation of the service: e.g, that there are zones, 
and that an instance will be placed in a particular zone. I would prefer 
something more along the lines of:

a. User issues a create-instance request, supplying the name of the instance to 
be created.
b. The top-level zone that receives the request does a zone-best-match and/or 
host-best-match call to determine where the instance will be created.
c. The top-level zone then passes the create-instance request to the selected 
zone/host.

[But what about subsequent actions ... the same zone-search would have be 
performed for each of them, no?]

-S


-- Ed Leafe





Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


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

Re: [Openstack] wiki.openstack.org broken in IE

[Colin Nicholson]

Not sure about StartingPage - it's not all that bad, and could easily
just be IE6, haven't ever looked at it in IE6 before.

As for the releasestatus page, I'd point my finger at the  at the top. That doesn't seem to be handled properly, stopping
all the css, js and image files from loading.


Colin

On 16/02/11 16:28, Thierry Carrez wrote:
> Ewan Mellor wrote:
>> Has someone changed Javascript or stylesheets on wiki.openstack.org
>> recently?  It’s broken in IE now, in a way that it wasn’t yesterday.
> Note that the releasestatus page and the rest of the wiki don't have any
> stylesheet in common, so that would rather point to a local issue...
>


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

Re: [Openstack] wiki.openstack.org broken in IE

[Colin Nicholson]

It looks similarly awful for me in IE6. Trying to see what's wrong now


Colin

On 16/02/11 16:28, Thierry Carrez wrote:
> Ewan Mellor wrote:
>> Has someone changed Javascript or stylesheets on wiki.openstack.org
>> recently?  It’s broken in IE now, in a way that it wasn’t yesterday.
> Note that the releasestatus page and the rest of the wiki don't have any
> stylesheet in common, so that would rather point to a local issue...


-- 
Colin Nicholson
Senior Software Developer

www.iomart.com
Main Switchboard: +44 (0)141 931 6400
Fax: +44 (0)141 931 6787

**
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential material. Statements and opinions 
expressed in this email may not represent those of the company. It is expressly 
declared that this email does not constitute or form part of a contract or 
unilateral obligation.
iomart Group plc. Reg No: SC204560. Reg Office: Lister Pavilion, Kelvin Campus, 
West of Scotland Science Park, Glasgow, G20 0SP
**


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

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Ed Leafe]

On Feb 16, 2011, at 10:26 AM, Sandy Walsh wrote:

> But this introduces a problem. Consider this use-case:
> 
> a. I issue a "create-instance" via the top-level API in zone-A
> b. the request is relayed down to zone-C
> c. the instance is created some time later 
>Q1. How does the user learn what the instance is named? For example, I 
> want to issue a "pause-instance" but don't know what to give as an instance 
> ID?

Isn't the instance name usually supplied by the user/originator?

>Q2. If I do "instance-list", do I have to search all zones again?

If the db is not centralized/replicated, yes. Caching could certainly 
be an option, especially in situations where instances tend to persist for long 
periods.

> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query 
> operations.
> 
> My above use-case would look like this:
> a. I issue a "find-best-zone" command to the top-level API in zone-A
> b. I get an API URL to zone-C
> c. I do my "create-instance" on zone-C, as well as all related operations. 

I don't really like this approach. It requires the requester to know 
too much about the implementation of the service: e.g, that there are zones, 
and that an instance will be placed in a particular zone. I would prefer 
something more along the lines of:

a. User issues a create-instance request, supplying the name of the instance to 
be created.
b. The top-level zone that receives the request does a zone-best-match and/or 
host-best-match call to determine where the instance will be created.
c. The top-level zone then passes the create-instance request to the selected 
zone/host.



-- Ed Leafe




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

Re: [Openstack] wiki.openstack.org broken in IE

[Thierry Carrez]

Ewan Mellor wrote:
> Has someone changed Javascript or stylesheets on wiki.openstack.org
> recently?  It’s broken in IE now, in a way that it wasn’t yesterday.

Note that the releasestatus page and the rest of the wiki don't have any
stylesheet in common, so that would rather point to a local issue...

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

[Openstack] Multi-Cluster/Zone - Devil in the Details ...

[Sandy Walsh]

Hi y'all

Like they say "The devil is in the details". I'm at the stage where the parent 
zones will talk to the child zones and there are some interesting 
implementation issues:

Problem 1. I'd like to pass the incoming HTTP Request object along to the 
Scheduler so I don't have to remarshall the command to send to the child zone.

Rather than modify all the *service/api.py methods to accept a request 
parameter, can anyone think of cleaner solution? I debated piggy-backing on the 
Context, but that's ugly.

Problem 2. I'm assuming only events that get routed through the scheduler 
should be candidates for being relayed to child zones. Currently, these are 
only volume/create_volume() and compute/create_instance().

But this introduces a problem. Consider this use-case:

a. I issue a "create-instance" via the top-level API in zone-A
b. the request is relayed down to zone-C
c. the instance is created some time later
   Q1. How does the user learn what the instance is named? For example, I want 
to issue a "pause-instance" but don't know what to give as an instance ID?
   Q2. If I do "instance-list", do I have to search all zones again?

Seems impractical if *every* command has to do a zone search every time.

One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query 
operations.

My above use-case would look like this:
a. I issue a "find-best-zone" command to the top-level API in zone-A
b. I get an API URL to zone-C
c. I do my "create-instance" on zone-C, as well as all related operations.

Yes, there is a potential race-condition if the zone changes radically in the 
time between operations. But anything could happen during that time, so it has 
to be anticipated. In this case the user should just start again at Step-A.

Also, this approach:
* keeps the code clean/small
* solves problem 1

Thoughts?

-S



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

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

[Openstack] [Nova] 2011.1.1 update

[Thierry Carrez]

Hello everyone,

At yesterday's meeting we considered additional fixes for inclusion into
the Bexar point release we have to do to care about the missing files
and translations in the Bexar release tarball.

We ended up targeting 3 additional fixes, see complete list here:
https://bugs.launchpad.net/nova/+milestone/2011.1.1

One issue with point releases is how do we test them. Most developers
are usually way into the development release so it's usually difficult
to divert them to test a point release (that's one of the reasons why
delegating that task to downstream distributions helps). In order to
minimize the risk, I think we should follow these guidelines:

* limit the number of fixes to the bare minimum
* only select low-regression-risk fixes
* the fix should appear and bake in the development release first
* the bug should contain a reproducible test case to externally validate
that the problem is indeed fixed
* a candidate tarball will be cut before 2011.1.1 formal release to help
with testing

Note that this point release does not set a precedent, 2011.1.1 being a
one-off to care about the missing files in 2011.1. The POC will formally
decide on a point release policy.

Regards,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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