← Back to team overview

openstack team mailing list archive

Re: [Quantum] Network, Subnet and Port names

 

On 07/17/2012 10:39 AM, Salvatore Orlando wrote:
I don't think either of you is wrong. I too think that in cases where it's not easy to find a majority, it might make sense to just do what the other projects are doing. Unfortunately for us, Keystone adopts the "name is unique" phylosophy, whereas nova adopts "name is a label".

Is it worth considering renaming the attribute to 'name-label' and let it be non-unique and non-mandatory?

This works for me.

Salvatore

On 16 July 2012 22:27, Dan Wendlandt <dan@xxxxxxxxxx <mailto:dan@xxxxxxxxxx>> wrote:

    Hi Gary, this is an example of when I wish openstack APIs had a
    "style-guide" to try to ensure some consistency across projects.

    For those new to the conversation, the original topic of
    discussion is whether "names" for API objects should be forced to
    be unique (presumably within a tenant?) or allowed to be
    duplicated.  The general feeling from the meeting was that since
    UUIDs are unique, the API itself would not enforce name
    uniqueness.  That also led to the point that names should then be
    optional, since they are really for informational/display purposes
    only.

    Personally, I tend to think that "description" tends to imply a
    sentence "private network for tenant1", rather than a simple name
    "tenant1-net".  There's also the fact that other openstack
    services like nova and glance use the term "name" with the similar
    (I believe) model that a name need not be unique.

    Would be curious to hear what others think.  The only thing I'm
    quite sure about is that there would be value in creating some
    notion of "openstack API consistency best practices" to give a
    more cohesive feel to APIs across different projects in the
    openstack family.

    Dan


    On Mon, Jul 16, 2012 at 10:05 PM, Gary Kotton <gkotton@xxxxxxxxxx
    <mailto:gkotton@xxxxxxxxxx>> wrote:

        Hi,
        If the name is intended to be a description then how about the
        idea of calling the field "description" instead. This is far
        more descriptive and does not lend the user to think that this
        should be unique.
        Thanks
        Gary

        _______________________________________________
        Mailing list: https://launchpad.net/~openstack
        <https://launchpad.net/%7Eopenstack>
        Post to     : openstack@xxxxxxxxxxxxxxxxxxx
        <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
        Unsubscribe : https://launchpad.net/~openstack
        <https://launchpad.net/%7Eopenstack>
        More help   : https://help.launchpad.net/ListHelp




-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Dan Wendlandt
    Nicira, Inc: www.nicira.com <http://www.nicira.com>
    twitter: danwendlandt
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~


    _______________________________________________
    Mailing list: https://launchpad.net/~openstack
    <https://launchpad.net/%7Eopenstack>
    Post to     : openstack@xxxxxxxxxxxxxxxxxxx
    <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~openstack
    <https://launchpad.net/%7Eopenstack>
    More help   : https://help.launchpad.net/ListHelp




Follow ups

References