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

NETOBSERV-788: adding conversion webhook for flowcollector obj #258

Merged
merged 4 commits into from
Feb 15, 2023

Conversation

msherif1234
Copy link
Contributor

@msherif1234 msherif1234 commented Jan 31, 2023

  • update to v1beta1 version.
  • created conversion webhook using v1beta1 as the HUB and v1alpha1 as the spoke, till we have a new release with v1beta1 then we can make v1beta1 as the storage version.
  • rearrange configs to allow KinD and OpenShift installs since different deployment needs different certifications, to deploy on kind there is new make file option make deploy-kind/undeploy-kind
  • add Makefile new target for conversion auto-gen tool

Signed-off-by: msherif1234 mmahmoud@redhat.com

@jotak
Copy link
Member

jotak commented Feb 1, 2023

Hey @msherif1234 ,
Thanks for this PR! Do you have some info about why a dependency on cert-manager is required? I'd like to understand where this is going to lead us in terms of operator dependencies, we should have as few as possible - our (soft) dependencies on loki operator and kafka operator brings already their loads of complexity.
Also, iiuc this dependency is inherent to doing webhooks "the OLM way", I wonder if there are alternatives

@msherif1234
Copy link
Contributor Author

Hey @msherif1234 , Thanks for this PR! Do you have some info about why a dependency on cert-manager is required? I'd like to understand where this is going to lead us in terms of operator dependencies, we should have as few as possible - our (soft) dependencies on loki operator and kafka operator brings already their loads of complexity. Also, iiuc this dependency is inherent to doing webhooks "the OLM way", I wonder if there are alternatives

cert mgr is needed to extend &authenticate api server to talk to webhook to do admission control this has nothing to do with OLM based operator
https://book.kubebuilder.io/cronjob-tutorial/cert-manager.html#deploying-cert-manager
https://cert-manager.io/docs/concepts/webhook/

I did install for kind env for testing the cert mgr service should be on by default on OCP cluster.

@msherif1234 msherif1234 changed the title NETOBSERV-788: WIP adding conversion webhook for flowcollector obj NETOBSERV-788: adding conversion webhook for flowcollector obj Feb 2, 2023
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Feb 2, 2023

@msherif1234: This pull request references NETOBSERV-788 which is a valid jira issue.

In response to this:

  • created v1beta1 version of flowCollector object
  • created conversion webhook using v1alpha1 as the HUB and v1beta1 as the spoken till we have a new release with v1beta1 then we can make v1beta1 as the new HUB
  • rearrange configs to allow KinD and Openshift installs since different deployment needs to different certifications tags, to depoly on kind there is new make file option make deploy-kind/undeploy-kind

Signed-off-by: msherif1234 mmahmoud@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Feb 2, 2023

@msherif1234: This pull request references NETOBSERV-788 which is a valid jira issue.

In response to this:

  • update to v1beta1 version.
  • created conversion webhook using v1alpha1 as the HUB and v1beta1 as the spoken, till we have a new release with v1beta1 then we can make v1beta1 as the new HUB.
  • rearrange configs to allow KinD and Openshift installs since different deployment needs different certifications, to deploy on kind there is new make file option make deploy-kind/undeploy-kind

Signed-off-by: msherif1234 mmahmoud@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Feb 2, 2023

@msherif1234: This pull request references NETOBSERV-788 which is a valid jira issue.

In response to this:

  • update to v1beta1 version.
  • created conversion webhook using v1alpha1 as the HUB and v1beta1 as the spoken, till we have a new release with v1beta1 then we can make v1beta1 as the new HUB.
  • rearrange configs to allow KinD and OpenShift installs since different deployment needs different certifications, to deploy on kind there is new make file option make deploy-kind/undeploy-kind

Signed-off-by: msherif1234 mmahmoud@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

config/openshift/patch.yaml Outdated Show resolved Hide resolved
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Feb 8, 2023

@msherif1234: This pull request references NETOBSERV-788 which is a valid jira issue.

In response to this:

  • update to v1beta1 version.
  • created conversion webhook using v1alpha1 as the HUB and v1beta1 as the spoken, till we have a new release with v1beta1 then we can make v1beta1 as the new HUB.
  • rearrange configs to allow KinD and OpenShift installs since different deployment needs different certifications, to deploy on kind there is new make file option make deploy-kind/undeploy-kind
  • add Makefile new target for conversion auto-gen tool

Signed-off-by: msherif1234 mmahmoud@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Signed-off-by: msherif1234 <mmahmoud@redhat.com>
Signed-off-by: msherif1234 <mmahmoud@redhat.com>
Signed-off-by: msherif1234 <mmahmoud@redhat.com>
Signed-off-by: msherif1234 <mmahmoud@redhat.com>
Comment on lines +38 to +42
// Manually restore data.
restored := &FlowCollector{}
if ok, err := utilconversion.UnmarshalData(r, restored); err != nil || !ok {
return err
}

Choose a reason for hiding this comment

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

Ok this looks good now, so, what fields are present in v1beta1 that aren't present in v1alpha1? Those will need to be manually restored here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

