On 12/24/18 04:34, Thomas Goirand wrote:
On 12/23/18 6:17 PM, Paul Graydon wrote:
In
addition to what we call "canned images", we also offer a Partner Image
Catalogue service, where third party vendors can produce and publish
images through our platform.
We'd like to include Debian as one of the main distributions we offer,
and I believe this is the right place to find out how we might go about
doing that.
You've knocked on the correct door. Welcome!
For some distributions (like CentOS), the preferred
approach is for us to generate the images ourselves, which is definitely
an option. For others (like Ubuntu), images are generated for us that
we publish. We're happy to go with whatever is the preferred approach.
The only Debian image that we allow to be called "official" are these
generated on our infrastructure, with the software being available in
Debian.
OK, that's not an issue for us.
I notice that Debian produce images for some clouds, including the older
Oracle Cloud Compute platform, via bootstrap-vz?.
We are now standardizing on FAI to build our images. If you want the
Debian Oracle image to become official, it will have to use that.
I took a quick look at FAI a few weeks back, but the dependency on
DHCP/tftp made it more than a little complicated to run in our cloud
environment (where we've been traditionally building images). As the
requirement is to build in your infrastructure, I guess that isn't an
issue :) I'll grab a look, after the Christmas break, at setting up a
simple VirtualBox environment and see what's what.
OCI supports
on-demand bare metal instances (no hypervisor), with root drive mounted
from iSCSI, which requires a slightly different image build.
Could you describe what changes are involved? To my experience, booting
an image via network only means providing a few parameters to the
kernel, and having the correct drivers loaded on the ramdisk. That's not
much to ask.
Have you tried some of the already existing images that Debian provides?
Does Oracle provide a metadata service compatible with cloud-init?
Off the top of my head, the changes for distributions so far are pretty
straightforward:
* UEFI
* a few iscsid configuration parameter changes (a few tweaks we've
found improve reliability and performance)
* specific firewall configuration (iscsi root without CHAP would
enable anyone to modify iSCSI drives, so we lock it down via iptables)
* NTP config (we're looking to get details in to metadata shortly, so
may not be necessary)
Preferably we support qcow2 for imports, or vmdk with limitations. In
theory the import process will work with anything qemu-img supports.
There's nothing too onerous in there. We're starting to offer our own
instance agent for emitting metrics, which we're just in the process of
open sourcing. We've been installing this direct via RPMs (and soon via
snaps for Ubuntu), but we can certainly look in to getting it in to the
debian repositories.
We do support cloud-init, configured for the openstack provider.
Upstream cloud-init now supports an oracle datasource, but it's not
critical to use that.
Do you take the same approach Canonical takes with Ubuntu (and a few
other distros do) and rely on grow-fs to expand and fill whatever size
boot volume is provided?
I've tried the official openstack image, but I'm having a little
difficulty getting it to boot. I haven't spent much time investigating
there. At first blush it looks like lack of UEFI (maybe there is an
alternate image that already supports UEFI?).
Paul
