Open Stack

I agree that we should pursue an implementation that allows for duplicate names, as I think that use case makes sense. I manage several application deployments that run different concurrent versions of the same application during blue/green and canary deployment, and I routinely use duplicate names with unique tags to represent them while using unique identifiers to act on them individually.

Our agreement in our 21015-03-10 team meeting allows operators to select on a per-tenant basis whether unique name constraints are imposed at resource creation time. It also allows tenants to change the setting if they prefer the alternative to the selected setting. What we set the system default to should be informed first by our best guess, and revisited later as-needed based on user feedback. Like Keith, I’m happy to try the unique name constraint as on by default to begin with.

Adrian

On Mar 11, 2015, at 1:48 PM, Keith Bray <keith.bray at RACKSPACE.COM<mailto:keith.bray at RACKSPACE.COM>> wrote:

Dev, thanks for bringing up the item about Heat enforcing unique stack names.. My mistake on thinking it supported non-unique stack names.  I remember it working early on, but probably got changed/fixed somewhere along the way.

My argument in IRC was one based on consistency with related/similar projects... So, as Murali pointed out, if things aren't consistent within OpenStack, then that certainly leaves much more leeway in my opinion for Solum to determine its own path without concern for falling in line with what the other projects have done (since a precedent can't be established).

To be honest, I don't agree with the argument about github, however.  Github (and also Heroku) are using URLs, which are Unique IDs.  I caution against conflating a URL with a name, where a URL in the case of github serves both purposes, but each (both a name and an ID) have merit as standalone representations.

I am happy to give my support to enforcing unique names as the Solum default, but I continue to highly encourage things be architected in a way that non-unique names could be supported in the future on at least a per-tenant basis, should that need become validated by customer asks.

Kind regards,
-Keith

From: Murali Allada <murali.allada at RACKSPACE.COM<mailto:murali.allada at RACKSPACE.COM>>
Reply-To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, March 11, 2015 2:12 PM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Solum] Should app names be unique?

The only reason this came up yesterday is because we wanted Solums 'app create' behavior to be consistent with other openstack services.

However, if heat has a unique stack name constraint and glance\nova don't, then the argument of consistency does not hold.

I'm still of the opinion that we should have a unique name constraint for apps and languagepacks within a tenants namespace, as it can get very confusing if a user creates multiple apps with the same name.

Also, customer research done here at Rackspace has shown that users prefer using 'names' rather than 'UUIDs'.

-Murali


________________________________
From: Devdatta Kulkarni <devdatta.kulkarni at RACKSPACE.COM<mailto:devdatta.kulkarni at RACKSPACE.COM>>
Sent: Wednesday, March 11, 2015 2:48 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Solum] Should app names be unique?

Hi Solum team,

In yesterday's team meeting the question of whether Solum should enforce unique app name constraint
within a tenant came up.

As a recollection, in Solum one can create an 'app' using:
solum app create --plan-file <plan-file> --name <app-name>

Currently Solum does support creating multiple apps with the same name.
However, in yesterday's meeting we were debating/discussing whether this should be the case.
The meeting log is available here:
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-03-10-21.00.log.html


To set the context for discussion, consider the following:
- heroku does not allow creating another app with the same name as that of an already existing app
- github does not allow creating another repository with the same name as that of an already existing repo

Thinking about why this might be in case for heroku, one aspect that comes to mind is the setting of a 'remote' using
the app name. When we do a 'git push', it happens to this remote.
When we don't specify a remote in 'git push' command, git defaults to using the 'origin' remote.
Even if multiple remotes with the same name were to be possible, when using an implicit command such as 'git push',
in which some of the input comes from the context, the system will not be able to disambiguate which remote to use.
So requiring unique names ensures that there is no ambiguity when using such implicit commands.
This might also be the reason why on github we cannot create repository with an already existing name.

But this is just a guess for why unique names might be required. I could be totally off.

I think Solum's use case is similar.

Agreed that Solum currently does not host application repositories and so there is no question of
Solum generated remotes. But by allowing non-unique app names
it might be difficult to support this feature in the future.

As an aside, I checked what position other Openstack services take on this issue.
1) Heat enforces unique stack-name constraint.
2) Nova does not enforce this constraint.

So it is clear that within Openstack there is no consistency on this issue.

What should Solum do?

Thoughts?

Best regards,
Devdatta


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
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/20150311/eb660c59/attachment.html>