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
