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
