<div>Overall, I really like the idea of providing support for configuration management through nova.</div><div><br></div>A couple of issues strike me on this, though.<div><br></div><div>Having worked quite a lot with Puppet, my experiences of running it in a client-server configuration at scale have demonstrated that it is hard. Generally, I have found that running puppet in a serverless mode is preferable, distributing the modules and site.pp files through some other means. </div>
<div><br></div><div>Running Nova in a multi-tenant environment is going to introduce a whole lot more issues, as this is something which Puppet doesn't support very well. The issues I'm thinking of are things like supporting custom modules for different tenants where the module may have information which that tenant would not want shared with others, or supporting different modules with overlapping namespaces - something that will happen with multiple tenants.</div>
<div><br></div><div>Also, how would one handle different operating systems, distros and/or images? A well coded Puppet module can usually find its way around those issues, but so many Puppet modules are not sufficiently well coded (or widely tested) that there will be either so few modules as to make the service fairly useless or it would only work with specific images/distros/OSes.</div>
<div><br></div><div>What I would consider may work better would be passing a meta-parameter with a uri. This uri would be a location (maybe a git repo) where all the relevant puppet modules (or chef recipes for that matter) could be downloaded by the instance. Alternatively, this could be passed in using the configuration drive as outlined earlier. A second meta-parameter could be included pointing to a location for a site.pp file. It would then be incumbent upon the image to include an appropriate tool to make use of this configuration, running puppet in a distributed way. If the tenant needed specific modules, they could be obtained from the tenant's 'own' repository without effecting other tenants. </div>
<div><br></div><div>If support for Puppet stored configurations was required, that too would have to be restricted to a per-tenant (possibly even per-project). This would make it difficult to support in a secure way using just the standard Nova database. Possibly a better option would be to provide a custom Puppet stored config driver (maybe an ENC - I've not used them so not sure what they would add) that could pull down details from a separate database which would break the data up by tenant, only allowing a tenant to access their own data.</div>
<div><br></div><div><br></div><div><br></div><div>Dan</div><div><br></div><div><br><br><div class="gmail_quote">On Sat, Jan 28, 2012 at 12:56 AM, Ryan Lane <span dir="ltr"><<a href="mailto:rlane@wikimedia.org">rlane@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 class="im">>> <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<br>
>> Manager, which is WikiMedia's VM management interface.  My main priority for<br>
>> adding puppet support to Nova is to facilitate the creation and control of a<br>
>> GUI much like that one.<br>
><br>
><br>
><br>
> Can you explain how your solution works now? You want to inject data into<br>
> the VMs in the proposal, but outside of designating the puppet master, all<br>
> the data for variables and classes should be changes to the puppet master,<br>
> not the instances. That's kind of the whole point of the puppet master.<br>
><br>
> One thing you really seem to want is RBAC for the nova users.<br>
><br>
> How are you getting the names for the recipes into your system? Is that sync<br>
> with what is on the puppet master somehow or you are going to do data entry<br>
> and it's all string matching?<br>
><br>
<br>
</div>Right now we are adding puppetvar and puppetclass attributes into LDAP<br>
nodes. An instance uses cloud-init, installs puppet, points puppet at<br>
the right puppet master, and does a puppet run. A puppet master waits<br>
for certificate requests, verifies the instance is in LDAP, then signs<br>
the certificate. The instance's catalogue is generated by the puppet<br>
master, based on the LDAP entry.<br>
<div class="im"><br>
>> On 1/26/12 5:03 PM, Andrew Clay Shafer wrote:<br>
>><br>
>><br>
>> I'd also like to see more of a service oriented approach and avoid adding<br>
>> tables to nova if possible.<br>
>><br>
>> I'm not sure the best solution is to come up with a generic service for<br>
>> $configuration_manager for nova core. I'd rather see these implemented as<br>
>> optional first class extensions.<br>
>><br>
>> This sounds intriguing, but I'll plead ignorance here; can you tell me<br>
>> more about what this would look like, or direct me to an existing analogous<br>
>> service?<br>
><br>
><br>
> I don't think there is a good existing example, but I know if the defacto<br>
> way to add functionality in nova is to add tables to the db, that's the path<br>
> to operational and maintenance hell.<br>
><br>
> That's not just for this integration, but in general.<br>
><br>
> For openstack to become what it should be, Nova shouldn't be a monolithic<br>
> app on a database.<br>
><br>
> Even if you wanted to run this on the same node, it probably shouldn't be<br>
> tables in the same database. It should be a separate services with it's own<br>
> db user and scheme then be integrated by apis or maybe adding to wsgi.<br>
><br>
<br>
</div>Well, I think part of the problem is there doesn't seem to be any way<br>
to extend nova core right now. The API is extendable, but actions<br>
generated by existing API can't be modified without hacking at the<br>
core code. This includes database code/schema as well.<br>
<br>
Having the tables in the same database isn't problematic as long as we<br>
ensure there aren't naming conflicts. Often the way to handle this is<br>
to have a standardized naming prefix.<br>
<div class="im"><br>
> I'm confused how you want to run puppet exactly. The site.pp would typically<br>
> live on the puppet master.<br>
><br>
> Can you explain more about what you are thinking or how your current<br>
> solution works?<br>
><br>
<br>
</div>We are currently using the LDAP approach with a puppet master, but<br>
it's problematic with what we're actually doing.<br>
<br>
In our implementation everything is controlled via puppet, and our<br>
puppet repo is kept in a gerrit repo. We have a branch for production<br>
and one for our pre-production cloned environment. One project<br>
contains our pre-production clone (testlabs). Every other project is<br>
meant as a space to build things, and then puppetize them. The<br>
services tested in other projects are moved into testlabs via a<br>
cherry-pick, then tested there, then cherry-picked across to<br>
production.<br>
<br>
Currently all projects use the testlabs puppet branch, because the<br>
centralized puppet master must run on a single branch. What we want is<br>
for each project to have their own branch of the repo, so that they<br>
can test all of their changes in their own branch without needing<br>
code-review and without needing to possibly clobber other projects.<br>
<br>
The problem we are running into is that each project needs its own<br>
puppet master (and no, puppet environments don't work), as puppet<br>
isn't multi-tenant. The good thing is, we don't really *need* a puppet<br>
master. Since we have all of the manifests in a single repo, we can<br>
just checkout the entire repo, and have the instance run the puppet<br>
configuration directly. We can create a gerrit branch on project<br>
creation, and have all instances configured to pull/push using that<br>
branch.<br>
<br>
So, what we really want is a way to stick the repo and the node<br>
configuration into something that can be accessed on instance<br>
creation.<br>
<div class="im"><br>
> I think it would be sweet if nova and the dashboard (and probably keystone<br>
> too) had a standardized way to add integrated functionality. I don't believe<br>
> nova core should be reimplementing/duplicating functionality and logic in<br>
> other systems.<br>
><br>
> The goal of interacting with the instances through a shared interface is a<br>
> good one, I'm not against that, I just want to see less deep coupling to<br>
> accomplish it.<br>
><br>
<br>
</div>Yes, a shared interface is what we'd like as well. My main motivation<br>
for getting this moved into nova is that I want people to be able to<br>
use the cli tools in addition to web tools. This was also my<br>
motivation for wanting DNS support added ;).<br>
<div class="im"><br>
>> I may be misunderstanding you, or my blueprint may be unclear.  Available,<br>
>> Unavailable, and Default don't refer to the availability of classes on the<br>
>> puppet master; rather, they refer to whether or not a class is made<br>
>> available to a nova user for a given instance.  An 'available' class would<br>
>> appear in the checklist in my screenshot.  An Unavailable class would not.<br>
>> A 'default' class would appear, and be pre-checked.  In all three cases the<br>
>> class is presumed to be present on the puppet master.<br>
><br>
><br>
> I already asked this, but what keeps that in sync with the puppet master?<br>
><br>
<br>
</div>Nothing, this is user-defined and global defined based on the<br>
end-user's knowledge of the puppet repo. The puppet master has no way<br>
of saying which variables are available, at minimum, since it's<br>
possible for templates to require variables that aren't defined in<br>
manifests.<br>
<div class="im"><br>
> Personally, I'd rather see an integration that has a per user configuration<br>
> to a puppet master that stays in sync than the RBAC per module.<br>
<br>
</div>Well, we aren't aiming at RBAC, but rather aiming at giving a user a<br>
list of classes and variables available in a specific project. Think<br>
of one project mostly wanting to use the CLI, another using horizon,<br>
and another using OpenStackManager (my MediaWiki extension). Without<br>
nova knowing what's available in a project there's no way for each<br>
interface to display this information.<br>
<div class="im"><br>
>>> I also think managing a site.pp is going to be inferior to providing an<br>
>>> endpoint that can act as an eternal node tool for the puppet master.<br>
>>> <a href="http://docs.puppetlabs.com/guides/external_nodes.html" target="_blank">http://docs.puppetlabs.com/guides/external_nodes.html</a><br>
>><br>
>> In which case nova would interact directly with the puppet master for<br>
>> configuration purposes?  (I don't hate that idea, just asking for<br>
>> clarification.)<br>
><br>
><br>
> That's puppet's model. Whether you use a site.pp, or external nodes. I'm<br>
> unclear how you want to do it. Can you explain how your system works now?<br>
>><br>
<br>
</div>As described above, we feel that using a non-centralized puppet system<br>
is preferable (for us). Of course, we'd like to have broad support.<br>
<div class="im"><br>
>>> One other point, that you might have thought of, but I don't see anywhere<br>
>>> on the wiki is how to handle the ca/certs for the instances.<br>
>><br>
>> I believe this (and your subsequent question) falls under the heading of "<br>
>> Instances are presumed to know any puppet config info they need at creation<br>
>> time (e.g. how to contact the puppet master). "  Important, but outside the<br>
>> scope of this design :)<br>
><br>
><br>
> Thinking through this is actually critical for any standardized puppet<br>
> integration in my opinion. The solution is a prerequisite before considering<br>
> anything else.<br>
<br>
</div>Yes, this is an issue. We'd need to figure this out. In the case where<br>
you don't have a puppet master, this isn't necessary, but for it to be<br>
generic, it would need to work. It's possible to sign through puppet's<br>
API, though, so it should be easy enough to have the puppet driver<br>
handle that, if needed.<br>
<div class="im"><br>
>> So that I understand your terminology... are extensions like the quotas or<br>
>> floating ips considered 'core nova'?<br>
><br>
><br>
> There is not a bright line especially with the way things have evolved to<br>
> now, but I would say floating IPs should definitely be core functionality.<br>
> Quotas may be debatable, but I think it is defensible, though part of me<br>
> feels like some of that kind of permission functionality might be better<br>
> decoupled.<br>
><br>
>> Thanks again for your input!  Clearly it would be best to hash this out at<br>
>> the design summit, but I'm hoping to get at least a bit of coding done<br>
>> before April :)<br>
><br>
><br>
> I hope to be there. I do like the idea, I just want to do what's best for<br>
> OpenStack.<br>
><br>
<br>
</div>Agreed. It may be that some form of hook system, or some other way of<br>
extending nova without hacking core would be a more appropriate way of<br>
handling things like this. Of course, an extensions system also makes<br>
compatibility between vendors much more difficult.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Ryan Lane<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div>