Unable to inspect configuration of running google-guest-agent

[davidkrauser]

Filed in Ubuntu Bug #1901042 as well.

We have a cloud-images qualification test for the google-guest-agent to ensure the following daemons are enabled for GCE images:

• accounts_daemon
• clock_skew_daemon
• network_daemon

I could not find a way to inspect a currently running agent to determine the configuration in use. The agent only takes the following actions:

• run
• install
• remove
• start
• stop
• help

An additional action to list the configuration in use would be very helpful.

I also looked at the output of journalctl -u google-guest-agent.service, but the agent does not log configuration settings in the log, either.

[hopkiw]

It's actually a bit misleading even to say the agent supports those actions (run, install, remove, etc.). As far as our documentation states, we do not support invoking the guest agent in any way. Nor do we support any kind of introspection by users; the settings are always those that exist in the config file at run time.

[hopkiw]

As for your use case, you can no longer or should no longer ensure the three legacy daemons are enabled. You could check that they are configured to be enabled (or not configured to be disabled, as they are enabled by default). We no longer have 3 distinct daemons, but the legacy config options are still respected for the relevant functional areas.

[davidkrauser]

Hi @hopkiw,

Sorry, I didn't explain this well. The default Ubuntu images do not ship with a configuration for the Google guest agent, and we want to be able to ensure that new Ubuntu images still have expected functionality enabled and available. The attached PR allows us to parse the agent logs and verify that new Ubuntu images have all expected functionality enabled.

Additionally (from the perspective of an end user), there's no easy way to debug issues with configuration related to the guest agent. Especially if configuration from a file is misapplied (typo in the configuration file, bug in the code, bad distro patches, etc.). Having a way to observe the actual applied configuration of the agent at runtime would be very useful in this area :-)

Thanks,

David

[hopkiw]

Even if you don't provide a configuration file, the defaults will apply. We aren't going to add a feature that dumps the entire config to logs and serial console. You'll have to test the functionality itself, not reporting from the agent. Some of these features are also affected by metadata keys.

I don't disagree about the issue of a bad config file, but it hasn't been reported to us by customers as an issue and we have other plans for debugging stories related to the agent.

[davidkrauser]

Hi @hopkiw,

I think that I've come about this backwards - I've proposed a solution to help us fit the agent into our existing Ubuntu cloud image acceptance tests, but I should be asking how we can modify our acceptance tests to fit the new agent.

Our goal with these tests is to ensure that new Ubuntu images for GCP work reliably and effectively for GCP users. A big piece of that is ensuring that the guest agent is functioning as expected (even as other packages and configuration on the image change over time).

What is the best avenue for us to test the guest agent to meet this goal?

Thanks,

David

[hopkiw]

It's a big topic! I own all the tests that we run for the agent today, but they are currently run within Google infrastructure. Part of our plans for the next year is to move those tests to a publicly consumable test suite that others can rely on, copy or mimic. I would be glad to discuss how we do that testing, which is largely a set of end to end feature tests. Let's set up some meeting or email correspondence to discuss.