Deprecating and removing the Legacy Content Hosts UI

Development RFCs
1

Context and Problem Statement

In the beginning, Foreman and Katello had two separate UIs with all their own pages. Foreman kept track of hosts through its Hosts pages, while Katello had the Content Hosts pages. The basic idea of these pages is simple:

  1. A “list” page, which lists all your hosts and allows you to perform bulk actions on several hosts
  2. A details page, which displays information about a single host and allows you to perform actions on that single host.

The legacy of Foreman and Katello starting as separate applications is that we basically have two of each of these. For years now, it’s been a goal to merge Foreman and Katello’s hosts pages into a single page, because that just makes more sense.

Originally, the pages consisted of

  • Foreman’s All Hosts list page, written in Ruby ERB/HTML, containing provisioning-related bulk actions
  • Foreman’s host details page, written in Ruby ERB/HTML, containing provisioning-related information and actions
  • Katello’s Content Hosts list page, written in AngularJS, containing content-related bulk actions
  • Katello’s Content Host details page, written in AngularJS, containing content-related information and actions

We are now well on our way towards combining these into

  • A single All Hosts page, written in React, that offers both provisioning- and content-related bulk actions and replaces both list pages.
  • A single host details page, written in React, that offers both provisioning- and content-related information and replaces both details pages.

In general, for large UI rewrites such as this, our process has been

  1. Offer a partially-functional new UI as a tech preview, gated behind a setting
  2. Expand functionality of the new UI until users can accomplish the most important tasks without having to fall back to the old UI
  3. Deprecate the old UI and make the new UI the default
  4. Remove the old UI completely. (Note that this does not necessarily mean that every function from the old page is available on the new one.)

The current state of these pages is

Content Host and Host details pages: Step 3. These pages have been combined and most functionality is available as part of the new UI, written in React. Links from the list page lead to the New UI by default. The Legacy UI is still available via links on the new pages.
All Hosts list page: Step 2. Most of the top bulk actions are available already, with more on the way. There is a “New UI” button on the legacy list page, for easy access.

In the next 1-2 Foreman and Katello releases, we plan to add the following bulk actions to the new All Hosts list page:

  • Repository sets
  • Location and org
  • Disassociate host
  • Change owner
  • Change host collections

After these are completed, it will mean that

  • most of the “top” (most important) bulk actions from the original All Hosts page are available in the new UI; and
  • all of the Content Host bulk actions are now available in the new UI.

Proposal

In light of this, we’d like to make the following changes:

  1. Remove the deprecated legacy Content Host details UI.
  2. Remove the legacy Content Host list UI.

Several good reasons for this include

  • It just makes more sense to have all host-related actions on one page instead of two.
  • This removal will mean that a lot of Katello’s AngularJS code can be removed, which furthers our goals of modernizing our tech stack, improving security, and eliminating technical debt.
  • The new pages conform to current, modern design standards (Patternfly 4, currently being upgraded to Patternfly 5) and have the involvement of UX designers. The old pages use outdated designs and cause a bad user experience.
  • Having some actions under “Hosts” and others under “Content Hosts” can be confusing to new users.

Proposed timeline / order

  1. First, we will complete adding the bulk actions mentioned above to the new UI.
  2. In the same Katello release that those bulk actions are complete, we will officially deprecate the legacy Content Host UI in favor of the new UI.
  3. In the next Katello release after that, we will remove access to those pages and remove the underlying AngularJS code and routes.

Keeping the legacy Content Host UI around simply isn’t a viable option, due to the security issues and technical debt of AngularJS.

Note that this proposal does not include the deprecation or removal of Foreman’s legacy host list or details pages. Those will still be available (though they will not be shown by default.) Rails ERB and HTML are still fully supported, so modernizing those is somewhat less urgent.

Decision Outcome

tbd

Impacts

It’s possible there may be actions available on the removed pages that were not available anywhere else. Depending on what the action is, it may still be available through Hammer CLI or API. I would expect that if a particular omission caused a lot of pain, that we would have heard about it already or will be hearing about it soon. However, often people don’t use the new UI until they have to, and we’ll find out where those pain points are after the old UI is removed.

Other than that, I expect most of the impacts from this to be positive, with the removal of technical debt and outdated pages and designs.

4 Likes
2

Getting the old content host page out would be a big win, especially since it would essentially kill the term “content host”. It would be good to hear if any users are partial to the old content host page for any reason (besides the missing actions that’ll be added soon).

2 Likes
3

would be great if you can also migrate " Manage Host tracer" bulk Action into the new “ALL Host” Page

1 Like
4

“Legacy Content Hosts UI” can be removed safely because the new “Content” Tab is sufficient and good enough :+1:
But at the moment I really would miss “Legacy Host UI” because the new Host UI isn’t satisfying my informational needs. :scream:

5

Not to derail this discussion (to be clear, the “non-Content” Legacy Host UI is not deprecated) - but what information is important to you?

6

The old UI is much more clearly arranged and condensed and not frisky at all. The informational content is extremly high at one single glance.

7

Keeping those points in mind, what is about the following actions:

  • edit parameters
  • change power status
  • manage module streams (might be part of repository sets)
  • manage system purpose
  • manage traces (was already mentioned in a comment before)
  • the current actions related to snapshots, puppet, salt, openscap

The last point may be something the plugins have to solve, but the other ones are also useful - for example changing parameters for multiple hosts or to power on/off multiple VMs.

2 Likes
8

Thanks, this is exactly the kind of feedback I was hoping to get!

  • edit parameters
  • change power status

These will still be available on the Legacy All Hosts page, which is sticking around for now. However, I agree it would be great to add them to the new UI as well.

manage module streams

Module streams are not as much of a concern because modularity is going away completely in EL10, so you won’t need to manage them. Without the existing bulk action, you can still use customized remote execution from any host’s details page (Content > Module streams tab), and re-set the target hosts to whatever you want.

Unlike the ones above, these actions are truly at risk, e.g. would go away when the legacy Content Hosts page does. We have existing “new UI” components for both, however, which would make them relatively easy to add. It’s just a matter of bandwidth and capacity.

For all of these, it would be great to get an idea if there are certain in-jeopardy actions that people consider essential, or more essential than others, to help us prioritize.

1 Like
9

As it is already a bit derailed with actions from hosts and not content hosts, I already have an open issue about getting back reboot for a vm when switching to build mode. The only thing which makes me switch back to the old UI regularly.

1 Like