Mechanism to set initializers / places for hooks prior to scheduling #3585

Replace ServiceAccountSecret secret type with a cluster account secret type. Secret types should be named for their contents, not their sources, IMO. (source can live in an annotation or something)

@lavalamp Is there a reason we can't fix ServiceAccountSecret now? It was just merged recently.

Agree, why not just fix it now?

On Thu, May 14, 2015 at 1:25 AM, Brian Grant notifications@github.com
wrote:

@lavalamp https://github.com/lavalamp Is there a reason we can't fix
ServiceAccountSecret now? It was just merged recently.

—
Reply to this email directly or view it on GitHub
#8190 (comment)
.

/subscribe

@bgrant0607 I'm OK with changing it now, but lack cycles to do it myself.

@liggitt... wrong issue? or maybe you can explain in more detail?

@lavalamp my bad, I misread "cluster account secret type" as "cluster-scoped"

Issue filed for ServiceAccount secrets: #8271.

Punted from v1:

• Eliminate most volume sources
• Eliminate phase Pod Phase - Vacating.  #6951
• Replace object names with specialized object references: Create the v1 API #7018 (comment)

Other use cases for subobject plugins:

• Secret providers, such as dockercfg
• Cloud-provider-specific load-balancing info communicated from service controller to kube-proxy (or plugin)

LocalReference: #8503

/subscribe @eparis

@bgrant0607 I assume you are just looking to collect breaking changes here, and not few features?

Suggest we change pointer-to-scalar to pointer-to-struct everywhere, for possible future compat with proto.

@erictune Yes, you are correct.

Generalized image representation: #8702

In addition to eliminating volume sources obsoleted by persistent volume claims (gcePersistentDisk, awsElasticBlockStore, nfs, iscsi, glusterfs, rbd), I'd also like to eliminate gitRepo in favor of a generic container volume mechanism (#831).

+100 to container volume
On Wed, May 27, 2015 at 3:20 AM Brian Grant notifications@github.com
wrote:

In addition to eliminating volume sources obsoleted by persistent volume
claims (gcePersistentDisk, awsElasticBlockStore, nfs, iscsi, glusterfs,
rbd), I'd also like to eliminate gitRepo in favor of a generic container
volume mechanism (#831
#831).

—
Reply to this email directly or view it on GitHub
#8190 (comment)
.

I'd also like to eliminate gitRepo in favor of a generic container volume mechanism

+1

@bgrant0607 I have been thinking for a while now that it's bad that we have gcePersistentDisk and awsElasticBlockStore as volume types that pods need to specify. It seems to me that if we want true workload mobility, we need to abstract this into a separate type, so that you can use the same pod descriptions on any cloud provider. IOW pods shouldn't depend on on the implementation of persistence, they should just request a persistent volume, and (cluster admin via config? cloud provider?) determines the implementation that pods get.

@lavalamp That's what persistentVolumeClaim is for. We just haven't removed the old fields yet.

Maybe it's just me, but there's a low-level annoyance I experience every time I try to look at API files - we document our API fields in terms of javascript-style names (leading lower-case) but Go demands we use leading upper-case. This makes for inconsistent comments and docs. Worse, Go will ignore case for JSON keys if it needs to, so there are probably lurking issues.

So my proposal is that if/when we start the v2 process, we consider explicitly using Go-style field names (leading upper-case). Other APIs (e.g. Docker) do it, and it's not so bad.

As a nice side-effect, go vet will stop complaining at us for a bunch of things.

Adding here so we don't forget (I hope).

Node.status.addresses uses 'type' as merge key but that is not sufficiently unique.

#73977

#81301

Probe.SuccessThreshold validation is contextual and ugly. "must be 1" in an API field is silly.

Associative lists with non-standard keys (and even multi-field keys) were totally a mistake. We should have just used maps. Merging would have been so much simpler.

Associative lists with non-standard keys (and even multi-field keys) were totally a mistake. We should have just used maps. Merging would have been so much simpler.

@bgrant0607 So this is not true anymore? Or is it kept as a convention, but third parties that e.G. develop CRD-based APIs should consider using maps instead?

As mentioned in #73527, we should use proper LabelSelector types for selector (instead of map[string]string as e.g. in Service or even string as in ListOptions) - they cost to much when being processed later many times.

related to #92226 it'd be nice to drop service links - or make them opt-in rather than opt-out.

This issue should really be moved to a doc (or multiple docs, as not everything is API machinery) and updated.

/remove-kind design
/kind feature

kind/design will soon be removed from k/k in favor of kind/feature. Relevant discussion can be found here: kubernetes/community#5641

Given #8190 (comment), should we close this?

I recommend closing. This issue is not actionable at this point.

/close

@sftim: Closing this issue.