Add a Mistral workflow to move nodes from available to manageable

Bug #1594879 reported by Dougal Matthews
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Expired
Undecided
Unassigned

Bug Description

The baremetal workflows have provide_manageable_nodes, which takes all manageable nodes and makes them available. We don't have a good way to do the opposite of this.

Either a specific workflow would do, or a more generic workflow could solve multiple cases.

Revision history for this message
Dougal Matthews (d0ugal) wrote :
Dougal Matthews (d0ugal)
tags: added: tripleo-common
tags: added: workflows
Changed in tripleo:
assignee: nobody → Ana Krivokapić (akrivoka)
Revision history for this message
Emilien Macchi (emilienm) wrote :

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

Changed in tripleo:
assignee: Ana Krivokapić (akrivoka) → nobody
Dougal Matthews (d0ugal)
Changed in tripleo:
importance: Medium → Low
Revision history for this message
Toure Dunnon (toure) wrote :

What would be the criteria to move a node from managed to available? Would this just be at the operator's discretion?

Changed in tripleo:
assignee: nobody → Toure Dunnon (toure)
Revision history for this message
Dougal Matthews (d0ugal) wrote : Re: tripleoclient should use the set_node_state workflow

I have updated the title and the tags. This has been partially solved, the remaining issue is to update tripleoclient to use the workflow tripleo.baremetal.v1.set_node_state instead of the tripleoclient.utils.set_node_state Python function.

tags: added: tripleoclient
removed: tripleo-common workflows
summary: - Add a Mistral workflow to move nodes from available to manageable
+ tripleoclient should use the set_node_state workflow
Revision history for this message
Dougal Matthews (d0ugal) wrote :

Actually, I added the old tags and reset the title. The workflow "tripleo.baremetal.v1.set_node_state" almost does what this bug wants, but it expects one node and we want to transition a set of nodes. So the criteria for this bug would be exactly the same as that workflow but with multiple nodes :)

Then tripleoclient needs to be updated to use it instead of its own set_node_state function.

summary: - tripleoclient should use the set_node_state workflow
+ Add a Mistral workflow to move nodes from available to manageable
tags: added: tripleo-common workflows
Revision history for this message
Dougal Matthews (d0ugal) wrote :

Thinking about this more, I am not even sure it is worth doing. It is really low priority IMO.

Revision history for this message
Emilien Macchi (emilienm) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, NEWTON, OCATA, PIKE, QUEENS, QUEENS).
  Valid example: CONFIRMED FOR: FUTURE

Changed in tripleo:
assignee: Toure Dunnon (toure) → nobody
importance: Low → Undecided
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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