Open Stack

Hi,
Exactly, it is not allowed to backport such a change to rocky for example,
so
on older branches the migration scripts will be there as I see, and you can
upgrade to a release which support migration to Victoria for example.

Regards
lajoskatona

Akihiro Motoki <amotoki at gmail.com> ezt írta (időpont: 2020. júl. 3., P,
15:39):

> On Thu, Jul 2, 2020 at 10:37 PM Ruby Loo <opensrloo at gmail.com> wrote:
> >
> > Hi,
> >
> > On Tue, Jun 30, 2020 at 10:53 PM Akihiro Motoki <amotoki at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <katonalala at gmail.com>
> wrote:
> >> >
> >> > Hi,
> >> > Simplification sounds good (I do not take into considerations like
> "no code fanatic movements" or similar).
> >> > How this could affect upgrade, I am sure there are deployments older
> than pike, and those at a point will
> >> > got for some newer version (I hope we can give them good answers for
> their problems as Openstack)
> >> >
> >> > What do you think about stadium projects? As those have much less
> activity (as mostly solve one rather specific problem),
> >> > and much less migration scripts shall we just "merge" those to init
> ops?
> >> > I checked quickly a few stadium project and only bgpvpn has newer
> migration scripts than pike.
> >>
> >> In my understanding, squashing migrations can be done repository by
> repository.
> >> A revision hash of each migration is not changed and head revisions
> >> are stored in the database per repository, so it should work.
> >> For initial deployments, neutron-db-manage runs all db migrations from
> >> the initial revision to a specified revision (release), so it has no
> >> problem.
> >> For upgrade scenarios, this change just means that we just dropped
> >> support upgrade from releases included in squashed migrations.
> >> For example, if we squash migrations up to rocky (and create
> >> rocky_initial migration) in the neutron repo, we no longer support db
> >> migration from releases before rocky. This would be the only
> >> difference I see.
> >
> > <snip>
> >
> > I wonder if this is acceptable (that an OpenStack service will not
> support db migrations prior to rocky). What is (or is there?) OpenStack's
> stance wrt support for upgrades?  We are using ocata and plan on upgrading
> but we don't know when that might happen :-(
> >
> > --ruby
>
> It is not true. What we the upstream community recommend is to upgrade
> the controller node and databases in the fast-foward upgrade manner.
> Even if the upstream repository just provides database migration from
> for example Rocky, you can upgrade from a release older than rocky, by
> upgrading one release by one.
> In addition, by keeping a specific number of releases in db
> migrations, operators can still upgrade from more than one old release
> (if they want).
>
> --amotoki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200706/a7a5cb0f/attachment.html>