Ian Denhardt

Point, we should add server side stuff as well. I think defining an 'identifier' schema and using it makes sense still.

Maybe instead of (2), do a hard *shutdown*, then add (4): turn machine on. This avoids some tricky race conditions. We could add a call to view the power status...

That could probably be removed now that we have set_bootdev. I think originally the notion was you'd have the default boot device set to disk, and rebooting via the api...

I think the right way to solve this issue is the following: 1. Add an API call to check the current power status of the node, so we can tell...

Yeah, that's what I'm talking about.

First step is probably to go through and identify what objects are common to all/most/many tests. From there we can move them into fixtures.

#514 is a separate set of issues from the stuff in `api/main.py` If you feel confident that you can write a set of fixtures that can pull the duplication out...

The big thing is figuring out how we're going to go about testing downgrades, and with each upgrade we'd need to think both ways about the change. I worry about...

I'd like to add this to the 0.4 milestone; we've got plans to have a somewhat fiddly upgrade process because of OBMd, so it would be good to have clear...

Sounds good to me; we can defer things to 0.5 Quoting Naved Ansari (2018-04-03 15:29:05) > Sure. > > From your [1]comment > The second part of the migration strategy...