[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: agents inside VMs (was: Oracle Cloud Infrastructure)



On 12/30/18 12:26 AM, Theodore Y. Ts'o wrote:
> I can understand how adding features via a cloud-specific agent is not
> viewed as particularly exciting for someone who wants to use VM's
> across multiple providers.

That's not the unique problem.

I've heard people from Google and Azure both complaining that they want
their agent to move fast, and they don't like the typical life cycle of
Debian stable, which prevents them from updating the agent often.

> Unfortunately, if the VM is starting with a common fixed image which
> is used by all customers, there has to be some way to set up ssh keys
> that can be used to log in as root.

Usually, you don't login as root. In the case of Debian, the default
user is "debian", and this user has "sudo su" rights. The ssh public key
is written in /home/debian/.ssh/authorized_keys by cloud-init at boot
time. Cloud-init does that by contacting a metadata server (there are
other ways, like config drive, which also comes with its issues, but
that's out of scope of this thread).

> And if the model is that requests
> to resize disks or take snapshot of disks can originated external to
> the VM, then there needs to be some way to let the VM know that the
> disk has changed in size, or that the VM should call the FIFREEZE
> ioctl on a disk in preparation for a snapshot.

Isn't there is a way to send this to the kernel as a signal from the
hardware? If there's currently no way, then probably we should think
about it.

> There currently is a
> standardized way that will work across all OS's, and all cloud
> providers, so this sort of things gets done via agents.

I very much would like to see a common agent being invented and become a
standard. This could even be part of the kernel or something. With such
standard, it would be easier to audit the agent code, the same way I
very much prefer cloud-init over any other specific solution.

> The shortcoming with OpenStack is that you end up having to support
> the lowest common denominator of functionality.

I really don't understand this sentence, even less with your example.

Cheers,

Thomas Goirand (zigo)


Reply to: