Ceph-relation-joined hook error

[james beedy]

Ceph-relation-joined hook error

This error occurs when the ceph-relation-joined hook executes, and happens because the package name 'nova-compute' that gets passed to get_os_version_package from assert_libvirt_imagebackend_allowed doesn't match the package name and key of 'nova-common' in the PACKAGE_CODENAMES dict in charmhelpers.contrib.openstack.utils. The hook error also happens in part due to the incorrect indexing into OPENSTACK_PACKAGES dict in the nested else conditional in get_os_version_package.

*** To replicate this issue, add a relation from nova-compute to ceph, or make a call to get_os_codename_package(package, fatal=True), where the input to the function is a package e.g. 'nova-compute' which is an openstack service package, but not in the OPENSTACK_CODENAMES dict.

*** To remedy this issue I have corrected the package name being passed to get_os_version_package in nova_compute_context.py, and touched up the indexing and parsing in charmhelpers.contrib.openstack.utils.

See below.

[james beedy (jamesbeedy)]

Apply these to resolve the issue:

https://code.launchpad.net/~jamesbeedy/charm-helpers/touch-up-indexing/+merge/275510

https://code.launchpad.net/~jamesbeedy/charms/trusty/nova-compute/fix-ceph-relation-joined/+merge/275511

[David Ames (thedac)]

James,

Thanks for reporting this bug and going above and beyond to propose solutions to it!

I have merged your nova-compute MP as this is the correct solution to Bug #1509267. The bug is now set to Fix committed.

I am however going to reject the charm-helpers MP. We use PACKAGE_CODENAMES OPENSTACK_CODENAMES for different types of of versions strings. OPENSTACK_CODENAMES has versions like '2015.2' where PACKAGE_CODNAMES has versions like '12.0.0'. The code in charmhelpers.contrib.openstack.utils.get_os_codename_package is checkgin for both types of version string. The proposed solution confuses the two and is not general enough for all situations.

[james beedy (jamesbeedy)]

David,

Got it....on that note, what I'm wondering is a) how return OPENSTACK_CODENAMES[vers] will ever return ('nova-common' version is vers=12.0.0 which is passed as a key to OPENSTACK_CODENAMES)? ...hence its indexing is incorrect. b) The introduction of the LIBERTY_PACKAGE_CODENAME_VERSIONS variable fixes the problem, does it introduce another(besides not being general enough for all cases)?

[james beedy (jamesbeedy)]

Ooooh I see a better fix! Here it comes!

[David Ames (thedac)]

"on that note, what I'm wondering is a) how return OPENSTACK_CODENAMES[vers] will ever return ('nova-common' version is vers=12.0.0 which is passed as a key to OPENSTACK_CODENAMES)? ...hence its indexing is incorrect."

This is the crux of the issue. With version 12.0.0 we will never get to line 260 and OPENSTACK_CODENAMES[vers]. If we get there we are then looking for versions strings of the form year.point_release.

This is why your nova-compute MP was the correct solution.

[james beedy (jamesbeedy)]

Ok, I see this now. Thank you!

[James Page (james-page)]

Fix cherry picked and pushed to stable charm - should hit the charm-store in the next hour or so.