summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_10_b48444a7ec6a69019a2fda927925cac1._comment40
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_11_feec29fe99528e66b0cbc0388793e10e._comment8
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_12_2a42bef328b8dc17754050e3cdb7e7d2._comment8
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment14
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment49
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment23
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_9_4ba83dedf873a1a70fc050f22fca343e._comment12
7 files changed, 154 insertions, 0 deletions
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_10_b48444a7ec6a69019a2fda927925cac1._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_10_b48444a7ec6a69019a2fda927925cac1._comment
new file mode 100644
index 00000000..9b142dcd
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_10_b48444a7ec6a69019a2fda927925cac1._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""code review"""
+ date="2018-11-06T14:59:06Z"
+ content="""
+Let's comment out the QCow2 constructor until that case is handled.
+
+With NumVCPUs and MiBMemory both Int, and used in the same property, they
+could get mixed up. Recommend newtypes.
+
+Would it make sense for defaultNetworkAutostarted
+to itself run the virsh net-start? It would simplify the example.
+
+It's named kvmDefined; is it actually guaranteed to use kvm and not some other VM?
+
+What happens when osVariant is Nothing and no --os-variant is passed?
+When osType is Nothing? Is it still likely to work?
+
+Please make osType not have a default case and define it for all the
+current constructors. That way, the next person to
+add an Linux distro to propellor won't forget to update it.
+
+The chroot nuking code depends on some implementation details in DiskImage,
+so I'd be inclined to move it to that module. (Which probably has similar
+code that can be factored out.)
+
+The "defined" scriptProperty uses a lot of values that are unlikely to
+contain spaces or other script unsafe stuff, but it would still be good to
+shellEscape them. (Or it could be rewritten to run virt-install w/o a
+shell, read its output, and write the file.)
+
+The "started" scriptProperty also needs some escaping. (Although I'd be
+inclined to parse virsh list in haskell, but up to you.)
+
+Minor: The `& Libvirt.defaultNetworkAutostarted` example line is currently
+indented by spaces while the other lines use tabs.
+
+Minor: I'd use `$` in some of the places where you have a parenthesized
+do block or other multiline block of code.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_11_feec29fe99528e66b0cbc0388793e10e._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_11_feec29fe99528e66b0cbc0388793e10e._comment
new file mode 100644
index 00000000..97467c3b
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_11_feec29fe99528e66b0cbc0388793e10e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 11"
+ date="2018-11-10T23:17:52Z"
+ content="""
+All done, I think. Thank you for a useful review. Commit messages and comments should explain my changes.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_12_2a42bef328b8dc17754050e3cdb7e7d2._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_12_2a42bef328b8dc17754050e3cdb7e7d2._comment
new file mode 100644
index 00000000..84fa1ada
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_12_2a42bef328b8dc17754050e3cdb7e7d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 12"
+ date="2018-11-10T23:29:35Z"
+ content="""
+(Hmm, here on Debian stretch, passing `--autostart` does not actually cause the VM to be marked for autostarting. This is a bug in virt-install, though, as we're using the command line interface as documented -- I confirmed this using `PROPELLOR_DEBUG=1`.)
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment
new file mode 100644
index 00000000..931b21fe
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="creating the libvirt VM"
+ date="2018-11-04T01:03:06Z"
+ content="""
+I've now an adhoc, proof-of-concept libvirt VM provisioned by my config.hs, just using a raw disk image. It turns out that propellor should not be writing the XML configuration file in /etc, but having libvirt generate it. This is because the config is not meant to be directly edited. So, propellor should call virt-install(1) to setup and boot the VM.
+
+My code uses virt-install's --import option, also passing it the location of the disk image generated by propellor. The main problem is that the invocation of virt-install won't return until after the VM first shuts down; the idea is that you are running the OS installer and then you reboot. Possibly using --boot instead of --import will help here; not sure.
+
+We will need the user to specify how much RAM and how many vCPUs to assign to the VM. All the other parameters to virt-install can be determined by looking at the properties of the VM `Host`.
+
+Otherwise, the user will need to set an IP property on the VM so that it can be conducted. I think we will need to leave the user to do this, as there are so many possible network configurations for libvirt VMs. But we could probably provide helper properties. In particular, the standard setup will be to use `Network.static`, though I'm not sure about how to do that with indeterministic interface names.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment
new file mode 100644
index 00000000..1aa82a09
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="New design: requesting feedback"
+ date="2018-11-04T17:39:51Z"
+ content="""
+Having slept on it, and also looked at some more of virt-install(1), I have a new design. I'd be grateful for feedback on this, before implementation.
+
+We have two properties: `Libvirt.kvmRunning` and `Libvirt.kvmRunningConducted`, where
+
+ kvmRunningConnected host = conducts host `requires` kvmRunning host
+
+The basic reason for separating these two properties is that for the conducting to work, various network things have to be set up, and there isn't a configuration that it would be sensible to have as a default. More generally, libvirt isn't at all suited to declarative configuration. What propellor can do well is build an image and have libvirt generate a barebones XML configuration file to boot the image. This is what `Libvirt.kvmRunning` will do. After that, we're going to have to leave it up to the user. I suspect that outside of the very simplest cases, they are going to have to make a series of virsh(1) calls, using `flagFile` to ensure that it only happens once.
+
+`Libvirt.kvmRunning` will work like this:
+
+1. ensure libvirt etc. are installed
+2. build the image if it doesn't exist
+3. nuke the chroot used to build the image
+3. if VM config does not exist,
+ 1. `virt-install -n vm-hostname --description \"vm-hostname VM\" --os-type=Linux --os-variant=debian9 --ram=1024 --vcpus=2 --autostart --disk path=/var/lib/libvirt/images/vm-hostname.img,device=disk,bus=virtio --import --print-xml >/tmp/foo`
+ 2. `virsh define /tmp/foo`
+ - `virt-install --print-xml` and then `virsh define` avoids the problem of virt-install not exiting until after the VM has been shutdown at least once/the virt-viewer instance launched by virt-install has been closed
+ 3. `virsh start vm-hostname`
+
+Sample usage:
+
+ laptop :: Host
+ laptop = host \"iris.silentflame.com\" $ props
+ & osDebian (Stable \"stretch\") X86_64
+ & Libvirt.kvmRunning Raw 1GB 2 develacc -- specification of image type, RAM and vCPUs to assign
+
+ develacc :: Host
+ develacc = host \"develacc.iris.silentflame.com\" $ props
+ & osDebian Unstable X86_64
+ & hasPartition
+ ( partition EXT4
+ `mountedAt` \"/\"
+ `addFreeSpace` MegaBytes 10240
+ )
+ & Apt.installed [\"linux-image-amd64\"]
+ & Grub.installed PC
+
+ & ipv4 \"192.168.122.31\"
+ & Network.static \"ens3\" (IPv4 \"192.168.122.31\")
+ (Just (Network.Gateway (IPv4 \"192.168.122.1\")))
+ `requires` Network.cleanInterfacesFile
+ & Hostname.sane
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment
new file mode 100644
index 00000000..0af0baaa
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-11-05T16:40:57Z"
+ content="""
+Seems that kvmRunning would need a warning that changes to the propellor
+configuration of the VM's Host won't affect the VM. Because it's unusual for
+propellor to only be able to set something up and not change it afterwards.
+
+But kvmRunning is certianly a useful low level property, and combining with
+other properties like that is good.
+
+Hmm, it's actually possible to mount a qcow2 image using libguestfs-tools.
+<http://ask.xmodulo.com/mount-qcow2-disk-image-linux.html>
+So, propellor could temporarily take down the VM and run inside the qcow2
+to update it! Although doing that every time propellor is run seems
+suboptimal. It could keep the chroot around and only update the qcow2 image
+if the chroot needed to be updated. I am not sure how I feel about that
+idea.
+
+We could also make conducting easier to set up, perhaps not needing `main`
+to be modified to use it.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_9_4ba83dedf873a1a70fc050f22fca343e._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_9_4ba83dedf873a1a70fc050f22fca343e._comment
new file mode 100644
index 00000000..94f2ef9b
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_9_4ba83dedf873a1a70fc050f22fca343e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 9"
+ date="2018-11-06T03:12:26Z"
+ content="""
+Thanks. I've now implemented enough of this to support my usecase in the libvirt branch of <https://git.spwhitton.name/propellor>.
+
+There are TODOs, but now seems as good a time as any for someone to implement the qcow2 support . . .
+
+With regard to your idea, taking down the VM and running propellor on the qcow2 file seems like it will not be useful to very many people. ISTM that treating the VM as a host and spinning it is right.
+"""]]