WISHLIST: Use Multistrap (optionally?) instead of Debootstrap for make-base-vm --lxc

[Michagogo]

This would essentially solve #91.

[josephbisch]

Some notes for the person who ends up implementing this:

• Add the "addimportant=true" setting to the general section of the config file for multistrap to get the same default package installation behavor as debootstrap (install important packages in addition to required packages).
• Multistrap uses apt and dpkg directly (unlike debootstrap), so it is a good idea to make multistrap optional like Michagogo suggested and leave the option to use debootstrap.

[Michagogo]

As a side note: why was this method of creating the base container chosen?
AIUI there are other, more "correct" ways of creating LXCs. There's the
lxc-create command for creating containers, and then other commands for
cloning/snapshotting containers. In addition, containers can be started and
stopped just like VMs. Why are we not simply using LXC the way it's
intended to be used? It seems to me that would make the whole process much
simpler, as we could simply treat a container in the same way that we do a
KVM. Unless there's something I'm missing (and there probably is), this may
be a route worth pursuing…

On Wednesday, May 4, 2016, Joseph Bisch notifications@github.com wrote:

Some notes for the person who ends up implementing this:

• Add the "addimportant=true" setting to the general section of the
  config file for multistrap to get the same default package installation
  behavor as debootstrap (install important packages in addition to required
  packages).
• Multistrap uses apt and dpkg directly (unlike debootstrap), so it is
  a good idea to make multistrap optional like Michagogo suggested and leave
  the option to use debootstrap.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#120 (comment)

[Michagogo]

And if we want to get even more streamlined, there may not even be a need
to shell out. LXC has Ruby bindings. But even if we don't touch that, using
the supported LXC workflow and commands, treating it as a VM and doing
everything as we do for KVM, seems to me like it would be an improvement
over our current situation, where things keep breaking. For example, right
now there's some kind of brokenness on Xenial (haven't really had a chance
to look into it).

On Wednesday, May 4, 2016, Micha Bailey michabailey@gmail.com wrote:

As a side note: why was this method of creating the base container chosen?
AIUI there are other, more "correct" ways of creating LXCs. There's the
lxc-create command for creating containers, and then other commands for
cloning/snapshotting containers. In addition, containers can be started and
stopped just like VMs. Why are we not simply using LXC the way it's
intended to be used? It seems to me that would make the whole process much
simpler, as we could simply treat a container in the same way that we do a
KVM. Unless there's something I'm missing (and there probably is), this may
be a route worth pursuing…

On Wednesday, May 4, 2016, Joseph Bisch <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Some notes for the person who ends up implementing this:

• Add the "addimportant=true" setting to the general section of the
  config file for multistrap to get the same default package installation
  behavor as debootstrap (install important packages in addition to required
  packages).
• Multistrap uses apt and dpkg directly (unlike debootstrap), so it
  is a good idea to make multistrap optional like Michagogo suggested and
  leave the option to use debootstrap.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#120 (comment)