Open Stack

On Thu, Aug 03, 2017 at 11:04:52AM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> > On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > > Just to clarify: we cannot land the tox.ini change until the requirements repo 
> > > > is actually branched, right?
> > > 
> > > Good point. The tests for those patches are passing for some projects in
> > > CI, but when the patches are landed it will make it a little harder for
> > > anyone to run the tests for the branch elsewhere because the
> > > requirements repo has not yet been branched.
> > > 
> > > So, yes, hold off on landing the constraint URL changes.
> > 
> > I wonder if we should look at publishing the upper-constraints.txt file
> > somewhere (other than cgit).  If we did something like:
> > 
> > tarballs.o.o/constraints/$series.txt
> > 
> > We wouldn't have an issue when we EOL a branch and the url's hard-coded
> > in tox.ini breaking.  queens.txt wouldn't exist until we branch
> > requirements but we could work around that with a redirect if needed.
> 
> I like the idea of publishing to a branch-specific file that always
> stays on the server. We could make the job on master publish both
> to a master.txt and a $series.txt file if we need both to exist at the
> same time.
> 
> > Later we could get really crazy and make a version that took a package
> > name and version perhaps like:
> > 
> > tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py --version)
> > 
> > Which would redirect to the appropriate series file.  I think we have
> > enough data in openstack/releases to generate those redirects.  We'd
> > need to think about projects / repos that don't use the release
> > infrastructure.
> 
> How would that redirect be used?

So I admit I typed that email and hit send without a huge amount of
thought and even though I use a web browser a lot I don't really
understand how http works but I was thinking about something like:

on $server probably releases.o.o but that's a detail we can sort out
later.

/constraints contains a .htaccess file generated from the data in
openstack relases that says something like:

redirect /constratints/nova/14.* to /constrataints/newton.txt
redirect /constratints/nova/15.* to /constrataints/ocata.txt

Any unknown versions get  /constratints/master.txt (or queens.txt
depending on what we do)

It could be a redirect or a rewrite rule whatever works best

then the nova tox.ini does something like:
${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
setup.py --version)}

Now it is probably that direct shell output can't be used like that and
then the whole thing fails but I hope we can do something like that ...
even if in the short term we need to use a helper script like we do to
work around other constraints issues.

If that doesn't work /constraints could become a script that looks and
the path_element and does the same logic.

Now it's herder with libraries but now that much harder.

The trick would be for repos that don't use releases and perhaps for
them in the first instance they need to hard code the serries.

> 
> > 
> > That'd mean we could get way from hard-coding the URLs in tox.ini and
> > therefore not need to update them at branch time.
> > 
> > I've either had too much coffee or not enough.  y'all decide.
> > 
> > Yours Tony.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170804/cb194a5b/attachment.sig>