Hey all,
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
Customizable, resizeable, dragable, add/remove columns in table views.
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).
I also miss the freedom of Elastic searches rather than the replacement
scoped searches.
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.
I had so many other ideas about what that subject would mean in an email.
– bk
···
On 12/07/2016 07:08 AM, Shlomi Zadok wrote:
> Hey all,
> 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 !
>
>
>
I have said this forever, and I still believe that Foreman needs a 'quick
search' [1] function that allows you to easily browse/search for hosts, etc.
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).
···
On Wed, Dec 7, 2016 at 7:08 AM, Shlomi Zadok wrote:
Hey all,
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
Add ability to add config groups and parameters at the Host Collection level
Add ability to merge parameters that come from org/location/OS/host collection/host/etc,etc (like you can do with Class Parameters)
Performance improvements related to creating and promoting [Composite] Content View versions
Ability to go back to "normal" Foreman interface from the Dynflow console, or better integration (so that you can deal with failed tasks easier)
More consistency regarding version numbers (sometimes it is a string, sometimes it is an integer, why is the ".0" on there when that's never used, sorting in dropdown boxes like CV versions in Composite views, etc)
Add a parameter consumable by templates and Puppet for the FQDN of the capsule the host uses (similar to the puppetmaster parameter)
···
From: "Shlomi Zadok"
To: "Foreman users"
Sent: Wednesday, December 7, 2016 6:08:51 AM
Subject: [foreman-users] This thing itches me....
Hey all,
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
Host Collections that are dynamic (so if a parameter changes, a fact
changes or a hosts hostgroup etc changes the hosts are added / removed)
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:
>
>
> - Add ability to merge parameters that come from org/location/OS/host
> collection/host/etc,etc (like you can do with Class Parameters)
>
+1
> - Ability to go back to "normal" Foreman interface from the Dynflow
> console, or better integration (so that you can deal with failed tasks
> easier)
>
+1
···
On Wednesday, December 7, 2016 at 9:51:27 AM UTC-5, Jason B. Nance wrote:
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
···
Am Mittwoch, 7. Dezember 2016 13:08:52 UTC+1 schrieb Shlomi Zadok:
>
> Hey all,
> 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 !
>
>
>
>
>
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.
Add ability to add config groups and parameters at the Host Collection
level
Add ability to merge parameters that come from org/location/OS/host
collection/host/etc,etc (like you can do with Class Parameters)
Performance improvements related to creating and promoting [Composite]
Content View versions
Ability to go back to “normal” Foreman interface from the Dynflow
console, or better integration (so that you can deal with failed tasks
easier)
More consistency regarding version numbers (sometimes it is a string,
sometimes it is an integer, why is the “.0” on there when that’s never
used, sorting in dropdown boxes like CV versions in Composite views, etc)
Add a parameter consumable by templates and Puppet for the FQDN of the
capsule the host uses (similar to the puppetmaster parameter)
Hey all,
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
···
On Wednesday, December 7, 2016 at 2:56:51 PM UTC+2, Josh wrote:
>
> I have said this forever, and I still believe that Foreman needs a 'quick
> search' [1] function that allows you to easily browse/search for hosts, etc.
>
> 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
>
>
>
> On Wed, Dec 7, 2016 at 7:08 AM, Shlomi Zadok > wrote:
>
>> Hey all,
>> 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 !
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Foreman users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-user...@googlegroups.com .
>> To post to this group, send email to forema...@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/foreman-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>>
>> * 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.
>
>
> Won't hurt I guess, +1
>
>>
>> * Associating provisioning templates to an operating system is complicated
>> and can be simplified
>
>
> +1
>
> * New host form should be an extensible wizard with less javascript and real
> persistence (user can return to any started host creation)
I'm not against javascript but +1 for the persistence. That would
probably mean splitting the save and built process and postponing some
of the validations.
Adding one more:
Enable partial updates of 1:N and M:N relations in API
···
On Wed, Dec 7, 2016 at 1:18 PM, Lukas Zapletal wrote:
> On Wed, Dec 7, 2016 at 1:08 PM, Shlomi Zadok wrote:
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.
> * 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.
>
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.
Add ability to add config groups and parameters at the Host Collection level
Add ability to merge parameters that come from org/location/OS/host collection/host/etc,etc (like you can do with Class Parameters)
Performance improvements related to creating and promoting [Composite] Content View versions
Ability to go back to “normal” Foreman interface from the Dynflow console, or better integration (so that you can deal with failed tasks easier)
More consistency regarding version numbers (sometimes it is a string, sometimes it is an integer, why is the “.0” on there when that’s never used, sorting in dropdown boxes like CV versions in Composite views, etc)
Add a parameter consumable by templates and Puppet for the FQDN of the capsule the host uses (similar to the puppetmaster parameter)
Hey all,
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
We definitely need a hosts form that would be extensible (and not so easy
to break), so +1 from me. The wizard with persistence would really be a
nice touch.
Puppet smart class parameters and other config related parameters management like Content view:
The goal here is to manage multiple parameters changes as a transaction, for easy review and rollback
More integration with compute resources #10539, #10539, #10244, #5441…
Access compute resources via foreman proxies
Isolated foreman proxies #8172
Simple Errata import API (for CentOS errata management for example) #8656
Nested organizations in Katello #10789
I'm working on #10539 (PR 4095 and 4096) and on prerequisites for #5441 (rbovirt part was merged and there is a PR3936 open on the fog part)
Thanks for your work, foreman/katello devs, i've seen a lot of improvements since we started to use it few years ago, and i think the best is still to come
Regards.
···
----- Le 19 Déc 16, à 22:28, Dirk Götz a écrit :
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.
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.
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.
Add ability to add config groups and parameters at the Host Collection
level
Add ability to merge parameters that come from org/location/OS/host
collection/host/etc,etc (like you can do with Class Parameters)
Performance improvements related to creating and promoting [Composite]
Content View versions
Ability to go back to “normal” Foreman interface from the Dynflow
console, or better integration (so that you can deal with failed tasks
easier)
More consistency regarding version numbers (sometimes it is a string,
sometimes it is an integer, why is the “.0” on there when that’s never
used, sorting in dropdown boxes like CV versions in Composite views, etc)
Add a parameter consumable by templates and Puppet for the FQDN of the
capsule the host uses (similar to the puppetmaster parameter)
Hey all,
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
In the GUI, I would like to be able to group Content Views into Composite
Views and Non Composite views.
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.
···
------
The most dangerous phrase in the language is, "We've always done it this
way."
Puppet smart class parameters and other config related parameters
management like Content view:
The goal here is to manage multiple parameters changes as a transaction,
for easy review and rollback
More integration with compute resources #10539, #10539, #10244, #5441…
Access compute resources via foreman proxies
Isolated foreman proxies #8172
Simple Errata import API (for CentOS errata management for example) #8656
Nested organizations in Katello #10789
I’m working on #10539 (PR 4095 and 4096) and on prerequisites for #5441
(rbovirt part was merged and there is a PR3936 open on the fog part)
Thanks for your work, foreman/katello devs, i’ve seen a lot of
improvements since we started to use it few years ago, and i think the best
is still to come
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.
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.
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.
