summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/__35__propellor_on_irc.oftc.net.mdwn2
-rw-r--r--doc/forum/__35__propellor_on_irc.oftc.net/comment_1_6e9595651c19d98353254f0914b685e1._comment9
-rw-r--r--doc/forum/support_for_non-bootable_disk_images/comment_2_cced7ce2491cf440ee1d576b75ab4539._comment10
-rw-r--r--doc/forum/support_for_non-bootable_disk_images/comment_3_8dd7f3dd8c80fda70233e395da2204b2._comment33
-rw-r--r--doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment15
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_2_54538a03d7085513538baa2970983ae0._comment8
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment14
7 files changed, 91 insertions, 0 deletions
diff --git a/doc/forum/__35__propellor_on_irc.oftc.net.mdwn b/doc/forum/__35__propellor_on_irc.oftc.net.mdwn
new file mode 100644
index 00000000..9f644611
--- /dev/null
+++ b/doc/forum/__35__propellor_on_irc.oftc.net.mdwn
@@ -0,0 +1,2 @@
+This might be wildly optimistic, but I registered the IRC channel #propellor on irc.oftc.net. I have no strong opinions on irc networks, but #git-annex is already there. Please join so you can answer my questions ;).
+
diff --git a/doc/forum/__35__propellor_on_irc.oftc.net/comment_1_6e9595651c19d98353254f0914b685e1._comment b/doc/forum/__35__propellor_on_irc.oftc.net/comment_1_6e9595651c19d98353254f0914b685e1._comment
new file mode 100644
index 00000000..187004c7
--- /dev/null
+++ b/doc/forum/__35__propellor_on_irc.oftc.net/comment_1_6e9595651c19d98353254f0914b685e1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-13T21:36:16Z"
+ content="""
++1 user for initiative ;)
+
+Although I will not want to help with any big type errors on irc ;)
+"""]]
diff --git a/doc/forum/support_for_non-bootable_disk_images/comment_2_cced7ce2491cf440ee1d576b75ab4539._comment b/doc/forum/support_for_non-bootable_disk_images/comment_2_cced7ce2491cf440ee1d576b75ab4539._comment
new file mode 100644
index 00000000..51cad6ff
--- /dev/null
+++ b/doc/forum/support_for_non-bootable_disk_images/comment_2_cced7ce2491cf440ee1d576b75ab4539._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="As commits"
+ date="2018-10-08T13:03:06Z"
+ content="""
+I pushed the changes to
+
+https://salsa.debian.org/bremner/propellor/commits/proposed/direct-boot
+"""]]
diff --git a/doc/forum/support_for_non-bootable_disk_images/comment_3_8dd7f3dd8c80fda70233e395da2204b2._comment b/doc/forum/support_for_non-bootable_disk_images/comment_3_8dd7f3dd8c80fda70233e395da2204b2._comment
new file mode 100644
index 00000000..d1761e51
--- /dev/null
+++ b/doc/forum/support_for_non-bootable_disk_images/comment_3_8dd7f3dd8c80fda70233e395da2204b2._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-13T21:41:25Z"
+ content="""
+Code^Wwhitespace review:
+
+* I noticed some places were using spaces for indentation;
+ please use tabs in propellor.
+* In "module Propellor.Property.DirectBoot(installed)'
+ there should be a space after the name of the module.
+* Needs comments explaining what properties are for.
+
+Naming ideas: Basically this is using qemu as the bootloader, rather than
+going through an (emulated) BIOS to start a bootloader. So I'm thinking
+names like QemuBootloader or NoBootloader, or NoBIOS. Don't want to
+bikeshed this too hard, it would be ok to keep the DirectBoot name, but
+I think Propellor.Property.DirectBoot at least needs a comment explaining what it's
+for, it would be confusing for a propellor user to stumble across that
+module without context.
+
+Your idea to copy the kernel and initrd out of the image so qemu can use
+them seems to point toward having a Property that gets one of these images
+booted up using qemu. And then the QemuBootloader name would make a lot of
+sense, because it would allow for later expansion to other emulators. Not
+that you have to build such a thing, but it's worth considering that someone
+may later want to.
+
+(In fact I could use such a thing, but I don't know how I'd want it to
+work. Should propellor only use the chroot for initial image build, and
+then ssh into the booted VM and run propellor in there when there are
+config updates? Or restart the VM when the image is changed?)
+"""]]
diff --git a/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment b/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment
new file mode 100644
index 00000000..55e4e20b
--- /dev/null
+++ b/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Naming and other hard problems"
+ date="2018-10-13T23:16:07Z"
+ content="""
+I'm not too attached to the terminology, \"direct booting\" just what an unscientific survey of sysadmin types came up with. QemuBoot is more descriptive, although I do wonder if it's really specific to Qemu. As far as I understand (which is just from reading the Xen wiki), Xen dom0 can also (and originally could only) boot this way. In fact I think the last Xen VPS I had worked like this, which was a pain as a guest admin. Maybe the connecting thread is that the boot is controlled by the host rather than the guest VM. HostBoot would be one option, although NoBootloader is also fine with me. I think things like QemuBootloader or whatever would likely be layered on top.
+
+I'm less sure about copying kernel and initrd than when I first wrote that. If it's reasonable to depend on the existence of the foo.img.chroot, then it's quite convenient to boot from the already conveniently present kernel and initramfs.
+
+I'll have to see how hard it is to get basic networking with just qemu. It might make sense to use libvirt to run the VMs, especially since that's what the production deployment uses. I saw [[spwhitton]] had some ideas about libvirt.
+
+
+
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_2_54538a03d7085513538baa2970983ae0._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_54538a03d7085513538baa2970983ae0._comment
new file mode 100644
index 00000000..497e364a
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_54538a03d7085513538baa2970983ae0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-14T00:36:55Z"
+ content="""
+@david, but you'd not then want to change the backing raw image, I assume,
+or does qcow somehow deal with that?
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment
new file mode 100644
index 00000000..db451976
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="qcow and raw imgs"
+ date="2018-10-13T23:48:46Z"
+ content="""
+Maybe this is obvious, but it's cheap to generate a qcow image \"backed\" by an existing raw image
+
+To quote from a script I have lying around to let a non-root user boot a root owned, read-only image
+[[!format txt \"\"\"
+qemu-img create -b /srv/vm/$vm.img -f qcow2 $img
+\"\"\"]]
+
+"""]]