Open Stack

On Thu, Nov 16, 2017 at 4:56 PM, James Slagle <james.slagle at gmail.com> wrote:
> On Thu, Nov 16, 2017 at 8:44 AM, Flavio Percoco <flavio at redhat.com> wrote:
>> Integration with TripleO Heat Templates
>> =======================================
>>
>> This work is on-going and you should eventually see some patches popping-up
>> on
>> the reviews list. One of the goals, besides consuming these ansible roles
>> from
>> t-h-t, is to be able to create a PoC for upgrades and have an end-to-end
>> test/demo of this work.
>>
>> As we progress, we are trying to nail down an end-to-end deployment before
>> creating roles for all the services that are currently supported by TripleO.
>> We
>> will be adding projects as needed with a focus on the end-to-end goal.
>
> When we consume these ansible-role-k8s-* roles from t-h-t, I think
> that should be a stepping stone towards migrating away from having to
> use Heat to deploy and configure those services. We know that these
> new ansible roles will be deployable standalone, and the interface to
> do that should be typical ansible best practices (role defaults, vars,
> etc).
>
> We can offer a mechanism such that one can migrate from a
> tripleo-heat-templates/docker/services/database/mysql.yaml deployed
> mariadb to one deployed via
> ansible-role-k8s-mariadb. The config-download mechanism could be
> updated to generate or pull from Heat the necessary ansible vars files
> for configuring the roles. We should make sure that the integration
> with tripleo-heat-templates results in the same inputs/outputs that
> someone would consume if using the roles standalone. Future iterations
> would then not have to require Heat for that service at all, unless
> the operator wanted to continue to configure the service via Heat
> parameters/environments.
>
> What I'm trying to propose is a path towards deprecating the Heat
> parameter/environment driven and hieradata driven approach to
> configuring the services. The ansible-role-k8s-* roles should offer a
> new interface, so I don't think we have to remain tied to Heat
> forever, so we should consider what we want the long term goal to be
> in an ideal world, and take some iterative steps to get there.

I agree this is a good time to discuss ways to rationalize the
toolchain, but I do suspect it may be premature to consider
derprecating puppet/hiera as AFAIK this doesn't provide any drop-in
replacement for the config file generation?

I was thinking we'd probably maintain the current docker-puppet.py
model for this first pass, to reduce the risk of migrating containers
to k8s, and we could probably refactor things such that this config
generation via puppet+docker is orchestrated via the ansible roles and
kubernetes?

The current model is something like:

1. Run temporary docker container, run puppet, write config files to
host file system
2. Start service container, config files bind mounted into container
from host filesystem
3. Run temporary bootstrapping container (runs puppet, optional step)

(this is simplified for clarity as there are opportunities for some
other bootstrapping steps)

In the ansible/kubernetes model, it could work like:

1. Ansible role makes k8s API call creating pod with multiple containers
2. Pod starts temporary container that runs puppet, config files
written out to shared volume
3. Service container starts, config consumed from shared volume
4. Optionally run temporary bootstrapping container inside pod

This sort of pattern is documented here:

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

The main advantage is we don't have to reimplement config management
for every single service, but obviously we'd want this to be pluggable
in the ansible roles so other config management strategies/tools could
be used instead of our puppet model.

> It's probably worthwhile as a thought experiment to update this
> diagram[0] as to how it might look at different future stages. The
> first stage might just be t-h-t driven ansible-role-k8s-* , followed
> by a migration to ansible-role-k8s-* as the primary interface, and
> then finally perhaps no Heat[1].

Agreed this is definitely a good time to discuss moving the service
configuration workflow to pure ansible, but as noted above I'm not
convinced we're yet ready to take puppet out of the mix, so it may be
safer to leave that (by now quite well proven in our heat+ansible
container architecture) pattern in place, at least initially?

Thanks!

Steve

> [0] https://slagle.fedorapeople.org/tripleo-ansible-arch.png
> [1] Except for perhaps deployment of baremetal resources, but even
> then I'm personally of the opinion that would be better serviced by
> Mistral->Ansible->Ironic directly.
>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev