Bug 1926331
Summary: | systemd presets request - google-guest-agent.service google-startup-scripts.service google-shutdown-scripts.service | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | ericedens <ericedens> |
Component: | fedora-release | Assignee: | Mohan Boddu <mboddu> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 34 | CC: | dennis, jkeating, kellin, kevin, mboddu, ngompa13, pbrobinson, sgallagh, thrcka, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-03-05 18:55:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1925322 |
Description
ericedens
2021-02-08 16:30:56 UTC
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 |