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

refactor(kubernetes): Reduce API surface of KubernetesKindProperties #4029

Merged
merged 4 commits into from
Sep 16, 2019
Merged

refactor(kubernetes): Reduce API surface of KubernetesKindProperties #4029

merged 4 commits into from
Sep 16, 2019

Conversation

ezimanyi
Copy link
Contributor

  • refactor(kubernetes): Reduce API surface of KubernetesKindProperties

    Only the statically-defined kinds are allowed to set isDynamic to false, or hasClusterRelationship to true. In order to make this statically true, make the full constructor private and expose a factory method that doesn't allow those properties to be set for use outside the class.

    (Some of the usages of the constructor in tests did set isDynamic and hasClusterRelationship, but these were just testing the API that was available; now that these are not exposed outside the class the tests can just use the factory method.)

  • refactor(kubernetes): Simplify getRegisteredKinds

    The only time we ever use the getRegisteredKinds method in KubernetesKindRegistry, what we actually want is a list of the global kinds (so we can set up the core caching agent).

    We do this by getting all the kinds and filtering on the isDynamic property; it would be simpler to just return the global kinds in the first place. A kind is global if and only if it is not dynamic.

  • refactor(kubernetes): Remove isDynamic property from kind properties

    The prior commit removed the last usage of isDynamic in the KubernetesKindProperties class. Remove the member variable from the class.

  • refactor(kubernetes): Move defaulting logic to account registry

    In preparation for a fix to reduce live CRD lookups, move the defaulting of unknown kinds from the GlobalKubernetesKindRegistry to the account KubernetesKindRegistry.

    This doesn't change the result of calling getRegisteredKind on the account registry, but moves where the defaulting happens.

Only the statically-defined kinds are allowed to set isDynamic to false,
or hasClusterRelationship to true. In order to make this statically
true, make the full constructor private and expose a factory method
that doesn't allow those properties to be set for use outside the class.

(Some of the usages of the constructor in tests *did* set isDynamic and
hasClusterRelationship, but these were just testing the API that was
available; now that these are not exposed outside the class the tests
can just use the factory method.)
The only time we ever use the getRegisteredKinds method in
KubernetesKindRegistry, what we actually want is a list of
the global kinds (so we can set up the core caching agent).

We do this by getting all the kinds and filtering on the
isDynamic property; it would be simpler to just return the
global kinds in the first place. A kind is global if and only
if it is not dynamic.
The prior commit removed the last usage of isDynamic in the
KubernetesKindProperties class. Remove the member variable from
the class.
In preparation for a fix to reduce live CRD lookups, move the defaulting
of unknown kinds from the GlobalKubernetesKindRegistry to the account
KubernetesKindRegistry.

This doesn't change the result of calling getRegisteredKind on the
account registry, but moves where the defaulting happens.
@ezimanyi ezimanyi changed the title Remove isdynamic refactor(kubernetes): Reduce API surface of KubernetesKindProperties Sep 16, 2019
Copy link
Contributor

@ethanfrogers ethanfrogers left a comment

Choose a reason for hiding this comment

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

🚗 🚌 🔨 🌋

Copy link
Contributor

@maggieneterval maggieneterval left a comment

Choose a reason for hiding this comment

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

⬇️ 🌎 🏦

To make sure my mental model is correct: global kinds are equivalent to registered kinds, and global kinds and dynamic kinds are a disjoint set?

@ezimanyi
Copy link
Contributor Author

@maggieneterval : Good question, here are the definitions of the relevant terms:
global kinds: The set of kinds built-in to Spinnaker (ie, the static entries in KubernetesKind.java) that exist across all accounts.
registered kinds: Any kind that is in a registry (so the definition depends on the actual registry we're using). For the global registry this would just be global kinds; for an account-specific registry it would also include kinds configured in the config for the account.
dynamic kinds: Kinds that are not global kinds (as you've said)

I've found these terms pretty confusing and so am slowly trying to get rid of them; this PR finally gets rid of the concept of a dynamic kind.

@ezimanyi ezimanyi merged commit 5d214b3 into spinnaker:master Sep 16, 2019
@ezimanyi ezimanyi deleted the remove-isdynamic branch September 16, 2019 15:32
@maggieneterval
Copy link
Contributor

@ezimanyi thank you! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants