<div dir="ltr">Hi,<div>Exactly, it is not allowed to backport such a change to rocky for example, so</div><div>on older branches the migration scripts will be there as I see, and you can </div><div>upgrade to a release which support migration to Victoria for example.</div><div><br></div><div>Regards</div><div>lajoskatona</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> ezt írta (időpont: 2020. júl. 3., P, 15:39):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jul 2, 2020 at 10:37 PM Ruby Loo <<a href="mailto:opensrloo@gmail.com" target="_blank">opensrloo@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Tue, Jun 30, 2020 at 10:53 PM Akihiro Motoki <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <<a href="mailto:katonalala@gmail.com" target="_blank">katonalala@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi,<br>
>> > Simplification sounds good (I do not take into considerations like "no code fanatic movements" or similar).<br>
>> > How this could affect upgrade, I am sure there are deployments older than pike, and those at a point will<br>
>> > got for some newer version (I hope we can give them good answers for their problems as Openstack)<br>
>> ><br>
>> > What do you think about stadium projects? As those have much less activity (as mostly solve one rather specific problem),<br>
>> > and much less migration scripts shall we just "merge" those to init ops?<br>
>> > I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.<br>
>><br>
>> In my understanding, squashing migrations can be done repository by repository.<br>
>> A revision hash of each migration is not changed and head revisions<br>
>> are stored in the database per repository, so it should work.<br>
>> For initial deployments, neutron-db-manage runs all db migrations from<br>
>> the initial revision to a specified revision (release), so it has no<br>
>> problem.<br>
>> For upgrade scenarios, this change just means that we just dropped<br>
>> support upgrade from releases included in squashed migrations.<br>
>> For example, if we squash migrations up to rocky (and create<br>
>> rocky_initial migration) in the neutron repo, we no longer support db<br>
>> migration from releases before rocky. This would be the only<br>
>> difference I see.<br>
><br>
> <snip><br>
><br>
> 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 :-(<br>
><br>
> --ruby<br>
<br>
It is not true. What we the upstream community recommend is to upgrade<br>
the controller node and databases in the fast-foward upgrade manner.<br>
Even if the upstream repository just provides database migration from<br>
for example Rocky, you can upgrade from a release older than rocky, by<br>
upgrading one release by one.<br>
In addition, by keeping a specific number of releases in db<br>
migrations, operators can still upgrade from more than one old release<br>
(if they want).<br>
<br>
--amotoki<br>
</blockquote></div>