<div dir="ltr">Yeah, I agree. Reusing the same config file across all services is basically a hack/workaround to compensate for the lack of clear documentation about which config option is consumed by which service.<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 13, 2013 at 10:51 AM, Joe Topjian <span dir="ltr"><<a href="mailto:joe.topjian@cybera.ca" target="_blank">joe.topjian@cybera.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Lorin,<div><br></div><div>That's a good point about nova.conf. Quantum enhances the issue by using / sharing more than just quantum.conf. :)</div><div><br></div><div>Regarding sharing the same config file: I thought about this as a solution for the Quantum issues I've run into -- having extraneous options in a config file does not seem to misconfigure Quantum. But there are two reasons I'm leaning (not pushing, just leaning :) on organizing as much as possible:</div>
<div><br></div><div>1. It's very confusing as it is</div><div>2. Mitigates potentially sensitive information from spreading to servers that do not need that information</div><div><br></div><div>
Thanks,</div><div>Joe</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 11, 2013 at 7:39 PM, Lorin Hochstein <span dir="ltr"><<a href="mailto:lorin@nimbisservices.com" target="_blank">lorin@nimbisservices.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Joe:<div><br></div><div>I don't think any such source of information exists, you'd have to go spelunking through the code to identify who uses what. The same issue exists with nova.conf. I think in an ideal world, we would annotate each config option with which service uses it (e.g., have a "used_by" parameter in the flag definition).</div>
<div><br></div><div>I suspect what nearly everyone does is reuse the same config file across all nodes, modulo things like my_ip. That's certainly what I have always done with nova.conf.</div><div><br></div><div>
<br></div><div>Lorin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Sat, May 11, 2013 at 3:50 PM, Joe Topjian <span dir="ltr"><<a href="mailto:joe.topjian@cybera.ca" target="_blank">joe.topjian@cybera.ca</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hello,<div><br></div><div>For the past few weeks, I've had my Puppet hat on and have been helping out with the Grizzly Puppet modules. In trying to update the modules to Grizzly, I found that Quantum posed the most troublesome part.</div>
<div><br></div><div>I have file this doc bug which explains the problem that I see:</div><div><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1179046" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1179046</a></div>
<div><br></div><div>If anyone could help with this, I'd really appreciate it. I know it sounds like such a simple thing (what option goes where?) but I haven't been able to find an existing definitive source of information for this. I also think there's still the possibility that I'm overlooking something extremely simple - in which case I'd be delighted!</div>
<div><br></div><div>Thanks,</div><div>Joe<span><font color="#888888"><br clear="all"><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div>
<div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
</font></span></div></div>
<br></div></div>_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org" target="_blank">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div>
<a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div><div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div><div>
<br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</div></div>