<div dir="ltr">I think the only people that would be affected by the puppet-openstack module default not matching the keystone default are people that are trying to retrofit puppet into an already running environment. Those people already have a ton of work laid out in front of them, so I’m ok with making it very slightly more difficult for them (if those people even exist).<div><br></div><div>However, for existing users of the modules, this is potentially a big pain, since we already have existing catalogs with the old (wrong) name.</div><div><br></div><div>For new users of the module, this might be slightly annoying, but again, they can override it.</div><div><br></div><div>Personally I’d prefer to leave it as is, instead of requiring all existing users of the modules to change.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 9:31 AM, Martin Mágr <span dir="ltr"><<a href="mailto:mmagr@redhat.com" target="_blank">mmagr@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
I'd like to discuss bug 1506061 ([1]). The main problem I'm trying to solve here is that using default parameters of classes cinder::api and nova::keystone::auth migration won't work, because Cinder will search for endpoint with different name ('Compute service' instead of 'nova'). I've submitted fix for that in first patchset of [2], but it was denied as backward incompatible change, which I agree with, and instead I just added warnings about rename in next cycle [3].<br>
<br>
So the question is if we should start following endpoint naming according to Keystone's default catalog or just change default value of $nova_catalog_.*info parameters in cinder::api to match endpoint created by nova::keystone::auth? I don't mind going one way or another, but I do think that default parameters has to create fully functional environment.<br>
<br>
Thanks in advance for answers,<br>
Martin<br>
<br>
[1] <a href="https://bugs.launchpad.net/puppet-nova/+bug/1506061" rel="noreferrer" target="_blank">https://bugs.launchpad.net/puppet-nova/+bug/1506061</a><br>
[2] <a href="https://review.openstack.org/#/c/222120/1" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/222120/1</a><br>
[3] <a href="https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z</a><br>
[4] <a href="https://review.openstack.org/#/c/219284/2/manifests/api.pp" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/219284/2/manifests/api.pp</a><br>
<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>
</blockquote></div><br></div>