Re: [openstack-dev] Adding new dependencies to stackforge projects
Matt, I've submitted a review to remove the gate-nova-docker-requirements from nova-docker: https://review.openstack.org/#/c/130192/ I am good with treating the current situation with DSVM jobs as we bug if there is consensus. I'll try to dig in, but we may need Dean, Sean etc to help figure it out :) thanks, dims On Tue, Oct 21, 2014 at 8:42 PM, Matthew Treinish mtrein...@kortar.org wrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Adding new dependencies to stackforge projects
Dear requirements-core folks, Here's the review as promised: https://review.openstack.org/130210 Thanks, dims On Wed, Oct 22, 2014 at 7:27 AM, Davanum Srinivas dava...@gmail.com wrote: Matt, I've submitted a review to remove the gate-nova-docker-requirements from nova-docker: https://review.openstack.org/#/c/130192/ I am good with treating the current situation with DSVM jobs as we bug if there is consensus. I'll try to dig in, but we may need Dean, Sean etc to help figure it out :) thanks, dims On Tue, Oct 21, 2014 at 8:42 PM, Matthew Treinish mtrein...@kortar.org wrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Adding new dependencies to stackforge projects
fyi, latest update after discussion on #openstack-infra, consensus seems to be to allow projects to add to g-r. 131+ All OpenStack projects, regardless of status, may add entries to 132+ ``global-requirements.txt`` for dependencies if the project is going 133+ to run integration tests under a devstack-configured environment. We 134+ want everyone testing with the same requirements, and any project 135+ that wants to test in a fully configured environment needs to have 136+ their dependencies in the global list. Please see https://review.openstack.org/#/c/130245/ The review that updates g-r with docker-py has been rebased to depend on 130245: https://review.openstack.org/#/c/128746/ Also, @ttx will be adding this discussion on next week's cross-meeting agenda. thanks, dims On Wed, Oct 22, 2014 at 9:15 AM, Davanum Srinivas dava...@gmail.com wrote: Dear requirements-core folks, Here's the review as promised: https://review.openstack.org/130210 Thanks, dims On Wed, Oct 22, 2014 at 7:27 AM, Davanum Srinivas dava...@gmail.com wrote: Matt, I've submitted a review to remove the gate-nova-docker-requirements from nova-docker: https://review.openstack.org/#/c/130192/ I am good with treating the current situation with DSVM jobs as we bug if there is consensus. I'll try to dig in, but we may need Dean, Sean etc to help figure it out :) thanks, dims On Tue, Oct 21, 2014 at 8:42 PM, Matthew Treinish mtrein...@kortar.org wrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims --
Re: [openstack-dev] Adding new dependencies to stackforge projects
On 2014-10-22 12:31:53 -0400 (-0400), Davanum Srinivas wrote: fyi, latest update after discussion on #openstack-infra, consensus seems to be to allow projects to add to g-r. [...] If that's deemed unacceptable for other reasons, the alternative solution which was floated is to tweak setup_package_with_req_sync() in the openstack-dev/devstack functions-common file to only call update.py on projects listed in the openstack/requirements projects.txt file. This will keep from triggering the restriction in update.py against unknown requirements in projects which don't opt into requirements enforcement. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Adding new dependencies to stackforge projects
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? 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 and the gate-nova-docker-requirements fails: http://logs.openstack.org/65/130065/1/check/gate-nova-docker-requirements/34256d2/console.html 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. 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/ -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Adding new dependencies to stackforge projects
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 pgpQ6KVhYL3ts.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
