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

added namespace validation for custom resources #1523

Merged
merged 4 commits into from Aug 2, 2022

Conversation

mgsh
Copy link
Contributor

@mgsh mgsh commented Jul 19, 2022

Fixed #1517

@mgsh
Copy link
Contributor Author

mgsh commented Jul 19, 2022

Hi @fedepaol , I've attempted a fix for namespace validation. Can you please review when you get a chance and suggest if any changes?

@fedepaol
Copy link
Member

Hi @fedepaol , I've attempted a fix for namespace validation. Can you please review when you get a chance and suggest if any changes?

sure thing, and thanks for the contribution! ❤️

@fedepaol
Copy link
Member

Looks good! A couple of quick nits:

@mgsh
Copy link
Contributor Author

mgsh commented Jul 21, 2022

Sure @fedepaol. I'll try and resolve your changes by today.

@mgsh mgsh closed this Jul 21, 2022
@mgsh mgsh reopened this Jul 21, 2022
@fedepaol
Copy link
Member

Sure @fedepaol. I'll try and resolve your changes by today.

no rush!

@mgsh
Copy link
Contributor Author

mgsh commented Jul 22, 2022

Just an update on status:
It took me some time to understand ginkgo setup and testing. I have created test cases and it's working as expected for all CRs except BFDProfiles which is not failing as expected when tested using the e2etests. I'm still debugging. Should be done by tomorrow.

@fedepaol
Copy link
Member

Just an update on status: It took me some time to understand ginkgo setup and testing. I have created test cases and it's working as expected for all CRs except BFDProfiles which is not failing as expected when tested using the e2etests. I'm still debugging. Should be done by tomorrow.

Sure thing! Again, no rush :-)

@mgsh
Copy link
Contributor Author

mgsh commented Jul 23, 2022

@fedepaol, I've added e2tests and pushed another commit (BFDProfile test was failing earlier because its webhook config did NOT have a CREATE hook registered, I've added it now, hope that's fine).

As for clear commit message, I currently have 2 separate commits which I've pushed already. Would you recommend that I rebase/squash both commits into one single commit and force push in its current branch (I was reluctant to try it without checking first, because it's usually not advised)? OR perhaps a new PR with just the changes applied as a single commit with a clear commit message? Please advise.

As for the message content, I think your description on the issue was sufficiently verbose. Based on your advise on rebase/squash or squash/merge we can use the below message accordingly (with your changes if any).

Added namespace validation in the create webhook for all CRs

Currently, there's nothing preventing the CRs to be created in a
namespace different from the one metallb is deployed to. This change
adds namespace validation to prevent creation of CRs in a different
namespace.

})

