-
Notifications
You must be signed in to change notification settings - Fork 119
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
rename registry clusteroperator resource plus file renames+cleanup #189
Conversation
bparees
commented
Feb 4, 2019
•
edited
Loading
edited
- add clusteroperator skeleton to our manifest so the CVO respects it
- rename our manifests dir to "manifests" to align w/ other operators
- remove what appeared to be some dead files
bc480dc
to
b602d96
Compare
/assign @dmage @legionus @coreydaley |
/hold we'll want to see this pass e2e-aws multiple times to ensure we're not going to block the installer w/ this change |
/assign @dmage @legionus @coreydaley |
/refresh |
/test e2e-aws |
/retest |
@smarterclayton @deads2k @abhinavdahiya i'm trying to add the image-registry clusteroperator resource to the manifest, but the CVO seems to be having issues picking it up:
the CRD was defined here:
and other cluster operator resources are managed w/o issue:
and there is no sign the registry operator was actually created (would normally happen after the clusteroperator resource was created based on our resource ordering), so i don't know what else would be deleting/interacting with that resource. Is it invalid to create the clusteroperator resource before creating the operator (because the CVO is going to wait for the clusteroperator to report available before instantiating the rest of the manifest resources)? Still wouldn't explain why it's reported as removed though.. |
/retest |
1 similar comment
/retest |
/retest |
still needs review please |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bparees, coreydaley 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 |
Assuming you mean stuff like this: I picked that pattern up elsewhere in origin (though i'm sure it's not consistent). In general I try to name the aliases in such a way that the references in the code make sense. (ie when you're reading the code, "configv1.Foo" doesn't tell you as much as "configapiv1.Foo" does. And don't get me started on "v1.Foo") Also since you can have a config client v1 and a config api v1, i didn't want to just call this "configv1" and then later when someone also imports client we'd have "clientconfigv1" and "configv1" which makes it unclear to someone reading the code who just sees "configv1" what it is. So better to head off the ambiguity up front, imho, because no one's going to refactor configv1 to apiconfigv1 when they add clientconfigv1. as for "apiconfigv1" vs "configapiv1", the latter reads more naturally to me (and again, is what i've seen elsewhere in origin). tldr: i prefer readability/clarity over arbitrary style guide recommendations |
Despite the fact that I agree with the reasoning, I don't like the |
we can certainly retain an exception for corev1 and metav1, I agree that I don't want to go search+replace the world. I'm not even suggesting we go change any of our existing ones, but as I find them in files i'm working on, I try to update them. (example of the pattern i'm trying to follow from origin: (note that they used "kapiv1" for corev1 in that file, so it's all an inconsistent mess anyway: |
New changes are detected. LGTM label has been removed. |
/refresh |
/test e2e-aws |
3 similar comments
/test e2e-aws |
/test e2e-aws |
/test e2e-aws |
/hold cancel |