DeviC3 commented on issue #13816:
URL: https://github.com/apache/cloudstack/issues/13816#issuecomment-5265183655
Thanks for reproducing it.
On the semantics question: a new password is already generated in this path
today, it
just never reaches anyone. In the first startVirtualMachine call
(ReturnAfterVolumePrepare
= true, L9808) vm.isUpdateParameters() is still true, so the params map is
built with
Param.VmPassword and the flag is cleared at L5843. In orchestrateStart the
early return
for ReturnAfterVolumePrepare sits after _networkMgr.prepare(...) (4.22.1.0,
L1359-1377),
so the password has already gone to the password service before that call
returns.
Two things follow, both read off the code and not yet confirmed on the wire:
- the null guard alone gives a running instance whose guest picks up a
password nobody
ever sees; the current NPE at least fails loudly,
- Start Instance = No does not avoid it, since only the second start is
gated on
getStartVm() - the first one always runs.
So the fix depends on the intent. If the instance should inherit (my reading
for a backup
restore - the root volume is a block-level copy, so the credentials on disk
are the source
VM's), the password param should not be generated in this path at all and
the guard is
just defence in depth. If a new password is meant to be issued, the Pair
from the first
call should be carried into the second one so the API returns the password
that already
went to the router.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
