Re: Oracle Cloud Infrastructure introduction
Hi Paul,
Noah has well replied already, but just saying it to, to avoid confusion.
On 10/27/20 8:00 PM, Paul Graydon wrote:
> On 10/27/20 10:06 AM, Noah Meyerhans wrote:
>> On Tue, Oct 27, 2020 at 09:58:05AM -0700, Paul Graydon wrote:
>>>> If you are considering installations directly from the Deb package, how
>>>> do you consider the client software update procedure when the virtual
>>>> machine has been running for a while? Snapd has a built-in mechanism
>>>> for
>>>> installing and distributing updates.
>>> That's a good call out. We have a self-updating mechanism built in
>>> to the
>>> RPM variant of the agent, and the core logic of it was built
>>> sufficiently
>>> generically that we should be able to adapt it to handle DEB
>>> packages, if
>>> that's the route we end up going here.
>> Is this agent required? In other words, is it reasonable to run a VM
>> instance that doesn't have it installed?
> I think I would settle on "strongly preferable", especially if it ends
> up being a platform image. You can run instances without the agent on
> our platform, no problem. You just won't get metrics, won't be able to
> leverage auto-scaling.
>> Debian's cloud images specifically do not include software from outside
>> of Debian's package archive. If we're going to provide pre-built images
>> via our own infrastructure, then this agent would need to be packaged
>> for Debian and included in the main archive.
>>
>> If you want to build derivitive images that are based on our
>> configuration and associated tooling but have additional software
>> installed, you are free to use our tooling and configuration as a
>> starting point. This is, for example, how Google builds the images for
>> GCE. This allows them to add their own additional apt repositories and
>> software that is distributed outside the Debian archive.
>
> Okay, that sounds like a reasonable route forwards here.
I would *strongly* advise for open sourcing your agent and package it in
Debian. That's the best way possible, IMO. We can help get your agent in
the Debian repo if you need help (I'm hereby volunteering for package
review and upload sponsoring).
On 10/27/20 9:33 PM, Ross Vandegrift wrote:
> We've mentioned the first restriction: only components from Debian
> main can be included. It's not just that you can't replace packaged
> software, it's that all software must be packaged.
As Ross wrote, adding a component outside of the Debian archive, even if
that's your agent, would make the image "non-official". That's a route
you can take, but I wouldn't advise it.
> Are there any
> restrictions around what we can/cannot do, while retaining the Debian
> branding, as it were? For example, with the CentOS images (that we
> build and publish), there are some tight restrictions around what we
> install in the images. The main obvious thing there that I'd imagine
> applies with Debian too, is no installation of packages of a different
> version for that that is packaged and shipped by them in their
> repository (so no replacing the kernel, systemd, etc. etc.), at least
> not while still referring to it as "CentOS".
If you're modifying components that are in Debian, then the image cannot
be called "official Debian".
On 10/29/20 12:58 AM, Paul Graydon wrote:
> We could build and distribute Debian images ourselves, but Official
> ones would be ones that you publish?
Yes, and built within our infrastructure.
If your system is using the s3 API, I believe there's some s3 clients in
Debian already (s4cmd, for example), so publishing shouldn't be a problem.
Cheers,
Thomas Goirand (zigo)
Reply to: