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

Mailing List Archive: OpenStack: Netstack

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

 

 

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


gkotton at redhat

Jul 17, 2012, 2:32 AM

Post #1 of 2 (188 views)
Permalink
Re: [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


snaiksat at cisco

Jul 17, 2012, 9:02 AM

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

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

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.