On 03/23/2016 03:11 PM, Fox, Kevin M wrote:
If heat convergence worked (Is that a thing yet?), it could potentially be used
instead of a COE like kubernetes.
The thing ansible buys us today would be upgradeability. Ansible is config
management, but its also a workflow like tool. Heats bad at workflow.
I think between Heat with Convergence, Kolla containers, and some kind of
Mistral workflow for upgrades, you could replace Ansible.
Then there's the nova instance user thing again
(https://review.openstack.org/222293)... How do you get secrets to the
instances securely... Kubernetes has a secure store we could use... OpenStack
still hasn't really gotten this one figured out. :/ Barbican is a piece of that
puzzle, but there's no really good to hook it and nova together.
Don;t really think Kubernetes has this solved, either. You need to
build security from the ground up.
I think the best we can do is get an One Time Password into the config
driver for a new instance, and immediately have that instance use the
OTP to register with an identity manager.
Thanks,
Kevin
________________________________________
From: Michał Jastrzębski [inc...@gmail.com]
Sent: Wednesday, March 23, 2016 8:42 AM
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
Hello,
So Ryan, I think you can make use of heat all the way. Architecture of
kolla doesn't require you to use ansible at all (in fact, we separate
ansible code to a different repo). Truth is that ansible-kolla is
developed by most people and considered "the way to deploy kolla" by
most of us, but we make sure that we won't cut out other deployment
engines from our potential.
So bottom line, heat may very well replace ansible code if you can
duplicate logic we have in playbooks in heat templates. That may
require docker resource with pretty complete featureset of docker
itself (named volumes being most important). Bootstrap is usually done
inside container, so that would be possible too.
To be honest, as for tripleo doing just bare metal deployment would
defeat idea of tripleo. We have bare metal deployment tools already
(cobbler which is used widely, bifrost which use ansible same as kolla
and integration would be easier), and these comes with significantly
less footprint than whole tripleo infrastructure. Strength of tripleo
comes from it's rich config of openstack itself, and I think that
should be portable to kolla.
On 23 March 2016 at 06:54, Ryan Hallisey <rhall...@redhat.com> 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.
Thanks!
-Ryan
[1] - https://github.com/openstack/kolla/blob/master/ansible/inventory/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: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
__________________________________________________________________________
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
