rename pod injection

[jessfraz]

from #254 (comment)

we also need to decide on the api group

ping @pmorie @erictune @bgrant0607

[pmorie]

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

[pmorie]

cc @pwittrock @smarterclayton @derekwaynecarr

[derekwaynecarr]

I also heard negative responses to the Policy suffix when discussing this today with folks. Defaults is preferred terminology. In a side note, LimitRange currently straddles a Policy (says no because of min or max constraints) and Defaults. In retrospect having them combined is useful for cluster operators that want to enforce a default is applied, but inhibits users from creating their own defaults based on our typical RBAC setups. I think something like ResourceDefaults would make a lot of sense in the future as well and the name fits there for me too. One concern I have is around API group conventions. If in 1.6 we add this resource as v1alpha1 and in 1.7 we desire to move it to v1beta1. Are we able to add a new *Defaults resource to this group in just the v1alpha1 version? I am admittedly confused on wheee we stand with mixed sets of resources across versions in a group. On Thu, Feb 23, 2017 at 9:33 PM Paul Morie <notifications@github.com> wrote: cc @pwittrock <https://github.com/pwittrock> @smarterclayton <https://github.com/smarterclayton> @derekwaynecarr <https://github.com/derekwaynecarr> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF8dbGT_SELL42oJhxAoawPJSpH0pthGks5rfkGAgaJpZM4MKleW> .

[derekwaynecarr]

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

[derekwaynecarr]

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.

[derekwaynecarr]

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

[pmorie]

I can live with PodServiceDefaults.

How about you @jessfraz ?

[liggitt]

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

[bgrant0607]

@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?

[jessfraz]

settings seems ok to me

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

[pwittrock]

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

[pmorie]

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.

[bgrant0607]

+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.

[jessfraz]

updated

[pmorie]

PodPresetSpec, plz

[jessfraz]

lol

[pmorie]

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

[pwittrock]

SGTM

[derekwaynecarr]

That works for me

…

On Fri, Feb 24, 2017 at 12:23 PM Paul Morie ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF8dbP_yFA6S-oKBOZZcAGdt1EWRkG0jks5rfxIngaJpZM4MKleW> .

[pmorie]

Merging, thanks for tolerating the bikeshedding, @jessfraz

[pmorie]

@smarterclayton did you want to change the name?

[smarterclayton]

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.

[smarterclayton]

No I decided i liked PodPreset because someone unprompted called it a preset in describing the concept.

…

On Mon, Feb 27, 2017 at 1:45 PM, Paul Morie ***@***.***> wrote: @smarterclayton <https://github.com/smarterclayton> did you want to change the name? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p_vxuJeRG_t1jvUa_OeVYUC_dFL7ks5rgxnTgaJpZM4MKleW> .