Bug 1404464

Summary: Heat doesn't inject personality files on rebuild
Product: Red Hat OpenStack Reporter: Robin Cernin <rcernin>
Component: openstack-heatAssignee: Rabi Mishra <ramishra>
Status: CLOSED ERRATA QA Contact: Amit Ugol <augol>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0 (Kilo)CC: aschultz, augol, jjoyce, mburns, pcaruana, ramishra, rhel-osp-director-maint, rrasouli, sbaker, sclewis, shardy, srevivo, zbitter
Target Milestone: asyncKeywords: Triaged, ZStream
Target Release: 7.0 (Kilo)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-heat-2015.1.4-3.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1424578 1424586 1424587 (view as bug list) Environment:
Last Closed: 2017-06-14 15:31:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1424578, 1424586, 1424587    

Description Robin Cernin 2016-12-13 22:13:58 UTC
Description of problem:

When we change image and do heat stack update it doesn't re-inject the personality files.

By default OS::Nova::Server image_update_policy is doing REBUILD of an instance.

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-image_update_policy

We can see that in nova when we call rebuild we preserve all the VMs metadata and personality files.

Also it's bit confusing since in Heat Resource OS::Nova::Server it shows that the personality property is update_allowed: false and from the developer_guide [1] we can see that this means that update is accomplished only by delete and re-create.

# heat resource-type-show OS::Nova::Server  | grep personality -A6
    "personality": {
      "description": "A map of files to create/overwrite on the server upon boot. Keys are file names and values are the file contents.", 
      "default": {}, 
      "required": false, 
      "update_allowed": false, 
      "type": "map", 
      "immutable": false

When we switched the image_update_policy to REPLACE it worked, that could be explained by above.

However if the personality files are preserved with nova, shouldn't it also be same for Heat?

[1] http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html

Version-Release number of selected component (if applicable):

heat 2015.1.2

How reproducible:

Steps to Reproduce:
1. Create stack
2. Change image to another image.
3. Update stack with new image

Actual results:

Personality files not injected

Expected results:

Inject personality files.

Additional info:

Possible patch submitted:

1, /usr/lib/python2.7/site-packages/heat/engine/resources/openstack/nova/server.py

def _update_image(self, prop_diff):
    image_update_policy = (prop_diff.get(self.IMAGE_UPDATE_POLICY) or self.properties[self.IMAGE_UPDATE_POLICY])
    image = prop_diff[self.IMAGE]
    image_id = self.client_plugin('glance').get_image_id(image)
    preserve_ephemeral = (image_update_policy == 'REBUILD_PRESERVE_EPHEMERAL')
    password = (prop_diff.get(self.ADMIN_PASS) or
    self.properties[self.ADMIN_PASS])
    personality_files = self.properties[self.PERSONALITY]
    kwargs = {'password': password,'preserve_ephemeral': preserve_ephemeral, 'files_to_inject':personality_files}
    prg = progress.ServerUpdateProgress(self.resource_id,'rebuild',handler_extra={'args': (image_id,), 'kwargs': kwargs})
    return prg

2,
/usr/lib/python2.7/site-packages/heat/engine/clients/os/nova.py

def rebuild(self, server_id, image_id, password=None,preserve_ephemeral=False, files_to_inject=None):
    """Rebuild the server and call check_rebuild to verify."""
    server = self.fetch_server(server_id)
    if server:
        server.rebuild(image_id, password=password,preserve_ephemeral=preserve_ephemeral,files=files_to_inject)
        return True
    else:
        return False

Comment 1 Zane Bitter 2016-12-15 22:06:08 UTC
There may already be a patch for this upstream in a later release. We'll see if we can track it down.

Comment 2 Rabi Mishra 2016-12-16 08:14:37 UTC
It seems we're not doing it. I've raised an upstream bug and would send a patch to fix it soon.

Comment 4 Rabi Mishra 2016-12-20 04:04:30 UTC
Hi Robin,

I think this can be backported till mitaka(RHOS9) upstream. kilo(OSP7)/liberty(OSP8) releases are already EOL. I'm not sure if we can backport downstream to OSP7. Zane could you please confirm, if it's possible?

Comment 5 Zane Bitter 2016-12-21 17:33:34 UTC
Once the fix and stable backports have been accepted upstream there's no reason we couldn't backport to RHOS 7/8.

Comment 6 Zane Bitter 2017-01-26 21:36:23 UTC
Ocata fix and backports to Newton and Mitaka have all merged upstream.

Comment 10 Ronnie Rasouli 2017-06-14 08:26:02 UTC
medium BZ

Comment 12 errata-xmlrpc 2017-06-14 15:31:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:1450