[nailgun] nodes don't return to discovered state

[Andrew Woodward]

case: if a node was previously in an error or deployed state, and for whichever reason the administrator want's to reset it. they should be able to force the node to load the discovery image and the node should switch status back to the discovered state.

If you force the node back into the discovered image it doesn't return to the discovered state, it just sits at its old state even though it should transition back to discovered so that tools can perform the necessary steps to re-provision/deploy

[Evgeniy L (rustyrobot)]

Hi Andrew,

It looks like reset environment feature https://blueprints.launchpad.net/fuel/+spec/nailgun-reset-env , doesn't it?

[Andrew Woodward (xarses)]

Not exactly, This is to allow a node that may be in a funky state to be able to run the bootstrap agent, and when that occurs the node must reset its data in the db as if it's a fresh node. This could be included in 'reset environment' work, but after re-reading the BP, it is likely out of scope

[Mike Scherbakov (mihgen)]

Looks like you simply need to remove a node from environment, do not you?
If it is in a "funky" state, you really need to reset it / remove it from Nailgun, so Cobbler feeds it with bootstrap.

We have node removal feature for this, as well as Delete Environment.
Will this solve your issue?

Also, why do we have multi-l3 tag on this bug?

[Dmitry Borodaenko (angdraug)]

Changing to Incomplete until questions from comment #3 are addressed.

[Andrew Woodward (xarses)]

No, deleting the node from the environment is not the goal here. We want to re-set it to discovery so that we can re-deploy the node in the current environment. Usually this occurs because there was a hardware error or other issue that caused the node to fail deployment. However when you force the node back into discovery, it doesn't reset the error state so it can not be re-deployed with out going through the overly un-necessary process of deleting/removing the node (which will cause it to lose all of its configuration)

Issues:

1) If you force a node into the bootstrap discovery image, it should reset the node back to discovered state. If you subsequently start the deployment, it should re-provision and bootstrap the node as if it was the first time adding the node to the cluster

2) You should be able to reset a node with out deleting it from the DB and cluster (I.E. It should maintain its Role, ID, Interface mappings

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/132809

[Dima Shulyak (dshulyak)]

It is possible to provide desired functionality by refactoring ResetEnvironment task.
It should be possible to define what nodes should be resetted, and reset everything only in case no nodes was received

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/132809
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=0ff69ab5fde7bba3b2cb75a5efa20027c01781bf
Submitter: Jenkins
Branch: master

commit 0ff69ab5fde7bba3b2cb75a5efa20027c01781bf
Author: Dima Shulyak <email address hidden>
Date: Wed Nov 5 11:33:26 2014 +0200

    Refactor reset_to_discover procedure

    Added reset_to_discover method which should be used
    when node resetted to discovery state.
    - Reconfigure volumes
    - Move roles to pendings roles
    - Remove assigned ip address
    - Set pending addition

    Change-Id: I07f1d12f904e8faa76e35f00a49a978a6643eb20
    Closes-Bug: 1389572
    Related-Bug: 1273006

[Vladimir Sharshov (vsharshov)]

Known issue. Moving to 8.0

[Ihor Kalnytskyi (ikalnytskyi)]

Alexey Shtokolov, why did you remove "feature" tag? It's not a bug, we never announce such functionality and hence this is a small enhancement . There should be a new handler for resetting node, which changes node status to "discover" and send to Astute message about removing node from cobbler and rebooting it.

So assign "feature" tag again.

[Alexey Shtokolov (ashtokolov)]

Igor Kalnitsky, this story looks like a re-installation feature implemented by Telco Team in 7.0
I've asked Michael Polenchuk to close this bug if it was covered by that feature.

[Dmitriy Novakovskiy (dnovakovskiy)]

So this appears to be a feature for the following UX:

1. User decides bring a node back to "discovered" state (from any currently applied one, incl. "provisioned" and "error")
2. User uses CLI or API to trigger this operation for a given node id
3. Fuel removes node from DB (and, if necessary, MOS cloud it's currently assigned to) prompts user to reboot it in PXE boot mode[1]

[1] Optionally - attempt to reboot it remotely, if node is accessible

Given that I suggest we add this as CLI-only option, with disclaimer provided - "Please be aware that any resources currently running on a selected node (VMs, Volumes etc) will be lost"

[Alexander Kislitsky (akislitsky)]

We passed SCF in 8.0. Moving the bug to 9.0.

[Amine (amine-bouabdallah)]

We stumbled into this bug when we wanted to to remove one compute node for a re-deployment.
Once the compute node has been removed, then rebooted and bootstrapped, it does not appear anymore in the fuel Web UI.

is there a workaround to this bug until it's been fully addressed ?

Thank you.

We are using MOS 7.0.