openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #23583
Re: New code name for networks
On 05/11/2013 05:48 PM, Anne Gentle wrote:
>
>
>
> On Sat, May 11, 2013 at 3:12 PM, Monty Taylor <mordred@xxxxxxxxxxxxx
> <mailto:mordred@xxxxxxxxxxxx>> wrote:
>
>
>
> On 05/11/2013 04:07 PM, Asher Newcomer wrote:
> > Or even better, just continue to call it openstack networking. The
> code
> > names only serve to confuse the uninitiated. They needlessly
> steepen the
> > learning curve and slow uptake.
>
> The problem with OpenStack Networking (or getting rid of codenames) is
> seen with pre-incubation->incubation->integrated cycle.
>
> A project cannot call itself "OpenStack Foo" until it actually _is_
> openstack foo. So any new project by necessity has to start off as
> something else.
>
> But - if we then require them to drop that name and become openstack foo
> when they become incubated or integrated, then we've got what's become a
> stable project with a decent amount of contributors renaming itself.
>
> Every. Time.
>
> The code names aren't just cute. I kind of wish they were, because it
> would make several things much easier if we could just ditch them and do
> a pure openstack. code namespace. But the reality is that it gets really
> really tricky to deal with a bunch of things if they go away.
>
>
> I told Monty and the TC this at the Summit (sorry I couldn't attend the
> session about code names).
I promise, it wasn't the world's most fun session. :)
> I find this trickiness a weak argument in the
> face of the invented names that are getting to be as bad as U.S.
> pharmaceuticals. Plus it forces us to put a "lookup" table in the docs
> forever. [1] Let's find a process for naming that meets a few reqs:
> - describes the service
> - goes through a legal review
> - enables new eyes to understanding it by reading the English word that
> the service represents (that can be translated into a meaningful word in
> other languages)
I don't think it's a weak argument at all. There are real technical issues.
That assumes that OpenStack is involved with the project pre-incubation.
That's was the case with Quantum and Ceilometer and Ironic. On the other
hand, the heat folks had heat-api.org and a heat github org and other
things before they started down the stackforge road. Looking right now
at non-incubated projects just off the top of my head:
Libra is an LBaaS solution that was started on stackforge and which it's
increasingly unlikely will go to incubation rather than just atttempt to
merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't
applied for incubation, might do so, but as of right now has been around
for almost a year yet has no formal relationship with OpenStack.
healthnmon may or may not be an incubation candidate.
Before that, reddwarf was not-incubated for pretty much the entire time
OpenStack has existed until just now.
All of these things have had to have lifecycles during a period of time
before they have any interaction with us formally.
On the other hand, if we did checking pre-incubation, we'd be in a very
odd position of granting permission/blessing/tentative interest in
projects before they come close to sorting things out. Moniker is great,
but 6 months ago there were as many as 4 different DNSaaS possibilities.
In any case, I don't think there is any way that we can, become directly
involved in projects before they are incubated.
Stackforge helps already, in that moniker is stackforge/moniker rather
than openstack/moniker. But neither has any effect on the fact that
there is a directory named "moniker" in moniker repository. If we go
with 'descriptive' names, then there are two choices:
a) moniker starts life with a directory structure underneath
openstack/dns inside of its repository, even though it is not an
openstack project.
b) moniker starts life with a moniker directory, and then when
incubated, renames that directory from moniker to openstack/dns.
We can't stop anybody from doing (a) of course, but let me tell you -
you wanna talk about confusing and bad messaging - we had apt repos at
the beginning of the project with giant letters on them "FOR TESTING
ONLY" but because they had our name on them people assumed we supported
them.
(b) sound easy, until you reckon with things like line-wrapping changes,
sort order changes, and client library/API consumption changes. If
something is using python-monikerclient and thus the monikerclient
namespace of the API, that person would have to port their code to now
do something like openstack.dns.client or similar.
Even ignoring people who may have already been using the code (many of
these things start life as a service by one of our member companies and
then enters incubation when it's become baked a little bit - reddwarf
was in production at RAX and HP before it got incubated, moniker is in
production at HP, etc) and just focusing on our own code base, the
massive undertaking that it is to change the name of the project inside
of the project is daunting enough that we're still talking about it for
Quantum.
Don't get me wrong - I totally hear you on the matrix of what-does-what,
and obviously there are legal naming issues- I'm not trying to be
insensitive to them - this is a crap position to be in. But so far, I
haven't heard an actual proposal on how we deal with a model other than
our current one - and when I say that, I mean a _detailed_ plan that
takes in to account all of the various things we know right now that we
will run in to. How do we do X, and then how do we deal with Y and what
is the process and timing we use to deal with Z. We have a massively
complex project, and as much as I would like for this question to be
simpler in its solution, it simply is not.
At the moment, absent a concrete proposal for the process change that
would necessarily ensue from ditching code names, I believe we're stuck
in the not-great but not-any-worse-than-current situation of having
potentially infringing names. For our current names, well, we're dealing
with that as best we can. For future incubation requests, we are now
raising the name as a question - which means that we can tell people
that we are going to be doing that, which means that projects that are
not careful and do not pick a trademark friendly name may have to go
through a rename if they hit a problem ... but it's also possible with
care that renames can be avoided.
> If we have to preface with Stackforge to indicate pre-incubation, that's
> fine. Use Incubating or some such to indicate incubation. Meaningful
> words have meaning.
Once it's incubating, it's in our world - we, as a body, have made a
choice that it's a thing we want to be involved with, pending the
technical things working out. I don't think we have any deficiencies
there at the moment.
> I acknowledge we still have to indicate what commands, daemon names, and
> so on are related to a particular service. That issue is also fixable
> with some resources and effort and pays off in easier adoption and
> understanding.
It's entirely possible that after all of that text above, we are talking
about completely different things when we talk about naming here. I love
meta discussions...
> 1.. http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html
>
>
>
> > On May 11, 2013 3:59 PM, "Davanum Srinivas" <davanum@xxxxxxxxx
> <mailto:davanum@xxxxxxxxx>
> > <mailto:davanum@xxxxxxxxx <mailto:davanum@xxxxxxxxx>>> wrote:
> >
> > Lattice
> >
> > -- dims
> >
> > On Sat, May 11, 2013 at 3:52 PM, Mark Turner <mark@xxxxxxxxxxx
> <mailto:mark@xxxxxxxxxxx>
> > <mailto:mark@xxxxxxxxxxx <mailto:mark@xxxxxxxxxxx>>> wrote:
> > > Tubes
> > >
> > > ;-)
> > >
> > >
> > > On Sat, May 11, 2013 at 12:51 PM, Jason Smith
> > <jason.smith@xxxxxxxxxxxxx <mailto:jason.smith@xxxxxxxxxxxxx>
> <mailto:jason.smith@xxxxxxxxxxxxx <mailto:jason.smith@xxxxxxxxxxxxx>>>
> > > wrote:
> > >>
> > >> Hello,
> > >> I understand why we had to give up Quantum code name but rather
> > than just
> > >> refer to it as networking let's come up with a new code name!
> > >>
> > >> Thoughts?
> > >>
> > >> Thanks,
> > >> -js
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~openstack
> > >> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxxx>
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
> > >> Unsubscribe : https://launchpad.net/~openstack
> > >> More help : https://help.launchpad.net/ListHelp
> > >
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~openstack
> > > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help : https://help.launchpad.net/ListHelp
> > >
> >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References