Open Stack

I am sending this email to get the terminology sorted out during the IRC. Also, it this may help in mapping Quantum Network concepts with things we may already be familiar with:

FILESYSTEMS                                      QUANTUM
----------------                                     --------------
Naming/disambiguation                               Name/inodes                                    Name/UUID
Type                                                                      file/directory/special                      L2/L3
Scope                                                                    permissions                                        Public/Private

I would like to see both Type and Scope for Q-networks.

-Shiv

From: netstack-bounces+sharis=brocade.com at lists.launchpad.net [mailto:netstack-bounces+sharis=brocade.com at lists.launchpad.net] On Behalf Of Shiv Haris
Sent: Tuesday, July 17, 2012 4:53 PM
To: Yong Sheng Gong; Salvatore Orlando
Cc: OpenStack Development Mailing List; netstack at lists.launchpad.net
Subject: Re: [Netstack] [openstack-dev] [Quantum] Starting a discussion on the official spec for v2 API

At the meeting I was not convinced that the name needs to be optional. I believe is need to be ‘not optional’ and ‘unique’.

My perspective is that a network should be created with a name. It is the systems responsibility to assign a UUID to it as it will be used by the system for referring to it internally. Needless to say that UUID are alright to use between machines and when humans get involved reasonable names are useful.

Example: I create a network with a name ‘vlan3’ – (hopefully used for deploying vlanid=3) and much later (maybe a week later) I want to deploy a VM which will use this network. From the UI is will be hard to refer to this network using a UUID.

(it is pretty similar to file names and inodes, as a human I am glad I never think in terms of inodes I am happy with filenames)

-Shiv

From: netstack-bounces+sharis=brocade.com at lists.launchpad.net [mailto:netstack-bounces+sharis=brocade.com at lists.launchpad.net] On Behalf Of Yong Sheng Gong
Sent: Tuesday, July 17, 2012 1:31 AM
To: Salvatore Orlando
Cc: OpenStack Development Mailing List; netstack at lists.launchpad.net
Subject: Re: [Netstack] [openstack-dev] [Quantum] Starting a discussion on the official spec for v2 API

Hi,
I thought we agreed to make the name optional and up to user to decide its uniqueness at meeting.

Thanks
Yong Sheng Gong


-----Salvatore Orlando <sorlando at nicira.com><mailto:sorlando at nicira.com> wrote: -----
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
From: Salvatore Orlando <sorlando at nicira.com><mailto:sorlando at nicira.com>
Date: 07/17/2012 03:30PM
Cc: netstack at lists.launchpad.net<mailto:netstack at lists.launchpad.net>
Subject: [openstack-dev] [Quantum] Starting a discussion on the official spec for v2 API

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.
- '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.
- 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!
    - 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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120723/ea7503f9/attachment-0001.html>