openstack team mailing list archive

[Sumit Naiksatam <sumitnaiksatam@xxxxxxxxx>]

How about "netstack"? We had originally coined this name for the
collection of quantum, melange, and donabe services. Melange got
folded into Quantum, so we stopped using netstack. But Quantum today
is actually a collection of network services, both for network
connectivity, and also for more advanced services like loadbalancers
and firewall. So "netstack" might be appropriate.

Thanks,
~Sumit.

On Sat, May 11, 2013 at 5:58 PM, Anne Gentle <anne@xxxxxxxxxxxxx> wrote:
>
>
>
> On Sat, May 11, 2013 at 6:43 PM, Monty Taylor <mordred@xxxxxxxxxxxx> wrote:
>>
>>
>>
>> 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'm sure. :) I think I don't have much regret but do feel sorry that I don't
> know more.
>
>>
>>
>> > 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.
>>
>
> The technical issues, to me, and I may be missing something, are when the
> name is used as:
> - service/daemon name
> - command/CLI name
>
> You can use any pet name you want for your team and project while addressing
> technical issues some other way?
>
> Here's another way I'm looking at the naming autonomy/process. Why incubate?
> - you get to pick your cool name
> OR
> - you get access to infrastructure, tools, events, community, and branding
> that is OpenStack
>
> The naming can't be THAT crucial. I get that we want projects to be fun to
> work on. But it can't be just the naming that brings the fun.
>
> I think you believe I have some strict naming process in mind, so I'm trying
> to explain my position more.
>
> It's more that I believe we can have team/project names without naming
> technical things (repositories, CLIs) with that "cool/fun" name.
>
> Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and
> your repo kumquat.
>
>
>>
>> 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.
>>
>
> Yeah I'm not too concerned with repository names, though I do understand the
> need for uniqueness there. We incubate for a reason, to experiment a bit. In
> that experimentation I hope projects are considering their users.
>
>>
>> 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.
>>
>
> I totally get how hard the CLI work is. But what I don't get is why a unique
> name that is meaningless is so valuable?
>
>>
>> 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.
>>
>
> I'd love to work on a concrete proposal (thanks to Davanum for the podling
> page, that's useful). I'm okay with digging into the work we have to do here
> as it has worthwhile outcomes.
>
>>
>> > 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...
>
>
> Does some further explanation help? Yours is so nice and eloquent, I feel a
> bit intimidated. :) It's not that I'm backing off either, but trying to get
> to the heart of my concerns/questions with naming.
>
> Thanks for the meta Monty!
> Anne
>>
>>
>> > 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
>> >
>> >
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>