Add migration endpoints to propolis-server #69
Conversation
| ) -> Result<(), MigrateError> { | ||
| info!(log, "Enter Migrate Task"); | ||
|
|
||
| // TODO: actual migration protocol, for now just send some stuff back and forth |
There was a problem hiding this comment.
cc @dancrossnyc this would be where we plug in the tokio codec Framed stuff to wrap this Upgraded object on the source side.
server/src/lib/migrate.rs
Outdated
| let mut conn = hyper::upgrade::on(res).await?; | ||
|
|
||
| // Good to go, ready to migrate from the source via `conn` | ||
| // TODO: wrap in a tokio codec::Framed or such |
There was a problem hiding this comment.
@dancrossnyc and here for the destination side.
|
I assume a5bdf81 is due to the stabilization of the |
Oh, no we already have a top-level rust-toolchain.toml which is set to nightly so that hasn't changed. I was just annoyed needed to change multiple other files while testing something earlier. But yup, I'll pull that outta this PR. |
luqmana
force-pushed
the
live-migrate
branch
2 times, most recently
from
888fcf0 to
c4047a3
Compare
| // Now, we spawn a new task to handle the actual migration over the upgraded socket | ||
| let task = tokio::spawn(async move { | ||
| let conn = match upgrade.await { | ||
| Ok(upgraded) => upgraded, |
There was a problem hiding this comment.
Could we perhaps call this conn or socket or something? I probably just need more caffeine, but I was thinking that this referred to the upgrade case for LM. :-D
There was a problem hiding this comment.
I already do have a conn there but I just added a comment to make it more clear. Let me know if that's enough.
luqmana
force-pushed
the
live-migrate
branch
from
302f48e to
b439789
Compare
…ropolis-server can also set it.
luqmana
force-pushed
the
live-migrate
branch
from
6acb4ef to
6304b1b
Compare
|
I see no reason why we should get this landed, provided it'll make it easier to integrate with the other pending bits for LM.
An item for later follow-up, but we might end up wanting a separate endpoint for creating an instance for the purpose of "rehydration" during a migration. The expectations there might be different enough to split those cases up. shrug Thanks for putting this all together. |
|
@pfmooney I think there was a typo in your comment, "I see no reason why we shouldn't get this landed" ? |
And this is why I shouldn't be up so late. |
:-) The meaning was clear from context, though. |
Building on the live migration work in propolis (oxidecomputer/propolis#69), this adds the nexus endpoint to trigger a migration of an instance.
This adds the endpoints described in RFD 71 along with a first pass for some of the setup.
New Endpoints:
/instances/{src-uuid}/migrate/start— This is the endpoint called by the new (destination) propolis-server instance when its ready to begin the migration process. This request requires no body as we'll perform an HTTP upgrade to reuse the underlying TCP socket as a bidirectional channel to perform the migration over./instances/{src-uuid}/migrate/status— This endpoint allows querying either the source or destination on the current progress of a migration.Modified Endpoints:
/instances/{dst-uuid}— This is the existing "ensure" endpoint, which has been extended with an optional blob describing a source VM from which a new VM will be populated.