Open Stack

On 07/17/2012 03:57 PM, Dan Wendlandt wrote:
> 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.  

I agree we need to be careful here.

As another data point, phase 2 of the provider networks BP
implementation will likely introduce a "provider:network_type" extended
attribute that indicates the physical networking technology underlying
the virtual network (i.e. vlan vs flat, which will both be supported by
the openvswitch and linuxbridge plugins). This is certainly a different
attribute than the network shareability indicated by Salvatore's
"public" attribute, or the multi-plugin-selection indicated by Nachi's
attribute.

I favor Salvatore's current boolean "public" attribute, unless we really
think that there will eventually be more than two choices, in which case
maybe we should call it "shareability" or "visibility" or something similar.

-Bob

> 
> 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 <mailto: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
>     <mailto: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:cisco.com at lists.launchpad.net>
>     >>> [mailto:netstack-bounces+snaiksat
>     <mailto:netstack-bounces%2Bsnaiksat>=cisco.com at lists.launchpad.net
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto:netstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~netstack
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt 
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>