Open Stack

On Tue, 2021-02-23 at 12:39 -0600, Ben Nemec wrote:
> 
> On 2/23/21 11:42 AM, Jay Bryant wrote:
> > 
> > On 2/23/2021 11:11 AM, Sean McGinnis wrote:
> > > On Mon, Feb 22, 2021 at 09:21:18PM +0100, Thomas Goirand wrote:
> > > > Hi,
> > > > 
> > > > Left, there's only myself and Monty as core reviewers. I don't have the
> > > > skills, or time for this. The only reason I'm a core reviewer, is that
> > > > historically, I was the one pointing out it got unmaintained, back a
> > > > long time ago (many years from now).
> > > > 
> > > > So it'd be nice of some people could step up and become core reviewer of
> > > > SQLA-migrate please.
> > > > 
> > > I may have things mixed up now, but I thought I was told a few years 
> > > ago now
> > > that sqlalchemy-migrate was deprecated and that projects should be 
> > > migrating to
> > > alembic now.
> > 
> > This was my understanding as well.  Has that position changed?
> 
> Quite the contrary, oslo.db just deprecated migrate support: 
> https://opendev.org/openstack/oslo.db/commit/fc855875236fd3bf760237fc64092f4a9d864fcb
> 
> This came up in the keystone meeting a few weeks ago because the 
> deprecation broke their test jobs. Unfortunately, from looking at other 
> projects' migration patches it doesn't appear to be trivial to move to 
> alembic.

If other projects are anything like nova, then I suspect DB migrations happen
relatively infrequently now. Everyone should be able do what nova is already
doing/planning to: compact everything up to a relatively recent release (we
chose Train) and then a new initial migration patch in alembic lingo with the
following pseudo-logic:

  is database already initialized/versioned with sqlalchemy-migrate?
  \-> yes
      |
      is latest version applied?
      \-> yes
          dummy apply alembic initial migration unless already applied
      \-> no
          tell user to upgrade
  \-> no
      |
      apply alembic initial migration unless already applied

> Based on the commit message, I think the deprecation was more intended 
> to prod users of migrate to move off it as opposed to start a ticking 
> clock for its removal, but we should have a discussion about how exactly 
> projects should proceed. Maybe a pop-up team that could write docs and 
> provide a point of contact for people with questions?

There was that and also to give an indication that no one is maintaining the
code and it therefore shouldn't be relied on (bit rot is a thing).
This is pretty much the Mox-mock thing all over again. sqlalchemy-migrate needs
to be retired and just needs bodies to do so. Alembic is by all accounts a much
better solution and it is actively maintained by the sqlalchemy community. I'm
working on removing sqlalchemy-migrate from nova, but it'll be Xena before we
can really dig into that. I proposed a BP and patches to remove it from Glance
early this cycle but alas that got very limited attention (thanks, abhishekk)
and I have draft patches locally to do the same for Cinder which I just need to
finish.

Regarding the initial question, @zigo you can add me to core for sqlalchemy-
migrate but with the caveat that I won't be sticking around to maintain it long-
term. This library is now a liability and project need to move off of it. The
combo of Nova, Glance and Cinder patch series that I'm proposing should get us a
long way there and will serve as a blueprint for other project, so there isn't
really a reason this can't happen in any healthy project over the next cycle.

Stephen