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