Open Stack

Neil,

The effort is to spread the knowledge and skills beyond the "small group of
people who already understand all this" :)

Let me explain a bit. working backwards from what we see.

Most of us have seen the Proposal bot update reviews that get logged
periodically that updates the requirements.txt and test-requirements.txt in
all projects. Now the proposal bot (actually just a jenkins job not a bot)
picks these up from global requirements repo:
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt

Now who updates that repo? it's a bunch of folks who keep an eye out on the
different python libraries out in the eco system or our own libraries and
figure out if any new version is out or if an old version has problems. So
remember the global-requirements and the project requirements are ranges,
example:

jsonschema>=2.0.0,<3.0.0,!=2.5.0


Next problem is how do we figure out a basic set of pinned
requirements (not ranges) so all jobs pick up the same specific set,
hopefully latest set of libraries...That is maintained in

http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt


So who figures out the latest versions etc and updates the
upper-constraints.txt? It's again the same job/bot. example:

https://review.openstack.org/#/c/226182/


Some of this is documented here:

http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html


In this specific review that lifeless is pointing out, the bot
calculated a set of specific versions and logged a review for a
specific set of libraries and they failed to work with each other and
the ask was to figure out why they are failing and suggest fixes where
necessary.


Hope that helps?


Thanks,

Dims


PS: For that specific problem from lifeless, mordred already filed
reviews with os-client-config and python-openstackclient so we are
good.





On Tue, Sep 22, 2015 at 8:19 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> To most people who write on this list about requirements, constraints
> and gate deadlocks, not just Robert...
>
> FWIW - this email is tagged [all], and asks for help, but I don't
> understand it.  Even though I've been fairly heavily engaged with
> OpenStack for more than a cycle now.
>
> Obviously we can't avoid having lots of project-specific terminology and
> jargon in various areas of OpenStack.  When those areas are
> domain-specific, say Cinder or Sahara, that doesn't bother me.  But this
> thread (and others like it) seems more about some of OpenStack's
> vertical integration, that I ought to understand.  But the jargon and
> imprecision of the language and description used are making it
> impossible for me to start understanding.
>
> So, please, if you really mean [all], say what you're saying in terms
> that everyone can understand, and not just the (apparently, and
> unfortunately) small group of people who already understand all this in
> detail.
>
> To emphasize again, I really don't mean to target this email
> specifically - but it is a good example of lots of emails that (AFAICT)
> are about this sort of thing.
>
> Regards,
>     Neil
>
>
> On 21/09/15 20:53, Robert Collins wrote:
> >Constraint updates are still failing: you can see this on
> >https://review.openstack.org/#/c/221157/ or more generally
> >
> https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:openstack/requirements/constraints,n,z
> >>Now, the constraints system is *doing its job* - its made the presence
> >of an incompatible thing not-a-firedrill. However, we need to do our
> >part of the job too: we need to fix the incompatibility that exists so
> >that we can roll forward and start using the new releases that are
> >being made.
> >>Right now the release team are picking individual components and
> >proposing them as merges to move things forward, but its fairly
> >fundamentally unsafe to cut the full liberty release while there is a
> >known incompatibility bug out there.
> >>So - I'm manually ringing the fire-drill alarm now: we need to get
> >this fixed so that the released liberty is actually compatible with
> >the entire ecosystem at time of release.
> >>What issues are there ?
> >>Firstly,
> >2015-09-21 06:24:00.911 | + openstack --os-token
> >3dc712d5120b436ebb7d554405b7c15f --os-url http://127.0.0.1:9292 image
> >create cirros-0.3.4-x86_64-uec --public --container-format ami
> >--disk-format ami
> >2015-09-21 06:24:01.396 | openstack: 'image' is not an openstack
> >command. See 'openstack --help'.
> >>(See the dvsm run from review 221157 -
> >
> http://logs.openstack.org/57/221157/12/check/gate-tempest-dsvm-full/17941bd/logs/devstacklog.txt.gz#_2015-09-21_06_24_00_911
> >)
> >>Secondly, its likely that once thats fixed there will be more things to
> unwind.
> >>What will help most is if a few folk familiar with devstack can pull
> >down review 221157 and do a binary search on the changes in it to
> >determine which ones are safe and which ones trigger the breakage:
> >then we can at least land all the safe ones at once and zero in on the
> >incompatibility - and get it addressed.
> >>To repeat: this is effectively a release blocker IMO, and the release
> >is happening - well, $now.
> >>-Rob
> >
> __________________________________________________________________________
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150922/a1d78368/attachment.html>