Open Stack

On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
[...]
> When there is an update to our requirements, such as the recent
> version increment in the version of angular used, a new package
> version doesn't automatically show up as evident from that list.
> How would that process be kicked off so we don't end up with a
> missing dependency? Does that have to wait for a release cycle?

I don't want to speak for the distro package maintainers, but from
what I've seen they generally wait until close enough to an
integrated release that they can be pretty sure the requirements are
close to frozen, so as not to waste effort packaging things which
will end up not being used.

> Many of the xstatic packages are maintained by the OpenStack
> community. Just see the list in stackforge
> (https://github.com/stackforge/?query=xstatic). Right now we need
> to update the xstatic package ourselves and then start using it.
> It also feels a little odd to maintain xstatic packages for pypi
> that we don't consume that way.

I assume (perhaps incorrectly?) that we do use those in CI jobs, so
that we can download the things a given project needs in an
automated fashion--for us handling pip requirements lists is a
solved problem (well, for some definitions of solved at least).

> This appears to affect the testing setup as well. When we start to
> use a new version of a JavaScript dependency no package will exist
> for it. I believe this would mean the testing environment needs to
> use the development setup, in the proposal, of bower. IIRC, bower
> goes out to the Internet and there isn't a mirror of packages
> (just a mirror of the registry). That means we'll loose the
> ability to run testing installs from local mirrors for these
> dependencies. I imagine a solution has been thought of for this.
> Can you share any details?

I am not aware of what the solution for this would be, but it will
be a show-stopper for the plan and so I (Infra hat on) would expect
the horizon developers to come up with an implementation which
solves that. Perhaps some routine to retrieve and pre-cache the
necessary files like we do with a lot of the random files devstack
uses, and then run that during image build time so that it's already
present on the filesystems of the machines which will run the jobs
needing it?
-- 
Jeremy Stanley