On Tue, Feb 9, 2016 at 10:12 PM, Cliff Rowley <[email protected]> wrote:
> > 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. On what cloud or virtualization platform are you running those images?
