Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Netstack

[Quantum] Starting a discussion on the official spec for v2 API

 

 

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded


sorlando at nicira

Jul 17, 2012, 12:28 AM

Post #1 of 7 (346 views)
Permalink
[Quantum] Starting a discussion on the official spec for v2 API

Hello people of Quantum!
As the Folsom release approaches, it is time to gather together and
finalize the specification for the v2 API, so that the Openstack-doc team
might cast it in stone for the sake of the Quantum users!

In order to make this happen, it looks like there are just a few bits that
needs to be agreed upon, and I think they can be summarized as follows:
- 'name' attributes and whether they should be mandatory. It looks like we
all agree we want them, but it has to be decided whether
i) they should be unique or not.
ii) they should be mandatory or not.
- 'public' attribute for networks. As we did not get negative feedback on
the proposal, I am going to assume nobody has strong opinions against this
decision.
- security group API. We have a blueprint open and targeted to F-3 (
https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups).
Personally I do not feel it is a good idea at this stage proposing them for
the core v2 API in Folsom. Apart from the necessary discussion concerning
the APIs, we will need support across all the plugins, which is hardly
going to happen IMHO. If you have a different opinion, this is the right
thread to shout it!
- NOTE: Leaving the security groups outside of Quantum core API also
means that we *must* ensure Quantum still allows Nova to use its own
firewall drivers.
- L3 features (
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat): among
the various sub-blueprints in which this blueprint can be broken, there's
one concerning APIs. As I have not followed the development of this
particular blueprint, I'll leave it to Dan whether L3 & NAT APIs should be
part of Folsom core.

>From my perspective, the above list includes all the items concerning the
Quantum v2 API which have not yet stabilized. Please do let me know if I
forgot anything.

Thanks and have a good day,
Salvatore


dan at nicira

Jul 17, 2012, 7:08 AM

Post #2 of 7 (337 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

On Tue, Jul 17, 2012 at 12:28 AM, Salvatore Orlando <sorlando [at] nicira>wrote:
>
>
> In order to make this happen, it looks like there are just a few bits that
> needs to be agreed upon, and I think they can be summarized as follows:
> - 'name' attributes and whether they should be mandatory. It looks like we
> all agree we want them, but it has to be decided whether
> i) they should be unique or not.
> ii) they should be mandatory or not.
> - 'public' attribute for networks. As we did not get negative feedback on
> the proposal, I am going to assume nobody has strong opinions against this
> decision.
>

I agree. While its tempting to try and build something more generic, this
is a key use case we must handle in Folsom, and having a notion of an API
being 'public' seems analogous to something like a public disk image in
glance.


> - security group API. We have a blueprint open and targeted to F-3 (
> https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups).
> Personally I do not feel it is a good idea at this stage proposing them for
> the core v2 API in Folsom. Apart from the necessary discussion concerning
> the APIs, we will need support across all the plugins, which is hardly
> going to happen IMHO. If you have a different opinion, this is the right
> thread to shout it!
> - NOTE: Leaving the security groups outside of Quantum core API also
> means that we *must* ensure Quantum still allows Nova to use its own
> firewall drivers.
> - L3 features (
> https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat): among
> the various sub-blueprints in which this blueprint can be broken, there's
> one concerning APIs. As I have not followed the development of this
> particular blueprint, I'll leave it to Dan whether L3 & NAT APIs should be
> part of Folsom core.
>


At the summit we decided to keep the scope of the v2 "core" API to
essentially the combination of the quantum v1 API and the melange API.
Additional items like configuring L3 forwarding, floating ips, and
security groups will be extensions. I agree that for Folsom, it is likely
the case that most plugins will just stick with Nova security groups due to
a lack of time.



>
> From my perspective, the above list includes all the items concerning the
> Quantum v2 API which have not yet stabilized. Please do let me know if I
> forgot anything.
>

I'm sure more corner case discussions will pop-up, they always do. For
example, while there's been some discussion on the topic, I think there's
still some work to be done with respect to batch operations, in particular,
their failure semantics.

Thanks for driving this.

