settingsLogin | Registersettings

[openstack-dev] [tripleo][kolla] Investigating containerizing TripleO

0 votes

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-config/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-templates/example-pristine-atomic-docker-compose.yaml

Similar example for docker-compose:

https://github.com/openstack/heat-templates/blob/master/hot/software-config/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

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 1, 2015 in openstack-dev by Steven_Hardy (16,900 points)   2 7 11
retagged Apr 14, 2015 by admin

2 Responses

0 votes

Hi,

Over the last few weeks Ian Main and I have been working on getting some integration between Kolla and tripleo.
For a simple proof of concept, we launched devstack to serve as an undercloud and used heat to spawn an overcloud
on a rhel-atomic image. In the overcloud, we deployed openstack in containers pulling from the latest kolla images.
We successfully tested keystone, loading an image into glance, booting an image in nova, and sshing into that image.

We're starting to move over to a tripleo environment to try and directly integrate now that we've proven it works.
Here is the heat template that we are using: https://github.com/rthallisey/atomic-osp-installer/blob/master/heat/openstack_deploy.yaml
This will serve as a template that will get openstack up and running on a single node. This template is a good foundation
to create addition templates since any other config is mostly going to be a copy and paste.

This POC uses atomic to start up openstack, but it can also be done using docker-compose.
The heat template for docker compose should look about the same.

We're going to push this work upstream shortly, but in the meantime the work can be tracked in the repo I linked above.

Thanks,
Ryan Hallisey


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 1, 2015 by Ryan_Hallisey (2,980 points)   1 3
0 votes

On 4/1/15, 10:52 AM, "Steven Hardy" shardy@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 3, 2015 by Steven_Dake_(stdake) (24,540 points)   2 10 23
...