Juju Charms Collection
nova-compute package

Ceph-relation-joined hook error

Bug #1509267 reported by james beedy
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
nova-compute (Juju Charms Collection)
Fix Released
High
David Ames
Juju Charms Collection 16.01

Bug Description

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.

See original description
james beedy (jamesbeedy)
tags: added: nova-compute openstack storage
Revision history for this message
james beedy (jamesbeedy) wrote :

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

james beedy (jamesbeedy)
description: updated
description: updated
description: updated
description: updated
james beedy (jamesbeedy)
description: updated
james beedy (jamesbeedy)
description: updated
james beedy (jamesbeedy)
summary: - Assert_libvirt_imagebackend_allowed passes incorrect package to
- get_os_codename_package
+ Ceph-relation-joined hook error
james beedy (jamesbeedy)
description: updated
David Ames (thedac)
Changed in nova-compute (Juju Charms Collection):
assignee: nobody → David Ames (thedac)
status: New → Confirmed
David Ames (thedac)
Changed in nova-compute (Juju Charms Collection):
status: Confirmed → Fix Committed
Revision history for this message
David Ames (thedac) wrote :

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.

Revision history for this message
james beedy (jamesbeedy) wrote :

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)?

Revision history for this message
james beedy (jamesbeedy) wrote :

Ooooh I see a better fix! Here it comes!

Revision history for this message
David Ames (thedac) wrote :

"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.

Revision history for this message
james beedy (jamesbeedy) wrote :

Ok, I see this now. Thank you!

Liam Young (gnuoy)
Changed in nova-compute (Juju Charms Collection):
importance: Undecided → High
milestone: none → 16.01
James Page (james-page)
tags: added: backport-potential
Revision history for this message
James Page (james-page) wrote :

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

Changed in nova-compute (Juju Charms Collection):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.