Adding openstack-dev, as all discussion should go on there.<div><br></div><div>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. </div>
<div><br></div><div>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).</div>
<div><br></div><div>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). </div>
<div><br></div><div>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). </div>
<div><br></div><div>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). </div>
<div><br></div><div>Dan</div><div><br></div><div>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? <br>
<div><br><div class="gmail_quote">On Tue, Jul 17, 2012 at 11:29 AM, Kyle Mestery (kmestery) <span dir="ltr"><<a href="mailto:kmestery@cisco.com" target="_blank">kmestery@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Thanks,<br>
Kyle<br>
<div><div><br>
On Jul 17, 2012, at 12:17 PM, Nachi Ueno wrote:<br>
<br>
> Hi folks<br>
><br>
> I'm +1 for a network type attribute, because the simple change can<br>
> support another usecase.<br>
><br>
> I'm going to implement this rosetta-plugin which can support multiple<br>
> types of networks.<br>
> <a href="https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin" target="_blank">https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin</a><br>
><br>
> 2012/7/17 Sumit Naiksatam (snaiksat) <<a href="mailto:snaiksat@cisco.com" target="_blank">snaiksat@cisco.com</a>>:<br>
>> Hi All,<br>
>><br>
>> 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.<br>
>><br>
>> Thanks,<br>
>> ~Sumit.<br>
>><br>
>><br>
>><br>
>>> -----Original Message-----<br>
>>> From: netstack-bounces+snaiksat=<a href="mailto:cisco.com@lists.launchpad.net" target="_blank">cisco.com@lists.launchpad.net</a><br>
>>> [mailto:<a href="mailto:netstack-bounces%2Bsnaiksat" target="_blank">netstack-bounces+snaiksat</a>=<a href="mailto:cisco.com@lists.launchpad.net" target="_blank">cisco.com@lists.launchpad.net</a>] On<br>
>>> Behalf Of Gary Kotton<br>
>>> Sent: Tuesday, July 17, 2012 2:33 AM<br>
>>> To: <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
>>> Subject: Re: [Netstack] [Quantum] Starting a discussion on the official spec<br>
>>> for v2 API<br>
>>><br>
>>> On 07/17/2012 10:28 AM, Salvatore Orlando wrote:<br>
>>>> Hello people of Quantum!<br>
>>>> As the Folsom release approaches, it is time to gather together and<br>
>>>> finalize the specification for the v2 API, so that the Openstack-doc<br>
>>>> team might cast it in stone for the sake of the Quantum users!<br>
>>>><br>
>>>> In order to make this happen, it looks like there are just a few bits<br>
>>>> that needs to be agreed upon, and I think they can be summarized as<br>
>>>> follows:<br>
>>>> - 'name' attributes and whether they should be mandatory. It looks<br>
>>>> like we all agree we want them, but it has to be decided whether<br>
>>>> i) they should be unique or not.<br>
>>>> ii) they should be mandatory or not.<br>
>>><br>
>>> Originally when I started to use Quantum I found it very awkward that the<br>
>>> name was not unique. My understanding from the meeting last night was<br>
>>> that it will no longer be mandatory for a network and does not need to be<br>
>>> unique. I wrote a mail to the list this morning suggesting that we use<br>
>>> description instead of name. Personally I think that this is a less binding way<br>
>>> of describing a network, subnet or port.<br>
>>><br>
>>><br>
>>>> - 'public' attribute for networks. As we did not get negative feedback<br>
>>>> on the proposal, I am going to assume nobody has strong opinions<br>
>>>> against this decision.<br>
>>><br>
>>> I would have preferred network type as it is more generic. Nonetheless I do<br>
>>> not have any strong objections to this.<br>
>>><br>
>>>> - security group API. We have a blueprint open and targeted to F-3<br>
>>>> (<a href="https://blueprints.launchpad.net/quantum/+spec/quantum-security-" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-security-</a><br>
>>> groups).<br>
>>>> Personally I do not feel it is a good idea at this stage proposing<br>
>>>> them for the core v2 API in Folsom. Apart from the necessary<br>
>>>> discussion concerning the APIs, we will need support across all the<br>
>>>> plugins, which is hardly going to happen IMHO. If you have a different<br>
>>>> opinion, this is the right thread to shout it!<br>
>>><br>
>>> I agree with you. I think that we still have a few road bumps to deal with. For<br>
>>> example when using devstack with Quantum V2 and the DHCP agent, the<br>
>>> DHCP requests do not arrive at the dnsmasq interface ... I am trying to<br>
>>> understand the reason for this. I have set the libvirt drivers to<br>
>>> "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not sure<br>
>>> if this is enough. Any help will be great.<br>
>>><br>
>>>> - NOTE: Leaving the security groups outside of Quantum core API<br>
>>>> also means that we *must* ensure Quantum still allows Nova to use its<br>
>>>> own firewall drivers.<br>
>>>> - L3 features<br>
>>>> (<a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat</a>):<br>
>>>> among the various sub-blueprints in which this blueprint can be<br>
>>>> broken, there's one concerning APIs. As I have not followed the<br>
>>>> development of this particular blueprint, I'll leave it to Dan whether<br>
>>>> L3 & NAT APIs should be part of Folsom core.<br>
>>>><br>
>>>> From my perspective, the above list includes all the items concerning<br>
>>>> the Quantum v2 API which have not yet stabilized. Please do let me<br>
>>>> know if I forgot anything.<br>
>>>><br>
>>>> Thanks and have a good day,<br>
>>>> Salvatore<br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Mailing list: <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
>>> Post to : <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
>>> Unsubscribe : <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
>>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
>> --<br>
>> Mailing list: <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
>> Post to : <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
> Post to : <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
<br>
--<br>
Mailing list: <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
Post to : <a href="mailto:netstack@lists.launchpad.net" target="_blank">netstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~netstack" target="_blank">https://launchpad.net/~netstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div></div>