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
