Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #36928 - (sorta) handle load balanced smart proxies when registering hosts #10804

Merged
merged 4 commits into from
Dec 11, 2023

Conversation

jeremylenz
Copy link
Member

@jeremylenz jeremylenz commented Nov 16, 2023

What are the changes introduced in this pull request?

As we know, currently

  • full load balanced setups are not supported
  • Smart proxy load balancing is only supported for Pulp content, not other smart proxy services
  • When registering a host, you pass the --serverurl parameter to subscription-manager, which contacts the server you specify for registration.
  • In such a case, the host's registered_through value is set to the hostname of the load balancer, which is not a smart proxy.
  • Therefore, the registered_through value won't match the name of any known Smart Proxy.
  • Previously, when calculating remote execution smart proxies available to the host, that caused the host's registered_through Smart Proxy to be listed as [], breaking Remote Execution on certain setups depending on your settings.

With this change, some methods are added to attempt to surmise

  • when you're registering to a load-balanced smart proxy;
  • when a certain smart proxy is behind a load balancer; and
  • which smart proxies are behind a given load balancer.

In the case of smart proxies, this is determined by comparing the smart proxy's registration_url hostname with its url hostname. If they're different, we assume it's a load balanced setup.

In the case of host registration, this is still determined (for now) by comparing the request headers to known smart proxy names.

Additionally, we add the following behavior changes when a host is registered through a load balancer:

  • Set the host's remote execution registered_through to all known smart proxies behind the load balancer
  • Set the host's content source to the first found smart proxy behind the load balancer. This should be safe because (theoretically) all smart proxies behind the load balancer should be syncing the same content. It's also better than setting content source to nil, because nil assumes the host has access to all library content, when actually it only has access to content synced by its smart proxy(ies).

Considerations taken when implementing this change?

Ideally a load balancer would be a Foreman entity which holds a list of smart proxies, and the user would explicitly tell us which smart proxies go with which load balancer, and we could just refer to that. But that would require a rather large effort, so this is being offered as somewhat of a stopgap to fix the immediate bug. None of the changes here preclude a more proper feature design from happening later.

What are the testing steps for this pull request?

I actually haven't tested this with a load balancer yet. You may leave my hard-codings in, or ideally set up an actual load balancer and take them out.


def registering_thru_load_balancer?(hostname)
# If the request doesn't come from any known smart proxy, it came from a load balancer.
get_content_source_id(hostname).nil?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a safe assumption? Could you instead check all smart-proxies registration URLs and see if they match the hostname?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would be better. At this point I should probably just change it not to use the header, too..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to check if hostname is a known load balancer. 👍

@ehelms
Copy link
Member

ehelms commented Nov 16, 2023

@ekohl given you had a lot of opinion around the implementation where we used registration_url to indicate a load-balancer rather than introducing a dedicated parameter to indicate load-balancing I think you should review this.

@jeremylenz jeremylenz force-pushed the 36928-load-balancers-whoa branch from e4139f2 to 4245df0 Compare November 17, 2023 14:49
@jeremylenz jeremylenz force-pushed the 36928-load-balancers-whoa branch from 4245df0 to 46a24de Compare November 21, 2023 20:28
@jeremylenz jeremylenz marked this pull request as ready for review November 21, 2023 20:28
@jeremylenz
Copy link
Member Author

Added some tests; marking ready for review.

Copy link
Member

@adamruzicka adamruzicka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a setup with load balanced capsules so I can't really test this, but in general this reads like it should do the trick, assuming my mental model of the whole thing is correct.

@sayan3296
Copy link
Contributor

@adamruzicka @jeremylenz I have done some testings on a Sat\Cap 6.15 + Haproxy setup with two RHEL clients .. The results are looking great.

Details can be found in the private comment 11 of the main Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2240956

ianballou
ianballou previously approved these changes Dec 8, 2023
Copy link
Member

@ianballou ianballou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After poking around the rails console on a load-balanced set up, this is looking good to me! Credit to @sayan3296 for the setup.

app/models/katello/concerns/host_managed_extensions.rb Outdated Show resolved Hide resolved
@ianballou ianballou dismissed their stale review December 8, 2023 16:10

missed the logs

Copy link
Member

@ianballou ianballou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the log statements need cleaning then this should be good to merge.

@jeremylenz jeremylenz force-pushed the 36928-load-balancers-whoa branch from ed31c3b to 4254bde Compare December 11, 2023 14:55
@jeremylenz jeremylenz force-pushed the 36928-load-balancers-whoa branch from 4254bde to a0ddb54 Compare December 11, 2023 16:48
@@ -6,6 +6,7 @@
require "oauth"
require "gettext_i18n_rails"
require "foreman-tasks"
require "foreman_remote_execution"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given

gem.add_dependency "foreman_remote_execution", ">= 7.1.0"

I am rather confident we never have a Katello install w/o REX.

But at the same time it indicates that the way we load stuff differs so heavily in prod/dev/test, that things go weird.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@ianballou ianballou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests are good, so ACK!

@jeremylenz jeremylenz merged commit 27e9e68 into Katello:master Dec 11, 2023
4 of 5 checks passed
ianballou pushed a commit to ianballou/katello that referenced this pull request Dec 19, 2023
…ering hosts (Katello#10804)

* Fixes #36928 - (sorta) handle load balanced smart proxies when registering hosts

(cherry picked from commit 27e9e68)
ianballou pushed a commit that referenced this pull request Dec 19, 2023
…ering hosts (#10804)

* Fixes #36928 - (sorta) handle load balanced smart proxies when registering hosts

(cherry picked from commit 27e9e68)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants