[openstack-dev] [puppet] Incompatible default parameters

Mathieu Gagné mgagne at internap.com
Wed Oct 21 14:10:38 UTC 2015


This change [1] introduced the nova_catalog_info and
nova_catalog_admin_info parameters.

Martin Mágr also mentioned that default values were wrong but the change
got merged anyway.

I agree that those default values should be changed to "nova" like
initially suggested as the 2nd field is the service_name, not
service_description. See default values in Cinder. [2]

This also means default values won't work for anyone, even people with
new or existing installations.

The default values in our manifests should be changed. There is no
backward compatibility breakage since it never worked in the first place.

Furthermore, existing installations NEED to update the default values
through Hiera or other means to make it work. Those people won't see the
change in default values.

I also think those parameters (and os_privileged_user_*) are in the
wrong manifest. Those values are also used by the cinder-volume service
to perform hypervisor assisted snapshots. They need to be moved.

[1] https://review.openstack.org/#/c/219284/2
[2]
http://docs.openstack.org/kilo/config-reference/content/section_cinder.conf.html

Mathieu

On 2015-10-21 9:39 AM, Clayton O'Neill wrote:
> 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 <mmagr at redhat.com
> <mailto:mmagr at redhat.com>> 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:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list