registry team mailing list archive

[justinsb <609312@xxxxxxxxxxxxxxxxxx>]

mac-fix makes remove-udev unnecessary:

Thanks... I think the remove-udev rules bit was probably more because I
made a mistake bundling the image (leaving the old rules file), and
found it much easier to fix this way.  I've been advised I should simply
have deleted the network udev rule file as part of image construction.

This is therefore probably part of a much larger debate about what
should be done in the image, and what by the 'launch VM' stage.  The
launch VM stage is convenient for me right now, but it won't cope with
other OSes or probably even other distros.

One possibility is to have a script that can fix common mistakes, that
could be run just before image uploading.  This could even do really
sneaky stuff, like figuring out the exact byte offsets to change so that
we can inject data into filesystems that we don't really understand
(e.g. Windows?)

If you agree, I might move some of my more questionable functionality
into a new script.  For instance, I don't really think that module
loading necessarily belongs in there; it's just me fixing up my own
mistakes.  But others will make the same mistakes, so it does need to be
easy.

===

File injection into images is messy:

I agree that I've probably pushed that function to its limits in terms
of number of parameters :-)

What isn't clear to me is whether this OS/distro-specific knowledge should be exposed beyond the disk injection function.  Maybe in an ideal world this mapping would be provided as part of the image upload.  Any auto-detection code is likely to get messy fast, so it makes sense to contain that mess in a single class / group of classes.
 
===

Lastly, the logic for booting without kernel if it isn't specified may
need to be changed.  We may need a flag to allow booting without
specifying a kernel, perhaps global and/or per-image in the image store.


Yeah, this was just a hack so that I could get it to work with the euca- tools.  Any ideas on a better side-channel to use with the euca- tools (until we get our own)?  Right now it's not too bad... if you don't specify a kernel at either the image registration or the instance launching, it'll presume there's no kernel and so it's a whole disk image.

Is there a "requirements" problem with the way I've done it, or is it
just that it's a bit of a hack?

-- 
Comments on raw-disk-image branch
https://bugs.launchpad.net/bugs/609312
You received this bug notification because you are a member of Registry
Administrators, which is subscribed to OpenStack.