Currently, the updateStrategy for Route-agent pods is set to RollingUpdate
with maxUnavailable as 1. Because of this, when the route-agent DaemonSet
is updated, the Pods are updated one after the other. While the rolling
update strategy is good for user-facing services, for route-agent DaemonSet
its not the most suitable one as it takes time for all the route-agent pods
to be updated in a large cluster.
Ideally, it would have been great if "Recreate" updateStrategy was supported
for DaemonSets, but unfortunately K8s does not support it. But an alternate
way to achieve something similar is to configure rollingUpdate.maxUnavailable
to 100% so that the DaemonSet controller can update all the route-agent Pods
in a single go.
https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/#daemonset-update-strategy
Fixes issue: https://github.com/submariner-io/submariner/issues/734
Signed-Off-by: Sridhar Gaddam <sgaddam@redhat.com>
* Add clusterrole to give lighthouse serviceaccount access to endpoints and
endpointslices
* Add role to give broker serviceaccont access to endpoint slices
Signed-off-by: Vishal Thapar <5137689+vthapar@users.noreply.github.com>
If crd.create is set to false when installing submariner on same cluster
as broker, gateways CRD never gets installed because it is missing from
broker charts. This change is to install the CRD even on broker, as a
cleaner alternative to adding more flags.
Signed-off-by: Vishal Thapar <5137689+vthapar@users.noreply.github.com>
Adds following permissions to lighthouse clusterrole
for `gateways.submariner.io`
- get
- list
- watch
This allows lighthouse to track changes to gateway status and know which
clusters are connected.
Signed-off-by: Vishal Thapar <5137689+vthapar@users.noreply.github.com>
In one of the earlier PRs, we modified the terminationGracePeriodSeconds
to 10 secs. However, its seen that this is causing more CI failures
during e2e redundancy tests. Ideally, once the Pods are terminated,
it should cleanup itself ASAP but it is seen that SM Pods are sometimes
taking time to exit and during this Period since there is no active SM
Pod running, this is triggering some failures.
Until we figure out the exact reason why the Pods are taking time for
cleanup, this PR reduces the terminationGracePeriodSeconds.
This issue would be properly addressed via
https://github.com/submariner-io/submariner/issues/694
Signed-Off-by: Sridhar Gaddam <sgaddam@redhat.com>
* Update versioning and image repositories
Update helm charts to follow the submariner versioning,
and include the image repositories by default.
Signed-off-by: Miguel Angel Ajo <majopela@redhat.com>
* Update final version
Signed-off-by: Miguel Angel Ajo Pelayo <majopela@redhat.com>
To optimize Lighthouse for Globalnet, Lighthouse needs to know if
globalnet was enabled.
Signed-off-by: Vishal Thapar <5137689+vthapar@users.noreply.github.com>
Add GitHub Action validating presence of signed-off-by line to accept
the Developer Certificate of Origin, as required for CNCF.
Relates-to: submariner-io/submariner#666
Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
In K8s the default termination grace period for a Pod is 30
secs. However, for Submariner Pods, we were configuring this as
0 secs, because of which, cleanup was not happening in a
consistent manner and we are seeing failures in CI jobs.
This PR modifies the terminationGracePeriodSeconds to 10 secs.
Along with this change, it also uses the proper namespace of
submariner in the excluded namespaces.
Fixes issue: https://github.com/submariner-io/submariner-charts/issues/39
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
The CI job currently only checks the bare chart, with optional flags set
to defaults which cause it to miss those parts. Set the flags so that
the job also checks those parts.
Add a GitHub CODEOWNERS file to support disaggregating commit rights.
Allows the Committer process in the Community Membership docs to be
implemented.
Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
It was missing the post-deletion operator which caused it to generate:
name:
submariner-lighthouse
Instead of `name: submariner-lighthouse`
Now it should be fine
As part of supporting connectivity from HostNetwork to remoteClusters, globalnet
controller requires the CNIInterfaceIP on each node. This PR adds the necessary
clusterRoles for the route-agent daemonSet which will annotate the node with the
CNIInterfaceIP on that respective node.
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
As part of supporting connectivity from HostNetwork to remoteClusters, globalnet
controller annotates a node with globalIP. This PR adds the necessary roles for
globalnetController.
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
This PR provides a mechanism to configure the following
Submariner Gateway leader election values
1. leaseDuration
2. renewDeadline
3. retryPeriod
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
In previous upstream discussions we talked about renaming submariner
engine "deployment" (now daemonset) to submariner-gateway to make
identification of the gateway easier to admins and avoid confusion.
Also see: https://github.com/submariner-io/submariner-operator/pull/145
Currently, the Submariner Engine is a deployment with nodeSelector
(for submariner.io/gateway=true). It is seen that when the label
is removed from the node after SM engine is deployed, SM engine
continues to run on that node. This behavior is not in Sync with
the DaemonSet (used by GlobalnetController) behavior where the POD
is immediately terminated when the label is removed from the node.
This PR updates SM engine as DaemonSet so that we have consistent
behavior between the SM Engine POD and GlobalnetController POD.
Signed-off-by: Sridhar Gaddam <sgaddam@redhat.com>
Added a chart for the globalnet controller which uses the global CIDR.
Also added the global CIDR to the submariner engine pod env so it can
utilize it.
The controller will only be deployed if the CIDR is specified.
