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.

@smarterclayton @thockin PTAL

Assigning to @smarterclayton, feel free to re-assign.

@smarterclayton actually, now that I look at the function signature, since PrepareForCreate/Update doesn't return anything right now, we won't be able to stop a create/update from proceeding when there's a referential integrity issue (i.e. not authorized for Bob to access Alice's ImageStream).

Does it make sense to have these methods return a ValidationErrorList? or an error?

Maybe an error. However, that gets into the question of why wouldn't this then be folded into Validate, where there is just two parts of validation in the strategy - inherent, and referential.

Having Prepare* return an error seems to just be duplicating Validate*

I thought you had said you didn't want to do referential integrity checking in the Validate* methods. I'm quite happy to modify Validate and ValidateUpdate to take in the ctx instead.

Not the core Validate methods - the Strategy validate methods.

On Mar 30, 2015, at 1:19 PM, Andy Goldstein notifications@github.com wrote:

I thought you had said you didn't want to do referential integrity checking in the Validate* methods. I'm quite happy to modify Validate and ValidateUpdate to take in the ctx instead.

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

@smarterclayton updated to pass ctx to the Validate* strategy methods

After you fix that one line LGTM

Goimports isn't smart enough to know that "fmt" and "strconv" are in the same group, it just knows that strconv doesn't belong with the deeply nested types.