> Host is provisioned successfully. Next, try to re-register the host using the Global registration template.

Why do you re-register managed host provisioned from Satellite?

(In reply to Leos Stejskal from comment #3)
> > Host is provisioned successfully. Next, try to re-register the host using the Global registration template.
> 
> Why do you re-register managed host provisioned from Satellite?

Why should we not do that? What is the goal to build a host when it is re-registered to its satellite? The users can do build host from the UI when they want that. We are using Ansible to migrate hosts from one "old" satellite to the new one. Maybe one of us or another customer re-registers a host to its satellite mistakenly, should this host loss all its data through this mandatory and automatically build?

> Why should we not do that?

Because registration is not for hosts that are managed and provisioned from the Satellite.
(IMO we should clearly state that in the docs).

Managed hosts are created by Satellite, why register them again?

Hosts provisioned from Satellite have their own registration methods,
for RHEL 9 it's the rhsm command [0], for RHEL 6,7,8 it's the subscription manager [1]

[0] https://github.com/theforeman/foreman/blob/develop/app/views/unattended/provisioning_templates/snippet/kickstart_rhsm.erb#L26
[1] https://github.com/theforeman/foreman/blob/develop/app/views/unattended/provisioning_templates/snippet/redhat_register.erb

But doesn't this also happen when you just try to register a (non managed, not Satellite provisioned) VM to a Hostgroup that has provisioning enabled (= a CR is set)?

> But doesn't this also happen when you just try to register a (non managed, not Satellite provisioned) VM to a Hostgroup that has provisioning enabled (= a CR is set)

Yes, when we are updating the registered host in DB (setting host parameters) we update the build status,
which for managed hosts means the behavior described in the BZ.

[0] https://github.com/theforeman/foreman/blob/develop/app/controllers/api/v2/registration_controller.rb#L95

From my perspective this is correct behavior and global registration should not be used for registering managed hosts.

When the global registration should not register a manged hosts, why you enable this?

Why do you let the global registration template register hosts, which are manged from the Satellite? I do not think that this practical.

> Why do you let the global registration template register hosts, which are managed from the Satellite? I do not think that this is practical.

Well, it was never intended for this use case, the same way as we didn't block registering managed hosts in bootsrap.py or katello-ca-consumer.rpm*.
If you want to have this kind of check, please raise an RFE, otherwise I suggest closing this BZ as not a bug.

---
* AFAIK there wasn't any check for managed hosts, but maybe it changed.

> Well, it was never intended for this use case, the same way as we didn't block registering managed hosts in bootsrap.py or katello-ca-consumer.rpm*.

That's why bootstrap.py explicitly passes `build=false` so that the host is not getting rebuilt.

BTW, GR also sets `build=false` for non-Katello scenarios, just not for Katello/Satellite ones. Why the difference?

@Leos Stejskal , I would like to add the below scenario to the BZ too,

Re-registering the host using Global Registration Template automatically runs Ansible roles associated with the host, the Ansible roles are triggered in the same manner as it happens after deploying a system using a satellite and there is no way to skip this.


Moreover while troubleshooting subscription / yum  related issues, we suggest customer to re-register the host to the satellite and most of the customer now uses GR to register the host and if for some reason the host remains in the pending installation state and the server got rebooted, the client will lose all the data, so I would suggest reconsidering this as a bug.

> BTW, GR also sets `build=false` for non-Katello scenarios, just not for Katello/Satellite ones. Why the difference?

AFAIK there shouldn't be a difference, need to investigate

> Re-registering the host using Global Registration Template automatically runs Ansible roles associated with the host, the Ansible roles are triggered in the same manner as it happens after deploying a system using a satellite and there is no way to skip this.

Agree that this can be a problem

> Moreover while troubleshooting subscription / yum  related issues, we suggest customer to re-register the host to the satellite and most of the customer now uses GR to register the host and if for some reason the host remains in the pending installation state and the server got rebooted, the client will lose all the data, so I would suggest reconsidering this as a bug.

I will do the investigation, if it's a valid use case for our CUs then we need to handle it.

Hi,
can you try this patch to check the fix: https://patch-diff.githubusercontent.com/raw/theforeman/foreman/pull/9746.patch

Upstream bug assigned to ekohlvan

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/36393 has been resolved.

Verified.

Tested on Satellite 6.14.0 Snap 12.0

Steps followed: 
1. Provision a host from the satellite on VMware
2. After successfully provisioned, re-register the host using the Global registration.

Observation: 
The host was provisioned successfully. 
After re-registering, the host build status remained `Installed`.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6818