openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 05/11/2013 08:58 PM, Anne Gentle wrote:
> 
> 
> 
> On Sat, May 11, 2013 at 6:43 PM, Monty Taylor <mordred@xxxxxxxxxxxxx
> <mailto: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 <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

And the directories in the code where those things live, and the name of
the python package that gets installed, and the name of the client
library used to connect to it.

> 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 don't think "having a cool name" is interesting or important at all.
Not one little bit. If any part of this was about esprit de corps or
team bonding or identity I'd be 100% on board with the no-codenames
approach.

Also, to be clear, I don't think there are any problems with using
non-codename for identification. Already, as part of the upgrade of our
build stuff to PBR I've been setting the project short description to
the non-codename. So, nova's is "OpenStack Compute" I think that's a
great idea, and it's important.

Equally as important, although harder, is that we should all try our
best to use the non-codenames when we're talking about official
projects. It's not going to work or be 100% covered - but we should all
make a best-effort.

(these are all things that did come out of that session - perhaps one of
us should do a writeup on that?)

The thing that _I'm_ sticking on is the above list of technical issues.
What is the daemon named? What is the command line tool named? What is
directory in which the code lives?

Those may seem trivial, but those are the primary interface that a
developer and deployer has with the project. And it's an issue because
of the lifecycle of these code projects before they are integrated. It's
not ok for moniker to call it's API daemon "openstack-dns-api" until
it's actually openstack DNS. It has to call itself something though.
That's where names come in. It's a practical thing that there must be a
name.

And let's be honest - it's my least favorite part of making a project.
So much so that our CI project which makes jenkins jobs from yaml files
is called "jenkins-job-builder" and the tool we use to manage our
projects in gerrit/github and launchpad is called jeepyb - which is a
phonetic re-working of "G P B" which stood for Gerrit Project Builder.
Shoot me now.

There's another rub with descriptive names. Jenkins Job Builder has
become WILDLY successful. People use it all over the place in areas
completely unrelated to OpenStack. I believe there's a guy on an oil rig
somewhere who is not only using it, but contributes patches. It's great.
AND ... a couple of weeks ago Jim and I met one of the guys from the
Eclipse Foundation...

You may not be aware, but the original codebase for Jenkins was called
Hudson, and it was a Sun project. When Oracle bought Sun, the screwed it
up like they screw up just about everything Open Source, so the core
team left, forked it, and many of us, including OpenStack, followed the
Jenkins fork. (If you've ever wondered why you get messages from jenkins
under the email name of "OpenStack Hudson" - that's why - we haven't
ever renamed the original hudson service account) In any case, Oracle
finally realized that they didn't know what they hell they were doing,
so they gave hudson to the Eclipse foudation...

which brings us back to - Jim and I and the guys from wikipedia and the
guys from Eclipse are going to have a talk about how we can all work
together better ... turns out Eclipse already uses gerrit too. We'll
tell them all about the things we've built that make things work
smoothly - like Zuul and Jenkins Job Builder.

Oops.

Jenkins Job Builder. That's going to be awkward. Zuul will be fine - it
reads gerrit event stream and makes jenkins API calls. Hudson has the
same calls, it should just work. Jenkins Job Builder creates xml
snippets. It SHOULD just work technically - but we're going to wind up
asking the guys running the hudson project to use "Jenkins Job Builder"
to manage their CI.

Naming is important - and not for cute hipster reasons. There are real
logistical challenges that a unique non-descriptive name help with.
There's a reason that Ivory doesn't just call itself "Pure White Soap"
Our brains process pattern and names in a peculiar manner, and it helps
us to communicate specifically. We also none of us have problems dealing
with made up word names - we've got 13 years of dot-com era dopplr and
yelp and bing and iphone and whatnot. It's not a problem.

One of the things that IS an interesting intersection of problems here
is actually the real issue. It's not that short names are bad for any
technical reasons. It's that they're potentially problematic from a
legal perspective, but there is no avenue for us to engage with that in
a way that is consistent with our community values.

