On 4/1/15, 10:52 AM, "Steven Hardy" <sha...@redhat.com> wrote:
>Hi all, > >I've had various discussions about $subject, which have been re-started >lately due to some excellent work going on in the Heat community (Rabi >Mishra's work integrating SoftwareDeployments with various container >launching tools [1]) > >tl;dr It's now possible to launch containers via heat SoftwareConfig >resources in much the same way as we currently apply puppet manifests. > >I'm also aware there has been some great work going on around the kolla >community making things work well with both docker-compose and atomic. > >I'm interested in discussing the next steps, which would appear to involve >providing an optional way to deploy services via containers using TripleO. > >It seems that we can potentially build on the existing abstractions which >were added for puppet integration, e.g: > >https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud- >resource-registry-puppet.yaml > >We could have an alternative resource-registry which maps in a different >set of templates (which have the same parameter interfaces) which >bootstrap >a container host, and deploy each service in a container. > >This might look something like: > >https://github.com/hardys/heat-templates/blob/docker-host/hot/software-con >fig/example-templates/example-docker-script.yaml > >This is just a simple example using "docker run", but similar (probably >much cleaner) approaches will be possible using atomic, docker-compose and >other tools. > >For example, here's an example of how we might bootstrap a pristine atomic >image, install a privileged container hosting the agents needed to talk to >heat, then use that container to launch containers with the services: > >https://review.openstack.org/#/c/164572/6/hot/software-config/example-temp >lates/example-pristine-atomic-docker-compose.yaml > >Similar example for docker-compose: > >https://github.com/openstack/heat-templates/blob/master/hot/software-confi >g/example-templates/example-docker-compose-template.yaml > >There does seem to be a variety of tools folks prefer, but the pattern >appears to be the same in most cases: > >1. Provide input parameters to the template >2. Map parameters to an environment consumable by the container-launching > tool >3. Run the tool and wait for success This is 100% accurate. If we can get this to work in a generic way, people could deploy with puppet in a traditional package based way or with containers in a shiny sparkly way :) > >It may be possible to abstract the details of the various tools inside the >heat hooks, such that you could e.g choose the tool you want via a >template >parameter - e.g it should be possible to build the templates in a way >which >is somewhat tool-agnostic, if we get the heat interfaces refined >correctly. > >What do people think, is this direction reasonable? I'm keen to figure >out >how we do a simple PoC which will bottom out the details, but it'd be >great >to get some feedback on the general approach. > >Thanks! > >Steve Sounds fantastic! I had a look at the templates, and I like Ryan¹s atomic template - perhaps he can post a link on this thread. Although it is Atomic specific, it is a really thin model of how to deploy OpenStack in containers. Of course tripleo will want to see support for more than just Atomic, but they are still worth a look. I¹m pleased to see some movement from the TripleO community on sorting out how to get these things integrated. That said, various off-list email threads have led me to believe people want to use Kolla with maestro-ng as well as Ansible. The core team agreed long ago to developmentally support all the relevant things, and tripleo seems like one good approach, so we are here to help. Regards -steve > >__________________________________________________________________________ >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