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) <snaik...@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....@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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
