Yes. Yes! YES!!!
Let’s remove unattended setting as well and do 2.0 version and my dream comes true 
I think doing this just in Release Notes and via a blog post is fair deal.
yes, yes, yes, yes, yes and yes If we write a blog post, it actually triggers notifications now, right?
1 Like
Assuming the user hasn’t changed the defaults for the RSS widget, yes.
Opened Tracker #24799: [tracker] Remove settings to disable taxonomies and settings - Foreman to track this change
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.
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.
Since it looks like there is general agreement on this, i started working on it.
Step 1 is at
https://github.com/theforeman/foreman/pull/6038/
Perhaps we should ask them then?
I’ve pinned this topic for more visibility, and I’ll mention it in the demo next week.
1 Like
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.
I like that - certainly unattended was always intended as a simplification, and doing it in the UI is definitely one way to achieve that.
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)
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).
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.
1 Like
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.
2 Likes
As a user of both location (I use this to identify EC2 instances in particular AWS regions) and organization (I use this to identify instances used by a particular business unit), what’s going to change from the user’s perspective? Are these going away completely or being accomplished in some other way?
We’re removing the settings to disable them. For the end user this means they’re always enabled which means we developers can remove conditionals in our code. Since you have both enabled, nothing will change for you.
2 Likes
do we need to add code to auto include every attribute into the default
location/org? I think the current user flow (a user that had those disabled
before) will need to assign all of his resources to the org?
The plan is to have a migration in 1.21 that will add the default org/loc for those that have none and assign all resources to them. For users that have them enabled already it will be a noop.
2 Likes