Extended.[images] openshift limit range admission should deny a push of built image exceeding limit on openshift.io/images resource

[bparees]

[Fail] [images] openshift limit range admission [It] should deny a push of built image exceeding openshift.io/Image limit 
/data/src/github.com/openshift/origin/test/extended/images/helper.go:148

[Fail] [images] openshift limit range admission [It] should deny a push of built image exceeding limit on openshift.io/images resource 
/data/src/github.com/openshift/origin/test/extended/images/helper.go:148

https://ci.openshift.redhat.com/jenkins/job/origin_extended_image_tests/395/consoleFull

Please fix or disable this test asap, it's getting run in the image bucket and causing that bucket to report failure.

[bparees]

@liggitt @deads2k

[bparees]

(also ideally please change the tag on the test. we are using [images] for tests related to specific images (eg testing the ruby image), this sounds like a registry test to me)

[bparees]

@PI-Victor as the extended test babysitter this sprint, I suggest you create a PR to move this test (and any other related tests that aren't actually docker image tests) into their own bucket (eg [imageapis]). I've already discussed with @deads2k though i'm not sure i convinced him of the merits of that solution. You can also just convince @mfojtik instead which might be easier.

[mfojtik]

@bparees lol :-)

[deads2k]

I've already discussed with @deads2k though i'm not sure i convinced him of the merits of that solution. You can also just convince @mfojtik instead which might be easier.

Not convinced enough enough to do it, but I don't feel strongly enough to argue either. Laying claim to someone else's API group for unrelated tests doesn't seem particularly polite.

[bparees]

Laying claim to someone else's API group for unrelated tests doesn't seem particularly polite.

@deads2k

1. I guarantee we were using that tag before these tests came along because we were the first ones doing extended tests
2. the tag in this case is based on the extended test directory name (running [images] runs all the tests that live under the test/extended/images) not api naming. The question would be why limitrange_admission was put in that directory, since it bears no relation to the other tests in that folder.
3. The point here is not laying claim to particular names, it's ensuring separate things are in separate buckets so we can easily test specific areas of function and not pick up unrelated stuff, particularly when that stuff is not passing. If you want to make the case that all the existing image tests should move to a different bucket instead, you can make that argument (i'll fight you, at a minimum based on (1), but you can make it).

In sum, i don't buy the impoliteness argument. Also I did initially say "fix or disable this test" before proposing moving it to another bucket (which is still the best answer because we need an easy way to run buckets of tests and this isn't related to the existing bucket), but since no one did that for 4 days and I don't want our tests to continue failing and wonder if we we are ignoring deeper problems any longer, getting it out of the bucket is the most expedient action at this point.

[bparees]

And if i seem overly defensive of the images bucket here, it's because we've spent a huge amount of effort getting that bucket to a passing state and every time we do, someone does something that breaks it and makes it useless to us again.

[mfojtik]

@bparees @PI-Victor is this issue fixed now when we moved the tests?

[bparees]

yup

[bparees]

well
the test is still failing.

[bparees]

so it's not my problem anymore, but you should still fix the tests (or the bug that's causing them to fail).

[miminar]

Here's a fix: #10835