Initial v1beta2 (experimental) cut

[smarterclayton]

@ncdc review please

This enables v1beta2 as experimental, exposing only the new v1beta2 objects.

[smarterclayton]

@bparees @pweil- @ironcladlou this does not include builds, routes, or deployments, the latter two will need a "spec" / "status", and the former should include the issues discussed in other threads. Can you guys make sure there is a card / issue to track each of those sections into v1beta2? Thanks.

[smarterclayton]

@deads2k @liggitt see the last commit - in order to properly default values (using the scheme defaults) the internal version needs to go through a conversion. This makes defaults versionable (which they aren't today).

[deads2k]

I'm not clear why we would want to version our default values is a way that is separate from us building the config itself. I would have said that the buildSerializeableConfig methods were a giant defaulter intended for matched set usage. Either we'd serialize out however we want into a fresh file or we'd use the memory copy directly. I can't envision a scenario where we'd want the config to built in a stale scheme.

[smarterclayton]

If you have value defaulting, you can't change those defaults once real values are in the wild. Since we will ship config that we have to add things to, we will have to set default values for a particular version of API objects. So defaults have to come from a version. It's really no different than our other API objects.

On Apr 13, 2015, at 8:00 AM, David Eads [email protected] wrote:

I'm not clear why we would want to version our default values is a way that is separate from us building the config itself. I would have said that the buildSerializeableConfig methods were a giant defaulter intended for matched set usage. Either we'd serialize out however we want into a fresh file or we'd use the memory copy directly. I can't envision a scenario where we'd want the config to built in a stale scheme.

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

[deads2k]

Defaults that are set during read will happen during the existing conversion process. If it's a concern that there will be value drift, why not continue to build the config using the in-memory representation and round-trip it through conversion before usage?

[deads2k]

Wouldn't we always round trip through the latest version of the scheme? I don't see why we'd continue using the old scheme for building the config in code.

It seems like our config validation (against the in-memory package) is going to force any bad defaulting into the open. At the very least, it would prevent usage.

[smarterclayton]

So that we don't have support to round tripping old config versions.

On Apr 13, 2015, at 8:53 AM, David Eads [email protected] wrote:

Defaults that are set during read will happen during the existing conversion process. If it's a concern that there will be value drift, why not continue to build the config using the in-memory representation and round-trip it through conversion before usage?

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

[smarterclayton]

The only risk is if we have behavior that can't be expressed in the external storage version (like objects internally that are read). If you think we have no expectation of doing that, we can round trip to latest.

However, it's looking likely that we will start using versioned objects internally for all the reasons mentioned and a few more. Validation is likely to move to external objects as well. We don't have to beat the rush, but we do need to be aware.

On Apr 13, 2015, at 9:01 AM, David Eads [email protected] wrote:

Wouldn't we always round trip through the latest version of the scheme? I don't see why we'd continue using the old scheme for building the config in code.

It seems like our config validation (against the in-memory package) is going to force any bad defaulting into the open. At the very least, it would prevent usage.

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

[ncdc]

I know we just created this as part of the ImageStream work, but I'm questioning if TagReference is the appropriate name for this type. It's entirely valid to have annotations for a tag without there being any "reference" part. Would TagSpec or something along those lines be more appropriate?

[smarterclayton]

Sure.

----- Original Message -----

+type ImageStream struct {

• kapi.TypeMeta json:",inline"
• kapi.ObjectMeta json:"metadata,omitempty"

• // Spec describes the desired state of this stream
• Spec ImageStreamSpec json:"spec"
• // Status describes the current state of this stream
• Status ImageStreamStatus json:"status,omitempty"
  +}

+// ImageStreamSpec represents options for ImageStreams.
+type ImageStreamSpec struct {

• // Optional, if specified this stream is backed by a Docker repository on
  this server
• DockerImageRepository string json:"dockerImageRepository,omitempty"
• // Tags map arbitrary string values to specific image locators
• Tags []NamedTagReference json:"tags,omitempty"

I know we just created this as part of the ImageStream work, but I'm
questioning if TagReference is the appropriate name for this type. It's
entirely valid to have annotations for a tag without there being any
"reference" part. Would TagSpec or something along those lines be more
appropriate?

---

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1694/files#r28236941

[pweil-]

@bparees @pweil- @ironcladlou this does not include builds, routes, or deployments, the latter two will need a "spec" / "status", and the former should include the issues discussed in other threads. Can you guys make sure there is a card / issue to track each of those sections into v1beta2? Thanks.

Yep, I have a card for the multi-port changes that were in the new rebase

[smarterclayton]

@deads2k all comments addressed PTAL

[deads2k]

One comment, otherwise the last commit lgtm.

[derekwaynecarr]

[test]

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1833/)

[smarterclayton]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1591/) (Image: devenv-fedora_1286)

[openshift-bot]

Evaluated for origin up to 6a7364d