none atm

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll add two fields in this PR: #252

Should I add these in both versions of the api or only in v1beta1 ?

Choose a reason for hiding this comment

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

This really depends on what you're trying to achieve

Looking at 252, if both of those fields are optional (which they are because they have defaults assigned) then you can add them to v1alpha1 without that being a breaking change. Which brings me back to the question, what are we trying to achieve with a new version of the API, is it to say yes, this API is more mature, or is there some change you want to make that isn't compatible with the current API? (eg renaming or restructuring a field)

Copy link
Contributor

Choose a reason for hiding this comment

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

For now I would say it's just a matter of API maturity. We restructured a lot before GA and I don't see breaking changes coming for now.
But it's definetly good to have this conversion code in place for the time we will bring breaking changes !

@OlivierCazade @jotak

Copy link
Contributor Author

@msherif1234 msherif1234 Feb 10, 2023

Choose a reason for hiding this comment

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

@JoelSpeed holding means not introducing betav1 at all or just not mark it the new storage API till we have the loki changes in or both ? I remember u said beta version need to get released then after that it will can be the new storage so is the plan to get it out in 4.13 and then make it the new storage with the breaking change in 4.14 ? or get it out in 4.14 with the breaking change then make it the new storage in 4.15 ?

Choose a reason for hiding this comment

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

My suggestion would be to hold of introducing v1beta1 as a supported version until you've made those breaking changes. So the first time it gets released would be with the breaking changes you're planning for loki. So, you can merge this all now, but I'd probably remove the CRD schema generation part for v1beta1 until you're ready to start installing that on clusters (ie you have those extra changes in you've talked about)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

can we keep all but just let controller and packages refer back to v1alpha1 so that makes the v1beta version noop and once we ready change them to point to v1beta1 ?

Choose a reason for hiding this comment

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

You can, but if you expose the v1beta1 API into a running cluster (ie a customer cluster via a release), then you have to support the shape it is at that point, you can't then make breaking changes to it from there

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok then better to hold the entire PR so I at least I can keep the whole context together instead of piece meal and regress it
/hold

@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Feb 8, 2023

@msherif1234: This pull request references NETOBSERV-788 which is a valid jira issue.

In response to this:

  • update to v1beta1 version.
  • created conversion webhook using v1beta1 as the HUB and v1alpha1 as the spoke, till we have a new release with v1beta1 then we can make v1beta1 as the storage version.
  • rearrange configs to allow KinD and OpenShift installs since different deployment needs different certifications, to deploy on kind there is new make file option make deploy-kind/undeploy-kind
  • add Makefile new target for conversion auto-gen tool

Signed-off-by: msherif1234 mmahmoud@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Copy link
Contributor

@jpinsonneau jpinsonneau left a comment

Choose a reason for hiding this comment

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

LGTM. Deployed on cluster bot and flows.netobserv.io/v1alpha1 is correctly translated to flows.netobserv.io/v1beta1

@memodi
Copy link
Contributor

memodi commented Feb 9, 2023

/ok-to-test

@openshift-ci openshift-ci bot added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Feb 9, 2023
@github-actions
Copy link

github-actions bot commented Feb 9, 2023

New image: ["quay.io/netobserv/network-observability-operator:815b810"]. It will expire after two weeks.

@memodi
Copy link
Contributor

memodi commented Feb 9, 2023

/rm-ok-to-test

@msherif1234
Copy link
Contributor Author

msherif1234 commented Feb 10, 2023

/hold cancel
since the breaking changes won't happen in the upcoming release(s) then we should proceed as planned and when time comes we will have new api version and by then we should all infra in place to make it just straight fwd

KalmanMeth pushed a commit to KalmanMeth/network-observability-operator that referenced this pull request Feb 13, 2023
@memodi
Copy link
Contributor

memodi commented Feb 15, 2023

/qe-approved
completed basic preliminary testing with NOO image: quay.io/netobserv/network-observability-operator:815b810, comprehensive testing to be followed post-merge.

@jotak
Copy link
Member

jotak commented Feb 15, 2023

thanks!
/approve

@openshift-ci
Copy link

openshift-ci bot commented Feb 15, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jotak

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 90d83f5 into netobserv:main Feb 15, 2023
memodi pushed a commit to memodi/network-observability-operator that referenced this pull request Feb 16, 2023
…serv#258)

* Implementing conversion webhook and add make target for auto conversion

Signed-off-by: msherif1234 <mmahmoud@redhat.com>

* refactor config to allow deployment on OCP or KinD platforms

Signed-off-by: msherif1234 <mmahmoud@redhat.com>

* update bundle

Signed-off-by: msherif1234 <mmahmoud@redhat.com>

* update controllers and pkg to use new api version

Signed-off-by: msherif1234 <mmahmoud@redhat.com>

---------

Signed-off-by: msherif1234 <mmahmoud@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved jira/valid-reference lgtm ok-to-test To set manually when a PR is safe to test. Triggers image build on PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants