-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. 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. Thanks for the explanation, /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUEvPjAAoJEC5aWaUY1u57kPYIAMuTz5w8cmNLeXHSGpb0s0BT 4GPbTvLIvoTRXf2froozSxVo6B4oKgUFe7IkSI8nsBHP+dcDPotKwJEMgAKpLL1n 37ccFR+RuMCVMa6ZYHgz88o4dbTgv5XC5tBTnY78mX7WOoQHQ0ByRcBUZkIc9aoI KF+SNRvHwVRT9qNPElcrfHKNPwROIe1Eml3aVaqnHWPWip5J7+E+/BU+YSxtDKIV whrJzUpHgwph4NJ1lHddrzVCAjf8mWKj8EX1WWU2zTgUtfLi+xqvOBCnQ+1rBXA8 brIBpbUOObMjBqbemlymKuFvcuy6yHTXXvAfLcgGcRXSmvdjtfAIZCr5d9AjKhU= =zPHu -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev