Change:
// registering all of these functions. Then, if you want to be able to understand // v1beta1 objects, you just import that package for its side effects. AddConversionFuncs( <del> // EnvVar's Name is depricated in favor of Key. </del> <ins> // EnvVar's Key is deprecated in favor of Name. </ins> func(in *EnvVar, out *v1beta1.EnvVar) error { out.Value = in.Value out.Key = in.Name

Discussion:
I'm trying to make sure I understand how Kubernetes will maintain compatibility between current and future api versions. While digging through the api and conversion packages I noticed the comment at states that EnvVar.Key will be deprecated soon. When I look in the conversion functions at it seems like EnvVar.Key is preferred over name. Should I assume both Key and Name are going away?
Name is staying, Key is going away. If you take another look at the file, you'll see that when we copy from internal to v1beta1, we set both Key and Name (to maintain compatibility with clients using Key). When we copy from v1beta1 to internal, we look at Key only if Name == "", that is, Name takes precedence if it's set. ...Unfortunately, the comment there is backwards, which is my fault, I'm sure.
Sorry about the confusion!
At some point we talked about just changing env to be a map[string]string and accepting it as such in JSON/YAML. Any feelings here? I think it might make a better API for humans , Daniel Smith wrote:
I'm OK with that and am willing to write the code to make it happen if everyone else is, too.
Yeah, that comment in was throwing me for a loop. I think the rest is making sense to me now so feel free to close this whenever the comment is updated. On a related note, the comments on sound promising to me. Right now I'm wrapping my head around what upgrading Kubernetes infrastructure is going to be like for admins (essentially, how hard will it be to perform rolling updates when APIs change between versions).
Yeah, while we don't have an official policy about version lifecycle/deprecation timeframe, it is on our roadmap to produce one. Ideally, churn will be low and the number of supported older versions high enough that updating one's config files is an infrequent activity. Additionally, given the way we're doing this, it would be easy for us to provide a tool that automatically updates config files to the latest version.
About moving to for this -- I'm torn on these things. It does look better but it can also make the serialization of the API more confusing when written out -- especially for the novice user.

Specifically, the way things are now it is very clear that when you serialize this as YAML that everything of the left side of an assignment is a system defined string while everything on the right side is something that the user provides. I admit, for things like environment variables things are pretty self explanatory. But it breaks the pattern. I'd be afraid we'd try and apply the same pattern (user values on the left) in other places where the semantics aren't as clear.
that's why I invoked your name - I think you feel most strongly of all of us, and given that you get veto power. I yield the floor to the gentleman from Seattle. , Joe Beda wrote:
Yeah -- let's leave it as-is for now. I thought of an example where we'd be tempted to follow this pattern and it'd be more confusing. Let's apply the same thing to . We have a name on and we could easily change to be a . But because ports don't have the same historical semantics new users might be confused if the port name is magic or not. Basically I think that this: Is less confusing than this: Even though the second one is shorter, to the novice user it looks like and are both magic system keywords when actually is just a user provided token.
I agree that the second is a step back for ports. For env it's a lot more obvious, but it is harder to hold the line once you have crossed it once. , Joe Beda wrote:
I agree that Joe's example is not a thing we should do, and also agree that it's much clearer with env vars. I think there's probably room in the middle of this slippery slope.