Open Stack

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

Doug

> 
> Thanks for the explanation,
> /Ihar
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev