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

James Slagle james.slagle at gmail.com
Mon Dec 21 18:26:02 UTC 2015


On Mon, Dec 21, 2015 at 8:35 AM, Steven Hardy <shardy at redhat.com> 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?
>

​I'd prefer backwards compatibility for both tripleoclient and
tripleo-common.​ Especially given that we may eventually use tripleo-common
as the backing for an API.


> - 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)?
>


We might need something like --template-version which would take kilo,
liberty, mitaka, etc. ​That could also then be used to determine version
specific steps (such as post-config for kilo clouds, that wouldn't be
needed for liberty/mitaka given the move to puppet-keystone for endpoint
configuration.)

We could also key off that to use a default template location. Should we
make tripleo-heat-templates pip installable via setup.cfg? The liberty
branch could install under a liberty subdirectory, while master could
install under mitaka and also setup a "latest" symlink.



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

Makes sense to me. We had talked about making this a periodic job
initially. Maybe we could have it in an experimental queue as well so we
could run it on demand on suspect changes.​



>>
>
> - 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?
>

​I think it'd be reasonable. You don't actually need a full undercloud to
build images. So, if you wanted to build images for an older release, you
really only need to install the older version of tripleoclient that had
support for building the images for that release.​



>
> Thoughts and feedback and volunteers appreciated, thanks!
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151221/270a92b6/attachment.html>


More information about the OpenStack-dev mailing list