openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 11/08/2011 08:13 AM, Dan Wendlandt wrote:
> 
> 
> On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx
> <mailto:thierry@xxxxxxxxxxxxx>> wrote:
> 
>     There are two ways of doing this.
> 
>     1. You can include the client code in the main core project, and produce
>     two tarballs from it (one project, two release deliverables) much like
>     what we'll need to do for Horizon (django module + ref impl).
> 
> 
> I would prefer that #1 at least be considered an acceptable option,
> unless there's some major downside that hasn't occurred to me.

#1 has several major downsides.

The primary downside is that it breaks PyPI and pip's ability to depend
on git locations. This in turn makes developer tooling around virtual
env depends much more of a nightmare, since it will wind up requiring us
to spin up a trunk-pacakges PyPI repo, and then point all of our
virtualenv creation scripts at both repos. Obviously can be done - but
is a large amount of work and infrastructure to support a funky code
organization strategy.

The second is that it breaks the link between a released set of sources
and its upstream repo. If I have a python-novaclient.tar.gz and I untar
it and I have python-novaclient, and then I go grab it from git and find
that it's actually a subdir and now we've created an additional element
of learning curve that an OpenStack dev as to get past.

Related to that, it breaks our ability to do standard scripting to deal
with projects. Currently, I can take a git repo URL, clone it, and run
run_tests.sh, or python setup.py sdist or python setup.py install and I
don't really have to even know what the project is.

If we start having multiple modules in a single source tree, tooling
will have to look around, figure out what might be going on, check and
see if there are subdirs with setup.py files, etc.

On the other hand, treating each client lib project as a first class
citizen means we can use all of the normal tooling to manage things. For
releases, we can use both install_requires or debian packaging depends
to treat it as a dependent library. But additionally for developer work
(venv-based environments) we can put -e git URLs into the pip-requires
file ... so we can still treat it like an upstream dependent library but
do so in a way that understands the source code relationships.

> 
>     2. You can add the new client project as a separate core project, which
>     happens to share the same PTL as its related project. This is more
>     costly since it basically multiplies by 2 the number of projects to
>     track (from a release management perspective).
> 
>     Which one are you after ?
> 
>     John Dickinson wrote:
>     > 2) Why does the PPB need to vote? Actually, what would the PPB be
>     voting on (assuming the answer to #1 is "no")?
> 
>     The PPB is always consulted when adding new core projects. Whatever
>     solution is chosen, you either create a new set of core projects
>     (python-novaclient, for example, is currently a separate project), or
>     you expand significantly the scope of existing core projects. That seems
>     to warrant a PPB discussion.
> 
>     In all cases, this will result in expanding the core set of release
>     deliverables, so expanding the scope of the project and spreading CI and
>     release management resources thinner.
> 
>     > 3) Why the requirement to have the same release schedule as the
>     paired project? I would expect a client binding to change much less
>     often than the underlying system (as I have seen with the
>     Rackspace-specific swift bindings).
> 
>     If we choose option 1 above, the client part would be a separate
>     deliverable for the same project. Nova, for example, would produce two
>     tarballs: nova and python-novaclient. They would obviously share the
>     same schedule.
> 
>     If we choose option 2 above, aligning milestone dates would limit the
>     increase in release management tracking work -- it might not be obvious
>     for everyone, but having each project using separate dates does not make
>     the release management job simpler.
> 
>     Regards,
> 
>     --
>     Thierry Carrez (ttx)
>     Release Manager, OpenStack
> 
>     _______________________________________________
>     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
> 
> 
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt 
> Sr. Product Manager 
> Nicira Networks: www.nicira.com <http://www.nicira.com>
> cell: 650-906-2650
> twitter: danwendlant
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp