osuosl / ganeti-instance-image Goto Github PK

Hi

I have opened a "RFP" (Request For Package) in the Debian BTS (Bug Tracking System) for this software. It seems the debian package metadata is already present, so with your collaboration it may be possible to upload this as a native package in jessie+1.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769611

What do you think?

Without proper support for systemd we will continue to have issues with guest's that use it as their init system.

Right now newer versions of grub2 aren't getting deployed correctly inside of the chroot. I've tried everything I can think of to fix this but unfortunately it seems like the only option is to run it on a helper VM (similar to what snf-image does). I'm not sure if this is fixable inside of a chroot or if there is a better way around this.

While working on GRNET's forked repo of ganeti-instance-image several years ago I made more than 154 new commits. Some added new functionality, some added entirely new tools, some fixed issues, and some ended up being rewrites. I opened various PRs against the osuosl repo in the beginning, but after several years of no response I assumed the repo was a zombie, so I closed the PRs (and there were many more commits since those PRs).

I just noticed that activity has restarted on the osuosl repo recently, and some of that activity is reimplementing what I had already done long ago. Obviously that means unnecessary (existing) work for you, and it also means me not getting the benefit of credit as a "contributor" if you reimplement more work that could have just been cherrypicked from me. Because GRNET stopped using ganeti-instance image back when I stopped working on it, I wasn't sure what they intended to do with their copy of the repo, so at the time I cloned a copy under my name too.

I am sure there are many commits you wouldn't want to use (stylistic changes, conflicts with newer commits of your own), but I suspect there is a lot there that will be useful to you if you dig through it. I remember I even wrote auxiliary tools for image-mounting and manipulating VMs' images offline (handy for root password-resets, etc).

Although I don't have time to dig back through historical code I have long since lost mental context for, I am willing to help you make sense of my intentions when I wrote stuff, if you are digging through it and cherrypicking, and it would be a shame if none of that mountain of work is used. Let me know.

My copy of the repo is here and the master and devel branches are at the same commit. Feel free to close this issue when you have finished looking there.

KERNEL_PATH is not in default config,
it is set in common.sh as
KERNEL_PATH="$INSTANCE_HV_kernel_path"

INSTANCE_HV_kernel_path is read by ganeti-image

if I create instance, no boot partition ( as expected )
but if I run
/usr/share/ganeti/os/image/tools/make-dump
KERNEL_PATH is null, so my dump fails because no boot partition.

If I set KERNEL_PATH in my .conf the dump works.

Regards, Mauro

Most systems that have a separate /tmp mounted don't have the disk space in order to properly unpack and import an image in /tmp. The export script doesn't have this because it calls

TARGET=`mktemp -d --tmpdir=${EXPORT_DIR}`

while the import script calls

TARGET=`mktemp -d`

I'd like to change this anti-symmetry by doing one (and only one) of the following:

1. Change the import script to TARGET=mktemp -d --tmpdir=${EXPORT_DIR}``
2. Set IMPORT_DIR in common.sh and use that in the import script.

Thoughts?