ginkgo.Context("For BFDProfile", func() {
ginkgo.It("Should reject creating BFDProfile in a different namespace", func() {
Copy link
Member

Choose a reason for hiding this comment

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

I think you could use a Table test here, providing resources as a table entry. This will avoid duplication, since we always expect the same behaviour.
See

table.DescribeTable("A service of protocol load balancer should work with ETP=local", func(pairingIPFamily ipfamily.Family, poolAddresses []string, tweak testservice.Tweak) {
for example

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! Wasn't aware of it. I've refactored it now to use DescribeTable.

var _ = ginkgo.Describe("Webhooks", func() {
ginkgo.BeforeEach(func() {
ginkgo.By("Clearing any previous configuration")
err := ConfigUpdaterOtherNS.Clean()
Copy link
Member

Choose a reason for hiding this comment

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

I'd expect there's no need for cleaning before or after, as all these tests won't add anything

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The latest version doesn't use setup code for namespace validation.

@@ -381,3 +383,175 @@ var _ = ginkgo.Describe("Webhooks", func() {
})
})
})

var _ = ginkgo.Describe("Webhooks", func() {
Copy link
Member

Choose a reason for hiding this comment

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

I'd add it under the same describe, just as a different Context

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The existing Describe has setup code which we don't need for the new specs. So I've retained it as a separate set of specs under a separate DescribeTable (since we don't need the setup code for it). Is that ok?

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.7.0
controller-gen.kubebuilder.io/version: v0.9.2
Copy link
Member

Choose a reason for hiding this comment

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

Can you use the same kubebuilder versoin? I know it's pretty old, but I'd be deliberate in changing the CRDs for that (I guess that's what is removing the status and adding x-kubernetes-map-type: atomic below)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've used the exact version of controller-gen and retested it in the latest changes.

@fedepaol
Copy link
Member

@fedepaol, I've added e2tests and pushed another commit (BFDProfile test was failing earlier because its webhook config did NOT have a CREATE hook registered, I've added it now, hope that's fine).

As for clear commit message, I currently have 2 separate commits which I've pushed already. Would you recommend that I rebase/squash both commits into one single commit and force push in its current branch (I was reluctant to try it without checking first, because it's usually not advised)? OR perhaps a new PR with just the changes applied as a single commit with a clear commit message? Please advise.

As for the message content, I think your description on the issue was sufficiently verbose. Based on your advise on rebase/squash or squash/merge we can use the below message accordingly (with your changes if any).

Added namespace validation in the create webhook for all CRs

Currently, there's nothing preventing the CRs to be created in a
namespace different from the one metallb is deployed to. This change
adds namespace validation to prevent creation of CRs in a different
namespace.

Commit message is fine. We normally split the changes with a commit for the changes and another one for the tests.
Rebasing is fine.
I'd also add a section to the release notes (you can create v0.13.5) in a separate commit to mention this change.

mgsh added a commit to mgsh/metallb that referenced this pull request Jul 27, 2022
@mgsh
Copy link
Contributor Author

mgsh commented Jul 28, 2022

Let me check the e2e failures and fix, certain scenarios are failing.

mgsh added a commit to mgsh/metallb that referenced this pull request Jul 28, 2022
@mgsh
Copy link
Contributor Author

mgsh commented Jul 28, 2022

My bad that I hadn't run all test possibilities (am exploring the use of act to run github actions locally before pushing changes, yet to get it fully working).

The helm based e2etests were failing. I had to make 2 changes:

  • Add CREATE op in the helm chart bfdprofile validation webhook config (and also fixed a possible typo) 163cf03#diff-dbf01c8949b94f349b1a6e20f162b6cacb22d3348e400200384e29100b990669
  • Updated the e2etest setup to use kube-system as the other namespace to expect failures in CR creation. I had used default earlier, but the helm based tests are using the default namespace to install metallb. Is this expected, shouldn't we be testing with helm install --create-namespace --namespace metallb-system ...?

@mgsh
Copy link
Contributor Author

mgsh commented Jul 28, 2022

The operator based e2etest required a change in the metallb-operator repo (to enable validation webhook for BFDProfile create op). Tracking that change under metallb/metallb-operator#240 (from what I understand, it fetches configs from this repo and that's causing its manifest validation tests to fail, looking into it).

Currently, there's nothing preventing the CRs to be created in a
namespace different from the one metallb is deployed to. This change
adds namespace validation to prevent creation of CRs in a different
namespace.
mgsh added a commit to mgsh/metallb that referenced this pull request Jul 28, 2022
@fedepaol
Copy link
Member

* Updated the e2etest setup to use `kube-system` as the other namespace to expect failures in CR creation. I had used `default` earlier, but the helm based tests are using the `default` namespace to install metallb. Is this expected, shouldn't we be testing with `helm install --create-namespace --namespace metallb-system ...`?

Yep, this is something that we can definitely improve. Regarding the 'other namespace', why not creating one? Despite it's reasonable to expect kube-system , maybe it makes sense to be more in control with that (deleting the namespace when the suite exits)

mgsh added a commit to mgsh/metallb that referenced this pull request Aug 1, 2022
@mgsh
Copy link
Contributor Author

mgsh commented Aug 1, 2022

I've made these two changes:

  1. create a different namespace for the namespace validation tests.
  2. use the fork version of metallb-operator (needs to be changed back to main once that fork is merged).

@fedepaol
Copy link
Member

fedepaol commented Aug 1, 2022

2. use the fork version of metallb-operator (needs to be changed back to main once that fork is merged).

when we deal with this chicken-egg situations, it's fine to have the operator lane temporary failing. I'd go that way, to avoid the need of reverting again.

@mgsh
Copy link
Contributor Author

mgsh commented Aug 1, 2022

when we deal with this chicken-egg situations, it's fine to have the operator lane temporary failing. I'd go that way, to avoid the need of reverting again.

Got it. In that case, let me remove that commit (6c78ab3) and push it again. I've tested the above commit already for all tests passing in my forked repo (mgsh#1), to cross-check that it was the only missing dependency. So once the metallb-operator changes are sorted out e2e-use-operator tests will be automatically fixed.

@@ -134,11 +137,24 @@ var _ = ginkgo.BeforeSuite(func() {
updater, err = testsconfig.UpdaterForCRs(clientconfig, metallb.Namespace)
framework.ExpectNoError(err)

// for testing namespace validation, we need an existing namespace that's different from the
// metallb installation namespace
otherNamespace := fmt.Sprintf("%s-other", metallb.Namespace)
Copy link
Member

Choose a reason for hiding this comment

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

Can you delete this in aftersuite?
Also, ignore the err if it is AlreadyExists, so if we interrupt the tests before aftersuite the new run won't fail.

var _ = table.DescribeTable("Webhooks namespace validation",
func(resources *metallbconfig.ClusterResources) {
err := ConfigUpdaterOtherNS.Update(*resources)
framework.ExpectError(err)
Copy link
Member

Choose a reason for hiding this comment

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

I guess this is not necessary given the next row

Copy link
Contributor Author

Choose a reason for hiding this comment

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

do you mean that framework.ExpectError is redundant because of the following Expect(err.Error()).To(...)?

Copy link
Member

Choose a reason for hiding this comment

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

yes, if err is nil that row will complain

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fedepaol ☝🏽 if that was your suggestion, won't err.Error() panic if it's nil and we remove the framework.ExpectError before it?

Copy link
Member

Choose a reason for hiding this comment

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

That's right. I misread the string checking line.

I suggest using
Expect(err).To(MatchError(ContainSubstring(....))

That will avoid adding the double check

@fedepaol
Copy link
Member

fedepaol commented Aug 1, 2022

Couple of small nits, and I think this is good to land!

mgsh added a commit to mgsh/metallb that referenced this pull request Aug 2, 2022
mgsh added a commit to mgsh/metallb that referenced this pull request Aug 2, 2022
mgsh added a commit to mgsh/metallb that referenced this pull request Aug 2, 2022
For each CR, we try creating a resource in a namespace other than the
metallb namespace and expect a failure.
@fedepaol
Copy link
Member

fedepaol commented Aug 2, 2022

LGTM, thanks!

@fedepaol fedepaol merged commit d4a5f97 into metallb:main Aug 2, 2022
pperiyasamy pushed a commit to pperiyasamy/metallb that referenced this pull request Aug 17, 2022
fedepaol pushed a commit that referenced this pull request Sep 1, 2022
pperiyasamy pushed a commit to pperiyasamy/metallb that referenced this pull request Sep 6, 2022
pperiyasamy pushed a commit to pperiyasamy/metallb that referenced this pull request Sep 7, 2022
novad03 pushed a commit to novad03/k8s-meta that referenced this pull request Nov 25, 2023
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.

Validating webhooks: make sure the crs are created in the metallb namespace
2 participants