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

Always return VIP as host if set #179

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

shayancanonical
Copy link
Contributor

@shayancanonical shayancanonical commented Oct 1, 2024

Issue

We would like to always return the configured VIP as the host when externally connected (to support use cases where the VIP may be configured outside of the charms e.g. openstack octavia)

Solution

Update the conditions that

  1. Report host as configured VIP if externally accessible
  2. Set active status on the unit if the charm is the leader and VIP is configured (and prior compatibility checks run - i.e. charm is externally accessible when related to hacluster + charm has a VIP if related to hacluster + VIP is configured only when related to data-integrator)

Reference

PGBouncer charm has the above described functionality: https://github.com/canonical/pgbouncer-operator/pull/337/files#diff-b9ed39bbc9c0387bd3e07da31d13373745534a1cd723d3e292c73496b12e307cR551

Copy link
Contributor

@carlcsaposs-canonical carlcsaposs-canonical left a comment

Choose a reason for hiding this comment

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

question: could you provide more information about what the deployment looks like (in terms of juju apps, relations, and config) if vip is externally configured?

also, is it possible to configure vip outside of hacluster and with hacluster simultaneously? do we need to guard UX if someone attempts this?

Comment on lines 89 to 90
if (
self._ha_cluster.relation
and self._ha_cluster.is_clustered()
and self.config.get("vip")
):
if self.is_externally_accessible(event=None) and self.config.get("vip"):
return self.config["vip"]
Copy link
Contributor

Choose a reason for hiding this comment

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

if ha_cluster.is_clustered() is False, will router be providing a non-accessible endpoint in the databag? is that desired?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on that. Can this just be transient condition though?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this change was made to support the use case where the VIP is somehow configured outside of hacluster. however, it is possible to confirm that hacluster is clustered if a relation with hacluster exists

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Checking _ha_cluster.is_clustered() only if relation with _ha_cluster exists in 03c5777

Copy link
Contributor

@paulomach paulomach left a comment

Choose a reason for hiding this comment

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

looks good, but need to understand Carl's comment

@shayancanonical
Copy link
Contributor Author

@carlcsaposs-canonical raises some very valid points. however, the stance in pgbouncer is that we do not know exactly how field will be using the virtual IP feature and to deliberately avoid being too restrictive. if the user decides to use the vip config, they can follow our directions to set up with HACluster, else they're on their own

@dragomirp please correct me if my understanding deviates from what we disucssed

@dragomirp
Copy link
Contributor

@carlcsaposs-canonical raises some very valid points. however, the stance in pgbouncer is that we do not know exactly how field will be using the virtual IP feature and to deliberately avoid being too restrictive. if the user decides to use the vip config, they can follow our directions to set up with HACluster, else they're on their own

@dragomirp please correct me if my understanding deviates from what we disucssed

As far as I am aware, the hacluster charm is the only Juju way to handle virtual IPs, but I don't think we can assume it will be the only vIP setup that will be used. Any manual vIP setup will be invisible to the charm, hooks wise, and IMHO difficult to detect, by inspecting the network.

I'd rather leave the vIP setup open ended, at least initially, rather than breaking potential use cases that we may have to fix urgently. Setting an unreachable vIP should be detected during initial deployment and in the worst case would just require redeploying the router.

Comment on lines 60 to 59
if (
isinstance(self.charm.get_workload(event=None), workload.AuthenticatedWorkload)
and self.charm.unit.is_leader()
and vip
):
if self.charm.unit.is_leader() and vip:
return ops.ActiveStatus(f"VIP: {vip}")
Copy link
Contributor

Choose a reason for hiding this comment

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

if workload is not running we shouldn't set active status

also follow-up to #177 (comment)

also this could also be an issue for refresh, where active status with vip will block refresh status (https://github.com/canonical/charm-refresh/blob/main/docs/requirements_and_user_experience.md#lower-priority-statuses)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed ActiveStatus setting on leader unit in 49ce228

Comment on lines -90 to +92
self._ha_cluster.relation
and self._ha_cluster.is_clustered()
and self.config.get("vip")
not self.is_externally_accessible(event=None)
or not self.config.get("vip")
or (self._ha_cluster and not self._ha_cluster.is_clustered())
Copy link
Contributor

Choose a reason for hiding this comment

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

do we need to check for ha_cluster.relation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added a check in is_clustered() to return false if no relation formed yet in 49ce228

@taurus-forever
Copy link
Contributor

@shayancanonical please clarify open questions with Carl directly. Feel free to inclide Dragomir in discussion to sync mysql-router with pgbouncer UX.

Copy link
Contributor

@taurus-forever taurus-forever left a comment

Choose a reason for hiding this comment

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

Thank you!

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.

5 participants