Re: [openstack-dev] [TripleO] tripleoclient/tripleo-common backwards compatibility

2015-12-21 Thread Steven Hardy
Ok, looked into this a little today, apologies for replying to my own
thread:

On Mon, Dec 21, 2015 at 01:35:54PM +, Steven Hardy wrote:
> Hi all,
> 
> So I've recently had several discussions related to $subject.
> 
> In summary - there's a requirement to enable underclouds to support
> deploying/updating previous versions of OpenStack overclouds.
> 
> So, say I upgrade my liberty undercloud to master/mitaka, I'd like to
> ensure the following is possible:
> 
> 1. Maintain any existing (liberty) overcloud without being forced to
> immediately upgrade to Mitaka (updating the undercloud can pull in features
> required to enable this upgrade however).
>
> 2. Deploy a new overcloud, with the choice between either liberty or mitaka
> 
> This has some implications related to distributing tripleo-heat-templates
> (need to allow for packaging to either install both versions of t-h-t, or
> always install all versions via one package), and then there are related
> requirements related to tripleoclient (and potentially tripleo-common), so
> we maintain backwards compatiblity wrt overcloud deployment/update.
> 
> So, some questions:
> 
> - Do we actually want stable branches for tripleoclient (or even
>   tripleo-common?) if we have to maintain backwards compatibility?
> 
> - Can we add features to tripleoclient now, to make it easier to
>   pre-configure known locations for specific releases (this should be
>   configurable via a config file IMO, not hard-coded)?
> 
> - How might we effectively test this in CI?  Have a job which deploys e.g
>   a stable/liberty overcloud with a master undercloud?
> 
> - How hard would it be to wire in image-building for a previous release
>   (Mitaka/master undercloud building liberty overcloud-full) - would it be
>   reasonable to assume existing images and say the undercloud only supports
>   building images for one release version?

Turns out this is pretty easy:

https://review.openstack.org/#/c/260144/

This shows how to build a liberty overcloud-full (on a master/mitaka
undercloud), then deploy a stable/liberty overcloud.

I've not heavily tested, but basically it seems to work OK, I had to apply
this pending stable/liberty backport:

https://review.openstack.org/#/c/258640/

I think the tripleo.sh patch (and steps outlined in the commit message) may
serve as a starting point for CI of this, and I do think we need to remove
the stable/liberty branch at least for tripleoclient.

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO] tripleoclient/tripleo-common backwards compatibility

2015-12-21 Thread Steven Hardy
Hi all,

So I've recently had several discussions related to $subject.

In summary - there's a requirement to enable underclouds to support
deploying/updating previous versions of OpenStack overclouds.

So, say I upgrade my liberty undercloud to master/mitaka, I'd like to
ensure the following is possible:

1. Maintain any existing (liberty) overcloud without being forced to
immediately upgrade to Mitaka (updating the undercloud can pull in features
required to enable this upgrade however).

2. Deploy a new overcloud, with the choice between either liberty or mitaka

This has some implications related to distributing tripleo-heat-templates
(need to allow for packaging to either install both versions of t-h-t, or
always install all versions via one package), and then there are related
requirements related to tripleoclient (and potentially tripleo-common), so
we maintain backwards compatiblity wrt overcloud deployment/update.

So, some questions:

- Do we actually want stable branches for tripleoclient (or even
  tripleo-common?) if we have to maintain backwards compatibility?

- Can we add features to tripleoclient now, to make it easier to
  pre-configure known locations for specific releases (this should be
  configurable via a config file IMO, not hard-coded)?

- How might we effectively test this in CI?  Have a job which deploys e.g
  a stable/liberty overcloud with a master undercloud?

- How hard would it be to wire in image-building for a previous release
  (Mitaka/master undercloud building liberty overcloud-full) - would it be
  reasonable to assume existing images and say the undercloud only supports
  building images for one release version?

Thoughts and feedback and volunteers appreciated, thanks!

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev