<br><div class="gmail_quote">On Thu, Jan 26, 2012 at 8:56 PM, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org">abogott@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Andrew --<br>
<br>
Thanks for your comments. I'm going to start with a screenshot for
context:<br>
<br>
<a href="http://bogott.net/misc/osmpuppet.png" target="_blank">http://bogott.net/misc/osmpuppet.png</a><br>
<br>
That's what it looks like when you configure an instance using Open
Stack Manager, which is WikiMedia's VM management interface. My
main priority for adding puppet support to Nova is to facilitate the
creation and control of a GUI much like that one.</div></blockquote><div><br></div><div><br></div><div>Can you explain how your solution works now? You want to inject data into the VMs in the proposal, but outside of designating the puppet master, all the data for variables and classes should be changes to the puppet master, not the instances. That's kind of the whole point of the puppet master. </div>
<div><br></div><div>One thing you really seem to want is RBAC for the nova users.</div><div><br></div><div>How are you getting the names for the recipes into your system? Is that sync with what is on the puppet master somehow or you are going to do data entry and it's all string matching?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
On 1/26/12 5:03 PM, Andrew Clay Shafer wrote:
<blockquote type="cite">
<div><br>
</div>
I'd also like to see more of a service oriented approach and avoid
adding tables to nova if possible.
<div><br>
</div>
<div>I'm not sure the best solution is to come up with a generic
service for $configuration_manager for nova core. I'd rather see
these implemented as optional first class extensions.</div>
</blockquote></div>
This sounds intriguing, but I'll plead ignorance here; can you tell
me more about what this would look like, or direct me to an existing
analogous service?</div></blockquote><div><br></div><div>I don't think there is a good existing example, but I know if the defacto way to add functionality in nova is to add tables to the db, that's the path to operational and maintenance hell.</div>
<div><br></div><div>That's not just for this integration, but in general.</div><div><br></div><div>For openstack to become what it should be, Nova shouldn't be a monolithic app on a database. </div><div><br></div>
<div>Even if you wanted to run this on the same node, it probably shouldn't be tables in the same database. It should be a separate services with it's own db user and scheme then be integrated by apis or maybe adding to wsgi.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>What are you going to inject into the instances exactly?
Where does the site.pp live?</div>
</blockquote></div>
This is the question I'm hoping to get feedback on. Either nova can
generate a fully-formed site.pp and inject that, or it can pass
config information as metadata, in which case an agent would need to
be running on the guest which would do the work of generating the
site.pp. I certainly prefer the former but I'm not yet clear on
whether or not file injection is widely supported.</div></blockquote><div><br></div><div>I'm confused how you want to run puppet exactly. The site.pp would typically live on the puppet master.</div><div><br></div>
<div>Can you explain more about what you are thinking or how your current solution works? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<blockquote type="cite">
<div>
I haven't thought about this that much yet, but off the top of
my head, but if the instances already have puppet clients and
are configured for the puppet master, then the only thing you
should need to interact with is the puppet master.</div>
</blockquote>
<br></div>
It's definitely the case that all of this could be done via LDAP or
the puppet master and involve no Nova action at all; that's how
WikiMedia's system works now. My aim is to consolidate the many
ways we currently interact with instances so that we delegate as
much authority to Nova as possible. That strikes me as generally
worthwhile, but you're welcome to disagree :)</div></blockquote><div><br></div><div>I think it would be sweet if nova and the dashboard (and probably keystone too) had a standardized way to add integrated functionality. I don't believe nova core should be reimplementing/duplicating functionality and logic in other systems.</div>
<div><br></div><div>The goal of interacting with the instances through a shared interface is a good one, I'm not against that, I just want to see less deep coupling to accomplish it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>I'm not a fan of the Available, Unavailable, Default,
particularly because you are managing state of something that
may not be true on the puppet master.</div>
</blockquote></div>
I may be misunderstanding you, or my blueprint may be unclear.
Available, Unavailable, and Default don't refer to the availability
of classes on the puppet master; rather, they refer to whether or
not a class is made available to a nova user for a given instance.
An 'available' class would appear in the checklist in my
screenshot. An Unavailable class would not. A 'default' class
would appear, and be pre-checked. In all three cases the class is
presumed to be present on the puppet master.</div></blockquote><div><br></div><div>I already asked this, but what keeps that in sync with the puppet master?</div><div><br></div><div>Personally, I'd rather see an integration that has a per user configuration to a puppet master that stays in sync than the RBAC per module.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>I also think managing a site.pp is going to be inferior to
providing an endpoint that can act as an eternal node tool for
the puppet master.</div>
<div><a href="http://docs.puppetlabs.com/guides/external_nodes.html" target="_blank">http://docs.puppetlabs.com/guides/external_nodes.html</a></div>
</blockquote></div>
In which case nova would interact directly with the puppet master
for configuration purposes? (I don't hate that idea, just asking
for clarification.)</div></blockquote><div><br></div><div>That's puppet's model. Whether you use a site.pp, or external nodes. I'm unclear how you want to do it. Can you explain how your system works now?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite">
<div>One other point, that you might have thought of, but I don't
see anywhere on the wiki is how to handle the ca/certs for the
instances.</div>
</blockquote></div>
I believe this (and your subsequent question) falls under the
heading of "
Instances are presumed to know any puppet config info they need at
creation time (e.g. how to contact the puppet master). " Important,
but outside the scope of this design :)</div></blockquote><div><br></div><div>Thinking through this is actually critical for any standardized puppet integration in my opinion. The solution is a prerequisite before considering anything else. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>Just to reiterate, I'd love to see deeper configuration
management integrations (because I think managing instances
without them is it's own hell), but I'm not convinced it should
be part of core nova per se.</div>
<div><br>
</div>
</blockquote></div>
So that I understand your terminology... are extensions like the
quotas or floating ips considered 'core nova'?<br></div></blockquote><div><br></div><div>There is not a bright line especially with the way things have evolved to now, but I would say floating IPs should definitely be core functionality. Quotas may be debatable, but I think it is defensible, though part of me feels like some of that kind of permission functionality might be better decoupled.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Thanks again for your input! Clearly it would be best to hash this
out at the design summit, but I'm hoping to get at least a bit of
coding done before April :)</div></blockquote><div><br></div><div>I hope to be there. I do like the idea, I just want to do what's best for OpenStack.</div><div><br></div><div>Regards,</div><div>Andrew</div><div>
<br></div></div><br>