Open Stack

-----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-----