You should be able to globally define fields at a top level. You could then, by browsing to the host's property/edit page modify values for these global custom fields.

Josh,

Check out https://github.com/isratrade/foreman_custom_parameters

I implemented "custom fields" as creating default host parameters by on a .yml file that you create. The advantage is that the parameters can be read by puppet and the UI doesn't need to change.

UI are changes are possible through an engine, but this is a first pass

Joseph,

Here are my thoughts on using parameters:

• The user interface for parameters is not very eloquent. The point of the custom fields (in my case), in addition to the inventory tracking/CMDB elements, is for "management types" to be able to login and quickly see relevant information about the host. For parameters, you have to click "Edit" then browse to a tab just to view the information. Parameters on this page also are not hyperlinked (although they can be searched using the search interface) which would allow for simple and quick searches (just like locations, organizations, etc on the host properties page).

• I think a better place to display these "custom fields" would be directly on the host properties page - where the other host properties are. Perhaps on an additional tab on this page to keep things organized.

• Also, we are able to utilize other properties such as location, host-group, owner, etc in our Puppet code since these properties are included in the ENC output. Can't the custom fields just be included in the ENC output like the other things?

Thanks!

Josh,

I submitted a PR for Foreman Core https://github.com/theforeman/foreman/pull/842
that adds a boolean field to HostParameter to "Show as Property". If selected, then the parameter shows on the Host Properties pages with a clickable search link
I think this will be good for "management types". Unless you have tons of parameters to show, I think it's best to show as under the properties tab rather than a new tab. Next to Properties | Metrics | Templates, there are two hidden tabs VM | BMC. If there are shown, there is no room for another tab.

The engine https://github.com/isratrade/foreman_custom_parameters can still be used to create default host parameters upon host creation, but this is totally independent from the PR/842

Joseph

I still question if this feature should be implemented using host parameters, or if it would be better suited to be implemented via a database schema modification and stored there as a separate entity.

If exposure to Puppet manifests is a concern, I'm curious as to how other non-parameter types such as "Location" and "Host-group" are exposed to the ENC which can then in turn be used in Puppet manifests and code.

Comments/feedback would be appreciated from anyone!

Also, I would like to say that I do believe the foreman_custom_paramaters functionality will be useful to many people to define default host parameters.

Yes, non-parameter types can be exposed to the ENC. Need to re-open the method managed#info from the engine and then modify it to pull in new fields custom associated with a host. I am trying to leverage the existing code as I don't fully understand the value-add of creating a new database migration, modifying the UI, modifying the Yaml dump, and modifying the search host functionality, just to show same custom data attributes on the hosts#show page for "management types". I think the current PR implementation with HostParameters provides what you need unless I'm missing something.

Two areas of discussion:
1) UI requirements regardless of backend implementation - is showing the new fields under properties sufficient? search functionality based on custom field is out of the box with parameters (but not with new custom db fields). what other UI requirements?
2) backend implementation regardless of UI implementation - is it important to create a new db migration to store the custom fields? do the custom fields need to be exposed to ENC? do custom fields need to be accessible by API?

Speaking strictly as a user here:

• I do believe that putting these "custom fields" on the host properties page is sufficient. If it is decided that this implementation will NOT continue to use host parameters, then the UI should also include an area to define "custom fields" on a global level (ie, in More -> Configuration - > Custom Fields).

• I'm not sure it is a requirement to have the custom field data exposed to the ENC, although I suppose this would be a nice bonus.

With this being said, I don't know how much work would be involved in a DB migration, UI modifications, etc. I can only comment on what I would believe would be the best experience for the user based on comments from co-workers and others on IRC.

Josh,

I worked on the rake task this morning but ran into errors. I'm half-day PTO today, so I'll work on it on Sunday.

Joseph

I added the wrote rake task to update existing hosts. Just follow the instructions at https://github.com/isratrade/foreman_custom_parameters