Bug 1318804

Summary:	Openshift nodes are deleted from master when stopped and re-added without labels when they restart.
Product:	OpenShift Container Platform	Reporter:	Matt Woodson <mwoodson>
Component:	Node	Assignee:	Andy Goldstein <agoldste>
Status:	CLOSED CURRENTRELEASE	QA Contact:	DeShuai Ma <dma>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.1.0	CC:	agrimm, aos-bugs, jokerman, mmccomas
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-04 18:52:07 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:	1303130

Description Matt Woodson 2016-03-17 21:11:07 UTC

Description of problem:

I am creating this bug to track this issue.

Our (OPS Dedicated) clusters are configured to use the AWS Cloud provider.  I noticed that this has the behavior of when a compute node is stopped via AWS (console or api), the node will no longer appear in "oc get nodes" from the master.  When the node is started again, the node reappears in "oc get nodes", but all of the labels have been removed.  This is undesired because we rely heavily on the labels.  Right now the labels of these nodes are applied via the master.

In Openshift 3.2 this issue can be solved by adding labels to the Node. In 3.1 we don't have this option yet.



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

Openshift 3.1 with AWS Cloud Provider

How reproducible:

Very

Steps to Reproduce:
1. start node, register it.  Label node
2. stop node. run "oc get nodes" from master see it go away
3. start node. run "oc get nodes" and see the node re-appear but not the labels.


Expected results:

We rely on the labels and want them to come back.

Additional info:

We are investigating additional steps to take in order to fix this.

Comment 3 Scott Dodson 2016-06-04 18:52:07 UTC

This was fixed in the latest 3.1.1.6 errata.