> On 9 Feb 2016, at 11:04, Chris Fordham <chris@fordham-nagy.id.au> wrote: > The former is right - its a list of data sources; which ideally enabling a source in a cloud image for a specific cloud that that image is not for is probably incorrect although most of the time you just see a large delay in boot or in reboot (or both) as it times out after long period of trying to hit that 169.foo. The issue sometimes is that the image is not specific to a cloud but a hypervisor or can work independent of hypervisor due to the support in the kernel (its more about the image format) - the problem there how do you cater for this unless providing a slightly different image per cloud/virtual env? I guess I am seeing the NoCloud datasource as the catch-all as it's the simplest and least intrusive of the datasources to get up and running, and although I haven't actually tested it I suspect it wouldn't add any delay (afaik it's just checking for the presence of the drive and moving on). > In terms of the latter, I'm not quite sure the process with our it works etc. but I assume it works with the relevant modules for each data source in each phase in kind of like a compilation. > > With all that said though we still don't have a link or ref to the particular image you are referring to :) Ah yes, whoops. I was trying out the OpenStack images from here http://cdimage.debian.org/cdimage/openstack/current/. Unless I've missed something, these are the only "cloud" images I can find for Debian.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature