Re: Oracle Cloud Infrastructure
On 12/26/18 3:19 PM, Paul Graydon wrote:
> On 12/24/18 04:34, Thomas Goirand wrote:
>> On 12/23/18 6:17 PM, Paul Graydon wrote:
>>> 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.
You probably want to try "debian-cloud-images" from Sid, which has the
necessary depends. Simply run "debian-cloud-images" as root to build.
The git repo for it is here:
https://salsa.debian.org/cloud-team/debian-cloud-images
>>> 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)
All of the above seems to either already be there (ie: UEFI), possible
to contribute (specific iscsid configuration enhancement), or needed to
be executed at runtime (firewall config IMO shouldn't be part of the
standard image, neither NTP).
> Preferably we support qcow2 for imports, or vmdk with limitations. In
> theory the import process will work with anything qemu-img supports.
Qcow2 is of course possible, as that's the preferred format for
OpenStack as well (well, with Ceph you may prefer raw, but I'm
digressing...), as you may know.
> 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.
It's IMO best if there's no intrusive agent in an image.
> 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.
If it is mandatory to have one, then it *must* be in Debian. Buster is
soon frozen, so you don't have time to loose here. It would not be
acceptable to push Snaps in the official Debian image.
> 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.
Then we probably can add the Oracle cloud data source in the long chain
of supported data sources! :)
> 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?
Yes. Cloud-init does that, in fact.
> 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?).
There's indeed no UEFI support in the image, even though the tool that
creates the image could do it. The problem was, at the time, that we had
no way to produce an image with Grub working with both UEFI and regular
BIOS. My understanding is that "grub-cloud", produced by Waldi (Bastian
in this list) fixes the issue. Though of course, that's not yet
available in Stretch, and we hope to fix this for Buster.
Cheers,
Thomas Goirand (zigo)
Reply to: