I'm interested to hear how this works out. I thought upper-constraints was somehow supposed to work to prevent this? Like maybe don't install a brand new shiny upstream version on the gate infrastructure test jobs until it passes all our tests? Prevent a fire drill? That bug was active back in July - but I guess 1.2 was released pretty recently? .... maybe I don't understand the timeline.
-Clay On Mon, Sep 26, 2016 at 2:21 PM, Dave McCowan (dmccowan) <dmcco...@cisco.com > wrote: > > The Barbican project uses Pecan as our web framework. > > At some point recently, OpenStack started picking up their new version > 1.2. This version [1] changed one of their APIs such that certain calls > that used to return 200 now return 204. This has caused immediate problems > for Barbican (our gates for /master, stable/newton, and stable/mitaka all > fail) and a potential larger impact (changing the return code of REST calls > is not acceptable for a stable API). > > Before I start hacking three releases of Barbican to work around Pecan's > change, I'd like to ask: are any other projects having trouble with > Pecan Version 1.2? Would it be possible/appropriate to block this version > as not working for OpenStack? > > Thanks, > Dave McCowan > > > [1] > http://pecan.readthedocs.io/en/latest/changes.html > https://github.com/pecan/pecan/issues/72 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
