Open Stack

FYI, it's very difficult to reply inline to HTML email ... please try to
use fixed-width only/plain-text emails to the mailing list. See here for
more information: http://wiki.openstack.org/MailingListEtiquette

Comments inline below...

On 07/23/2012 07:03 PM, Shiv Haris wrote:
> 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.

On a filesystem, you can have multiple files named exactly the same.
Suppose, for instance, the following:

/home/shiv/notes.txt
/home/jay/notes.txt

In the above, the file has exactly the same name (notes.txt). It's
disambiguation is the filepath. Imagine if each user on a UNIX
filesystem needed to create files with unique names. This would make it
necessary for each user to know the name of all files on the filesystem
in order to pick a unique name for their files. Clearly, this isn't
ideal. A similar situation exists with Q-networks. We cannot expect
users to know the names of all other users' networks. About the only
thing we *could* do is enforce uniqueness within a tenant/project --
which is similar to the UNIX filesystem scenario if you equate a
directory with a tenant.

In your equation above of UNIX file permissions with the Public/Private
Q-network types, I think the analogy is pretty solid. I would just add
that the notion of a "shared" Q-network that has been thrown around
recently would be reminiscent of the UNIX group permission for a
file/directory.

All the best,
-jay

> -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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>