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).
However, for existing users of the modules, this is potentially a big pain, since we already have existing catalogs with the old (wrong) name. For new users of the module, this might be slightly annoying, but again, they can override it. Personally I’d prefer to leave it as is, instead of requiring all existing users of the modules to change. On Wed, Oct 21, 2015 at 9:31 AM, Martin Mágr <[email protected]> wrote: > Greetings, > > 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]. > > 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. > > Thanks in advance for answers, > Martin > > [1] https://bugs.launchpad.net/puppet-nova/+bug/1506061 > [2] https://review.openstack.org/#/c/222120/1 > [3] > https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z > [4] https://review.openstack.org/#/c/219284/2/manifests/api.pp > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
