openstack team mailing list archive

[Colin McNamara <colin@xxxxxxxxx>]

Exceedingly well put.

On Sunday, May 12, 2013, Monty Taylor wrote:

>
>
> 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 <javascript:;>>> wrote:
> >
> >
> >
> >     On 05/11/2013 05:48 PM, Anne Gentle wrote:
> >     >
> >     >
> >     >
> >     > On Sat, May 11, 2013 at 3:12 PM, Monty Taylor <mordred@inaugust.
> .com
> >     > <mailto:mordred@xxxxxxxxxxxx <javascript:;> <mailto:
> mordred@xxxxxxxxxxxx <javascript:;>>>> 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
> > >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx <javascript:;>>
> >     >     <mailto:openstack@lists.launchpad <javascript:;>.
> >     <mailto:openstack@lists.launchpad <javascript:;>.>.net>
> >     >     >   >     <mailto> >