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

set the policy controller to the latest release branch #314

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ metadata:
capabilities: Basic Install
categories: Integration & Delivery
containerImage: quay.io/kuadrant/kuadrant-operator:latest
createdAt: "2023-11-17T10:07:35Z"
createdAt: "2023-11-17T10:46:25Z"
operators.operatorframework.io/builder: operator-sdk-v1.28.1
operators.operatorframework.io/project_layout: go.kubebuilder.io/v3
repository: https://github.com/Kuadrant/kuadrant-operator
Expand Down
2 changes: 1 addition & 1 deletion config/policy-controller/kustomization.yaml
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
resources:
- github.com/Kuadrant/multicluster-gateway-controller/config/policy-controller/default?ref=main
- github.com/Kuadrant/multicluster-gateway-controller/config/policy-controller/default?ref=release-0.2
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 say that these kind of version pointing in our manifests in main branch, should point to floating latest tag or main branch, and use the specific version for release branches. Does it make sense?

Copy link
Member

@didierofrivia didierofrivia Nov 17, 2023

Choose a reason for hiding this comment

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

on a second thought, if we want to treat the policy controller as an external dependency, say, like istio, it's a different story

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

issue with that is, any time something changes in the policy controller repo yamls, it will mean the verify-bundle will fail in this repo

Copy link
Contributor

Choose a reason for hiding this comment

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

Authorino is listed as a dependency and it points it to main:

- github.com/Kuadrant/authorino-operator/config/deploy?ref=main

Copy link
Contributor

Choose a reason for hiding this comment

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

In fact, I think the policy controller could be treated the same way. Why not having it under config/dependencies?

Copy link
Member

Choose a reason for hiding this comment

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

This really depends what you are trying to achieve. If you want the TLSPolicy and DNSPolicy CRDs and policy controller deployment included in the kuadrant-operator bundle, then adding them to config/dependencies probably won't work. AFAIK, none of those dependencies are pulled into the bundle and the likes of kuadrant-operator/config/dependencies/authorino/kustomization.yaml is only used where you want to run everything without OLM. In a normal OLM installation authorinio-operator is installed as an OLM dependency since it has it's own bundle, policy-controller doesn't.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense. Indeed the APIs defined by those dependencies are not part of Kuadrant Operator's bundle.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok so only question is whether it should ref main or not. I am thinking not at least initially

Copy link
Contributor

Choose a reason for hiding this comment

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

About fixing a version or using latest, I think the logic behind it was that:

  • components we control we default to latest – and therefore we pick up changes in those that affect Kuadrant Operator as soon as possible, whereas
  • components we do not control we fix a version – and therefore ensure stability of Kuadrant Operator before externalities going on on those projects.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok so then we don't change this one and we close this PR?


patchesStrategicMerge:
- delete-ns.yaml
Expand Down
Loading