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) <snaik...@cisco.com>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....@lists.launchpad.net
> > [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On
> > Behalf Of Gary Kotton
> > Sent: Tuesday, July 17, 2012 2:33 AM
> > To: netstack@lists.launchpad.net
> > 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@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~netstack
> > More help : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
