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.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
