<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 8:35 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
So I've recently had several discussions related to $subject.<br>
<br>
In summary - there's a requirement to enable underclouds to support<br>
deploying/updating previous versions of OpenStack overclouds.<br>
<br>
So, say I upgrade my liberty undercloud to master/mitaka, I'd like to<br>
ensure the following is possible:<br>
<br>
1. Maintain any existing (liberty) overcloud without being forced to<br>
immediately upgrade to Mitaka (updating the undercloud can pull in features<br>
required to enable this upgrade however).<br>
<br>
2. Deploy a new overcloud, with the choice between either liberty or mitaka<br>
<br>
This has some implications related to distributing tripleo-heat-templates<br>
(need to allow for packaging to either install both versions of t-h-t, or<br>
always install all versions via one package), and then there are related<br>
requirements related to tripleoclient (and potentially tripleo-common), so<br>
we maintain backwards compatiblity wrt overcloud deployment/update.<br>
<br>
So, some questions:<br>
<br>
- Do we actually want stable branches for tripleoclient (or even<br>
tripleo-common?) if we have to maintain backwards compatibility?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">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.<br></div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Can we add features to tripleoclient now, to make it easier to<br>
pre-configure known locations for specific releases (this should be<br>
configurable via a config file IMO, not hard-coded)?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace"><br>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.)<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.<br></div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- How might we effectively test this in CI? Have a job which deploys e.g<br>
a stable/liberty overcloud with a master undercloud<div class="gmail_default" style="font-family:monospace,monospace;display:inline">?</div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">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.</div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div><br>
<br>
- How hard would it be to wire in image-building for a previous release<br>
(Mitaka/master undercloud building liberty overcloud-full) - would it be<br>
reasonable to assume existing images and say the undercloud only supports<br>
building images for one release version?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">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.</div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts and feedback and volunteers appreciated, thanks!<br>
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">-- James Slagle<br>--</div>
</div></div>