Open Stack

On 03/17/2016 07:12 AM, Richard Jones wrote:
> On 13 March 2016 at 07:11, Matthias Runge <mrunge at redhat.com
> <mailto:mrunge at redhat.com>> wrote:
> 
>     On 10/03/16 11:48, Beth Elwell wrote:
>     > If we will anyway have potential breakage I don’t understand why the
>     > better solution here would not be to just use the bower and npm tools
>     > which are standardised for JavaScript and would move Horizon more
>     > towards using widely recognised tooling from within not just Openstack
>     > but the wider development community. Back versions always need to be
>     > supported for a time, however I would add that long term this could end
>     > up saving time and create a stable longer term solution.
>     >
> 
>     I have a few issues with those "package managers":
>     - downloads are not verified, there is a chance of getting a "bad"
>     download.
>     - they are pointing to the outside world, like to github etc. While they
>     appear to work "most of the time", that might not good enough for
>     the gate
>     - how often have we been blocked by releases of software not managed by
>     OpenStack? Seriously, that happens quite a few times over a release
>     cycle, not to mention breakages by releases of our own tools turning out
>     to block one or the other sub-project
> 
> 
> To be fair to those package managers,  the issues OpenStack has had with
> releases of libraries breaking things is a result of us either:
> 
> a) not pinning releases (upper-constraints now fixes that for *things
> that use it*, which isn't everything, sadly) or
> b) the system that tests upper-constraints changes not having broad
> enough testing across OpenStack for us to notice when a new library
> release breaks things. I would like to increase the inclusion of
> Horizon's test suite in the constraints testing for this reason. At
> least, it's on my TODO :-)
> 
> Horizon, for example, currently does *not* use the upper-constraints
> pinning in its test suite or installation, so we're vulnerable to, say,
> a python-*client release that's not compatible. I have a patch in the
> works to address this, but it kinda depends on us moving over from
> run_tests.sh to tox, which is definitely something to wait until N for.

Thanks for this work. I'm looking forward to it. Do you also have in the
pipe to stop using nose / python -m coverage, and switch to testr?

Cheers,

Thomas Goirand (zigo)