Create the v1 API

[bgrant0607]

We're still finishing loose ends on v1beta3, but we need to clone it into the v1 API soon, and stop making breaking changes to v1beta3. As with v1beta3, v1 shouldn't be exposed by default and shouldn't be the latest API version until we freeze it.

[thockin]

Do we have a list of candidate changes for v1 as compared to v1b3?

On Fri, Apr 17, 2015 at 8:27 PM, Brian Grant notifications@github.com
wrote:

We're still finishing loose ends on v1beta3, but we need to clone it into
the v1 API soon, and stop making breaking changes to v1beta3. As with
v1beta3, v1 shouldn't be exposed by default and shouldn't be the latest API
version until we freeze it.

—
Reply to this email directly or view it on GitHub
#7018.

[bgrant0607]

Mostly this is intended to be a rename of the API.

Possible changes:

• cleanup ContainerStatus/ContainerState (s/termination/terminated/, reconsider use of "State", key vs. value REST api - container status is represented in an inconvenient fashion #6979)
• eliminate Phase Pod Phase - Vacating.  #6951
• eliminate most volume sources
• split API into multiple prefixes split api in to cluster and pod/user portions #3806

[thockin]

Can I add "make some optional fields into pointers for clearer denotation" ?

I am torn on volume sources. I am reviewing PV stuff still, I am just
nervous about how new it is..

On Mon, Apr 20, 2015 at 9:34 AM, Brian Grant notifications@github.com
wrote:

Mostly this is intended to be a rename of the API.

Possible changes:

• cleanup ContainerStatus/ContainerState (s/termination/terminated/,
  reconsider use of "State", key vs. value REST api - container status is represented in an inconvenient fashion #6979
  REST api - container status is represented in an inconvenient fashion #6979)
• eliminate Phase Pod Phase - Vacating.  #6951
  Pod Phase - Vacating.  #6951
• eliminate most volume sources
• split API into multiple prefixes split api in to cluster and pod/user portions #3806
  split api in to cluster and pod/user portions #3806

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

[derekwaynecarr]

I would like to see us support

delete /namespace/foo/pods

This would delete all pods in namespace foo.

It would literally delete the folder node that contained all pods in that namespace in etcd.

[bgrant0607]

Maybe another pass on /componentstatuses, which was prematurely merged #6597.

[bgrant0607]

We shouldn't need to wait until v1 in order to change the Go structs.

[thockin]

I was specifically thinking about #6735 which would change the default
value of replication controller.

On Mon, Apr 20, 2015 at 4:25 PM, Brian Grant notifications@github.com
wrote:

We shouldn't need to wait until v1 in order to change the Go structs.

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

[bgrant0607]

Ah right, default of 1 replica rather than 0 replicas.

There's also the issue of changing the default cleanup behavior of replication controllers, as discussed in #1535 (comment)

[bgrant0607]

Deduplication of SecurityContext-related fields (#6287) in Pod. cc @erictune

[bgrant0607]

StatusDetails ID field should be name: #7333

[thockin]

ServiceStatus should have a Phase

On Mon, Apr 27, 2015 at 4:19 PM, Brian Grant notifications@github.com
wrote:

StatusDetails ID field should be name: #7333
#7333

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

[bgrant0607]

Or nothing should have a Phase. :-)

[bgrant0607]

As suggested in #6910, perhaps we should eliminate the term "portal".

[thockin]

VIP ? But it might not always be Virtual - you could imagine an "internal"
load balancer that worked better - HAProxy or something - and using real
IPs. Just IP, maybe?

On Mon, Apr 27, 2015 at 7:40 PM, Brian Grant notifications@github.com
wrote:

As suggested in #6910
#6910, perhaps
we should eliminate the term "portal".

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

[thockin]

#6979 proposes rejiggering some of the named-one-of fields. better API, but requires cusotm JSON unmarshalling code.

[bgrant0607]

Another possible issue: expanded image spec: #7203

[bgrant0607]

api.Pod.Host vs. Node: #6895

[bgrant0607]

Generalized label selectors: #7053 / #341

[bgrant0607]

Created a new issue for replacement of phase with condition: #7856.

[bgrant0607]

Clarification: Replacement of phase is almost certainly out for v1. I just referenced it for completeness.

[bgrant0607]

We might want to reconsider use of ObjectReference in the API.

For cases in object specs where kind, namespace, and api version are fixed and where uid, resource version, etc. aren't supported for stronger consistency, it's simpler to just specify an object name.

I still feel that ObjectReference is probably easier for clients to deal with generically when comprehending objects, though, so we should use it in status, where necessary.

Current fields in specs:

Names: PodSpec.Host, PersistentVolumeClaimVolumeSource.ClaimName, GlusterfsVolumeSource.EndpointsName, SecretVolumeSource.SecretName, PodSpec.ServiceAccount

ObjectReference: PersistentVolumeSpec.ClaimRef, ServiceAccount.Secrets, PodSpec.PullSecrets, ReplicationControllerSpec.TemplateRef, Binding.Target, EnvVarSource.FieldRef (subset)

[bgrant0607]

v1 is enabled by default, is the preferred API version, and is tested as much as v1beta3.

Docs/examples are covered by #9286.