Proposal: remove support for disabling taxonomies or login

#1

Hello,

There are 3 settings in Foreman that affect a lot of code for very little value IMHO:

  1. locations_enabled
  2. organizations_enabled
  3. login

These settings allow running a “simplified” Foreman, but come at a significant cost with respect to code complexity:

  • every method touching taxonomies or users has to check the value of the relevant setting
  • installer and puppet modules need to support setting them
  • some methods related to taxonomies need to account for the possibility of just organizations or just locations enabled
  • tests need to check all possible setting combinations as well

Going forward, I suggest being more opinionated and removing these settings.

This should be done in several stages:

  1. Informing users these settings are going to be removed in version X (1.21? 1.22?), perhaps using notifications.
  2. Creating a default organization and/or location and assigning all objects to it for users who have the matching taxonomy disabled. (perhaps not needed and we can set the “all” option on the taxonomy?)
  3. setting all the settings to true during upgrade to X or X-1
  4. removing a whole lot of code

TBH, I would be happy to get rid of the unattended setting as well, but it seems that it has more users and use-cases and would be harder to remove.

If you think there is reason to keep these settings, please shout out. Otherwise, if there is agreement, I would want to deprecate the settings in 1.20 already so by 1.22 we can get to step #4 above.

#2

Yes. Yes! YES!!!

Let’s remove unattended setting as well and do 2.0 version and my dream comes true :slight_smile:

I think doing this just in Release Notes and via a blog post is fair deal.

#3

yes, yes, yes, yes, yes and yes :slight_smile: If we write a blog post, it actually triggers notifications now, right?

#4

Assuming the user hasn’t changed the defaults for the RSS widget, yes.

#5

Opened Tracker #24799: [tracker] Remove settings to disable taxonomies and settings - Foreman to track this change

#6

ACK! In general, I agree completely that removing the matrix of configuration and being opinionated here will make code and deployments easier. Speaking from a Katello point of view that requires both taxonomies to be enabled this would reduce a headache with adding Katello to an existing Foreman.

#7

Changes in installer modules and answer files will be needed too. But if there’s no strong push back from users, I’m all for it.

#8

Since it looks like there is general agreement on this, i started working on it.
Step 1 is at

Foreman Community Demo #50
#9

Perhaps we should ask them then? :slight_smile:

I’ve pinned this topic for more visibility, and I’ll mention it in the demo next week.

#10
#11

Let’s play the devils advocate. Can we keep supporting locations_enabled and organizations_enabled without the code overhead? Would it be possible to use locations and organizations but only hide it in the UI? That would mean always using a single location + organization and hiding the selectors. It would make it possible to change it from a pre-install setting (because of seeding) to a runtime setting.

I don’t care much about the login setting because a critical part of infra like Foreman should IMHO always be protected by a login.

I suspect unattended could be done more on the UI level as well. At least keeping the same class signatures and changing return values would improve the situation.

#12

I like that - certainly unattended was always intended as a simplification, and doing it in the UI is definitely one way to achieve that.

#13

As I mentioned in the original post, I didn’t include unattended on purpose, since that also changes a lot of the behavior of the application. For example, the whole host build and orchestration workflow is different when enabled or disabled, not only in the ui but also behind the scenes.

For location and organizations, we could just hide the relevant bits in the UI, but that would require more complexity in the ui - e.g. assign the default taxonomies when hiding the elements etc. If there is much push-back that could be a viable option, but let’s see first if there is any such.

Regarding the login I agree, this should definitely be enforced (and if anyone doesn’t like typing their password often they can change the session timeout setting)

#14

On the other hand, is it really big deal to have a single org/loc and having extra two fields for each resource?

I’d rather see investing dev time into fixing UX around taxonomy so for example org/loc is always set automatically according to default selection so uses can completely forget about it and simply ignore the setting rather than doing extra work of “hiding” the stuff. That can easily generate more pain (e.g. hidden element preventing a form from being submitted).

#15

personal experience of rolling out foreman in a number of different use cases I’ve found that using foreman on it’s only normally only warrants one location/org, I’ve rarely hit a use case that required the complex org/locations configuration, so normally disable them by default. Having them hardcoded to enabled but all resources under a default location / org actually makes things significantly better.

When using complex orgs/location layouts I’ve found Katello normally is a better fit due to the size of the estate that warrants this complexity and the functionality the estate requires, so foreman on it’s own normally doesn’t need that level of complexity.

#16

It’s a good idea, if we are able to tweak some of the usability of taxonomies. I agree there’s very little difference to the user if there’s 1 location and 1 organization and they always do things in that context. All the UI fields get populated based on that context. Hammer now has the default taxonomy options too, so it’s not too painful.

But, you can still create organizationless/locationless objects and that does cause issues. It would be nice if we could avoid letting users do that, and stopped do it for auto populated hosts (e.g. puppet reports). Also smart proxies are always registered without a taxonomy.