-
Notifications
You must be signed in to change notification settings - Fork 19
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
Update operator-sdk version #74
Update operator-sdk version #74
Conversation
9bb3814
to
b2d5107
Compare
@ebaron I had to do a lot of messing about with go module stuff before getting this to work, so please test out |
9ad86b2
to
1dc1add
Compare
I'm still working on the bundling part. It seems like the bundles created by operator-sdk are not the same thing as what operator-courier made. Quay accepts uploads of them, but I haven't yet tested what happens if you try to consume that from the marketplace. |
bed3bf5
to
850f7dd
Compare
I think these docs are relevant for this bundling format, but I'm still trying to piece it together. I haven't found anything like a migration guide or explanation of this bundling vs operator-courier. Maybe I should just push it to Quay and see what my cluster's marketplace makes of it. https://github.com/operator-framework/operator-registry/#manifest-format https://github.com/openshift/enhancements/blob/master/enhancements/olm/operator-bundle.md#docker |
I'm not sure how to see any logs the marketplace/OperatorHub might be producing, but it looks like it's silently ignoring my custom operator source when I point it at my namespace and the latest bundle is one produced by operator-sdk. The bundle produced does look very different from what operator-courier does when inspected manually, so I really don't know what to do with this bundle format. |
Ah, okay. Part of my issue was with the |
Here's a comparison from my namespace of $ tree
.
├── andrewazores_container-jfr-operator-bundle_0.3.3
│ └── container-jfr-operator-bundle-54tn2q3f
│ ├── 0.3.1
│ │ ├── container-jfr-operator-bundle.v0.3.1.clusterserviceversion.yaml
│ │ ├── containerjfrs.rhjmc.redhat.com.crd.yaml
│ │ └── flightrecorders.rhjmc.redhat.com.crd.yaml
│ ├── 0.3.2
│ │ ├── container-jfr-operator-bundle.v0.3.1.clusterserviceversion.yaml
│ │ ├── containerjfrs.rhjmc.redhat.com.crd.yaml
│ │ └── flightrecorders.rhjmc.redhat.com.crd.yaml
│ ├── 0.3.3
│ │ ├── container-jfr-operator-bundle.v0.3.3.clusterserviceversion.yaml
│ │ ├── containerjfrs.rhjmc.redhat.com.crd.yaml
│ │ └── flightrecorders.rhjmc.redhat.com.crd.yaml
│ ├── container-jfr-operator-bundle.package.yaml
│ └── openshift
│ └── operator-source.yaml
└── andrewazores_container-jfr-operator-bundle_0.4.0
├── container-jfr-operator-bundle.v0.4.0.clusterserviceversion.yaml
├── metadata
│ └── annotations.yaml
├── rhjmc.redhat.com_containerjfrs_crd.yaml
└── rhjmc.redhat.com_flightrecorders_crd.yaml
|
9198324
to
18535cc
Compare
It's a bit confusing, but my impression is that this new operator-registry format doesn't use an application repository like we currently do. I think we need to add the steps in
Going by https://github.com/operator-framework/operator-registry/#using-the-index-with-operator-lifecycle-manager, I think we then need to replace our OperatorSource with a CatalogSource pointing to our index image. Then a user can access the operator, by applying the CatalogSource to their cluster. I could very well be wrong, but that's my interpretation of how this all works now. |
That was a great tip, I think I've made some more progress. Testing it out currently. But, in the meantime before I forget - if you try that out yourself, you'll currently need to build operator-framework/operator-registry manually and get a local copy of |
That last commit /seems/ to work using that new bundling/index/catalog system. The catalog-source points to an index in my personal Quay namespace for the time being, and all the bundles indexed are also in my own namespace. Those will be cleaned up once we've verified this all works correctly and we can generate those bundles and the index and push them to the team namespace. |
cdb38d9
to
757b98b
Compare
I ran through the steps myself, and everything seems to work. Nice work! |
25508e4
to
6378fee
Compare
775a4f6
to
ddb2228
Compare
Sorry for the dozen force-pushes that just happened. I went through and cleaned up the two WIP commits, but also realized there was a left behind "clean-bundle" Make recipe, and then tried scorecard testing and ran into a few CRD issues. Also realized that I had copied in several newer CSV versions that were from my personal namespace and which don't reflect versioning in the real upstream repositories. I think this is more or less cleaned up and ready now. Scorecard testing still fails with the following however:
|
That's odd, I wonder if they expect us to remove |
Not sure. I can take a further look into it separately though if that's okay. |
I'm also not sure what it's complaining about with the |
It looks like the group name is wrong for the alm-examples. Should be rhjmc.redhat.com instead of apiextensions.k8s.io. |
315ce43
to
15020a3
Compare
Yep, the group name part fixed the examples piece. The status field tests are still failing but the overall result looks much better:
|
@ebaron do you think this can be merged without fixes for the scorecard test results above? I've spent some time poking at them so far but haven't figured out what exactly is expected yet. In any case, it seems like they're only tangentially related to the SDK upgrade. I'll do a last double-check smoke test that everything still works as expected with the last few changes I made, but nothing has changed significantly since end of last week when the bundling and index pieces got put in. |
Update operator-sdk to 0.15.2 and update related dependencies, replace deprecated openapi code generation command with new binary, and first pass of updated generated CRDs and openapi code Related to cryostatio#73
8ad433c
to
35a116f
Compare
Rebased. |
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.
Looks good, just a couple comments below.
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.
Good to go from my end. Nice work!
This updates the operator-sdk version and related generated files. In my testing this works up to the point of
make image
andmake deploy
, and the resulting operator logs show that the sdk version is indeed 0.15.2 and everything appears to work correctly. Not yet done is replacing operator-courier and using the newer sdk version to create the operator bundles.