On Mon, Feb 15, 2016 at 12:16 PM, Cliff Rowley <[email protected]> wrote: > > Hey Juerg, thanks for your response. I have been trying out various mechanisms including NoCloud, ConfigDrive and also going as far as emulating the OpenStack metadata server on the magic URL to try to determine the simplest and easiest way to get a Debian cloud image up and running. In the end, I decided just to build my own images and simply add the NoCloud data source to cloud config (it really was as simple as that).
Hmm... And how do you get the password/ssh-key into the image? Hard-coded? ...Juerg > Personally, I still think its worth the minimal effort to add the NoCloud datasource to the existing cloud image (if there is to be only one) as it would allow the image to be run as-is by anyone with very little configuration. Not sure why that isn't attractive enough to be the default already and I'll be honest it makes Debian a decision rather than simply a choice when looking at cloud images because it's the only major distribution I've found that can't be simply run with NoCloud. > > > Anyway, my personal problem is solved for now, thanks :-) > — > Cliff Rowley > Thinker, Tinkerer, Dork > @cliffrowley > > On 15 Feb 2016, at 11:10, Juerg Haefliger <[email protected]> wrote: > > > > On Tue, Feb 9, 2016 at 12:36 PM, Cliff Rowley <[email protected]> wrote: > >> > >> Straight libvirt/kvm (hence my push for the NoCloud datasource!) > > > > Right, so we can see why there is a mismatch. > > > > I'll leave it the right peeps on this list to comment, however I think what we ideally want to provide is a generic kvm image (in fact not necessarily specific to kvm; just call it a generic image) that only has NoCloud enabled. I think there is room to add in extra datasources ( http://cloudinit.readthedocs.org/en/latest/topics/datasources.html) as long as they don't inhibit the boot process and gracefully degrade without delay. > > > > > > A generic KVM image with NoCloud would be fine with me. > > I understand your use case but it's not free to build and maintain several different flavors of images. Have you looked at using an OpenStack config drive in conjunction with the Debian cloud image? Basically, you build a JSON file with the metadata and put it on an ISO disk image (see [1]) which you attach to your VM. Cloud-init will then pull metadata from it instead of trying to contact the 169.foo voodoo server. > > Another possibility is to provide a generic config drive image with the cloud images so that users don't have to bother creating their own. > > Or maybe [2] might be of use to you if you want to run plain OpenStack images locally :-) > > ...Juerg > > [1] https://github.com/juergh/dwarf/blob/master/dwarf/compute/servers.py#L122 > [2] https://github.com/juergh/dwarf > > > > > > I'm happy building my own images too (have just built one with NoCloud enabled to "see what happens"), but as an end user what I'd really like is to be able to pull and cache an official image. > > > > Its hard to cater for everything no matter how many different types of images you provide, however I'd just like to flag that Ubuntu do this pretty well. > > > > > > They do, but not without problems - I had some issues with the interfaces configuration in their image (it tries to use both /etc/interfaces and /etc/interfaces.d/* - unsuccessfully). I guess then init specific images is probably a good thing after all. > > > > > -- > Juerg Haefliger > Hewlett Packard Enterprise > > -- Juerg Haefliger Hewlett Packard Enterprise
