On 06/06/2017 03:21 AM, Dougal Matthews wrote: > > > On 31 May 2017 at 09:35, Renat Akhmerov <renat.akhme...@gmail.com > <mailto:renat.akhme...@gmail.com>> wrote: > > > On 31 May 2017, 15:08 +0700, Thierry Carrez <thie...@openstack.org > <mailto:thie...@openstack.org>>, wrote: >> >>> This has hit us with the mistral and tripleo projects particularly >>> (tagged in the title). They disallow pbr-3.0.0 and in the case of >>> mistral sqlalchemy updates. >>> >>> [mistral] >>> mistral - blocking sqlalchemy - milestones >> >> I wonder why mistral is in requirements. Looks like tripleo-common is >> depending on it ? Could someone shine some light on this ? It >> might just >> mean mistral-lib is missing a few functions, and switching the release >> model of mistral itself might be overkill ? > > This dependency is currently needed to create custom Mistral > actions. It was originally not the best architecture and one of the > reasons to create 'mistral-lib' was in getting rid of dependency on > ‘mistral’ by moving all that’s needed for creating actions into a > lib (plus something else). The thing is that the transition is not > over and APIs that we put into ‘mistral-lib’ are still experimental. > The plan is to complete this initiative, including docs and needed > refactoring, till the end of Pike. > > What possible negative consequences may we have if we switch release > model to "cycle-with-intermediary”? > > > I don't fully understand this, but I have one concern that I'll try and > explain. > > Mistral master is developed against master of other OpenStack projects > (Keystone for auth, and all projects for OpenStack actions). If we were > to release 5.0 today, it would mean that Mistral has a release that is > tested against unreleased Pike but would need to work with Ocata stable > releases (and AFAIK we do not tested Mistral master with Ocata Keystone > etc.) >
This is true and what makes this hard, but the other cycle-with-intermediary projects do the same thing (make releases when using other projects master based releases). So as long as your testing is good I don't see a problem. > We are very close to breaking the link between tripleo-common and > mistral - I would favour that approach and would prefer a nasty hack to > rush that along rather than changing Mistrals release cycle. I expect to > remove mistral from requirements.txt after the transition anyway. > This would be best, but how long will this take? How long will mistral be holding back sqlalchemy updates? > What needs to happen to remove the dep? > - RDO promotion to get a new mistral-lib release > - After promotion this should start passing > https://review.openstack.org/#/c/454719/ > - Port this functionality to tripleo-common > https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py > (we were planning on moving this to mistral-extra, but it could go into > tripleo-common as a short term solution) > Thanks for the update. > > > > Renat Akhmerov > @Nokia > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 > -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