Dan



>
> Thanks and have a good day,
> Salvatore
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


nachi at nttmcl

Jul 17, 2012, 10:17 AM

Post #3 of 7 (341 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

Hi folks

I'm +1 for a network type attribute, because the simple change can
support another usecase.

I'm going to implement this rosetta-plugin which can support multiple
types of networks.
https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin

2012/7/17 Sumit Naiksatam (snaiksat) <snaiksat [at] cisco>:
> Hi All,
>
> I second Gary's suggestion here for a network type attribute. I was curious to know why we moved away from the kwargs mechanism which we had earlier in the core API. That made it easier to pass any plugin-specific parameters which need not be core attributes, and not have to necessarily implement an extension for that.
>
> Thanks,
> ~Sumit.
>
>
>
>> -----Original Message-----
>> From: netstack-bounces+snaiksat=cisco.com [at] lists
>> [mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
>> Behalf Of Gary Kotton
>> Sent: Tuesday, July 17, 2012 2:33 AM
>> To: netstack [at] lists
>> Subject: Re: [Netstack] [Quantum] Starting a discussion on the official spec
>> for v2 API
>>
>> On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
>> > Hello people of Quantum!
>> > As the Folsom release approaches, it is time to gather together and
>> > finalize the specification for the v2 API, so that the Openstack-doc
>> > team might cast it in stone for the sake of the Quantum users!
>> >
>> > In order to make this happen, it looks like there are just a few bits
>> > that needs to be agreed upon, and I think they can be summarized as
>> > follows:
>> > - 'name' attributes and whether they should be mandatory. It looks
>> > like we all agree we want them, but it has to be decided whether
>> > i) they should be unique or not.
>> > ii) they should be mandatory or not.
>>
>> Originally when I started to use Quantum I found it very awkward that the
>> name was not unique. My understanding from the meeting last night was
>> that it will no longer be mandatory for a network and does not need to be
>> unique. I wrote a mail to the list this morning suggesting that we use
>> description instead of name. Personally I think that this is a less binding way
>> of describing a network, subnet or port.
>>
>>
>> > - 'public' attribute for networks. As we did not get negative feedback
>> > on the proposal, I am going to assume nobody has strong opinions
>> > against this decision.
>>
>> I would have preferred network type as it is more generic. Nonetheless I do
>> not have any strong objections to this.
>>
>> > - security group API. We have a blueprint open and targeted to F-3
>> > (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
>> groups).
>> > Personally I do not feel it is a good idea at this stage proposing
>> > them for the core v2 API in Folsom. Apart from the necessary
>> > discussion concerning the APIs, we will need support across all the
>> > plugins, which is hardly going to happen IMHO. If you have a different
>> > opinion, this is the right thread to shout it!
>>
>> I agree with you. I think that we still have a few road bumps to deal with. For
>> example when using devstack with Quantum V2 and the DHCP agent, the
>> DHCP requests do not arrive at the dnsmasq interface ... I am trying to
>> understand the reason for this. I have set the libvirt drivers to
>> "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not sure
>> if this is enough. Any help will be great.
>>
>> > - NOTE: Leaving the security groups outside of Quantum core API
>> > also means that we *must* ensure Quantum still allows Nova to use its
>> > own firewall drivers.
>> > - L3 features
>> > (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
>> > among the various sub-blueprints in which this blueprint can be
>> > broken, there's one concerning APIs. As I have not followed the
>> > development of this particular blueprint, I'll leave it to Dan whether
>> > L3 & NAT APIs should be part of Folsom core.
>> >
>> > From my perspective, the above list includes all the items concerning
>> > the Quantum v2 API which have not yet stabilized. Please do let me
>> > know if I forgot anything.
>> >
>> > Thanks and have a good day,
>> > Salvatore
>> >
>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack [at] lists
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


sorlando at nicira

Jul 17, 2012, 10:22 AM

Post #4 of 7 (337 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

Thanks for your feedback.
I am pretty sure more inputs will come into this thread. However, it seems
we agree to keep security groups / L3 / Floating IP / NAT api outside of
the core for Quantum.

Some discussion is instead going on:
1) how public networks should be described: public: { true | false } vs
network_type: { public | private }
2) naming for the 'symbolic name' attribute - current proposals: name,
name-label, description
3) whether the 'symbolic name' should be optional or not (and hence not a
symbolic name) [.it looks like most people agree on making it optional
anyway]

