Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?
Paul Bourke wrote: Hi Joshua, Thanks for sharing your workflow, interesting to see. To answer your question, there is a 1:1 relationship between Kolla and OpenStack releases. As Kevin outlined, you may get lucky, currently in Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most part it works fine. But it's not recommended from an upstream point of view. Thanks Paul, good to hear that I'm not the only one asking this :-P Can u describe more of the 'most part it works fine'? Anything that you've hit that I don't have to would be nice to know ;) Maybe we need more discussion on that as it's something I see popping up frequently. We also have a warning in the docs around this, see http://docs.openstack.org/developer/kolla/quickstart.html#building-container-images Yes +1 A matrix of kolla release to what openstack release would be nice, Especially taking into account the fact that the image building process will likely work across many releases but the deployment part may not (which is fine with me, all I want right now is the docker image building, the deployment we already have existing tooling that we are working through and adjusting anyway). PS: this likely won't be a permanent question but is more situational as godaddy moves from liberty to a newer release (once we get our processes streamlined we shouldn't be so far behind...). -Paul __ 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
Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?
Hi Joshua, Thanks for sharing your workflow, interesting to see. To answer your question, there is a 1:1 relationship between Kolla and OpenStack releases. As Kevin outlined, you may get lucky, currently in Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most part it works fine. But it's not recommended from an upstream point of view. Maybe we need more discussion on that as it's something I see popping up frequently. We also have a warning in the docs around this, see http://docs.openstack.org/developer/kolla/quickstart.html#building-container-images -Paul On 09/11/16 17:28, Joshua Harlow wrote: Hi kolla folks, As I am (and others at godaddy) are working through integrating kolla image building into our jenkins pipeline(s), Currently the pipeline is the following (taking an example of glance), # Checkout stage 1. Checkout kolla at X tag/branch 2. Checkout glance at Y tag/branch 3. Checkout internal-deploy repo (which has patches for various projects) at Z tag/branch 4. Checkout requirements repo at Y tag/branch (same Y as #2) # Test stage 5. Create a virtualenv for glance using constraints from #4 6. Run testr and capture the results of tests and make sure those work (or fail here) 7. Patch glance using patches from #3 8. Retest glance using same routine as #6 and make sure those work (or fail here) # Kolla stage 9. Setup kolla-build.conf with sections for glance (setup to take the glance tested as a local directory) and sections for openstack-base (which == the requirements repo from #4) and create a template-overrides.j2 with various specific kolla overrides 10. Build images (or fail here) 11. Upload images to artifactory (WIP here) Stage next So the general question I have is that kolla has tags/branches that match glance and other openstack releases but I'm not really sure how tightly bound kolla is to those same tags/branches, For example right now I am taking kolla at stable/newton but glance and requirements at stable/liberty, This seems to work (ya!) but I don't quite know if this is really recommended, is kolla really tied to the same branches of the other openstack projects, With the projects moving to more independent releases is there any suggested policy, will kolla work with what project releases? Some range of releases that will work, won't work...? Ie, kolla stable/newton for example will work with A, B, C, ... branches of [neutron, glance...]? Should kolla have a known working list, stating the above in some location inside of the kolla repo (so people know)? Thoughts? Comments? -Josh __ 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 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
Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?
Fox, Kevin M wrote: 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 Right cool, I'm not yet looking into the k8s+kolla stuffs, More of just trying to get the docker images built and used and wondering some of these questions; I'm sure adding in k8s would help, but is probably not something that I could easily pull-off because we have existing clouds that have been running afaik before even k8s existed, ha. So starting at ground-zero (with just the images that get built). -Josh __ 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
Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?
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 [harlo...@fastmail.com] 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack?
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 From: Joshua Harlow [harlo...@fastmail.com] Sent: Wednesday, November 09, 2016 9:28 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [kolla] How tied is kolla to matching 1:1 releases of openstack? Hi kolla folks, As I am (and others at godaddy) are working through integrating kolla image building into our jenkins pipeline(s), Currently the pipeline is the following (taking an example of glance), # Checkout stage 1. Checkout kolla at X tag/branch 2. Checkout glance at Y tag/branch 3. Checkout internal-deploy repo (which has patches for various projects) at Z tag/branch 4. Checkout requirements repo at Y tag/branch (same Y as #2) # Test stage 5. Create a virtualenv for glance using constraints from #4 6. Run testr and capture the results of tests and make sure those work (or fail here) 7. Patch glance using patches from #3 8. Retest glance using same routine as #6 and make sure those work (or fail here) # Kolla stage 9. Setup kolla-build.conf with sections for glance (setup to take the glance tested as a local directory) and sections for openstack-base (which == the requirements repo from #4) and create a template-overrides.j2 with various specific kolla overrides 10. Build images (or fail here) 11. Upload images to artifactory (WIP here) Stage next So the general question I have is that kolla has tags/branches that match glance and other openstack releases but I'm not really sure how tightly bound kolla is to those same tags/branches, For example right now I am taking kolla at stable/newton but glance and requirements at stable/liberty, This seems to work (ya!) but I don't quite know if this is really recommended, is kolla really tied to the same branches of the other openstack projects, With the projects moving to more independent releases is there any suggested policy, will kolla work with what project releases? Some range of releases that will work, won't work...? Ie, kolla stable/newton for example will work with A, B, C, ... branches of [neutron, glance...]? Should kolla have a known working list, stating the above in some location inside of the kolla repo (so people know)? Thoughts? Comments? -Josh __ 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 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] [kolla] How tied is kolla to matching 1:1 releases of openstack?
Hi kolla folks, As I am (and others at godaddy) are working through integrating kolla image building into our jenkins pipeline(s), Currently the pipeline is the following (taking an example of glance), # Checkout stage 1. Checkout kolla at X tag/branch 2. Checkout glance at Y tag/branch 3. Checkout internal-deploy repo (which has patches for various projects) at Z tag/branch 4. Checkout requirements repo at Y tag/branch (same Y as #2) # Test stage 5. Create a virtualenv for glance using constraints from #4 6. Run testr and capture the results of tests and make sure those work (or fail here) 7. Patch glance using patches from #3 8. Retest glance using same routine as #6 and make sure those work (or fail here) # Kolla stage 9. Setup kolla-build.conf with sections for glance (setup to take the glance tested as a local directory) and sections for openstack-base (which == the requirements repo from #4) and create a template-overrides.j2 with various specific kolla overrides 10. Build images (or fail here) 11. Upload images to artifactory (WIP here) Stage next So the general question I have is that kolla has tags/branches that match glance and other openstack releases but I'm not really sure how tightly bound kolla is to those same tags/branches, For example right now I am taking kolla at stable/newton but glance and requirements at stable/liberty, This seems to work (ya!) but I don't quite know if this is really recommended, is kolla really tied to the same branches of the other openstack projects, With the projects moving to more independent releases is there any suggested policy, will kolla work with what project releases? Some range of releases that will work, won't work...? Ie, kolla stable/newton for example will work with A, B, C, ... branches of [neutron, glance...]? Should kolla have a known working list, stating the above in some location inside of the kolla repo (so people know)? Thoughts? Comments? -Josh __ 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
