On Wed, Mar 23, 2016 at 1:34 PM, Zane Bitter <zbit...@redhat.com> wrote: > On 23/03/16 07:54, 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. > > > My concern about kolla-ansible is that the requirements might start getting > away from what the original design was intended to cope with, and that it > may prove difficult to extend. For example, I wrote about the idea of doing > the container deployments with pure Heat: > >>> What's more, we are going to need some way of redistributing services >>> when a machine in the cluster fails, and ultimately we would like that >>> process to be automated, which would *require* a template generation >>> service. >>> >>> We certainly *could* build all of that. But we definitely shouldn't > > > and to my mind kolla-ansible is in a similar category in that respect (it > does, of course, have an existing community and in that sense is still > strictly superior to the pure-Heat approach). There's lots of stuff in e.g. > Kubernetes that it seems likely we'll want and, while there's no > _theoretical_ obstacle to implementing them in Ansible, these are hard, > subtle problems which are presumably better left to a specialist project.
Fully agree with Zane here. I'm not really excited by using anything other than Kubernetes for container orchestration (unless it's mesos, but my understanding is it's a bit more heavyweight). Though I am certainly okay with using kolla-ansible to generate config for all the OpenStack services, but if it's faster to use puppet then that's fine too. The only drawback that I know of is that the Kolla containers would need modifying since Kubernetes has no notion of dependencies. But perhaps I'm getting ahead of myself... > I'd be happy to hear other opinions on that though. Maybe we don't care > about any of that container cluster management stuff, and if something fails > we just let everything run degraded until we can pull in a replacement? I > don't know. __________________________________________________________________________ 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