-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
Observe the cluster at runtime, support namespace globs & partial resource specs #600
Conversation
This pull request introduces 5 alerts and fixes 1 when merging cbfbb08 into 9fe89e9 - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 4 alerts and fixes 1 when merging 199d9d7 into 214310c - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts and fixes 1 when merging 7bcc7b7 into f5a6dcd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts when merging 3be426f into 53aef59 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 732d0b9 into 53aef59 - view on LGTM.com new alerts:
|
5bc43b8
to
5b3c636
Compare
This is slightly more efficient due to acquiring the lock only once (compared to the for-cycle dropping). And also add some code readability.
The runtime cluster observation lets the operator to know which resources & namespaces actually exist, which, in turn, lets the operator developers to specify the resources by their shorter names instead of their full API endpoints (group-version-plural):
Or even serve the resources by categories:
Or even serve all the resources. It might be a terrible idea to try this on a real cluster unless some filtering is used:
Some other forms of the specifiers are shown in the docs. In particular, kind, singular, plural, short names are supported, with or without groups and versions.
Similarly, due to observation of the existing namespaces, multiple namespaces can be served, specified by globs and negations:
More pattern notations are also mentioned in the docs.
This PR is huge. It could not be made smaller. All unrelated and partially related things are already extracted into separate preparational PRs #576 #575 #572 #597 #598 #596 #608 #609 #610 #622 #623 #624 #626 #627. This PR has also triggered the final removal of the deprecated registries #611 #625 and other deprecated features #511 as a preparation to make it possible to implement it (refactor the reactor's core).
Consider this PR as a full remake of the framework's core the way as it should have been done originally, but it was too early to overengineer it that way.
Addresses the initial framework vision: #57, #85.