We, from the beginning, and to this day, spend a MASSIVE amount of
effort in doing everything in the open, because Open Process and Open
Governance are just as important to a community as Open Source is. This,
however, it turns out, is directly at odds with just about everything of
how corporate entities work. We've way more meta-discussion at the board
meetings about the need for our private executive sessions. We don't
like it, but there are times that for legal reasons we actually HAVE to
not do some things publicly. I think it's crap and one more way in which
the man is trying to keep us down, but it is a fact of life.

Why do I think that's relevant?

It's because we don't get the benefit of private codenames for work and
then public marketing names. Rackspace Cloud Servers internally is
called Ozone, am I right? Cloud Files was called Swift before it was
part of OpenStack. And it still is.

Our problem is directly related to our value - which is that we market
ourselves directly through telling people they can look at our code.
That means that as much as we can have a project called swift that the
business folk call OpenStack Object Storage - there is no escaping the
fact that the technical folk are going to talk about it as swift in
their technical conversations. In fact, we've done such a good job as a
technical meritocracy that people consider our
non-marketing/non-business choices as marketing/business actions - and
they consider them potential grounds for lawsuits.

So we're going to have this problem. It's not going to go away - because
we're doing something different, and we're doing it in a way that isn't
compliant with the box that the world wants to put us in.

In theory, it should be hurting adoption for us to have 18 different
projects with completely un-understandable names. I'm pretty sure that
the last couple of summits have shown that, of the problems we have,
that is not one of them.

There is one more problem with coupling the technical part of the
project to the branding - and that's one from the opposite side of
incubation. What if we eject a project? What if the TC decides to get
together and say "you know what? We don't think swift has enough
production deployments at scale (hahaha) and doesn't meet our criteria
for a good OpenStack project. Monty and Jim wrote a shell script that
stores objects in mercurial. Mercurial is in python. We want to use that
for OpenStack Object Storage instead." Now what? Does swift have to
rename their project again? If they decide "cool, we don't need you,
we're going to continue life as part of the Eclipse foundation" - do
they need to rename the innards of their project from
openstack/storage/object back to swift? Which law forces them to do
that? Because I'm pretty sure that would be trademark. That would mean
that we'd have a non-free trademark usage policy concerning forks -
which would make us DFSG incompatible which would mean that Debian would
stop shipping us.

I would really like to keep our trademark out of our source code,
because it opens a giant can of worms.

I would really like to keep the marketing/business folks out of our
source code.

Most importantl, I would really like to keep the lawyers out of our
source code.

Occasionally this means we're going to get stuck, like with Quantum, and
we're going to need to do a project name change. Ok. I think we've now
learned that we as technical people have GOT to check more than just "is
the project name available on github/launchpad/debian/redhat and pypi" -
cause we already do that. We should do things like "does a quick google
search of my project name and core elements of it return, you know, a
business." I mention our erstwhile nascent DNSaaS project as an example
of pre-incubation... hopefully someone in that project will do the thing
I just mentioned and will come to us at incubation time with a name that
is not a CLEAR violation. I mean, we can't be perfect, but we can at
least try. Because if we try, then it keeps the lawyers out of our
business - and that's really better for all of us.

> 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 <http://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>>
>     >     > <mailto: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>>
>     >     >     <mailto: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>>
>     >     <mailto: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@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:openstack@lists.launchpad.
>     <mailto:openstack@lists.launchpad.>.net>
>     >     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxxx>>>
>     >     >     >> 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>>
>     >     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxxx>>>
>     >     >     > 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>>
>     >     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>>>
>     >     >     Unsubscribe : https://launchpad.net/~openstack
>     >     >     More help   : https://help.launchpad.net/ListHelp
>     <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
>     >     >
>     >
>     >     _______________________________________________
>     >     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
>     >
>     >
> 
>