<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 27, 2014 at 4:03 AM, Mathieu Gagné <span dir="ltr"><<a href="mailto:mgagne@iweb.com" target="_blank">mgagne@iweb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Joe,<br>
<br>
Your experience and story about Puppet and OpenStack makes me feel like you are a long lost co-worker. :)<span class=""><br>
<br>
On 2014-09-25 10:30 PM, Joe Topjian wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Hiera takes the cake for my love/hate of Puppet. I try really hard to<br>
keep the number of hierarchies small and even then I find it awkward<br>
sometimes. I love the concept of Hiera, but I find it can be<br>
unintuitive.<br>
</blockquote>
<br></span>
Same here. The aspect I hate about Hiera is that files become very big and unorganized very fast due to the quantity of configs. So you try to split them in multiples files instead and then you have the problem you describe below...<span class=""><br>
<br>
<br>
> Similar to the other replies, I have a "common" hierarchy<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
where 90% of the data is stored. The other hierarchies either override<br>
"common" or append to it. When I need to know where a parameter is<br>
ultimately configured, I find myself thinking "is that parameter common<br>
across everything or specific to a certain location or node, and if so,<br>
why did I make it specific?", then doing a "grep -R" to find where it's<br>
located, and finally thinking "oh right - that's why it's there".<br>
</blockquote>
<br></span>
Yep. That's the feeling I was referring to when I said "heart attack".<br>
<br>
And now, try to form a new co-worker and explain him how it's organized: "Oh, I felt the file was too big so I split it in a hope to restore sanity which it did with limited success."<br>
<br>
The other difficulty is the management of "common" configs like keystone auth URL. Multiple services need this value, yet their might be split in multiple files and the YAML anchor hack [1] I used so far does not work across YAML files. Same for database configs which are needed by the database server (to provision the user) and services (for the database connection string).<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Another area of Puppet that I'm finding difficult to work with is<br>
configuring HA environments. There are two main pain points here and<br>
they're pretty applicable to using Puppet with OpenStack:<br>
</blockquote>
><br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The other HA pain point is creating many-to-one configurations [...]<span class=""><br>
<br>
I think a cleaner way of doing this is to introduce service discovery<br>
into my environment, but I haven't had time to look into this in more<br>
detail.<br>
</span></blockquote>
<br>
I wholly agree with you and that's a concept I'm interested to explore.<br>
Come to think of it, it strangely looks like the "dependency inversion principle" in software development.<br>
<br>
I however feel that an external ENC becomes inevitable to achieve this ease of use. Unfortunately, each time I looked into it, I rapidly get lost in my dream of a simple dashboard to manage everything. I feel I rapidly come to the limits of what exported resources, Hiera and puppetdb can do.<br>
<br>
One idea would be to export an haproxy::listen resource from one of the controller (which now becomes a pet as you said) and realize it on the HAProxy nodes with its associated haproxy::member resources.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I should mention that some of these HA pains can be resolved by just<br>
moving all of the data to the HAProxy nodes themselves. So when I want<br>
to add a new service, such as RabbitMQ, to HAProxy, I add the RabbitMQ<br>
settings to the HAProxy role/profiles. But I want HAProxy to be "dumb"<br>
about what it's hosting. I want to be able to use it in a Juju-like<br>
fashion where I can introduce any arbitrary service and HAProxy<br>
configures itself without prior knowledge of the new service.<br>
</blockquote>
<br></span>
Yes! How do you guys think we can implement such discovery?<br>
<br>
With Nova cells, this problem became much more apparent due to inter-relations between the API cell and compute cells. The API cell has to know about the compute cells and vice versa.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In general, though, I really enjoy working with Puppet. Our current<br>
Puppet configurations allow us to stand up test OpenStack environments<br>
with little manual input as well as upgrade to newer releases of<br>
OpenStack with very little effort.<br>
</blockquote>
<br></span>
Yes, I really enjoy Puppet too. After all hardware/infrastructure aspects are figured out, we are able to bootstrap a new OpenStack region in less than an hour.<br>
<br>
To summarize my current pain points:<br>
- Out of control Hiera configuration files<br>
- Lack of service auto-discovery<br>
<br>
[1] <a href="https://dmsimard.com/2014/02/15/quick-hiera-tips/" target="_blank">https://dmsimard.com/2014/02/<u></u>15/quick-hiera-tips/</a><span class=""><font color="#888888"><br>
<br>
-- <br>
Mathieu</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a></div></div></blockquote><div><br></div><div>I am working towards a client side ENC that queries a Consul [1] k/v store, and building similar scripting to what I built for puppet_openstack_builder so that I can import hiera -> consul and set ACLs + node classifications. An ENC would also avoid the 'everything must be a string' issues in hiera, although maybe bodepd will finally solve that with this [2]. Consul already has a decent dashboard (though not as nice as the puppet enterprise one) so I should be able to leverage that.</div><div><br></div><div>Consul might similarly provide part of a suitable mechanism for discovery, although the nature of Puppet and its expectation that data is available at catalog compile time is a significant barrier to implementing this sanely, since functions and facts are evaluated before resources, and resources don't have a way to feed data back. My thoughts to mitigate this were to split into smaller profiles and allow nodes to signal each other indicating that a specific profile should be state-checked via running puppet, so that I could watch consul and listen for messages and apply new data quickly, but splitting catalogs sensibly is quite difficult.</div><div><br></div><div>I have a talk scheduled for the Paris summit on how I'm doing that using Serf for the message bit, but I'm still not completely convinced it's actually the best way to go about things, and I have a long way to go still on implementation. Serf/Consul are also very new pieces of software so I'm sure I'll hit more issues as I go.</div><div><br></div><div>I have heard there are others attempting similar things with etcd.</div><div><br></div><div>[1] <a href="http://www.consul.io/">http://www.consul.io/</a><br></div><div>[2] <a href="https://github.com/puppetlabs/hiera/pull/213">https://github.com/puppetlabs/hiera/pull/213</a> </div></div><br></div></div>