Document URL: Fixes for broken GCE will be available in satellite 6.6. So needs to update details about it in documentation. Section Number and Name: Describe the issue: Suggestions for improvement: Additional information:
Upstream Documentation link for reference - https://theforeman.org/manuals/nightly/index.html#5.2.4GoogleComputeEngineNotes
The related upstream bug with info to be added to docs: https://projects.theforeman.org/issues/27419 The community demo from 2013: https://www.youtube.com/watch?time_continue=20&v=6B4F563l-E0
Hello Sergei, Thank you for providing GCE documentation. I am having few points after reading the documentation: >> 12.1. Prerequisites for GCE Provisioning >> 5. A Capsule Server managing a network on the GCE environment. Ensure no other DHCP services run on this network to avoid conflicts with the Capsule Server. For more information, see Chapter 4, Configuring Networking. Satellite doesn't support network management for GCE. Whatever networks details it gets from GCE, it shows list of networks under "Virtual Machine TAB" on host form. Instead of above point can we just add - "Make sure that your satellite and GCE VMs can communicate with each other for further configurations." >> 12.2. Adding a GCE Connection to Satellite Server >> 1. In GCE, generate service account key in JSON format and upload this file to the /usr/share/foreman/ directory on Satellite Server. >> 2. On Satellite Server, configure permissions for the service account key: >> # chown foreman /usr/share/foreman/gce_key.json >> # chmod 0600 /usr/share/foreman/gce_key.json >> # restorecon -vv /usr/share/foreman/gce_key.json Addition to this, would it be possible to add note saying - "Please ensure this key file is readable by your Satellite." >> 12.3. Adding GCE Images to Satellite Server >> 9. Optional: Select the User data check box if you want the image to support user data input, such as cloud-init data. Using this flag, User can use cloud-init inputs with the help of templates. But it will work properly when that image includes cloud-init package or through template user have to setup cloud-init first on provisioned machine so we will need to modify above statement to clarify this. "If selected image supports cloud-init then Select the User data check box to support user data input (such as cloud-init data)." Please let me know your views.
Hi Kavita, thank you for your comments. I have a question about your comment#2. (In reply to Kavita from comment #6) > >> 12.1. Prerequisites for GCE Provisioning > >> 5. A Capsule Server managing a network on the GCE environment. Ensure no other DHCP services run on this network to avoid conflicts with the Capsule Server. For more information, see Chapter 4, Configuring Networking. > > Satellite doesn't support network management for GCE. Whatever networks > details it gets from GCE, it shows list of networks under "Virtual Machine > TAB" on host form. > > Instead of above point can we just add - "Make sure that your satellite and > GCE VMs can communicate with each other for further configurations." Will do > > >> 12.2. Adding a GCE Connection to Satellite Server > >> 1. In GCE, generate service account key in JSON format and upload this file to the /usr/share/foreman/ directory on Satellite Server. > > >> 2. On Satellite Server, configure permissions for the service account key: > >> # chown foreman /usr/share/foreman/gce_key.json > >> # chmod 0600 /usr/share/foreman/gce_key.json > >> # restorecon -vv /usr/share/foreman/gce_key.json > > Addition to this, would it be possible to add note saying - "Please ensure > this key file is readable by your Satellite." I would like to give direct instruction here. How to ensure the file is readable? These 3 commands ensure that, do not they? > > >> 12.3. Adding GCE Images to Satellite Server > >> 9. Optional: Select the User data check box if you want the image to support user data input, such as cloud-init data. > > Using this flag, User can use cloud-init inputs with the help of templates. > But it will work properly when that image includes cloud-init package or > through template user have to setup cloud-init first on provisioned machine > so we will need to modify above statement to clarify this. > > "If selected image supports cloud-init then Select the User data check box > to support user data input (such as cloud-init data)." Perfect correction. This bit was unclear to me. WIll do. Thank you
(In reply to Sergei Petrosian from comment #7) > I would like to give direct instruction here. How to ensure the file is > readable? These 3 commands ensure that, do not they? Yeah. These 3 commands will ensure that. I mentioned it because if in case any external factor as part of infrastructure not allowing it then customer will take care of it. I couldn't imagine any real time situation right now so we can skip this point.
(In reply to Kavita from comment #8) > Yeah. These 3 commands will ensure that. > I mentioned it because if in case any external factor as part of > infrastructure not allowing it then customer will take care of it. > I couldn't imagine any real time situation right now so we can skip this > point. Thank you, Kavita. I will change the step to the following to ensure it is clear why we are changing permissions: . On Satellite Server, configure permissions for the service account key to ensure that the file is readable by the `foreman` user: ---- # chown foreman /usr/share/foreman/_gce_key_.json # chmod 0600 /usr/share/foreman/_gce_key_.json # restorecon -vv /usr/share/foreman/_gce_key_.json ----
Hello Sergie, As per Googles official document [1] and line [2] in that doc, "When the customer has enable-oslogin metadata set to TRUE in their GCE project, GCE disables the metadata-based SSH Key. And hence foreman won't be able to create new user in provisioned VM. The result of not creating a user is that the customer will never see 'Installed' status on UI for their provisioned host. and in fact that's not the complete provisioning" So to avoid this, advice customer to set enable-oslogin metadata to FALSE. [1] : https://cloud.google.com/compute/docs/instances/managing-instance-access [2] : Caution: Enabling OS Login on instances disables metadata-based SSH key configurations on those instances. Disabling OS Login restores SSH keys that you have configured in project or instance metadata.
These changes are live on master and on 6.6-beta and ready to be published.