Move validation to be per-API-version

[thockin]

Validation as it exists today is pretty wrong - it tracks internal types. Once we have long-term support for v1 API and are deep into v2 rework, the validation errors that are produced for v1 will be less and less useful.

We've gone back and forth about this but have not yet come up with a good answer on how to do this generically. I propose we just move it to be per-version, same as defaulting.

Given that v1beta[12] are on the block right now and v1beta3 will be soon, this is the right time. The same day we delete v1beta3 we should move pkg/api/validation into v1 and make it use versioned types.

Yes, it will be tedious to make changes, but I think that is the cost of having multiple versioned APIs in support cycles.

[nikhiljindal]

My impression was that we have decided that we want to go this path.
Its not part of 1.0 since that will have just one API version: #3084 (comment)

[hurf]

Agree with @thockin , put validation on internal structs also looks odd to me. I think better to validate template itself for each version. Though #3084 may not be an issue now, it will come out along with v2, sooner or later we had to resolve this problem. I guess @nikhiljindal 's concern is mainly about limited timeline?

[bgrant0607]

I think we have agreed in principle that validation should be versioned. I don't see this happening before 1.0, however. We should do it before introducing the v2 api.

See also #3084, #5889, #8116, #6210, #1451

@lavalamp @smarterclayton

[thockin]

That's fine, my point was we should do it after v1b3 dies and before v2b1
is born :)

On Wed, May 20, 2015 at 11:09 AM, Brian Grant notifications@github.com
wrote:

I think we have agreed in principle that validation should be versioned. I
don't see this happening before 1.0, however. We should do it before
introducing the v2 api.

See also #3084
#3084, #5889
#5889, #8116
#8116, #6210
#6210, #1451
#1451

@lavalamp https://github.com/lavalamp @smarterclayton
https://github.com/smarterclayton

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

[nikhiljindal]

cc @caesarxuchao

[bgrant0607]

Ref #8190 so that it's on my "v2" radar.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[bgrant0607]

/remove-lifecycle stale
/lifecycle frozen

[sftim]

Can I check: is this issue still relevant? If it is, how does it manifest? (eg: as maintenance toil for contributors)

[liggitt]

I think completely per-version validation will cause more bugs than it fixes. Keeping open-coded validation rules consistent between multiple versions sounds really difficult to get right (both to write and to test).

We have the ability to propagate the request version into validation when we need to, and have used that in a few places to do ratcheting or version-specific validation, but generally, we expect all versions of an API to pass the same validation rules.

[thockin]

What we have is "obviously" wrong but works in practice. We have very few places where the field-path differs between API versions, so special-casing those works "well enough". It's smelly but not the worst smelling hunk of code we have. Doing it per-version would have a LOT of duplicated-but-identical code.

If/when we have a v2 of something major, we may want to revisit this. Hopefully by then we will have declarative validation for all but the most bespoke logic. Then we have to keep the decalarations in sync across API versions, but hopefully we can automate most of that.