<p>Eoghan,</p>
<p>Yes, it does make perfect sense. Kind thanks for the explanation.</p>
<p>However,  what is still unclear is what config iteems that pertain to other apps must  still be present (ie. duplicated in) glance-api.conf  (e.g. image_cache_driver , etc )</p>
<p>Thanks again,</p>
<p>Florian<br>
</p>
<div class="gmail_quote">On Mar 14, 2012 10:45 AM, "Eoghan Glynn" <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Florian,<br>
<br>
The key point in the split between glance-api.conf, glance-registry.conf,<br>
glance-cache.conf etc. is the glance application intended to consume that<br>
config.<br>
<br>
This follows directly from the naming:<br>
<br>
 bin/glance-api by default consumes glance-api.conf<br>
 bin/glance-registry by default consumes glance-registry.conf<br>
 bin/glance-cache-* by default consumes glance-cache.conf<br>
 bin/glance-scrubber by default consumes glance-scrubber.conf<br>
<br>
This is merely a convention, which can be overridden for example by<br>
naming the glance API service config as foobar.conf:<br>
<br>
 bin/glance-api --config-file /path/to/foobar.conf<br>
<br>
However the naming convention is convenient as it may allow the pathname<br>
of the config file to be inferred if not explicitly specified, for example<br>
for the glance-api application, the follow search order is used:<br>
<br>
      ~/.glance/glance-api.conf<br>
      ~/glance-api.conf<br>
      /etc/glance/glance-api.conf<br>
      /etc/glance-api.conf<br>
<br>
or, in general, replace glance-api above with the program name, i.e.<br>
basename(sys.argv[0])<br>
<br>
The intended consumer then determines what options should be specified in<br>
each config file, for example there would be no point in defining the<br>
the backend s3/swift store config in glance-cache.conf, similarly no<br>
need to define the max cache size in glance-api.conf, nor the scrubber<br>
wakeup time in glance-registry.conf.<br>
<br>
Then each .conf file has a corresponding -paste.ini, which splits along<br>
a different axis. Here the idea is to separate the core and paste deploy<br>
config for a particular glance application. So for example the default<br>
paste config for glance-api is glance-api-paste.ini, to be found in the<br>
same directory as glance-api.conf. Again this is merely a convenient<br>
convention that may be overridden.<br>
<br>
Does that all make sense?<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
> Can someone help me understand what options need to be in<br>
> "glance-api.conf" and what options can be left to<br>
> "glance-cache.conf" , resp "glance-cache-paste.ini" ?<br>
><br>
> Case in point: If I wanted to use the "xattr" driver, I need to<br>
> specify that in "glance-api.conf" -- specifying that in<br>
> "glance-cache.conf" is ignored. The trivial solution is to copy the<br>
> options from "glance-cache.conf" and paste them in "glance-api.conf"<br>
> but I hardly think this was the intention of having the two split.<br>
><br>
> So I'd like to understand when & how those two files are loaded /<br>
> parsed.<br>
><br>
> The questions above is for the image cache, but I guess the same type<br>
> of questions can be asked for the scrubber (i.e.<br>
> glance-scrubber.conf" resp "glance-scrubber-paste.ini")<br>
><br>
> Least I forget: This is for the E4 code release.<br>
><br>
> TIA for the help,<br>
><br>
> Florian<br>
><br>
><br>
><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>
><br>
</blockquote></div>