-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[snapshots] resolve instance dir in vm #3130
Conversation
Hey @sharder996, it looks like this needs a rebase and conflict fix. |
9365e06
to
7af15d3
Compare
8757363
to
5220596
Compare
Hey @sharder996, I pushed a new commit to account for new tests that are now present after rebasing. However, there are still a few other tests that failed when I tried them locally:
I am not sure if they broke with my rebase or if they were already failing. Would you be able to take a look, please? Thank you! |
Ho @ricab, thanks for fixing those tests! When I created this PR, I had not prioritized fixing tests since I'm anticipating there being review changes which would require me to fix tests again. |
Ah OK, if it's not caused by my rebase I am happy. |
1adce11
to
fa3de91
Compare
fa3de91
to
d9926b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, thanks @sharder996! It took me a little to wrap my head around this one, but I think I finally formed a cohesive opinion...
This is tricky stuff but you made good progress here. I understand the option for creating the directory where it is derived (in get_instance_directory_name()
), but I am not sure it's worth all the additional trips to disk (even to remove resources, the code tries to create the directory before removing it). We've been operating without that safety net for a long time and if we failed to create the directory now, that would be quickly noticed.
IIUC, the instance directory needs to be created only before it is used, i.e.:
- when fetching, just before placing the instance image there
- when launching with LXD (which does not place the image there), just before calling the instance constructor
- when starting up the daemon with LXD, on creation of pre-existing (LXD) VMs that still do not have a directory, just before calling the instance constructor (only needed the first time after upgrading)
Additionally, I don't see a need to create parent directories separately:
.../vault
is the vault's business.../vault/instances
is not needed until there is an instance- creating
.../vault/instances/<instance>
withMP_UTILS.make_dir
creates those parents
Therefore, it seems to me that, strictly speaking, the only new place we need to create a directory is in LXDVMFactory::create_vm()
. Other backends already require the image to be in place when creating the VM, whichever way it got there (DefaultVMImageVault
today, clone tomorrow, etc.). So there is no need to create the directory in those cases.
If this all makes sense to you, I think you could still keep the instance directory derivation, parameters, and fields where you added them, but actually create the directory only in DefaultVMImageVault
, as before (image_instance_from
and extract_image_from
) and in the LXD factory.
WDYT?
src/platform/backends/libvirt/libvirt_virtual_machine_factory.cpp
Outdated
Show resolved
Hide resolved
d9926b8
to
b1ef49d
Compare
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
Signed-off-by: sharder996 <[email protected]>
… to factory Signed-off-by: sharder996 <[email protected]>
b1ef49d
to
c505a13
Compare
557c0ad
to
54faf5f
Compare
Hey @sharder996, is this ready for another pass? |
…ction calls to base class
Remove `explicit` keyword from constructor with two parameters.
…d modified vm factory
Codecov Report
@@ Coverage Diff @@
## snapshots #3130 +/- ##
=============================================
+ Coverage 84.61% 84.77% +0.15%
=============================================
Files 247 247
Lines 13107 13228 +121
=============================================
+ Hits 11091 11214 +123
+ Misses 2016 2014 -2
|
Remove artificial constructors from base VM and factory classes. Let stub classes pass in stub arguments when needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this is getting there, only a few loose ends left to tie (please see comments above too).
src/platform/backends/libvirt/libvirt_virtual_machine_factory.cpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting real close, but something is fishy now:
$ multipass launch -n a
Launched: a
$ ll /var/snap/multipass/common/data/multipassd/vault/instances/a/
total 703784
drwxr-xr-x 3 root root 4096 set 20 11:43 .
drwxr-xr-x 3 root root 4096 set 20 11:43 ..
drwxr-xr-x 2 root root 4096 set 20 11:43 a
-rw-r--r-- 1 root root 53248 set 20 11:43 cloud-init-config.iso
-rw-r--r-- 1 root root 720699392 set 20 11:46 ubuntu-22.04-server-cloudimg-amd64.img
Notice the extra "a" subdir.
@@ -154,6 +154,8 @@ class Utils : public Singleton<Utils> | |||
// virtual machine helpers | |||
virtual void wait_for_cloud_init(VirtualMachine* virtual_machine, std::chrono::milliseconds timeout, | |||
const SSHKeyProvider& key_provider) const; | |||
virtual Path derive_instances_dir(const Path& data_dir, const Path& backend_directory_name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, well done adding this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great Scott :} Looking good on this side, so approving but postponing merging until the other side is reviewed too.
[snapshots] resolve instance dir in vm r=ricab a=sharder996 Co-authored-by: ScottH <[email protected]>
[snapshots] resolve instance dir in vm r=ricab a=sharder996 Co-authored-by: ScottH <[email protected]>
The motivation behind this change is to allow a vm to resolve the directory in which it and all it's relevant files are stored, which is needed for snapshots and retrospectively, native mounts on hyperv instances.
In order to achieve this, the idea was to take away the responsibility of creating/deleting instance directories from the vm image vault and give it to the vm factory. This conceptually makes more sense as the factory is the class responsible for creating/removing vm resources in the first place and is also the place where platform/backend specific directories locations are resolved. The vm image vault then queries the factory for a instance specific directories and using it as a download directory.
As this is not a small architectural change, I want to get some feedback on this and improve it.
Public side of #549