Open Stack

Excerpts from Tony Breeds's message of 2018-03-15 11:59:00 +1100:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> > The current version of proposed patches which drops tox_install.sh
> > works in our CI. Even if we have neutron>=12.0.0 (queens) or
> > horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> > config, tox-sibling role ensures to install the latest master of
> > neutron/horizon. It is okay in our CI.
> > 
> > On the other hand, this change brings a couple of problems. I think it
> > is worth discussed broadly here.
> > 
> > (1) it makes difficult to run tests in local environment
> > We have only released version of neutron/horizon on PyPI. It means
> > PyPI version (i.e. queens) is installed when we run tox in our local
> > development. Most neutron stadium projects and horizon plugins depends
> > on the latest master. Test run in local environment will be broken. We
> > need to install the latest neutron/horizon manually. This confuses
> > most developers. We need to ensure that tox can run successfully in a
> > same manner in our CI and local environments.
> 
> This is an issue I agree and one we need to think about but it will be
> somewhat mitigated for local development by pbr siblings[1]
> 
> In the short term, developers can do something like:
> 
> for env in pep8,py35,py27 ; do
>    tox -e $env --notest
>    .tox/$env/bin/pip install -e /path/to/{horizon,neutron}
>    tox -e $env
> done
> 
> Which is far from ideal but gives as a little breathing room to decide
> if we need to revert and try again in a while or persist with the plan
> as it stands.
> 
> pbr siblings wont fix all the issues we have and still makes consumption of
> neutron and horizon (and plugins / stadium projects) difficult outside
> of test.
>  
> > (2) neutron/horizon version in requirements.txt is confusing
> > In the cycle-with-milestone model, a new version of neutron/horizon
> > will be released only when a release is shipped.
> > The code depends on the latest master, but requirements.txt says it
> > depends on queens or later. It sounds confusing.
> 
> Yes we either need to create a new release-model or switch
> neutron/horizon to the cycle-with-intermediary model and encourage
> appropriate releases.  I'd really like to avoid publishing daily to pypi.

We keep doing lots of infra-related work to make it "easy" to do
things we shouldn't be doing in the first place when it comes to
managing dependencies.  There are three ways to address the issue
with horizon and neutron, and none of them involve adding features
to pbr.

1. Things that are being used like libraries need to release like
   libraries. Real releases. With appropriate version numbers. So
   that other things that depend on them can express valid dependencies.

2. Extract the relevant code into libraries and release *those*.

3. Things that are not stable enough to be treated as a library
   shouldn't be used that way. Move the things that use the application
   code as library code back into the repo with the thing that they
   are tied to but that we don't want to (or can't) treat like a
   library.

Let's stop making things hard on ourselves and start managing this
code properly.

Doug