Open Stack

>  We have users who use 'rebuild' on volume booted servers before nova
>  microversion 2.93, relying on the behavior that it keeps the volume as
>  is. And they would like to keep doing this even after the openstack
>  distro moves to a(n at least) zed base (sometime in the future).

Maybe I'm missing something, but what are the reasons you would want to
rebuild an instance without ... rebuilding it?

I assume it's because you want to redefine the metadata or name or
something. There's a reason why those things are not easily mutable
today, and why we had a lot of discussion on how to make user metadata
mutable on an existing instance in the last cycle. However, I would
really suggest that we not override "recreate the thing" to "maybe
recreate the thing or just update a few fields". Instead, for things we
think really should be mutable on a server at runtime, we should
probably just do that.

Imagine if the way you changed permissions recursively was to run 'rm
-Rf --no-delete-just-change-ownership'. That would be kinda crazy, but
that is (IMHO) what "recreate but don't just change $name" means to a
user.

>  As a naive user, it seems to me both behaviors make sense. I can
>  easily imagine use cases for rebuild with and without reimaging.

I think that's because you're already familiar with the difference. For
users not already in that mindset, I think it probably seems very weird
that rebuild is destructive in one case and not the other.

>  Then there are a few hypothetical situations like:
>  a) Rebuild gets a new api feature (in a new microversion) which can
>  never be combined with the do-not-reimage behavior.
>  b) Rebuild may have a bug, whose fix requires a microversion bump.
>  This again can never be combined with the old behavior.
>
>  What do you think, are these concerns purely theoretical or real?
>  If we would like to keep having rebuild without reimaging, can we rely
>  on the old microversion indefinitely?
>  Alternatively shall we propose and implement a nova spec to explicitly
>  expose the choice in the rebuild api (just to express the idea: osc
>  server rebuild --reimage|--no-reimage)?
>
> I'm not opposed to challenge the usecases in a spec, for sure. 

I really want to know what the use-case is for "rebuild but not
really". And also what "rebuild" means to a user if --no-reimage is
passed. What's being rebuilt? The docs[0] for the API say very clearly:

"This operation recreates the root disk of the server."

That was a lie for volume-backed instances for technical reasons. It was
a bug, not a feature.

I also strongly believe that if we're going to add a "but not
really" flag, it needs to apply to volume-backed and regular instances
identically. Because that's what the change here was doing - unifying
the behavior for a single API operation. Going the other direction does
not seem useful to me.

--Dan

[0] https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action