There seem to be two issues to settle:

1. The name of the API group
2. The name of the resource

I agree that the 'policy' name should be about what is allowed to do a thing. By that measure, this is not a policy at all. I like 'settings' as a name for this type of resource. How about this:

• API group: settings
• Resource name: ServiceInjection

cc @pwittrock @smarterclayton @derekwaynecarr

settings is fine too but I think injection should be avoided in favor of defaults.

How about API group settings and resource name is PodServiceDefaults? I think having the noun associated with the resource it mutates on admission front and center will avoid user confusion. Having Service* kind of obfuscates that it impacts Pods and not Services.

saying kubectl get podservicedefaults is not the worst thing...

I can live with PodServiceDefaults.

How about you @jessfraz ?

Remember that groups get k8s.io suffix. kubectl will find specified resources via server-specified discovery order and do fuzzy matching on group names, so any of the following would work:

kubectl get podservicedefaults
kubectl get podservicedefaults.settings
kubectl get podservicedefaults.settings.k8s.io

@jessfraz Sorry I wasn't clear. I'd like to nix "Service", "Injection", and "Policy".

I like "settings" for the name of the API group.

"Defaults" doesn't quite fit, since the values in the Pod don't gracefully override the values in this resource, according to the proposal.

PodPresets?

@derekwaynecarr Is there a reason you wouldn't add compute resources to this API?

settings seems ok to me

is pod presets ok? i'll wait for status quo before doing find replace lol

@bgrant0607 WDYT of "Dependencies" instead of "Defaults"? This looks similar to Inversion of Control software design principles.

I think settings is best for the name of the group, and PodPreset is fine for the name of the resource. It's hard to find a perfect name that will be perfect forever; I think settings/PodPreset is plenty-good.

+1 to settings/PodPreset.

@pwittrock While this is similar in some ways to dependency injection, the mechanism is (deliberately) more general purpose than that. For example, it could be used just to set an environment variable in a group of pods.

updated

LGTM - I'll give it 30 min and then merge if no one objects.

SGTM

Merging, thanks for tolerating the bikeshedding, @jessfraz

@smarterclayton did you want to change the name?

I'm trying to reconcile "settings" to how we'd present this in UIs and in relation to other existing groups. Not opposed to it, although as a group it might be too close to "extensions" (grab bag for my stuff). I'll squawk if I can come up with an objection.