currently one to one on kolla version and openstack release. so 2.0.x is mitaka. 3.0.x is newton.
I think if we continue forward with the helm idea it will simplify the use case too. as you can then match up a k8s package (with its templates) for a mitaka resource with the mitaka containers. So there shouldn't need to be conditional logic in the templates. Thanks, Kevin ________________________________________ From: Joshua Harlow [[email protected]] Sent: Wednesday, November 09, 2016 1:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack? Fox, Kevin M wrote: > I think its kind of in the same vein as the rest of the openstack services. > It might, (and probably will) work with n-1& n services in the same system. > But it all depends on either: > 1. The things that are actually tested > or > 2. Luck > > I've been testing the kolla-kubernetes deployment tools with 2.0.x containers > and 3.0.x containers, so those should work. any other combination might work > but I no idea if they actually will work as its untested. > > More gate testing would help and be welcome. :) > > Thanks, > Kevin Agreed on gate testing, I'm just not sure the general direction people would want. I've done cross n-1 and n and n-2 and such and jinja2 templates start to have a bunch of if conditions to handle specific releases peculiarities. As far as 2.0.x containers and 3.0.x containers, what version of openstack projects compose 2.0.x, is there a mapping of something like: 3.0.x: - nova: branches_supported: [stable/newton] - glance: branches_supported: [stable/newton, stable/mitaka] .... Or is it just assumed that the mapping is sorta known? Unsure quite how to correlate a given kolla release to what underlying projects it can build into images or deploy or manage (is this online somewhere, or do I just have to dig through the code) :-P -Josh __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
