Re: Oracle Cloud Infrastructure
On 12/29/18 3:06 PM, Paul Graydon wrote:
> Based on comments in that debian-cloud-images repository, it looks like
> you're favouring Chrony these days instead of NTP, which is good with
> me, particularly from a security perspective.
I forgot about this, but I believe you're right, indeed.
> I may be misunderstanding your comment, but so far as runtime vs
> baked-in, we've been attempting to make everything as secure as possible
> from the get-go, and assume that customers ignore any good practices or
> suggestions we document. Given the security risk of the iSCSI endpoint,
> we don't want to be taking risks there.
It looks like I'm missing exactly what you're doing. Could you please
explain what you're doing with iSCSI exactly? Maybe some configuration
example, etc. I have to admit I don't know much about it, apart from
having configured Cinder and let the magic happen with tgtd... :)
> Putting it in via cloud-init
> isn't entirely straightforward, and then introduces the possibility of
> unintentionally nuking what customers have done to an instance before
> taking a custom image, that they then use to provision other instances.
>
>>> 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.
>
> It's not all that much different from Google's instance agent that comes
> installed on their instances.
Or the Microsoft's agent as well. I well know that popular cloud
provider tends to love adding an agent within the instance. That doesn't
make it a good practice. If it can be avoided, IMO that's best. That's
exactly the type of "feature" which, as a customer, would make me avoid
your public cloud (and GCE & Azure). But anyway, I'm digressing,
especially that I really don't need any public cloud access (I have
plenty of that kind of things running under OpenStack)... :)
> [...] With the images we produce, we've
> been definitely trying to avoid doing anything beyond the default as
> much as possible. From a pragmatic perspective, Oracle's primary
> customers are enterprise ones that tend to expect things to "just work",
> correctly, straight out of the box. They don't want to be configuring
> NTP/chrony themselves, they don't want to be installing instance agents
> etc.
Of course!
> With bare metal instances in the picture, and being a particular desire
> for our customers, we can't just take hypervisor metrics, like Amazon
> does, yet we need to also provide auto-scaling and similar services that
> rely on metrics being emitted. Putting an instance agent on the box
> gives the customers the power and control to make their own decisions.
> Being installed via normal package mechanisms, if they don't want it,
> it's an easy uninstall.
Ok, it makes sense, however, there are many non-intrusive ways to do get
metrics for auto-scaling use. Often, the best metrics are at the
application level btw (like for example, the number of Apache
processes...), so in this type of case, a generic agent isn't very
useful. If you get an external load balancer managed by your infra (is
there an equivalent to Octavia in your cloud?), you also get the metrics
you need externally. Anyway, again digressing... :)
> We do provide a launch options via the API (and in the web console) that
> allow customers to enable or disable features in the instance agent,
> with the configuration spit out via a metadata endpoint that the agent
> checks on start-up.
>
> In reference to "runtime" configuration above, and in keeping with "do
> as little as possible", part of the intent with the instance agent is to
> have the agent become responsible for initial run-time configuration for
> features outside of cloud-init.
The very point of cloud-init is to gather all the features cloud
providers need, so that we get a single tool to manage them all. So the
correct course of action would have been to contribute to cloud-init,
rather than implement things outside of it. Why didn't Oracle take that
path and decided it was best to do things outside of cloud-init?
>>> 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.
>
> Thanks for the heads up. I've pointed co-workers towards the
> maintainers documentation,
> https://www.debian.org/doc/manuals/maint-guide/, that seems to be the
> right place to start getting to grips with the process. We'll get
> working on it.
If you have a source package to be reviewed, please give the link to the
.dsc file, so we (or even, *I*) can review the package, and sponsor the
upload to Debian if it is in good enough shape. Then you'll get to
maintain the package directly in Debian until ... well, forever! :)
> Would it be acceptable to be installing the instance-agent as a deb
> package via cloud-init, on start-up?
Since you are controlling what the metadata server pushes to your
instance via cloud-init, I guess you could do whatever you want. Though
I'm guessing that this isn't what you're asking.
If your question is:
- can I do: "curl $foo | bash" at startup and hardwire it in rc.local
then my answer would be: of course not! Please do things properly, have
your agent packaged and uploaded to Debian. We have a bit more than a
month to have this happen if you don't want to miss Buster.
>
>> 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)
>
> I see various references to grub-efi in the debian-cloud-images
> repository, I'll try spinning up some other images and see what I get.
You got to understand that the current official OpenStack images for
Debian aren't based on what you've seen in "debian-cloud-images". They
were produced using:
https://packages.debian.org/openstack-debian-images
which I wrote, and which is a monolithic shell script. These images
don't have the EFI support. The ones produced by our new FAI based
script do.
> I'd like to make sure we're singing from the same hymn sheet. What's the
> route forwards? Do we do the work and provide patches for review, do we
> need to be contracting with the Debian group to get the work done, or is
> the route forwards something else entirely?
IMO, the route forward is:
1/ Get your instance agent packaged, and give me (or someone else) the
link to the source package for review. Probably best would even be if
the packaging was done in Salsa as a new repository here:
https://salsa.debian.org/cloud-team/
(or in another group, but there is fine...)
2/ Get patches done to debian-cloud-images so it produces an Oracle image.
3/ Get Steve McIntire (aka: Sledge) to also publish your image in our
web site.
4/ Ultimately, get in touch with SPI once all of the above is done, so
that you can give a login / pass to Oracle, so that when we produce a
new Debian image (maybe because of a point release, or a security
update) then it gets uploaded automatically in your could. We can deal
with that last part later.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
Reply to: