Re: [Openstack] POC for Pluggable Network Service

2011-04-01 Thread 石井 久治
Hi Ryu, I appreciate your feedbacks to my design. And we welcome your contributes to this project. I created a new LaunchPad team ~nova-network-poc and invited your team ~midokura to it. Please approve this invitation, then you can commit to lp:~nova-network-poc/nova/network-service, which is

Re: [Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus

2011-04-01 Thread Thierry Carrez
Gabe Westmaas wrote: Given this, what makes the most sense to me is to focus on stability for version 1.0 API excluding XML support. The bindings that are out there have strong support for the JSON data formats in v1.0. As suggested, I think we call the current mostly implemented 1.1 API

Re: [Openstack] POC for Pluggable Network Service

2011-04-01 Thread Ishimoto, Ryu
Hi Hisaharu, Ah, sorry we actually already created our own branch: lp: ~midokura/nova/network-servicehttps://code.launchpad.net/~midokura/nova/network-service. We'll be committing our stuff there. Thanks! Ryu 2011/4/1 石井 久治 ishii.hisah...@lab.ntt.co.jp Hi Ryu, I appreciate your feedbacks

Re: [Openstack] Feature Freeze status

2011-04-01 Thread FUJITA Tomonori
On Thu, 31 Mar 2011 10:02:34 +0200 Soren Hansen so...@openstack.org wrote: 2011/3/31 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: Sounds like the importance of blueprints is overrated. If you look at Linux kernel development (more than ten times developers and development speed, I

Re: [Openstack] Feature Freeze status

2011-04-01 Thread Jay Pipes
On Fri, Apr 1, 2011 at 8:41 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: I bet that we'll face more serious shortage of reviewing with developers increasing. In genera, developers prefer to write own code rather than reviewing. We can't change the nature. Yes, this is certainly

[Openstack] heterogeneous instance types

2011-04-01 Thread Brian Schott
I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes They could use some reviews in advance of the

Re: [Openstack] Feature Freeze status

2011-04-01 Thread Jay Pipes
On Fri, Apr 1, 2011 at 9:19 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: Yeah, but discussion on the mailing list before the summit is useful (developers who can't attend the summit are able to discuss, I might not be able to make it too). True enough :) Didn't mean to suggest the

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-01 Thread Sandy Walsh
I was stewing on the suggestion of subject/verb/object tuples. There's a gotcha in the federated AuthZ situation: mapping Public and Private Objects in the tuples. Essentially, who owns the rights over the object if the object is externally managed (by, let's say, a service provider). My

Re: [Openstack] heterogeneous instance types

2011-04-01 Thread Thierry Carrez
Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types http://wiki.openstack.org/HeterogeneousInstanceTypes Hey Brian, interesting

Re: [Openstack] heterogeneous instance types

2011-04-01 Thread Lorin Hochstein
On Apr 1, 2011, at 10:55 AM, Thierry Carrez wrote: Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release: https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types

Re: [Openstack] heterogeneous instance types

2011-04-01 Thread Chuck Short
On Fri, 01 Apr 2011 16:55:36 +0200 Thierry Carrez thie...@openstack.org wrote: Brian Schott wrote: I've uploaded a family of related of blueprints that the USC-ISI team is hoping to integrate into the Diablo release:

Re: [Openstack] heterogeneous instance types

2011-04-01 Thread Brian Schott
That is a good idea if the networking service supports it. One of the things we've been thinking about is how to best to make the virt subsystem more modular. It really needs a better driver-style interface with plugins for non-libvirt virts, I think. Mikyung actually had to build a bare

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-01 Thread Vishvananda Ishaya
Made a few notes on thoughts at the bottom. I won't replicate the notes here because it kind of requires reading through the link you supplied first. In short, I think we have some options for keeping AuthZ isolated to a given deployment and even a given service. I like this approach,

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-01 Thread Sandy Walsh
For those of you following along at home ... there was a big IRC discussion around this: http://paste.openstack.org/show/1075/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or

Re: [Openstack] Feature Freeze status

2011-04-01 Thread Soren Hansen
2011/4/1 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: On Thu, 31 Mar 2011 10:02:34 +0200 Soren Hansen so...@openstack.org wrote: 2011/3/31 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp: Sounds like the importance of blueprints is overrated. If you look at Linux kernel development (more

Re: [Openstack] Feature Freeze status

2011-04-01 Thread FUJITA Tomonori
On Fri, 1 Apr 2011 22:02:02 +0200 Soren Hansen so...@openstack.org wrote: I already saw the shortage of reviewing (and I even saw that a half-baked feature without enough reviewed was merged and reverted). Yes! EXACTLY! Because people who ought to be reviewing aren't. I think that we

Re: [Openstack] heterogeneous instance types

2011-04-01 Thread Ferran Rodenas
Brian, nice spec! It's a great example of why I appreciate detailed blueprints. Although I think it's very interesting to store more information about instance types, I'd be more cautious in creating new columns if it's not strictly necessary. I'd prefer a metadata table, something similar to the