Hi Monty,
Thanks for bringing this up.
Having run into the topic for a few combination of deps, I'll certainly
agree that we need something better than what we currently have.
I don't feel that I've enough perspective on the whole system and
practices to give a strong opinion on what we should do though.
A few comments... (below)
On 25/04/2018 16:40, Monty Taylor wrote:
projects with test requirements on git repo urls of other projects
------------------------------------------------------------------
There are a bunch of projects that need, for testing purposes, to
depend on other projects. The majority are either neutron or horizon
plugins, but conceptually there is nothing neutron or horizon specific
about the issue. The problem they're trying to deal with is that they
are a plugin to a service and they need to be able to import code from
the service they are a plugin to in their unit tests.
(using neutron to avoid being too abstract, but this generalizes to
other components with plugins)
True, but sometimes a change to a neutron plugin may (with or without a
need to actually import neutron), need to run against a neutron version
from git (because the change has a Depends-On a Neutron change, or
because the change depends on something that is in neutron master but
not in a release). We have this when the plugin depends on a new or
fixed behavior.
While this case can in theory be fixed by moving the code introducing
the fixed or new behavior into neutron-lib, it doesn't mean that this
is always feasible (because the work required to move this part of the
code to neutron-lib hasn't happened).
unwinding things
----------------
There are a few different options, but it's important to keep in mind
that we ultimately want all of the following:
* The code works
* Tests can run properly in CI
* "Depends-On" works in CI so that you can test changes cross-repo
Note that this was true with tools/tox_install.sh, but broke when it was
removed for a job such as legacy-networking-bgpvpn-dsvm-functional (see
[1]) which does not inherit from zuul tox jobs, but still relies
ultimately on zuul to run the test.
[1]
http://logs.openstack.org/41/558741/11/check/legacy-networking-bgpvpn-dsvm-functional/86a743c/
* Tests can run properly locally for developers
(Broke when tools/tox_install.sh was abandoned, currently causing minor
pain to lots of people working on neutron-plugins unless py27-dev hacks
are in place in their project)
* Deployment requirements are accurately communicated to deployers
Was definitely improved by removing tools/tox_install.sh!
Specific Suggestions
--------------------
As there are a few different scenarios, I want to suggest we do a few
different things.
* Prefer interface libraries on PyPI that projects depend on
Like python-openstackclient and osc-lib, this is the *best* approach
for projects with plugins. Such interface libraries need to be able to
do intermediate releases - and those intermediate releases need to not
break the released version of the projects. This is the hardest and
longest thing to do as well, so it's most likely to be a multi-cycle
effort.
I would object to "best", for the following reasons:
- because this is not the starting point, the effort to librarize code
is significant, and it's seems a fact that people don't rush to do it
- there is a practical drawback of doing that: even for project that
have compatible release cycle, we have overhead of having to release
e.g. neutron-lib with the change before we can consume it in neutron or
a neutron plugin (and we have overhead to test the changes as well, with
extra jobs to test against master or local .zuul.yaml hacks to force
Depends-On to test what we want e.g. [x] ) ; a situation that would
avoid this overhead would I think be superior
[x] https://review.openstack.org/#/c/557660/
* Treat inter-plugin depends as normal library depends
If networking-bgpvpn depends on networking-bagpipe and networking-odl,
then networking-bagpipe and networking-odl need to be released to PyPI
just like any other library in OpenStack. These are real runtime
dependencies.
Juste a side note here: networking-bagpipe and networking-odl provide
components drivers for their corresponding drivers in networking-bgpvpn,
they aren't strict runtime dependencies, but only dependencies for a
scenario where their driver is used. Given that, they were moved as
test-requirements dependencies recently (only required to run unit tests).
The situation for these drivers is a bit in flux though:
- ODL: the bgpvpn driver for ODL is a v1 driver that became obsolete,
there is a v2 driver sitting entirely in networking-odl
- bagpipe: the bgpvpn driver for bagpipe could be moved to
networking-bagpipe entirely -- the one reason why it hasn't happened
(apart from inertia) is that is it the reference driver for the
networking-bgpvpn project, and removing it from networking-bgpvpn would
give us a project without any usable driver in tree
That said, I'm not sure I agree with:
> need to be released to PyPI just like any other library in OpenStack
As said above, their is a price to pay in having to do a release before
it can be consumed by other projects.
And additionally in this case, it would also means that
networking-bagpipe would have to move to a different release model with
intermediate releases.
I have the feeling that it is legitimate to be able to do joint work on
coupled components without having to pay for such a price.
Perhaps some of the improvements belong to projects have to deal with
theirs deps in a saner way, and perhaps some other belong to the real of
improvements needed to the CI tooling.
* Relax our rules about git repos in test-requirements.txt
Introduce a whitelist of git repo urls, starting with:
* https://git.openstack.org/openstack/neutron
* https://git.openstack.org/openstack/horizon
For the service projects that have plugins that need to test against the
service they're intending to be used with in a real installation. For
those plugin projects, actually put the git urls into
test-requirements.txt. This will make the gate work AND local
development work for the scenarios where the thing that is actually
needed is always testing against tip of a corresponding service.
It seems like this would help a lot.
I agree with Doug that a separate requirements file will help play nice
with the requirements checking tools.
* In the zuul jobs, add something similar to tox-siblings but before
the initial install that will detect a git url that matches a locally
checked out repo and will swap the local copy instead so that we don't
have tox cloning directly in gate jobs.
At this point, horizon and neutron plugin projects should be able to
use normal tox jobs WITHOUT needing to list anything other than
horizon and neutron themselves in required-projects, and they can also
add project-specific -tips jobs that will add intra-plugin depends to
their required-projects so that they can test both sides of the coin.
Finally, and this is a thing we need broadly for OpenStack and not
just neutron/horizon plugins:
* Extract the tox-siblings logic into a standalone tool that can be
installed and used from tox so that it's possible to replicate a -tips
job locally. I've got this pretty much done and just need to get it
finished up. As soon as it exists I'll update python-openstackclient's
tox.ini file to use it - and people can cargo cult from there and/or
we can work it up into a documented recipe for people.
Yes, ideally this would be transparent to users, not requiring to use a
different job name, and not being tied to zuul-v3 job definitions (in
particular not something working only for jobs inheriting from the tox
job template).
Best,
-Thomas
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
