On Sep 12, 2014, at 9:23 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Signed PGP part > On 12/09/14 13:20, Sean Dague wrote: > > On 09/12/2014 06:41 AM, Ihar Hrachyshka wrote: > >> Some updates/concerns/questions. > >> > >> The status of introducing a new driver to gate is: > >> > >> - all the patches for mysql-connector are merged in all > >> projects; - all devstack patches to support switching the driver > >> are merged; - new sqlalchemy-migrate library is released; > >> > >> - version bump is *not* yet done; - package is still *not* yet > >> published on pypi; - new gate job is *not* yet introduced. > >> > >> The new sqlalchemy-migrate release introduced unit test failures > >> in those three projects: nova, cinder, glance. > >> > >> On technical side of the failure: my understanding is that those > >> projects that started to fail assume too much about how those > >> SQL scripts are executed. They assume they are executed in one > >> go, they also assume they need to open and commit transaction on > >> their own. I don't think this is something to be fixed in > >> sqlalchemy-migrate itself. Instead, simple removal of those > >> 'BEGIN TRANSACTION; ... COMMIT;' statements should just work and > >> looks like a sane thing to do anyway. I've proposed the following > >> patches for all three projects to handle it [1]. > >> > >> That said, those failures were solved by pinning the version of > >> the library in openstack/requirements and those projects. This is > >> in major contrast to how we handled the new testtools release > >> just several weeks ago, when the problem was solved by fixing > >> three affected projects because of their incorrect usage of > >> tearDown/setUp methods. > >> > >> Even more so, those failures seem to trigger the resolution to > >> move the enable-mysql-connector oslo spec to Kilo, while the > >> library version bump is the *only* change missing codewise (we > >> will also need a gate job description, but that doesn't touch > >> codebase at all). The resolution looks too prompt and ungrounded > >> to me. Is it really that gate failure for three projects that > >> resulted in it, or there are some other hidden reasons behind it? > >> Was it discussed anywhere? If so, I wasn't given a chance to > >> participate in that discussion; I suspect another supporter of > >> the spec (Agnus Lees) was not involved either. > >> > >> Not allowing those last pieces of the spec in this cycle, we > >> just postpone start of any realistic testing of the feature for > >> another half a year. > >> > >> Why do we block new sqlalchemy-migrate and the spec for another > >> cycle instead of fixing the affected projects with *primitive* > >> patches like we did for new testtools? > > > > Because we are in Feature Freeze. Now is the time for critical bug > > fixes only, as we start to stabalize the tree. Releasing dependent > > libraries that can cause breaks, for whatever reason, should be > > soundly avoided. > > > > If this was August, fine. But it's feature freeze. > > I probably missed the fact that we are so strict now that we don't > allow tiny missing bits to go in. In my excuse, I was offline for > around three last weeks. I was a bit misled by the fact that I was > approached by an oslo core very recently on which remaining bits we > need to push before claiming the spec to be complete, and I assumed it > means that we are free to complete the work this cycle. Otherwise, I > wouldn't push for the new library version in the first place. I suspect you’re referring to me, there. I believed the work was ready to be wrapped up. I’m sorry my misunderstanding led to the issues. > > Anyway, I guess there is no way now to get remaining bits in Juno, > even if small, and we're doomed to postpone them to Kilo. I think we’re only looking at a couple of weeks delay. During that time we can work on fixing the problem. I don’t think we will want to retroactively change the migration scripts (that’s not something we generally like to do), so we should look at changes needed to make sqlalchemy-migrate deal with them (by ignoring them, or working around the errors, or whatever). Doug > > Thanks for the explanation, > /Ihar > > > _______________________________________________ > 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