-
Notifications
You must be signed in to change notification settings - Fork 17
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
Target Namespace #10
Target Namespace #10
Conversation
a42f6b8
to
73fd05e
Compare
1e2f016
to
5934b71
Compare
/retitle Target Namespace |
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.
a brief/initial high level pass @otaviof .... no specific requests for change
I do pose a question around start up options ... curious on the opinions of you and the rest of the team.
FWIW the finalizer stuff is simpler than what we have to do with the CVO opeartors (where they have support the recreate behavior when managed). Not a bad thing of course.
I'm unfamiliar with the manifest stuff. So nothing to add there.
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.
Most of my comments are style nits and API doc cleanups.
I am concerned about the use of a finalizer - see the comment within the review.
@@ -11,4 +11,4 @@ source "${ENVTEST_ASSETS_DIR}/setup-envtest.sh" | |||
fetch_envtest_tools "${ENVTEST_ASSETS_DIR}" | |||
setup_envtest_env "${ENVTEST_ASSETS_DIR}" | |||
# Run tests sequentially - the controller integration tests cannot be run concurrently | |||
go test ./... -coverprofile cover.out -p 1 | |||
go test ./... -coverprofile cover.out -p 1 -failfast -ginkgo.v -ginkgo.failFast |
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.
You can pass -ginkgo
flags this way? 🤯
|
||
"github.com/shipwright-io/operator/api/v1alpha1" | ||
) | ||
|
||
const ( | ||
// FinalizerAnnotation annotation string appended on finalizer slice. | ||
FinalizerAnnotation = "finalizer.operator.shipwright.io" |
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.
My main question is why do we need a finalizer? Finalizers make it difficult to tear down a Kubernetes cluster because it will block a namespace from getting deleted.
Is the concern that an admin will delete the target namespace by accident, and we'll get caught in this weird place where the operator won't work?
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 have been researching this subject, and indeed, back in ~2018 we had issues open to deal with this situation. So, I have tested this with an updated cluster, and you can delete a namespace without getting stuck. it might have happen before, but not by design.
6fa8605
to
58d1587
Compare
@adambkaplan please consider it again with |
// Foo is an example field of ShipwrightBuild. Edit ShipwrightBuild_types.go to remove/update | ||
Foo string `json:"foo,omitempty"` | ||
// TargetNamespace is the target namespace where Shipwright's build controller will be deployed. | ||
TargetNamespace string `json:"targetNamespace,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.
Can this just be Namespace
?
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.
targetNamespace
is a common convention for operator configuration custom resources. The operator itself can be installed in a different namespace - for example, upstream with OLM operators will get installed by default in the olm-operators
namespace. The community has converged on "target namespace" to indicate where cluster-scoped operand components are created.
This is different from, say, a MySQL operator that could provision multiple MySQL databases in multiple namespaces. For those the configuration CR would be namespace scoped, and the operands would be the individual MySQL DBs.
README.md
Outdated
``` | ||
|
||
It will deploy the Build-Controller in `default` namespace. When `.spec.namespace` is not set, | ||
it will use the `shipwright-build` namespace instead, this namespace needs to be created before the |
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.
Have we already settled on the shipwright-build
namespace somewhere or could we use something like just shipwright
or shipwright-io
?
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.
Given what this operator is going to rollout, I think shipwright-build
might be a meaningful name. It's a good start in my opinion.
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.
Not a bad thing to bike shed. Opened #15 so we can discuss without blocking this PR.
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.
/approve
This generally looks good @otaviof - please squash your commits and then another reviewer can lgtm.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adambkaplan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/assign @coreydaley Since you took a pass before, want to give this another look? |
metadata: | ||
name: shipwright-operator | ||
spec: | ||
namespace: default |
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.
can we go ahead and use shipwright-build
in the example here since it is the default? And maybe add the yaml for creating the namespace to this example and make it a List
?
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'm updating this example to use the shipwright-build
namespace instead, and also showing the namespace must be present before. Please consider latest changes.
controllers/default_test.go
Outdated
// namespace where ShipwrightBuild instance will be located | ||
const namespace = "default" | ||
// namespace where shipwright Controller and dependencies will be located | ||
const targetNamespace = "namespace" | ||
|
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.
Can we use a namespace and targetNamespace that are more realistic and less confusing here?
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.
Sure! I'm following your suggestion, please consider.
// default namespace instead | ||
targetNamespace := b.Spec.Namespace | ||
if targetNamespace == "" { | ||
logger.Info("Namespace is not informed, using default namespace instead") |
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.
We should refer to the constant here instead of a hard coded shipwright-build
o "github.com/onsi/gomega" | ||
"github.com/shipwright-io/operator/api/v1alpha1" | ||
appsv1 "k8s.io/api/apps/v1" | ||
corev1 "k8s.io/api/core/v1" | ||
"k8s.io/apimachinery/pkg/api/errors" | ||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
"k8s.io/apimachinery/pkg/runtime" | ||
"k8s.io/apimachinery/pkg/types" | ||
"sigs.k8s.io/controller-runtime/pkg/client" | ||
"sigs.k8s.io/controller-runtime/pkg/client/fake" | ||
"sigs.k8s.io/controller-runtime/pkg/log/zap" | ||
"sigs.k8s.io/controller-runtime/pkg/reconcile" |
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 be sorted into blocks
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.
Okay, I'm adding a extra plugin to my editor, so that should happen automatically from now on 😅. Please consider latest changes.
de443ef
to
72edd4c
Compare
CRD changes, adding `.spec.namespace` attribute. Deploying Shipwright Build Controller, and dependencies, on a target namespace informed on the CRD spec. Additionally, implementing Kubernetes Finalizer workflow to remove objects with actions centered on the Reconciler directly. Co-authored-by: Adam Kaplan <[email protected]>
/lgtm |
Changes
Allowing namespaces to be configurable via
.spec.namespace
attribute, when not informed it usesshipwright-build
by default.There is some refactoring as well, notably implementing Finalizer Pattern in order to detect resource deletion, and handle manifests removal at Reconciler level.
Fixes #6
Submitter Checklist
Release Notes