RFC: Adding host's creator field

Hi everyone,

I’m working on a new feature for updating the message on the new host’s details UI, to display the host’s creator instead of the host’s owner, as described in this PR.

We discussed whether we should send the host’s creator details as a hash, or as two separate fields: one for the creator_id, and one for the creator_name.

Right now we are sending other fields (like the host’s owner details) as separate fields, but maybe we should consider sending them as a hash, instead of a string, for a more generic implementation.

We are suggesting the following options:

  1. Remain consistent and add send the host’s creator details as separate fields (creator_id and creator_name).

  2. Sending the host’s creator details as a hash as described in this comment.

  3. Do both: send the fields as a hash and also as two separate fields.

I would be happy to hear your opinions about it, and any suggestions are welcome!

1 Like

@evgeni perhaps you could weigh in on the foreman-ansible-modules side.

1 Like

Thanks for pinging me.

If I understand it correctly, “creator” is a field that won’t be changeable, it’s just set at the creation of the host to the id of the user and that’s it. This is also a differentiation to the “owner” (and “owner_group”) which can really be changed.

In that case, from a Ansible PoV, I don’t care. I never have to set this field (so also never have to check if it has the correct value) and thus it would be ignored, regardless if it’s a Hash with multiple entries or multiple separate entries.

Now, if you’d want to apply the same logic to Owner etc, it might get different, as those are actually fields I care about from Ansible and want to be able to manage them, and then separate ones are easier.

Hi everyone,

just chiming in for a user perspective. I have no opinion on how the data is sent since I’m not a dev, but from a user perspective I have concerns about the field potentially being not-changeable (as implied by evgeni and also some comments in the PR). When deleting users (because someone left the team/company or sth like that) we already have to move every system owned by that user to another user or else we cannot delete the user. Having this problem on a immutable field would be a nightmare, because it would mean you can never delete users who have created a host.
I just want to double-check this concern is addressed in the final design.
Regards

Yeah, both of them should be null-able and automatically be nulled when the User is deleted.

1 Like

The field should be immutable from a user perspective and the current PR sets the ID to null on user deletion. That means many hosts will be NULL (especially since there’s no migration to derive the creator from audits so any historical machines won’t have a creator set.

1 Like

It looks like it doesn’t matter if the new fields for the host’s creator are being sent as a hash or as separate fields, as long as it is set to null on user deletion.

For that reason and also since it is easier to send the host’s owner fields as separate ones, I think it is better we keep it that way and send the host’s creator fields the same way for a more consistent code.

Regarding what @ekohl mentioned about not having a migration to derive the creator from audits, the reasons for that are:

  1. We don’t save all audits (they are deleted after a period of time).
  2. I’m not sure if we would want to run this migration, in case we have a large number of hosts.
2 Likes

Who is the creator of a host if it is registered through an activation key or added by the puppet module?

I guess, how useful this is depends if you use provisioning a lot or not.

Personally, much more important to me would be an array value for the owner, so that I can set multiple owners/ownergroups on a host.

I think the creator will be the Admin User in case you register a host through an activation key or by the puppet module.
Regarding your suggestion for sending the owner as a hash, I think it is out of scope for this feature, but maybe we can achieve it in a future RFC.