<div dir="ltr">We decided in the meeting today to just to a naked include:<div><br></div><div><a href="https://review.openstack.org/#/c/253311/">https://review.openstack.org/#/c/253311/</a><br></div><div><a href="https://review.openstack.org/#/c/254824/">https://review.openstack.org/#/c/254824/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 11:29 AM, Cody Herriges <span dir="ltr"><<a href="mailto:cody@herriges.org" target="_blank">cody@herriges.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Matt Fischer wrote:<br>
> I found this bug in the liberty branch [1] over the weekend in the<br>
> handling of openstack client between glance & keystone. As a part of<br>
> fixing that I've discussed with Clayton and Michael Chapman just what<br>
> the right way is to include the openstackclient.<br>
><br>
> Keystone does it by conditionally including the class in client.pp [2].<br>
> Glance does it with an ensure_resources call in the main class [3].<br>
><br>
> Michael Chapman was of the opinion we should just include the<br>
> openstacklib::openstackclient unconditionally and let hiera figure it<br>
> out (hope I'm paraphrasing his opinion). That is cleaner but perhaps<br>
> less flexible.<br>
><br>
> Whatever solution we pick, I want to be consistent and back-portable.<br>
><br>
> Thoughts?<br>
><br>
><br>
> [1] - <a href="https://bugs.launchpad.net/puppet-openstacklib/+bug/1523643" rel="noreferrer" target="_blank">https://bugs.launchpad.net/puppet-openstacklib/+bug/1523643</a><br>
> [2]- <a href="https://github.com/openstack/puppet-keystone/blob/master/manifests/client.pp#L20-L26" rel="noreferrer" target="_blank">https://github.com/openstack/puppet-keystone/blob/master/manifests/client.pp#L20-L26</a><br>
<br>
</span>This way is "ok."<br>
<br>
> [3]- <a href="https://github.com/openstack/puppet-glance/blob/master/manifests/init.pp#L33" rel="noreferrer" target="_blank">https://github.com/openstack/puppet-glance/blob/master/manifests/init.pp#L33</a><br>
<br>
The glance way seems bad since it maintaining its own private<br>
implementation for a thing that intended to be shared.<br>
<br>
<br>
The best is probably to just unconditionally including<br>
Class[openstacklib::openstackclient] using the include function across<br>
all modules and removing the option for each module to override the<br>
package_ensure parameter for Class[openstacklib::openstackclient].<br>
This'll leave you open to resource conflicts based on manifest parse<br>
order though.  For example, if I want to set<br>
Class[openstacklib::openstackclient]'s package_ensure parameter to<br>
latest I need to declare a class resource;<br>
<br>
class { '::openstacklib::openstackclient':<br>
  package_ensure => $ensure,<br>
}<br>
<br>
This is all fine and good if I do this at the top of the manifest in my<br>
composite class then cross my fingers that all subsequent declarations<br>
of the class are using the include function.  If this happens the other<br>
way around Puppet will throw a duplicate resource definition error.<br>
<br>
To ease into the API and manifest change you could basically combine the<br>
glance and keystone example and use the ensure_resource function to<br>
ensure a class resource type with the name<br>
::openstacklib::openstackclient exists.  That just puts you in the<br>
situation where the first puppet-* module class to declare it with a<br>
certain set of parameters will win.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Cody<br>
<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>