On Thu, Mar 31, 2016 at 12:12 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > The main issue is one of upgradability, not stability. We all know tripleo > is stable. Tripleo cant do upgrades today. We're looking for ways to get > there. So "upgrading" to ansible isnt nessisary for sure since folks > deploying tripleo today must assume they cant upgrade anyway.
That is wrong now: we are able to upgrade from Liberty to Mitaka. We're even engaging some CI efforts to have an upgrade job, that will run on each patch. > Honestly I have doubts any config management system from puppet to heat > software deployments can be coorced to do a cloud upgrade without downtime > without a huge amount of workarounds. You really either need a workflow > oriented system with global knowledge like ansible or a container > orchestration system like kubernes to ensure you dont change too many things > at once and break things. You need to be able to run some old things and > some new, all at the same time. And in some cases different versions/config > of the same service on different machines. > Thoughts on how this may be made to work with puppet/heat? Yes, TripleO team is currently investigating and pushing efforts on Mistral, that is the workflow service in OpenStack. Some background about Mistral choice: http://lists.openstack.org/pipermail/openstack-dev/2016-January/083757.html The spec is discussed here: https://review.openstack.org/#/c/280407/ We think Mistral will really help us to achieve workflows in TripleO, including upgrades. Dan Prince made a screencast to demonstrate Mistral usage: https://www.youtube.com/watch?v=bnAT37O-sdw > Thanks, > Kevin > > ________________________________ > From: Dan Prince > Sent: Monday, March 28, 2016 12:07:22 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, > containers, and the future of TripleO > > On Wed, 2016-03-23 at 07:54 -0400, Ryan Hallisey wrote: >> *Snip* >> >> > >> > Indeed, this has literally none of the benefits of the ideal Heat >> > deployment enumerated above save one: it may be entirely the wrong >> > tool >> > in every way for the job it's being asked to do, but at least it >> > is >> > still well-integrated with the rest of the infrastructure. >> > >> > Now, at the Mitaka summit we discussed the idea of a 'split >> > stack', >> > where we have one stack for the infrastructure and a separate one >> > for >> > the software deployments, so that there is no longer any tight >> > integration between infrastructure and software. Although it makes >> > me a >> > bit sad in some ways, I can certainly appreciate the merits of the >> > idea >> > as well. However, from the argument above we can deduce that if >> > this is >> > the *only* thing we do then we will end up in the very worst of >> > all >> > possible worlds: the wrong tool for the job, poorly integrated. >> > Every >> > single advantage of using Heat to deploy software will have >> > evaporated, >> > leaving only disadvantages. >> I think Heat is a very powerful tool having done the container >> integration >> into the tripleo-heat-templates I can see its appeal. Something I >> learned >> from integration, was that Heat is not the best tool for container >> deployment, >> at least right now. We were able to leverage the work in Kolla, but >> what it >> came down to was that we're not using containers or Kolla to its max >> potential. >> >> I did an evaluation recently of tripleo and kolla to see what we >> would gain >> if the two were to combine. Let's look at some items on tripleo's >> roadmap. >> Split stack, as mentioned above, would be gained if tripleo were to >> adopt >> Kolla. Tripleo holds the undercloud and ironic. Kolla separates >> config >> and deployment. Therefore, allowing for the decoupling for each >> piece of >> the stack. Composable roles, this would be the ability to land >> services >> onto separate hosts on demand. Kolla also already does this [1]. >> Finally, >> container integration, this is just a given :). >> >> In the near term, if tripleo were to adopt Kolla as its overcloud it >> would >> be provided these features and retire heat to setting up the >> baremetal nodes >> and providing those ips to ansible. This would be great for kolla >> too because >> it would provide baremetal provisioning. >> >> Ian Main and I are currently working on a POC for this as of last >> week [2]. >> It's just a simple heat template :). >> >> I think further down the road we can evaluate using kubernetes [3]. >> For now though, kolla-anisble is rock solid and is worth using for >> the >> overcloud. > > Yeah, well TripleO heat Overclouds are rock solid too. They just aren't > using containers everywhere yet. So lets fix that. > > I'm not a fan of replacing the TripleO overcloud configuration with > Kolla. I don't think there is feature parity, the architectures are > different (HA, etc.) and I don't think you could easily pull off an > upgrade from one deployment to the other (going from TripleO Heat > template deployed overcloud to Kolla deployed overcloud). > >> >> Thanks! >> -Ryan >> >> [1] - https://github.com/openstack/kolla/blob/master/ansible/inventor >> y/multinode >> [2] - https://github.com/rthallisey/kolla-heat-templates >> [3] - https://review.openstack.org/#/c/255450/ >> >> >> _____________________________________________________________________ >> _____ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs >> cribe >> 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 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 > -- Emilien Macchi __________________________________________________________________________ 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
