<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 4:24 PM James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There's been a fair amount of recent work around simplifying our Heat<br>
templates and migrating the software configuration part of our<br>
deployment entirely to Ansible.<br>
<br>
As part of this effort, it became apparent that we could render much<br>
of the data that we need out of Heat in a way that is generic per<br>
node, and then have Ansible render the node specific data during<br>
config-download runtime.<br>
<br>
To illustrate the point, consider when we specify ComputeCount:10 in<br>
our templates, that much of the work that Heat is doing across those<br>
10 sets of resources for each Compute node is duplication. However,<br>
it's been necessary so that Heat can render data structures such as<br>
list of IP's, lists of hostnames, contents of /etc/hosts files, etc<br>
etc etc. If all that was driven by Ansible using host facts, then Heat<br>
doesn't need to do those 10 sets of resources to begin with.<br>
<br>
The goal is to get to a point where we can deploy the Heat stack with<br>
a count of 1 for each role, and then deploy any number of nodes per<br>
role using Ansible. To that end, I've been referring to this effort as<br>
N=1.<br>
<br>
The value in this work is that it directly addresses our scaling<br>
issues with Heat (by just deploying a much smaller stack). Obviously<br>
we'd still be relying heavily on Ansible to scale to the required<br>
levels, but I feel that is much better understood challenge at this<br>
point in the evolution of configuration tools.<br>
<br>
With the patches that we've been working on recently, I've got a POC<br>
running where I can deploy additional compute nodes with just Ansible.<br>
This is done by just adding the additional nodes to the Ansible<br>
inventory with a small set of facts to include IP addresses on each<br>
enabled network and a hostname.<br>
<br>
These patches are at<br>
<a href="https://review.opendev.org/#/q/topic:bp/reduce-deployment-resources" rel="noreferrer" target="_blank">https://review.opendev.org/#/q/topic:bp/reduce-deployment-resources</a><br>
and reviews/feedback are welcome.<br></blockquote><div><br></div><div>This is a fabulous proposal in my opinion.</div><div>I've added (and will continue to add) TODO ideas in the etherpad.</div><div>Anyone willing to help, please ping us if needed.</div><div><br></div><div>Another point, somewhat related: I took the opportunity of this work to reduce the complexity around the number of hieradata files.</div><div>I would like to investigate if we can generate one data file which would be loaded by both Puppet and Ansible for doing the configuration management. I'll create a separated thread on that effort very soon.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Other points:<br>
<br>
- Baremetal provisioning and port creation are presently handled by<br>
Heat. With the ongoing efforts to migrate baremetal provisioning out<br>
of Heat (nova-less deploy), I think these efforts are very<br>
complimentary. Eventually, we get to a point where Heat is not<br>
actually creating any other OpenStack API resources. For now, the<br>
patches only work when using pre-provisioned nodes.<br>
<br>
- We need to consider how we'd manage the Ansible inventory going<br>
forward if we open up an interface for operators to manipulate it<br>
directly. That's something we'd want to manage and preserve (version<br>
control) as it's critical data for the deployment.<br>
<br>
Given the progress that we've made with the POC, my sense is that<br>
we'll keep pushing in this overall direction. I'd like to get some<br>
feedback on the approach. We have an etherpad we are using to track<br>
some of the work at a high level:<br>
<br>
<a href="https://etherpad.openstack.org/p/tripleo-reduce-deployment-resources" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/tripleo-reduce-deployment-resources</a><br>
<br>
I'll be adding some notes on how I setup the POC to that etherpad if<br>
others would like to try it out.<br>
<br>
-- <br>
-- James Slagle<br>
--<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div>