[openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

Sean Dague sean at dague.net
Fri Sep 12 15:25:14 UTC 2014


On 09/12/2014 11:19 AM, Doug Hellmann wrote:
> 
> On Sep 12, 2014, at 9:23 AM, Ihar Hrachyshka <ihrachys at 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).

Yes, please, that would be highly appreciated. That kind of backwards
compat guaruntees is kind of why we took over migrate in the first place
as a project.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list