Katello features a lot of remote action related Ui bits for installing/updating packages. The current UI buttons/elements are always present, and subset of options are hidden when REX is not present.
It was also expressed in a recent meeting to have REX automatically deployed with a katello dev environment, so the question came up if should be done so in production as well.
This presents us with a couple of options:
Require REX with Katello at a gem level and installer level. Remote actions work out of the box similar to today.
Hide UI bits for errata/package actions if REX isn’t present
0voters
Let me know if there are other options that i haven’t considered.
From a user perspective I tend to lean towards the first option, as it gives a simpler setup. It also reduces code complexity to make assumptions around its presence.
I’m not sure if there are any gotchas from a build perspective though.
Could you clarify - is this REX deployment on the server side? IMHO there’s 3 layers:
Server - katello gem depends on foreman_remote_execution gem
Smart Proxy - there is a proxy feature present
Client - is the SSH key present on the client
IMHO the Server can depend on REX. It can’t assume the proxy feature is present. There should be a proper fallback if no proxy can be found. This is because it may also be invisible due to permissions/organizations/locations. The same goes for the Client - it may be misconfigured.
It feels like the Require REX is that, but I wanted to make sure this isn’t just my interpretation.
After 1 day this seems like an overwhelming consensus. I will go ahead and make the change to require REX within the gemspec. This will help uncover any issues that may pop up with packaging prior to us making code changes that actually require it and make it easy to back out if it does cause changes.
I think REX currently still moves at a faster pace than Foreman. The flexibility to release things at a faster pace is certainly of value. If we’re talking about having a small and minimal Foreman, that’s also an argument against it.
On the other hand, Foreman already has some code to SSH and perhaps that could be replaced.
IMHO a larger discussion that shouldn’t hold up Katello right now.
I don’t think it moves very fast these days. Actually it’s quite the opposite, the functionality barely changes.
I think it was discussed several times, but if you think it’s necessary or it would block the progress on this effort, I’m OK with suggested and preferred option. I just want to point out, there’s at least 6 plugins that rely on REX (leapp, chef, openscap, katello, ansible, salt) and more that are considering it (discovery), which makes me feel, this is a core functionality. At the same time I realize, this would also require merging foreman-tasks which may be a bigger thing. Though the same applies, many other plugins depend on it.
Merging both tasks and rex to core does make sense to me, consider how widely used they are in other plugins.
An alternative approach, if we wish to keep them as separate projects, might be to switch the dependency direction - have Foreman core depend on them instead of them depending on Foreman core, and than all other plugins will get them as well.
I think REX is still releasing bugfixes more often than Foreman itself.
And as you say, it would also mean merging foreman-tasks. Merging something into core is a non-trivial effort. For example, do you also merge the REX components into Smart Proxy? Right now we deploy Smart Proxy Dynflow Core as a service on RPM-based installs but part of the main proxy on Debs. Will you align that? Does it mean running an additional service by default with the additional memory usage?
I’m not strictly against it, but it’s a large effort with a lot of implications on the packangig and installer side as well. That shouldn’t hold up others.
This doesn’t really work with the infrastructure we have today. We ran into this with foreman-tasks. The way we build packages is that you can build Foreman from scratch and then build a plugin against that Foreman package. You’d end up in a dependency cycle.
In my opinion, REX should be moved as a core functionality to foreman itself.
Agree, that the REX plugin is released more often than foreman, but is this a advantage or disadvantage if you think about stability?
Additionally, a lot of plugins depends on REX (foreman_ansible, foreman_salt, Katello, …). Merge it
As I said earlier, I’m not trying to hold up anyone, if there are no resources for this effort, let’s go with just adding a dependecy to Katello. I just wanted to point out alternative, that long term IMHO is better and if there are people who have the motivation for this have resources and time, why we don’t go this path right away.
If this is not feasible at the moment, please take my answers below as off-topic, just so that they are answered for the future.
yes
I don’t think it’s necessary, but I think that would be ideal. The reason why dynflow core is running separately is gone for a long time (different ruby versions required), if there’s no other benefit, we can use the in-process option. If we want to scale that separately in future, we can split it.
Yes, but it could easily be enhanced to start only if the feature for smart proxy is enabled I believe. OTOH if dynflow was in smart proxy before, I’m sure other plugins would use it, like openscap for ARF reports parsing. Or even a core TFTP functionality, for downloading the installation media.
