openstack team mailing list archive

[Sean Dague <sean@xxxxxxxxx>]

On 05/13/2013 11:03 AM, Doug Hellmann wrote:
> +1
>
> 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?

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. implementation.

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.

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. :)

	-Sean

--
Sean Dague
http://dague.net