> On 9 Feb 2016, at 11:04, Chris Fordham <[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
