Hi Mikhail, Vish, Kei,
I filed the blueprint below.
https://blueprints.launchpad.net/nova/+spec/kvm-block-migration
and, please check the full specification page too.
http://etherpad.openstack.org/kvm-block-migration
BTW, who is the appropriate person as the approver?
Also, I'm wondering
We're using quagga for route exchange (via ospf) between the network
servers, and the api server. The api server peers with each network
server. This is about as simple a quagga setup as you can have.
Basically, when nova-network starts up a new project network, quagga
begins to advertise that
Hi Lorin,
Zones can have multiple parents. Child Zones don't know their parents ...
parents only know about children.
Sharing services across Zones isn't permitted (since they would need to share a
DB and AMQP).
You could solve the problem by using the Capabilities to determine where
I assigned it to milestone 2 since there are already a lot of changes we are
trying to get in in milestone 1
Vish
On May 10, 2011, at 11:37 PM, Masanori ITOH wrote:
Hi Mikhail, Vish, Kei,
I filed the blueprint below.
https://blueprints.launchpad.net/nova/+spec/kvm-block-migration
On May 11, 2011, at 10:47 AM, Matt Dietz wrote:
Hey Seshu,
1) Yes, that will be contained within the publisher_id field of the message body
2) We should be able to get customer related data from the message where it
makes sense. It would be contained within the payload dictionary. Given that
Hi Sandy:
Do you know if there are there any nova branches floating out there that
implement Capabilities? I've seen the following related wiki pages and
blueprints, but I haven't found any implementations out there yet.
https://blueprints.launchpad.net/nova/+spec/extra-data
Mark's been a very good reviewer and an invaluable resource on the API
side, particularly regarding serialization. I propose he join
nova-core.
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Hey all,
I'm going to remove myself from the nova-core group. I'll still do
reviews and stuff, but I've been focusing a lot on Glance, and there
are much more knowledgeable folks already on and proposed for
nova-core.
Not sure if this is the way to go about resigning from nova-core,
but since
+1
On May 11, 2011, at 10:06 AM, Jay Pipes wrote:
Subject says it all. I think Brian's demonstrated that his code
reviews are thoughtful and thorough, and he knows the OpenStack API
controller stuff as well as anyone else I believe.
Cheers,
jay
+1
On May 11, 2011, at 10:07 AM, Jay Pipes wrote:
Mark's been a very good reviewer and an invaluable resource on the API
side, particularly regarding serialization. I propose he join
nova-core.
-jay
___
Mailing list:
Hello Everyone,
We have quite a large backlog of merge proposals here:
https://code.launchpad.net/~rlane/nova/lp773690/+merge/59565
I've been attempting to go through them to find some high priority ones to
review. It seems like people are being pretty active in reviewing branches,
but there
On May 11, 2011, at 1:06 PM, Jay Pipes wrote:
Subject says it all. I think Brian's demonstrated that his code
reviews are thoughtful and thorough, and he knows the OpenStack API
controller stuff as well as anyone else I believe.
Definitely! +1
-- Ed Leafe
Confidentiality Notice:
I've been thinking of doing the same to focus on Burrow since I've
not been following many of the nova discussions lately and there are
so many new folks involved in -core. I think I'll follow your lead,
but I'll still be around for reviews where I'm useful.
-Eric
On Wed, May 11, 2011 at
++ on your suggestions.
On Wed, May 11, 2011 at 3:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Hello Everyone,
We have quite a large backlog of merge proposals here:
https://code.launchpad.net/~rlane/nova/lp773690/+merge/59565
I've been attempting to go through them to find some
I'm not nova-core, but this makes a heck of a lot of sense to me, too.
On May 11, 2011, at 1:16 PM, Jay Pipes wrote:
++ on your suggestions.
On Wed, May 11, 2011 at 3:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Hello Everyone,
We have quite a large backlog of merge proposals
+1
On 5/11/11 3:01 PM, Ed Leafe ed.le...@rackspace.com wrote:
On May 11, 2011, at 1:06 PM, Jay Pipes wrote:
Subject says it all. I think Brian's demonstrated that his code
reviews are thoughtful and thorough, and he knows the OpenStack API
controller stuff as well as anyone else I believe.
+1
On 5/11/11 3:02 PM, Ed Leafe e...@leafe.com wrote:
On May 11, 2011, at 1:07 PM, Jay Pipes wrote:
Mark's been a very good reviewer and an invaluable resource on the API
side, particularly regarding serialization. I propose he join
nova-core.
+1
-- Ed Leafe
2011/5/11 Vishvananda Ishaya vishvana...@gmail.com:
I'd also like to propose a change to our process that will make the ready to
[...]
once the changes have come in. Does this seem acceptable to everyone? If I
don't here any major dissents, I will add this info to the wiki and we can
put it
+1
On 5/11/11 3:16 PM, Jay Pipes jaypi...@gmail.com wrote:
++ on your suggestions.
On Wed, May 11, 2011 at 3:38 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Hello Everyone,
We have quite a large backlog of merge proposals here:
Hey again!
dabo, sirp and myself have been working on the Distributed Scheduler branch,
which does all this.
It's a large branch, so while Ed (dabo) continues on getting things functional,
myself and Rick (sirp) have started pulling chunks of code from the branch and
getting smaller
+1
I just SmokeStack'ed a couple more suspiciously old branches and marked them
needs fixing because they didn't merge w/ trunk. Most of which already had
needs fixing for other reasons anyway.
---
Also, I've been sitting on lp:~dan-prince/nova/chown_vdb_device for a month
now. I'm happy to
Sandy:
I took a quick look at see how capabilities are represented and how the
information flows from the ComputeManager to the ZoneManager, it looks great. I
see you're using the message queue (RPC call) instead of storing the capability
info in the database. Anxiously awaiting for this code
Cool! Glad to hear we're on the right path. Yes, we're using rabbit to send the
metrics to the schedulers since they're largely ephemeral.
We'll be using the existing scheduler.host_filter:HostFilter code to fill out
the filter_hosts() method. Other groups will be making more drivers for that
23 matches
Mail list logo