I am thinking of creating a Launchpad poll for collecting people's
opinions, so that we can take an informed decision at the next Quantum
meeting. Would that work for you? We can keep using this thread for
discussion.

Salvatore

On 17 July 2012 09:02, Sumit Naiksatam (snaiksat) <snaiksat [at] cisco>wrote:

> Hi All,
>
> I second Gary's suggestion here for a network type attribute. I was
> curious to know why we moved away from the kwargs mechanism which we had
> earlier in the core API. That made it easier to pass any plugin-specific
> parameters which need not be core attributes, and not have to necessarily
> implement an extension for that.
>
> Thanks,
> ~Sumit.
>
>
>
> > -----Original Message-----
> > From: netstack-bounces+snaiksat=cisco.com [at] lists
> > [mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
> > Behalf Of Gary Kotton
> > Sent: Tuesday, July 17, 2012 2:33 AM
> > To: netstack [at] lists
> > Subject: Re: [Netstack] [Quantum] Starting a discussion on the official
> spec
> > for v2 API
> >
> > On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
> > > Hello people of Quantum!
> > > As the Folsom release approaches, it is time to gather together and
> > > finalize the specification for the v2 API, so that the Openstack-doc
> > > team might cast it in stone for the sake of the Quantum users!
> > >
> > > In order to make this happen, it looks like there are just a few bits
> > > that needs to be agreed upon, and I think they can be summarized as
> > > follows:
> > > - 'name' attributes and whether they should be mandatory. It looks
> > > like we all agree we want them, but it has to be decided whether
> > > i) they should be unique or not.
> > > ii) they should be mandatory or not.
> >
> > Originally when I started to use Quantum I found it very awkward that the
> > name was not unique. My understanding from the meeting last night was
> > that it will no longer be mandatory for a network and does not need to be
> > unique. I wrote a mail to the list this morning suggesting that we use
> > description instead of name. Personally I think that this is a less
> binding way
> > of describing a network, subnet or port.
> >
> >
> > > - 'public' attribute for networks. As we did not get negative feedback
> > > on the proposal, I am going to assume nobody has strong opinions
> > > against this decision.
> >
> > I would have preferred network type as it is more generic. Nonetheless I
> do
> > not have any strong objections to this.
> >
> > > - security group API. We have a blueprint open and targeted to F-3
> > > (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
> > groups).
> > > Personally I do not feel it is a good idea at this stage proposing
> > > them for the core v2 API in Folsom. Apart from the necessary
> > > discussion concerning the APIs, we will need support across all the
> > > plugins, which is hardly going to happen IMHO. If you have a different
> > > opinion, this is the right thread to shout it!
> >
> > I agree with you. I think that we still have a few road bumps to deal
> with. For
> > example when using devstack with Quantum V2 and the DHCP agent, the
> > DHCP requests do not arrive at the dnsmasq interface ... I am trying to
> > understand the reason for this. I have set the libvirt drivers to
> > "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not sure
> > if this is enough. Any help will be great.
> >
> > > - NOTE: Leaving the security groups outside of Quantum core API
> > > also means that we *must* ensure Quantum still allows Nova to use its
> > > own firewall drivers.
> > > - L3 features
> > > (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
> > > among the various sub-blueprints in which this blueprint can be
> > > broken, there's one concerning APIs. As I have not followed the
> > > development of this particular blueprint, I'll leave it to Dan whether
> > > L3 & NAT APIs should be part of Folsom core.
> > >
> > > From my perspective, the above list includes all the items concerning
> > > the Quantum v2 API which have not yet stabilized. Please do let me
> > > know if I forgot anything.
> > >
> > > Thanks and have a good day,
> > > Salvatore
> > >
> >
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> > Post to : netstack [at] lists
> > Unsubscribe : https://launchpad.net/~netstack
> > More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>


kmestery at cisco

Jul 17, 2012, 11:29 AM

Post #5 of 7 (338 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

I'll add my vote for network type attribute as well. Nachi's proposal below is a good example of how this can be used as well.

Thanks,
Kyle

On Jul 17, 2012, at 12:17 PM, Nachi Ueno wrote:

> Hi folks
>
> I'm +1 for a network type attribute, because the simple change can
> support another usecase.
>
> I'm going to implement this rosetta-plugin which can support multiple
> types of networks.
> https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin
>
> 2012/7/17 Sumit Naiksatam (snaiksat) <snaiksat [at] cisco>:
>> Hi All,
>>
>> I second Gary's suggestion here for a network type attribute. I was curious to know why we moved away from the kwargs mechanism which we had earlier in the core API. That made it easier to pass any plugin-specific parameters which need not be core attributes, and not have to necessarily implement an extension for that.
>>
>> Thanks,
>> ~Sumit.
>>
>>
>>
>>> -----Original Message-----
>>> From: netstack-bounces+snaiksat=cisco.com [at] lists
>>> [mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
>>> Behalf Of Gary Kotton
>>> Sent: Tuesday, July 17, 2012 2:33 AM
>>> To: netstack [at] lists
>>> Subject: Re: [Netstack] [Quantum] Starting a discussion on the official spec
>>> for v2 API
>>>
>>> On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
>>>> Hello people of Quantum!
>>>> As the Folsom release approaches, it is time to gather together and
>>>> finalize the specification for the v2 API, so that the Openstack-doc
>>>> team might cast it in stone for the sake of the Quantum users!
>>>>
>>>> In order to make this happen, it looks like there are just a few bits
>>>> that needs to be agreed upon, and I think they can be summarized as
>>>> follows:
>>>> - 'name' attributes and whether they should be mandatory. It looks
>>>> like we all agree we want them, but it has to be decided whether
>>>> i) they should be unique or not.
>>>> ii) they should be mandatory or not.
>>>
>>> Originally when I started to use Quantum I found it very awkward that the
>>> name was not unique. My understanding from the meeting last night was
>>> that it will no longer be mandatory for a network and does not need to be
>>> unique. I wrote a mail to the list this morning suggesting that we use
>>> description instead of name. Personally I think that this is a less binding way
>>> of describing a network, subnet or port.
>>>
>>>
>>>> - 'public' attribute for networks. As we did not get negative feedback
>>>> on the proposal, I am going to assume nobody has strong opinions
>>>> against this decision.
>>>
>>> I would have preferred network type as it is more generic. Nonetheless I do
>>> not have any strong objections to this.
>>>
>>>> - security group API. We have a blueprint open and targeted to F-3
>>>> (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
>>> groups).
>>>> Personally I do not feel it is a good idea at this stage proposing
>>>> them for the core v2 API in Folsom. Apart from the necessary
>>>> discussion concerning the APIs, we will need support across all the
>>>> plugins, which is hardly going to happen IMHO. If you have a different
>>>> opinion, this is the right thread to shout it!
>>>
>>> I agree with you. I think that we still have a few road bumps to deal with. For
>>> example when using devstack with Quantum V2 and the DHCP agent, the
>>> DHCP requests do not arrive at the dnsmasq interface ... I am trying to
>>> understand the reason for this. I have set the libvirt drivers to
>>> "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not sure
>>> if this is enough. Any help will be great.
>>>
>>>> - NOTE: Leaving the security groups outside of Quantum core API
>>>> also means that we *must* ensure Quantum still allows Nova to use its
>>>> own firewall drivers.
>>>> - L3 features
>>>> (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
>>>> among the various sub-blueprints in which this blueprint can be
>>>> broken, there's one concerning APIs. As I have not followed the
>>>> development of this particular blueprint, I'll leave it to Dan whether
>>>> L3 & NAT APIs should be part of Folsom core.
>>>>
>>>> From my perspective, the above list includes all the items concerning
>>>> the Quantum v2 API which have not yet stabilized. Please do let me
>>>> know if I forgot anything.
>>>>
>>>> Thanks and have a good day,
>>>> Salvatore
>>>>
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~netstack
>>> Post to : netstack [at] lists
>>> Unsubscribe : https://launchpad.net/~netstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack [at] lists
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack [at] lists
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

Jul 17, 2012, 12:57 PM

Post #6 of 7 (341 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

Adding openstack-dev, as all discussion should go on there.

I think we need to be very careful here, as people are championing a
"network type" field, but for two very different use cases that I feel
don't make sense together.

What Salvatore is talking about is a notion of a "public network" that has
different rules in terms of authz (namely, that someone other than the
owner has limited permissions to create and view a subset of the networks).

What Nachi and others are talking about is akin to what we have in the past
called a "flavor" of a network (not sure I'm a fan of that term, but
anyway..). This is saying that one quantum network may have different
properties (e.g., created by plugin X vs. plugin Y).

Both seem like valid use cases, but using the same mechanism for both
strikes me as quite confusing, as they strike me as orthogonal (i.e., I
could create a network that is either public or private and independently
choose the flavor of that network).

I'm not sure a poll makes sense, as these are not mutually exclusive
options. I'm in favor of sticking pretty close to what Salvatore proposed
for the notion of a public network (again, this is about authz and would be
the same across all quantum deployments), and allowing for another
mechanism if we need to have a flavor-like notion (presumably, each quantum
deployment might expose different sets of network flavors).

Dan

p.s. Sumit, the entire network/subnet/port object is now passed to the
plugin, so I would expect that you already have access to additional
parameters passed in with the request. Or are you finding that those are
filtered out somewhere?

On Tue, Jul 17, 2012 at 11:29 AM, Kyle Mestery (kmestery) <
kmestery [at] cisco> wrote:

> I'll add my vote for network type attribute as well. Nachi's proposal
> below is a good example of how this can be used as well.
>
> Thanks,
> Kyle
>
> On Jul 17, 2012, at 12:17 PM, Nachi Ueno wrote:
>
> > Hi folks
> >
> > I'm +1 for a network type attribute, because the simple change can
> > support another usecase.
> >
> > I'm going to implement this rosetta-plugin which can support multiple
> > types of networks.
> > https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin
> >
> > 2012/7/17 Sumit Naiksatam (snaiksat) <snaiksat [at] cisco>:
> >> Hi All,
> >>
> >> I second Gary's suggestion here for a network type attribute. I was
> curious to know why we moved away from the kwargs mechanism which we had
> earlier in the core API. That made it easier to pass any plugin-specific
> parameters which need not be core attributes, and not have to necessarily
> implement an extension for that.
> >>
> >> Thanks,
> >> ~Sumit.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: netstack-bounces+snaiksat=cisco.com [at] lists
> >>> [mailto:netstack-bounces+snaiksat=cisco.com [at] lists] On
> >>> Behalf Of Gary Kotton
> >>> Sent: Tuesday, July 17, 2012 2:33 AM
> >>> To: netstack [at] lists
> >>> Subject: Re: [Netstack] [Quantum] Starting a discussion on the
> official spec
> >>> for v2 API
> >>>
> >>> On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
> >>>> Hello people of Quantum!
> >>>> As the Folsom release approaches, it is time to gather together and
> >>>> finalize the specification for the v2 API, so that the Openstack-doc
> >>>> team might cast it in stone for the sake of the Quantum users!
> >>>>
> >>>> In order to make this happen, it looks like there are just a few bits
> >>>> that needs to be agreed upon, and I think they can be summarized as
> >>>> follows:
> >>>> - 'name' attributes and whether they should be mandatory. It looks
> >>>> like we all agree we want them, but it has to be decided whether
> >>>> i) they should be unique or not.
> >>>> ii) they should be mandatory or not.
> >>>
> >>> Originally when I started to use Quantum I found it very awkward that
> the
> >>> name was not unique. My understanding from the meeting last night was
> >>> that it will no longer be mandatory for a network and does not need to
> be
> >>> unique. I wrote a mail to the list this morning suggesting that we use
> >>> description instead of name. Personally I think that this is a less
> binding way
> >>> of describing a network, subnet or port.
> >>>
> >>>
> >>>> - 'public' attribute for networks. As we did not get negative feedback
> >>>> on the proposal, I am going to assume nobody has strong opinions
> >>>> against this decision.
> >>>
> >>> I would have preferred network type as it is more generic. Nonetheless
> I do
> >>> not have any strong objections to this.
> >>>
> >>>> - security group API. We have a blueprint open and targeted to F-3
> >>>> (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
> >>> groups).
> >>>> Personally I do not feel it is a good idea at this stage proposing
> >>>> them for the core v2 API in Folsom. Apart from the necessary
> >>>> discussion concerning the APIs, we will need support across all the
> >>>> plugins, which is hardly going to happen IMHO. If you have a different
> >>>> opinion, this is the right thread to shout it!
> >>>
> >>> I agree with you. I think that we still have a few road bumps to deal
> with. For
> >>> example when using devstack with Quantum V2 and the DHCP agent, the
> >>> DHCP requests do not arrive at the dnsmasq interface ... I am trying to
> >>> understand the reason for this. I have set the libvirt drivers to
> >>> "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not
> sure
> >>> if this is enough. Any help will be great.
> >>>
> >>>> - NOTE: Leaving the security groups outside of Quantum core API
> >>>> also means that we *must* ensure Quantum still allows Nova to use its
> >>>> own firewall drivers.
> >>>> - L3 features
> >>>> (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
> >>>> among the various sub-blueprints in which this blueprint can be
> >>>> broken, there's one concerning APIs. As I have not followed the
> >>>> development of this particular blueprint, I'll leave it to Dan whether
> >>>> L3 & NAT APIs should be part of Folsom core.
> >>>>
> >>>> From my perspective, the above list includes all the items concerning
> >>>> the Quantum v2 API which have not yet stabilized. Please do let me
> >>>> know if I forgot anything.
> >>>>
> >>>> Thanks and have a good day,
> >>>> Salvatore
> >>>>
> >>>
> >>>
> >>> --
> >>> Mailing list: https://launchpad.net/~netstack
> >>> Post to : netstack [at] lists
> >>> Unsubscribe : https://launchpad.net/~netstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>
> >> --
> >> Mailing list: https://launchpad.net/~netstack
> >> Post to : netstack [at] lists
> >> Unsubscribe : https://launchpad.net/~netstack
> >> More help : https://help.launchpad.net/ListHelp
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> > Post to : netstack [at] lists
> > Unsubscribe : https://launchpad.net/~netstack
> > More help : https://help.launchpad.net/ListHelp
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack [at] lists
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


itzikb at dev

Jul 26, 2012, 2:53 PM

Post #7 of 7 (311 views)
Permalink
Re: [Quantum] Starting a discussion on the official spec for v2 API [In reply to]

Hi,

As for the public networks I'll go with public: { true | false }.
network_type may be devoted for other purpose.

Itzik

On 7/17/2012 8:22 PM, Salvatore Orlando wrote:
> Thanks for your feedback.
> I am pretty sure more inputs will come into this thread. However, it
> seems we agree to keep security groups / L3 / Floating IP / NAT api
> outside of the core for Quantum.
>
> Some discussion is instead going on:
> 1) how public networks should be described: public: { true | false }
> vs network_type: { public | private }
> 2) naming for the 'symbolic name' attribute - current proposals: name,
> name-label, description
> 3) whether the 'symbolic name' should be optional or not (and hence
> not a symbolic name) [.it looks like most people agree on making it
> optional anyway]
>
> I am thinking of creating a Launchpad poll for collecting people's
> opinions, so that we can take an informed decision at the next Quantum
> meeting. Would that work for you? We can keep using this thread for
> discussion.
>
> Salvatore
>
> On 17 July 2012 09:02, Sumit Naiksatam (snaiksat) <snaiksat [at] cisco
> <mailto:snaiksat [at] cisco>> wrote:
>
> Hi All,
>
> I second Gary's suggestion here for a network type attribute. I
> was curious to know why we moved away from the kwargs mechanism
> which we had earlier in the core API. That made it easier to pass
> any plugin-specific parameters which need not be core attributes,
> and not have to necessarily implement an extension for that.
>
> Thanks,
> ~Sumit.
>
>
>
> > -----Original Message-----
> > From: netstack-bounces+snaiksat=cisco.com [at] lists
> <mailto:cisco.com [at] lists>
> > [mailto:netstack-bounces+snaiksat
> <mailto:netstack-bounces%2Bsnaiksat>=cisco.com [at] lists
> <mailto:cisco.com [at] lists>] On
> > Behalf Of Gary Kotton
> > Sent: Tuesday, July 17, 2012 2:33 AM
> > To: netstack [at] lists
> <mailto:netstack [at] lists>
> > Subject: Re: [Netstack] [Quantum] Starting a discussion on the
> official spec
> > for v2 API
> >
> > On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
> > > Hello people of Quantum!
> > > As the Folsom release approaches, it is time to gather
> together and
> > > finalize the specification for the v2 API, so that the
> Openstack-doc
> > > team might cast it in stone for the sake of the Quantum users!
> > >
> > > In order to make this happen, it looks like there are just a
> few bits
> > > that needs to be agreed upon, and I think they can be
> summarized as
> > > follows:
> > > - 'name' attributes and whether they should be mandatory. It looks
> > > like we all agree we want them, but it has to be decided whether
> > > i) they should be unique or not.
> > > ii) they should be mandatory or not.
> >
> > Originally when I started to use Quantum I found it very awkward
> that the
> > name was not unique. My understanding from the meeting last
> night was
> > that it will no longer be mandatory for a network and does not
> need to be
> > unique. I wrote a mail to the list this morning suggesting that
> we use
> > description instead of name. Personally I think that this is a
> less binding way
> > of describing a network, subnet or port.
> >
> >
> > > - 'public' attribute for networks. As we did not get negative
> feedback
> > > on the proposal, I am going to assume nobody has strong opinions
> > > against this decision.
> >
> > I would have preferred network type as it is more generic.
> Nonetheless I do
> > not have any strong objections to this.
> >
> > > - security group API. We have a blueprint open and targeted to F-3
> > > (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
> > groups).
> > > Personally I do not feel it is a good idea at this stage proposing
> > > them for the core v2 API in Folsom. Apart from the necessary
> > > discussion concerning the APIs, we will need support across
> all the
> > > plugins, which is hardly going to happen IMHO. If you have a
> different
> > > opinion, this is the right thread to shout it!
> >
> > I agree with you. I think that we still have a few road bumps to
> deal with. For
> > example when using devstack with Quantum V2 and the DHCP agent, the
> > DHCP requests do not arrive at the dnsmasq interface ... I am
> trying to
> > understand the reason for this. I have set the libvirt drivers to
> > "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver"
> Not sure
> > if this is enough. Any help will be great.
> >
> > > - NOTE: Leaving the security groups outside of Quantum
> core API
> > > also means that we *must* ensure Quantum still allows Nova to
> use its
> > > own firewall drivers.
> > > - L3 features
> > >
> (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
> > > among the various sub-blueprints in which this blueprint can be
> > > broken, there's one concerning APIs. As I have not followed the
> > > development of this particular blueprint, I'll leave it to Dan
> whether
> > > L3 & NAT APIs should be part of Folsom core.
> > >
> > > From my perspective, the above list includes all the items
> concerning
> > > the Quantum v2 API which have not yet stabilized. Please do let me
> > > know if I forgot anything.
> > >
> > > Thanks and have a good day,
> > > Salvatore
> > >
> >
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> > Post to : netstack [at] lists
> <mailto:netstack [at] lists>
> > Unsubscribe : https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> > More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> Post to : netstack [at] lists
> <mailto:netstack [at] lists>
> Unsubscribe : https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
>

OpenStack netstack RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.