-
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
Install build strategies via operator #171
Install build strategies via operator #171
Conversation
if !crdExists { | ||
return true, nil | ||
} | ||
// Apply the provided manifest containing the build strategies |
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.
After checkiing crds, shouldnt we wait also for the webhook svc to be up, otherwise we will face a connection refused error when we apply the stragetgies
I have seen this issue happening when the webhook is not up, and with parallel controllers, now that the logic is after the webhook install, we may not have the issue
conversion webhook for shipwright.io/v1beta1, Kind=ClusterBuildStrategy failed: Post \"https://shp-build-webhook.shipwright-operator.svc:443/convert?timeout=30s\": dial tcp 10.96.125.48:443: connect: connection refused
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.
Great point! I think this explains a lot, especially with the tests driven by EnvTest. Unlike a real cluster, we have no pods being deployed for the webhook (or service, for that matter). I'll switch to using the v1alpha1
samples to see if that fixes the issue by avoiding the conversion webhook invocation.
Add shipwright-io/build v0.12.0 as a dependency, with additional updates via `go get`: - Update ginkgo to v2.13.0 - Update k8s.io/* to v0.26.9
b72656a
to
5260204
Compare
Install the build strategy samples from shipwright-io/build, at the v0.12.0 tag. Only cluster build strategies were added - namespace scoped build strategies were dropped. Red Hat-specific strategies were also dropped, in part to avoid potential trademark issues. The build strategies use v1alpha1 APIs because this is the stored version in v0.12.0. Testing revealed that if we reconciled v1beta1 APIs, we would need to wait for (and mock out!) the conversion webhook deployment. Lastly, the operator was granted RBAC permission to administer all ClusterBuildStrategies. Reconciling build strategies required adding logic to wait for the required CRDs to be installed on the cluster first. If a requeue is required, the operator will report the Ready status condition as "Unknown." The manifestival library code also had to enhanced to optionally recurse a directory for manifests to deploy. Finally, development of this feature revealed refactoring opportunities with respect to our use of k8s and controller-runtime client libraries, and the way we are organizing/managing Manifestival-driven reconcilers. Some refactoring of test code was included to simplify future testing efforts.
5260204
to
d423d71
Compare
/assign @jkhelil Thanks for pointing me in the right direction wrt. the conversion webhook. Reconciling with the "stored" api version bypasses the need to wait for the conversion webhook to be ready. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jkhelil 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 |
/lgtm |
Changes
Enhance the operator to install a set of sample cluster build strategies. These were hand-copied from shipwright-io/build samples, only including
ClusterBuildStrategy
objects.Fixes #155
/kind feature
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes