Open Stack

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



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120717/7fb5d6c7/attachment.html>