Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Michael Stang]

I think we give it a try then, thank you :-)
 
Kind regards,
Michael

> Simon Leinen  hat am 18. Juni 2016 um 16:21
> geschrieben:
>
>
> Michael Stang writes:
> > Is this one the actual guid for upgrades, and is it valid for every
> > upgrade or ony for specific versions?:
> > http://docs.openstack.org/ops-guide/ops_upgrades.html
>
> Yes, that's part of the official Operations Guide. It is not
> version-specific. The examples are based on Ubuntu as the underlying OS
> distribution. But the approach and recommendations are general.
> --
> Simon.
 ___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Simon Leinen]

Michael Stang writes:
> Is this one the actual guid for upgrades, and is it valid for every
> upgrade or ony for specific versions?:
> http://docs.openstack.org/ops-guide/ops_upgrades.html

Yes, that's part of the official Operations Guide.  It is not
version-specific.  The examples are based on Ubuntu as the underlying OS
distribution.  But the approach and recommendations are general.
-- 
Simon.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Dan Smith]

> +1 to everything Daniel said. Nova really expects release-to-release
> upgrades. We do online data migrations between releases. Maybe one
> reason you're getting this to work is we have a nova-manage command to
> force the migration of data between releases rather than doing the
> online data migration as resources are accessed. But there are some DB
> migrations where we do a full stop until you've migrated the data.

Yeah, this ^

We try to put blocker migrations into the stream at critical
synchronization points to make sure that anything that *has* to be
online migrated will have been complete before we roll forward (usually
because we're about to drop something or introduce a constraint).
However, I'm sure there are some subtleties we don't catch with that.

To echo and expand on what Matt said, if you're going to do an
accelerated upgrade, I would _at least_ recommend deploying the
intermediate code an running all the online migrations to completion
(after applying the intermediate schema updates) before rolling to the
next. This means running this after "db sync" for releases after it was
added:

https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L823

Just deploying the target code and running online migrations isn't
really enough, because we often remove the migration code once we know
it (should have been) run to completion. Since we can't know everyone's
upgrade cadence, and since our official support is "N-1 to N", that's
the price you pay for skipping a release.

--Dan

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Matt Riedemann]

On 6/15/2016 10:30 AM, Daniel P. Berrange wrote:

On Wed, Jun 15, 2016 at 03:19:28PM +, Jesse Keating wrote:

I'll offer a counter point.

We're not doing Juno to Mitaka, however we are doing Kilo to Mitaka, skipping
over Liberty.

The database migrations to get from Kilo to Mitaka have ran smoothly for us.


While it is great that it /appeared/ to work correctly for you, that is in
no way guaranteed. There also might be data that has silently been incorrectly
migrated due to missing the intermediate release that could cause problems
at some indeterminate point down the road. While we do test the N -> N+1
upgrade path, there is no CI testing of the N -> N + 2 upgrade path. IOW
while it may have worked for you between these 2 particular releases, there
is again no guarantee it'll work for any future pair of N, N+2 releases.
If you want to accept the risks, that's fine, but I'd certainly not suggest
it is a reasonable thing todo for deployments in general. Also what happened
to work for you may just as easily not work for other people, depending on
characteristics of their deployment configuration & data set.

Regards,
Daniel



+1 to everything Daniel said. Nova really expects release-to-release 
upgrades. We do online data migrations between releases. Maybe one 
reason you're getting this to work is we have a nova-manage command to 
force the migration of data between releases rather than doing the 
online data migration as resources are accessed. But there are some DB 
migrations where we do a full stop until you've migrated the data.


--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Daniel P. Berrange]

On Wed, Jun 15, 2016 at 03:19:28PM +, Jesse Keating wrote:
> I'll offer a counter point.
>  
> We're not doing Juno to Mitaka, however we are doing Kilo to Mitaka, skipping
> over Liberty.
>  
> The database migrations to get from Kilo to Mitaka have ran smoothly for us.

While it is great that it /appeared/ to work correctly for you, that is in
no way guaranteed. There also might be data that has silently been incorrectly
migrated due to missing the intermediate release that could cause problems
at some indeterminate point down the road. While we do test the N -> N+1
upgrade path, there is no CI testing of the N -> N + 2 upgrade path. IOW
while it may have worked for you between these 2 particular releases, there
is again no guarantee it'll work for any future pair of N, N+2 releases.
If you want to accept the risks, that's fine, but I'd certainly not suggest
it is a reasonable thing todo for deployments in general. Also what happened
to work for you may just as easily not work for other people, depending on
characteristics of their deployment configuration & data set.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Jesse Keating]

I'll offer a counter point.
 
We're not doing Juno to Mitaka, however we are doing Kilo to Mitaka, skipping over Liberty.
 
The database migrations to get from Kilo to Mitaka have ran smoothly for us.
 
https://github.com/blueboxgroup/ursula/blob/master/upgrade.yml
-jlk
 
 
- Original message -From: Melvin Hillsman To: Saverio Proto Cc: OpenStack Operators Subject: Re: [Openstack-operators] Upgrade OpenStack Juno to MitakaDate: Wed, Jun 15, 2016 8:11 AM 
+1 on Saverio's response. You will want to upgrade to Mitaka by NOT jumping releases; J - K - L - M not J - M 
 
On Wed, Jun 15, 2016 at 4:13 AM, Saverio Proto  wrote:

Hello,first of all I suggest you read this article:http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions> What is the best way to performe an upgrade from Juno to Mitaka?I would go for the in place upgrade, but I always upgraded withoutjumping version, that AFAIK is not supported.The main problem I see, is that database migrations are supported whenyou upgrade to the next release, but if you jump form Juno to Mitaka Ihave to idea how the database upgrade cloud be done.Saverio___OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

[Saverio Proto]

Hello,

first of all I suggest you read this article:
http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions

> What is the best way to performe an upgrade from Juno to Mitaka?

I would go for the in place upgrade, but I always upgraded without
jumping version, that AFAIK is not supported.

The main problem I see, is that database migrations are supported when
you upgrade to the next release, but if you jump form Juno to Mitaka I
have to idea how the database upgrade cloud be done.

Saverio

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators