* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? - No modifications are required after installation to be useful. * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? - The services don't listen on external network sockets. * Is the service non-persistent (i.e. run once at startup and exit)? - google-guest-agent.service: Persistent with restart - https://github.com/GoogleCloudPlatform/guest-agent/blob/master/google-guest-agent.service - google-startup-scripts.service: Runs once at startup - https://github.com/GoogleCloudPlatform/guest-agent/blob/master/google-startup-scripts.service - google-shutdown-scripts.service: Runs once at startup - https://github.com/GoogleCloudPlatform/guest-agent/blob/master/google-shutdown-scripts.service * What is the exact name (or names) of the systemd unit files to be enabled? google-guest-agent.service google-startup-scripts.service google-shutdown-scripts.service * Is this request for all Fedora deliverables or only for some Editions (list them)? All deliverables.
Please include for F33 and F34. Thanks!
Is Google Cloud guest agent packaged in Fedora? I cannot find it. Do these services gracefully exit (without being marked as failed) in the event that they are not being started on a Google Cloud instance? Also, please review https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_hardware_support_services
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
> Is Google Cloud guest agent packaged in Fedora? It's under review here: Bug 1925322 > Do these services gracefully exit (without being marked as failed) in the event that they are not being started on a Google Cloud instance? If started on an instance that is not running on Google Cloud, the services will continue running and wait for the metadata server [1] to become available. (They will not exit with an error.) 1. https://cloud.google.com/compute/docs/storing-retrieving-metadata
(In reply to ericedens from comment #4) > If started on an instance that is not running on Google Cloud, the services > will continue running and wait for the metadata server [1] to become > available. (They will not exit with an error.) > > 1. https://cloud.google.com/compute/docs/storing-retrieving-metadata So the service will attempt to communicate with a service on the network, originating from the guest machine and receiving configuration from that remote source?
> So the service will attempt to communicate with a service on the network, originating from the guest machine and receiving configuration from that remote source? That's right. (It doesn't open a socket to receive the configuration)
Anything else that we need? Or is it a matter of waiting for bug 1925322 to finish?
I opened a ticket for a FESCo vote: https://pagure.io/fesco/issue/2578
(In reply to ericedens from comment #6) > > So the service will attempt to communicate with a service on the network, originating from the guest machine and receiving configuration from that remote source? > > That's right. (It doesn't open a socket to receive the configuration) What's the reason why it persistently stays open like this if it can't get configuration? My understanding is that usually these things quit if they can't get metadata information. Also, why does it work this way as opposed to receiving metadata via an extra device or something (like how cloud-init or ignition do)?
Good questions! > why does it work this way as opposed to receiving metadata via an extra device or something (like how cloud-init or ignition do)? Some providers use special devices to expose metadata. A downside of this approach: The instance is functionally locked to the provider's environment. Consider network configuration: If the VM boots outside of the provider's environment, then its agent will be unable to find the device, and the network will be unavailable. In contrast, on Google Compute Engine, VMs boot with KVM, and the network configuration is managed by DHCP. If the guest agent is installed, the instance will receive enhancements and features. If the machine boots outside GCE, it's still functional (it will just lack the features provided by the agent). > What's the reason why it persistently stays open like this if it can't get configuration? It's a design decision that's intended to increase reliability. That said, I'm not familiar with other agents regarding their behavior.
Hi! I see the FESCo vote passed; anything else we need? https://pagure.io/fesco/issue/2578
(In reply to ericedens from comment #11) > Hi! I see the FESCo vote passed; anything else we need? > > https://pagure.io/fesco/issue/2578 https://src.fedoraproject.org/rpms/fedora-release/pull-request/174 https://src.fedoraproject.org/rpms/fedora-release/pull-request/175
preset files merged; thanks for your help! - https://src.fedoraproject.org/rpms/fedora-release/pull-request/174 - https://src.fedoraproject.org/rpms/fedora-release/pull-request/175 - https://src.fedoraproject.org/rpms/fedora-release/pull-request/176