Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pod templates as their own type #5012

Merged
merged 4 commits into from
Apr 22, 2015

Conversation

smarterclayton
Copy link
Contributor

This pull request adds pod templates as their own type (first step towards #170). Having
a distinct type allows their use to be clearly delineated for end users, to have their
own independent validation rules, and to simplify interactions from the client. This does
not prevent pods from having "inert" behavior in the future that can also be used for
templates. Replication controllers should work against inert pods or pod templates equally.

Only the last commit is new - the others are issues found while trying to support a
type that only exists in v1beta3.

@googlebot
Copy link

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

@pmorie
Copy link
Member

pmorie commented Mar 4, 2015

@liggitt since we were just talking about this
On Tue, Mar 3, 2015 at 11:05 PM Clayton Coleman notifications@github.com
wrote:

This pull request adds pod templates as their own type (first step towards
#170 #170).
Having
a distinct type allows their use to be clearly delineated for end users,
to have their
own independent validation rules, and to simplify interactions from the
client. This does
not prevent pods from having "inert" behavior in the future that can also
be used for
templates. Replication controllers should work against inert pods or pod
templates equally.

Only the last commit is new - the others are issues found while trying to
support a

type that only exists in v1beta3.

You can view, comment on, or merge this pull request online at:

#5012
Commit Summary

  • genericetcd.Etcd should test resourceVersion
  • Stop round trip testing in latest
  • Skip types that are not registered on an API version
  • Stop logging stack traces for 4xx requests
  • Switch List/Watch to ListPredicate/WatchPredicate
  • Enumerate all versions when looking for an output conversion
  • Use IsListType instead of checking ItemPtr in resourcebuilder
  • Pod Templates
  • Only insert outputversion as a preferred mapping type if no error
    occurs

File Changes

Patch Links:


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

@bgrant0607
Copy link
Member

Thanks!!

The main change is now the next-to-last commit. :-)

I'm fine with the API. I can see the benefit of an explicit template.

One thing to consider for separate templates: We may want to allow users to specify the resourceVersion of the template in the ObjectReference (the necessary field already exists) and force the replication controller to observe the specified version before it creates any new pods, for WAW consistency, if the user cares.

When this is ready for full review, let me know, though I may need to punt it to someone else.

@bgrant0607
Copy link
Member

I'm fine with this being v1beta3 only. I want to finalize v1beta3 and flip to it as the default asap.

Looking at the json, I see why you changed "spec" to "template". My main concern is whether we might add status in the future, such as to publish the last time the template was used to create a pod.

@smarterclayton
Copy link
Contributor Author

I could certainly imagine a status in the future. Is an object that behaves like a template having a root "template" field better (obviousness) vs encouraging others to invent things besides spec. My thought was that spec is a real object which is converged, while a template isn't. Might be good to get a few other opinions.

On Mar 14, 2015, at 7:52 PM, Brian Grant notifications@github.com wrote:

I'm fine with this being v1beta3 only. I want to finalize v1beta3 and flip to it as the default asap.

Looking at the json, I see why you changed "spec" to "template". My main concern is whether we might add status in the future, such as to publish the last time the template was used to create a pod.


Reply to this email directly or view it on GitHub.

@bgrant0607
Copy link
Member

@smarterclayton You're logic is reasonable. I don't really want to bikeshed on this particular topic. Let's go with template.

@piosz
Copy link
Member

piosz commented Apr 8, 2015

Is this PR active? If not please close it according to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/pull-requests.md

@smarterclayton
Copy link
Contributor Author

Yes

On Apr 8, 2015, at 12:54 PM, Piotr Szczesniak notifications@github.com wrote:

Is this PR active? If not please close it according to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/pull-requests.md


Reply to this email directly or view it on GitHub.

@smarterclayton smarterclayton changed the title WIP - Pod templates as their own type Pod templates as their own type Apr 20, 2015
@smarterclayton
Copy link
Contributor Author

Rebased and ready to use.

@smarterclayton
Copy link
Contributor Author

Ready for review

@bgrant0607
Copy link
Member

Cool, thanks. Will take a look.

You're getting a gendocs failure due to the addition of a new noun.

@wojtek-t
Copy link
Member

/subscribe

@smarterclayton
Copy link
Contributor Author

Yes

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

Looks pretty good. Found only one minor problem.

The next steps are to expose a subresource for creating pods from the
template, and then to use that in the replication controller?


Reply to this email directly or view it on GitHub:
#5012 (comment)

}

// NewREST returns a RESTStorage object that will work against pod templates.
func NewREST(h tools.EtcdHelper) *REST {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love how simple this is now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, reduced about 5k lines from openshift code base.

@smarterclayton
Copy link
Contributor Author

Comments addressed.

@bgrant0607
Copy link
Member

Please regenerate the kubectl docs.

@bgrant0607
Copy link
Member

LGTM. Waiting for Travis.

@bgrant0607 bgrant0607 added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 21, 2015
@bgrant0607
Copy link
Member

# github.com/GoogleCloudPlatform/kubernetes/pkg/registry/controller/etcd
_output/local/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/registry/controller/etcd/etcd_test.go:78: unknown api.PodTemplate field 'Spec' in struct literal
FAIL    github.com/GoogleCloudPlatform/kubernetes/pkg/registry/controller/etcd [build failed]

@smarterclayton
Copy link
Contributor Author

Weird.

@bgrant0607
Copy link
Member

Rerunning Travis. I have no idea what happened. Looks like Template to me.

@bgrant0607
Copy link
Member

Hmm. Still fails.

@bgrant0607 bgrant0607 removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 22, 2015
@smarterclayton
Copy link
Contributor Author

Fixed, merge changes coming in.

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

https://github.com/GoogleCloudPlatform/kubernetes/blob/1a2e4f8e1d35b38fde55414a3c61347f5894a24f/pkg/registry/controller/etcd/etcd_test.go#L63


Reply to this email directly or view it on GitHub:
#5012 (comment)

@bgrant0607
Copy link
Member

Thanks. Tests passed, but needs to be rebased, apparently.

@bgrant0607 bgrant0607 added lgtm "Looks good to me", indicates that a PR is ready to be merged. cla: yes and removed cla: no labels Apr 22, 2015
@smarterclayton
Copy link
Contributor Author

Rebased and travis is green

bgrant0607 added a commit that referenced this pull request Apr 22, 2015
@bgrant0607 bgrant0607 merged commit 97302af into kubernetes:master Apr 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. area/apiserver kind/design Categorizes issue or PR as related to design. lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants