I am trying to collect and learn about the things that mostly {piss you off,itch} on Foreman.

It could be little things like a misplaced button or big things. Anything.

So let's start a thread of what are the things that mostly piss you off in Foreman.

Here are my contributions to the thread:

* We need to add "compute resource" select to hostgroup, so when I create new host(s) I do not have to select a compute resource each time.

* Associating provisioning templates to an operating system is complicated and can be simplified

Now: it's your turn :)

Thanks !

+1

* New host form should be an extensible wizard with less javascript and real persistence (user can return to any started host creation)


--

I find myself manually typing the URL (eg, /hosts/blah.boo.com) when I need to quickly browse to a specific host, because clicking the 'All Hosts' button takes too long with a lot of hosts.

I also think that we somehow need to figure out how to speed up VMWare host creation/manipulation.  With a large-ish vSphere environment, it can take minutes to 'Edit' a host or to create a host (having to wait for the 'Interfaces' tab to be ready, etc).

Mostly, I love Foreman, though.  :)

[1] http://projects.theforeman.org/issues/3573

Full width tables too.  With perhaps an alternative style that can be selected by a user with smaller font, less padding inside cells and smaller cells (tables can appear wasteful on screen space depending on what you're trying to see).

The ability to deploy all the subcomponents of Foreman/Katello in an HA configuration in containers in an OpenShift-style environment would be great, but I don't suppose that's quite an itch yet.

cheers

- Parameters which can be defined as types - hash, array, boolean etc.

- Expose the version of a content view as a parameter

- Matchers which can match against types (so check if a string is IN an array - when you have structured facts for example)

- Allow structured facts to be searchable with regards to their type (subtly related to the above)

- Allow default values for puppet parameters to be set where parameters can (for example, locations etc) (this would save on having a matcher which says if location = <location> <value> or obfuscating this into the puppet parameter with something like <%= YAML.load(@host.params['<name>']) %>

- Add provisioning templates etc to the promotion / publish process. This way if we have a lifecycle of ENG -> TEST -> PROD we can test new partition tables, kickstart templates, snippets etc in the ENG environment without impacting other environments.

- A concerted effort to fix all the bugs as opposed to adding new features!

And:

The API! 

- Unify and standardise the foreman and katello API's (same arguments, same return)

- Fix the Content Upload API!

- Allow packages to be managed / copied / moved between repositories.

Is it what you are looking for?

Thanks for bringing this up.

My main concern currently is stability. .0 releases are usually broken to some extend. I think, we should come up with better integration testing before a release. E.g. try to deploy a host with all available compute resources automatically before a release. Our main goal should be to improve stability.

Foreman is great if you stick to simple use cases. I believe, there are some sophisticated use cases (yet quite common in an Enterprise environment), that should be addressed. We should come up with some supported use cased and implement them (and eventually test them before each release).

Feature-wise, what I really miss:

* Bare Metal Bonding Support (RM #9487)

Just as an example, what I mean by supported use cases:

If you use bare metal provisioning, you'll most definitely look into the discovery plugin. And you'll most definitely also want to use some kind of network bonding for redundancy. So you have your servers connected to the same VLAN on multiple interfaces.

After the server is racked, it should boot the discovery image and show up in Foreman's list of recently discovered hosts. It does detect the bonding via lldp but does not automatically configure it.

When you configure the bond manually, you fail because you don't know the mac address of the bonded interface and tftp / dhcp is not provisioned (partially fixed in RM #17485). Then there is the case, that the os installs correctly on the first bonded interface and the discovery process starts again on the second bonded interface. A horrible experience to sum up. Should be better on an enterprise grade software. Will be better with 1.15. Any help or comments are appreciated.

* Permissions

I think, the permissions system lacks the ability to specify a permission like this: Allow a user to view a subnet, but don't allow a user to create a host in that subnet.

* Default Owner of Hosts (RM #14013)

The default owner of hosts should be configurable. The default user might be a group where the user is a member of.

* Linking of Compute Resources VLANs to Subnet (RM #10539)

Foreman should know more about the Network of a Compute Resource. The subnet should be linked to VLANs on the Compute Resource. That would prevent a lot of errors when manually deploying a VM.

* Bulk Actions for Environments, Hostgroups

Environments and Hostgroups need bulk actions via the UI. Would save a lot of clicks / foreman console sessions.

Timo

Hi,

my wishlist:

* Handling OS for provisioning is still complicated: What I mean in detail is every OS is listed also if not prepared for provisioning because every minor release is autocreated when an updated system shows up in a puppet run. Listing only the prepared once and/or add templates, media and so on when autocreate another minor release would make handling easier.

* Katello adds to much complexity: As others mentioned Katello, I think its to complex by default. Not everyone needs multitenancy, docker, ... when he needs content staging. Having this things as separate plugins would be more helpful.

* Having to use IDs in API/CLI instead of names

* Redmine vs. Github: Having same issue in both trackers or having the feeling of added the bug to the wrong tracker is unsatisfactory

* Long-standing bugs/feature request: As for all software seeing bugs many years old makes me sad, sometimes reviewing and closing as wont fix would be more honest

And my +1 list:

* A huge +1 for stability as updating the training material always ends in creating to many bugs.

* Ability to add a new Lifecycle stage to the middle of a Lifecycle Path.
 

 
But with all the negative things mentioned I have to say Foreman is one of my favorite tools and developers do a great job. This is why I care about these details.

Regards,
 Dirk

All of my servers are deployed using composite CVs. All non composite CVs are single purpose for flexibility within the Composite CVs. It would be handy to be able to visually separate them without resorting to naming conventions.

cheers

L.

- better support for alternative container technologies like LXD. This would provide a lightweight alternative to "full" VMs while retaining Foreman as a spawning/management center.