-
Notifications
You must be signed in to change notification settings - Fork 52
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
Add option to disable Gossip Router #1667
Conversation
79dda49
to
b51cba1
Compare
Type DiscoverySiteType `json:"type,omitempty"` | ||
// Enables (default) or disables the Gossip Router pod and cross-site services | ||
// +optional | ||
LaunchGossipRouter *bool `json:"launchGossipRouter,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As DiscoverySiteSpec
is a new struct, I think we can remove the pointer here.
The infinispan defaulting webhook, api/v1/infinispan_webhook, can add the DiscoverySiteSpec when spec.sites.local.discovery
is nil for new CRs so that the default value of LaunchGossipRouter
is true.
If upgrading from an old operator version, then spec.sites.local.discovery
will remain nil and we can test for this in CrossSiteDiscoveryType
and LaunchGossipRouterEnabled
as you currently have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would happen if a user puts an empty element in the yaml? Like
spec:
service:
type: DataGrid
sites:
local:
name: lon
discovery:
locations:
-name: nyc
edit: assuming this is a valid yaml format
edit2: is this considered a nil
structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kept the *bool
but added the default in the webhook (and removed the nil
checks)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the valid format would be to have discovery: {}
or discovery: ~
, but either way it's redundant as we have omitempty
defined on the field, so any of these will result in discovery being nil
in the struct.
kept the *bool but added the default in the webhook (and removed the nil checks)
I don't think this is necessary due to ^.
// +kubebuilder:validation:Enum=gossiprouter | ||
type DiscoverySiteType string | ||
|
||
// GossipRouterType is the only one supported but we may add other like submariner and/or skupper |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thinking 👍
documentation/asciidoc/topics/proc_xsite_disable_gossip_router.adoc
Outdated
Show resolved
Hide resolved
|
||
[role="_abstract"] | ||
Only a single Gossip Router is required to route the cross-site traffic however, the {brandname} operator starts a Gossip Route on each site. | ||
You can disable the Gossip Router in one of the sites to save resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the best practice if 3 sites are configured?
If you have a GossipRouter enabled on site 1, but not 2 & 3, does that mean that xsite will fail if Site 1 becomes unavailable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the best practice for 2 or more sites is to let the operator start the Gossip Router on all sites.
This is a customer request that does not want to have a Gossip Router on one of the sites (2 sites total).
In your scenario, the connection will be broken and cross-site becomes available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a note explaining this to the docs, maybe as a NOTE section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I'll leave this for the @infinispan/docs team :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. I'm looking into it and I'll be back on Monday
@dvagnero @dfitzmau Can you review the doc contributions when you get a chance? Thanks |
Hi @ryanemerson . Dominika beat me too it. Just to let you know we created a members group for docs, so you can tag us both with @infinispan/docs |
test/e2e/utils/kubernetes.go
Outdated
if err != nil { | ||
fmt.Println(err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a comment so we don't forget to remove these before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
already gone!
api/v1/infinispan_webhook.go
Outdated
} | ||
if i.Spec.Service.Sites.Local.Discovery.LaunchGossipRouter == nil { | ||
i.Spec.Service.Sites.Local.Discovery.LaunchGossipRouter = new(bool) | ||
*i.Spec.Service.Sites.Local.Discovery.LaunchGossipRouter = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI you can do this as a one-liner with i.Spec.Service.Sites.Local.Discovery.LaunchGossipRouter = pointer.BoolPtr(true)
024b761
to
733f955
Compare
Hey, I added a commit with some docs suggestions. Please let me know what you think |
|
||
.Prerequisites | ||
|
||
* Have multiple working Gossip routers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't multiple Gossip Routers is a prerequisite. Rather, it's necessary for a Gossip Router to be enabled on at least one site.
|
||
* Have multiple working Gossip routers. | ||
+ | ||
You can have an external Gossip router that is not managed by the {ispn_operator}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't correct. The Gossip Router will be managed by the Operator, however it will only be enabled on one of the sites, therefore it's only managed by the Operator on the enabled site.
documentation/asciidoc/topics/proc_disabling_gossip_router_cross_site.adoc
Show resolved
Hide resolved
documentation/asciidoc/topics/proc_disabling_gossip_router_cross_site.adoc
Outdated
Show resolved
Hide resolved
documentation/asciidoc/topics/proc_disabling_gossip_router_cross_site.adoc
Outdated
Show resolved
Hide resolved
documentation/asciidoc/topics/proc_disabling_gossip_router_cross_site.adoc
Outdated
Show resolved
Hide resolved
documentation/asciidoc/topics/proc_disabling_gossip_router_cross_site.adoc
Outdated
Show resolved
Hide resolved
. For the *LON* cluster, set `false` as the value for the `spec.service.sites.local.discovery.launchGossipRouter`. | ||
. For the *LON* cluster, specify the `url` with the `spec.service.sites.locations.url` to connect to the *NYC*. | ||
+ | ||
In the *NYC* configuration, do not specify `spec.service.sites.locations.url`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be part of the procedure steps?
4b525af
to
d14dd1b
Compare
just rebased on top of |
@pruivo LGTM. Can you rebase on latest |
d14dd1b
to
4757dad
Compare
Thanks @pruivo @dvagnero |
Closes #1665
Documentation missing.