[openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO
Adam Young
ayoung at redhat.com
Thu Mar 24 02:46:17 UTC 2016
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 [inc007 at 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 <rhallise at 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-request at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list