Via the NoCloud config drive of course :-) Sent from the ether
> On 16 Feb 2016, at 07:48, Juerg Haefliger <[email protected]> wrote: > > > > 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
