openstack team mailing list archive
Mailing list archive
Re: New code name for networks
On Mon, May 13, 2013 at 11:30 AM, Sean Dague <sean@xxxxxxxxx> wrote:
> On 05/13/2013 11:03 AM, Doug Hellmann wrote:
>> Use a namespace package "openstack" then each project has a unique
>> package under that for their meaningfully named package (compute,
>> networking, etc.).
> Sounds great and all, except when you try to do something like quantum, or
> even cinder, where you break out function into another project.
> from openstack import network <- wait, is that what used to be nova
> network, or quantum, or some abstraction?
Fair point, and those specific examples of names may not be good. :-)
On the other hand, there's no reason each team needs to be limited to
deploying a single package. If nova network was "openstack.network" to
begin with, then perhaps quantum could have just been an evolution of that.
> from openstack.compute import network as compute_network ?
> Code names are actually incredibly useful in developing this stuff,
> because it lets us think about an implementation separate from a concept,
> and work with non native english speakers a lot easier where concept vs.
> Honestly, there is already incredible confusion when you talk with people
> about "compute". Where you have to be really paying attention to nuance to
> figure out if people meant "Nova as a whole", "the Nova compute daemon", "A
> nova compute node, which might also have nova-network on it". The number of
> times we had to explain no-db-compute blueprint because of that speaks to
> the fact that generic names do not make anything easier, they generate more
> confusion quite often.
> Code names are useful because it gives us a whole other namespace of words
> to work with to be very specific about what we mean, that can't be confused
> for the generic concepts of networking or computing. Yes, it's inside
> baseball, but when you are dealing with code as complicated as OpenStack,
> not having that inside baseball really slows things down.
This seems like a stronger argument than "it's hard to rename things"
(which I think is at least a large part of the argument against moving away
from code names during/after incubation).
FWIW, I'm in favor of not branding every little thing we do "openstack,"
especially when components can be reused by other projects (I would love to
see us acquire a few downstream users of some of the Oslo libraries, for
example). But for the big core stuff, it feels weird to have separate
commands, separate package namespaces, etc.
> Just look at the regular confusion new people have about the 2 uses of the
> term migrations in Nova, one for the database schema, and one for moving
> guests around. :)
I'm not sure we're going to eliminate confusion entirely. I'm not even sure
changing anything will reduce it. But it does seem like we can minimize
legal issues by avoiding using code names in the code, which is where this
> Sean Dague