[openstack-dev] Adding new dependencies to stackforge projects

Matthew Treinish mtreinish at kortar.org
Wed Oct 22 00:42:38 UTC 2014


On Tue, Oct 21, 2014 at 08:09:38PM -0400, Davanum Srinivas wrote:
> Hi all,
> 
> On the cross project meeting today, i promised to bring this to the
> ML[1]. So here it is:
> 
> Question : Can a StackForge project (like nova-docker), depend on a
> library (docker-py) that is not specified in global requirements?

So the answer is definitely yes, and this is definitely the case for most
projects which aren't in the integrated release. We should only be enforcing
requirements on projects in projects.txt in the requirements repo.

> 
> Right now the answer seems to be "No", as enforced by the CI systems.
> For the specific problems, see review:
> https://review.openstack.org/#/c/130065/
> 
> You can see that check-tempest-dsvm-f20-docker fails:
> http://logs.openstack.org/65/130065/1/check/check-tempest-dsvm-f20-docker/f9000d4/devstacklog.txt.gz

I think you've just hit a bug either in devstack or the nova-docker devstack
bits. There isn't any reason these checks should be run on a project which
isn't being tracked by global requirements.

> 
> and the gate-nova-docker-requirements fails:
> http://logs.openstack.org/65/130065/1/check/gate-nova-docker-requirements/34256d2/console.html
> 

I'm not sure why this job is configured to be running on the nova-docker repo.
The project should either decide to track global-requirements and then be added
to projects.txt or not run the requirements check job. It doesn't make much
sense to enforce compliance with global requirements if the project is trying to
use libraries not included there.

Just remove the job template from the zuul layout for nova-docker:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n4602

and then once the issue with devstack is figured out you can add the docker-py
to the requirements list.

> For this specific instance, the reason for adding this dependency is
> to get rid of custom http client in nova-docker project that
> just duplicates the functionality, needs to be maintained and does not
> do proper checking etc. But the question is general
> in the broader since projects should be able to add dependencies and
> be able to run dsvm and requirements jobs until
> they are integrated and the delta list of new dependencies to global
> requirements should be vetted during the process.

If nova-docker isn't tracked by global requirements then there shouldn't be
anything blocking you from adding docker-py to the nova-docker requirements. It
looks like your just hitting a bug and/or a configuration issue. Granted, there
might be some complexity in moving the driver back into the nova tree if there
are dependencies on a packages not in global requirements, but that's something
that can be addressed when/if the driver is being merged back into nova.

> 
> Thanks,
> dims
> 
> PS: A really long rambling version of this email with a proposal to
> add a flag in devstack-gate/devstack is at [2], Actual review
> with hacks to get DSVM running by hook/crook that shows that docker-py
> indeed be used is at [3]
> 
> [1] http://eavesdrop.openstack.org/meetings/project/2014/project.2014-10-21-21.02.log.html
> [2] https://etherpad.openstack.org/p/managing-reqs-for-projects-to-be-integrated
> [3] https://review.openstack.org/#/c/128790/
> 

-Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/b1d70391/attachment.pgp>


More information about the OpenStack-dev mailing list