Open Stack

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.