Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1600411

Summary:	stack correct option in case of resource deletion (neutron ports) in a deployed heat stack
Product:	Red Hat OpenStack	Reporter:	Aviv Guetta <aguetta>
Component:	openstack-heat	Assignee:	Rabi Mishra <ramishra>
Status:	CLOSED ERRATA	QA Contact:	Ronnie Rasouli <rrasouli>
Severity:	medium	Docs Contact:
Priority:	high
Version:	10.0 (Newton)	CC:	aguetta, amcleod, fherrman, fpezzell, fsoppels, mburns, pcaruana, pmorey, ramishra, sbaker, shardy, srevivo
Target Milestone:	z9	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-heat-7.0.6-4.el7ost	Doc Type:	Bug Fix
Doc Text:	Previously, if a user deleted a port in a deployed heat stack, there was no option to recreate the port with the heat CLI, and recreating the whole stack was not possible due to total service unavailability. With this update, users can mark deleted port resources as unhealthy in heat, and replace these deleted ports with a stack update.	Story Points:	---
Clone Of:
Clones:	1611895 1611897 (view as bug list)		Environment:
Last Closed:	2018-09-17 16:57:52 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:	1611895, 1611897

Description Aviv Guetta 2018-07-12 08:07:04 UTC

Description of problem:
In case of a deleted port (by mistake), in an already deployed heat stack, the user should have an option to recreate that specific resource from heat CLI (and not by manually recreating the port - as we can expect the user doesn't have the specific info).
Additionally, recreating the whole stack isn't an option as it means a total service (VNF) unavailability issue.

Version-Release number of selected component (if applicable):
Any Red Hat OpenStack Platform version

How reproducible:
Every Time

Steps to Reproduce:
1. User1 instantiated a VNF using a heat template.
2. User2 by mistake deleted one of the ports used by the VNF.
3. User1 found the missing port and wants to fix it.
4. User1 tries to fix the stack by `openstack stack check`, but it shows the 
   following message:
 
  Check Complete: CHECK not supported for OS::Neutron::Port

Comment 2 Zane Bitter 2018-07-12 15:14:02 UTC

If I'm understanding correctly, the issue is that the port was deleted manually (i.e. from outside Heat). The goal is to get Heat to recognise that the port is, in fact, gone and create a replacement.

You can tell Heat that the port needs replacement by using the command:

  openstack stack resource mark unhealthy <stack_name_or_uuid> <resource_name>

This puts the resource into the CHECK_FAILED state. It will then be replaced on any subsequent stack update.

Note that if the resource is in a nested stack, the stack_name_or_uuid must be the name or UUID of the nested stack that directly contains the port resource, not the root stack.

Comment 17 Alex McLeod 2018-09-03 08:03:28 UTC

Hi there,

If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field.

The documentation team will review, edit, and approve the text.

If this bug does not require doc text, please set the 'requires_doc_text' flag to -.

Thanks,
Alex

Comment 21 Fabrizio Soppelsa 2018-09-14 10:33:27 UTC

Hi, we have an additional feedback:

The update do work if setting the unhealthy flag on missing resource (tested with port)

This is not the expected behavior: the missing resource must be manually marked to unhealthy before running the update while the expected behavior is that a stack check understand which is the missing resource and recreates it on stack update.

Comment 23 Rabi Mishra 2018-09-17 09:36:39 UTC

> while the expected behavior is that a stack check understand which is the missing resource and recreates it on stack update

Historically stack check (handle_check interface) has not been implemented by all resource plugins (ex. OS::Neutron::Port).

However, I think it's probably possible to have a default implementation to mark the resources as CHECK_FAILED if they don't exist. But it has to wait for https://storyboard.openstack.org/#!/story/1727142. We currently don't recommend using stack check with convergence architecture (default on overcloud since OSP10).

Comment 25 Fabrizio Soppelsa 2018-09-17 13:57:59 UTC

> However, I think it's probably possible to have a default implementation to mark the resources as CHECK_FAILED if they don't exist. But it has to wait for https://storyboard.openstack.org/#!/story/1727142. We currently don't recommend using stack check with convergence architecture (default on overcloud since OSP10).

Hi Rabi,
do we not recommend using stack check because of this https://bugzilla.redhat.com/show_bug.cgi?id=1626367 or other?

Comment 26 errata-xmlrpc 2018-09-17 16:57:52 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/RHBA-2018:2716