On Dec 16, 2014, at 8:15 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> > On Dec 15, 2014, at 5:58 PM, Doug Hellmann <d...@doughellmann.com> wrote: > >> >> On Dec 15, 2014, at 3:21 PM, Doug Hellmann <d...@doughellmann.com> wrote: >> >>> The issue with stable/juno jobs failing because of the difference in the >>> SQLAlchemy requirements between the older applications and the newer >>> oslo.db is being addressed with a new release of the 1.2.x series. We will >>> then cap the requirements for stable/juno to 1.2.1. We decided we did not >>> need to raise the minimum version of oslo.db allowed in kilo, because the >>> old versions of the library do work, if they are installed from packages >>> and not through setuptools. >>> >>> Jeremy created a feature/1.2 branch for us, and I have 2 patches up [1][2] >>> to apply the requirements fix. The change to the oslo.db version in >>> stable/juno is [3]. >>> >>> After the changes in oslo.db merge, I will tag 1.2.1. >> >> After spending several hours exploring a bunch of options to make this >> actually work, some of which require making changes to test job definitions, >> grenade, or other long-term changes, I’m proposing a new approach: >> >> 1. Undo the change in master that broke the compatibility with versions of >> SQLAlchemy by making master match juno: https://review.openstack.org/141927 >> 2. Update oslo.db after ^^ lands. >> 3. Tag oslo.db 1.4.0 with a set of requirements compatible with Juno. >> 4. Change the requirements in stable/juno to skip oslo.db 1.1, 1.2, and 1.3. >> >> I’ll proceed with that plan tomorrow morning (~15 hours from now) unless >> someone points out why that won’t work in the mean time. > > I just reset a few approved patches that were not going to land because of > this issue to kick them out of the gate to expedite landing part of the fix. > I did this by modifying their commit messages. I tried to limit the changes > to simple cosmetic tweaks, so if you see a weird change to one of your > patches that’s probably why. That solution evolved into a third approach, which has taken most of the day to land. We now have an oslo.db 1.0.3 with SQLAlchemy requirements that work with setuptools 8. stable/juno is currently capped to oslo.db>1.0.0,<1.3 but another change to move the cap down to <1.1 is in the queue right now [1]. This is a lower cap than the last tests we were running, but it has the benefit of providing a version of oslo.db that does not introduce any other requirements changes in stable/juno as 1.2.1 would have. More details are available in the etherpad we used for notes today [2], and of course please post here if you have questions. Doug [1] https://review.openstack.org/#/c/142180/2 [2] https://etherpad.openstack.org/p/cloL2FzTRd > >> >> Doug >> >>> >>> Doug >>> >>> [1] https://review.openstack.org/#/c/141893/ >>> [2] https://review.openstack.org/#/c/141894/ >>> [3] https://review.openstack.org/#/c/141896/ >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
