Extended.[builds][Conformance] oc new-app should succeed with a --name of 58 characters #14043
Assignees
Labels
component/apps
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
priority/P2
Milestone
Comments
deads2k
added
the
kind/test-flake
|
It failed trying to push to the registry (it got a 404). Unfortunately in this test setup, we don't gather any logs from gce. Also, the test code that dumps the registry log is currently broken (I'm fixing it). I'm going to close this because it's impossible to triage. We can reopen if we see it again with appropriate logging. |
|
@mfojtik these are deployment failures |
|
Seen https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2552/ jUnit |
|
seems like the deployment is waiting for the container to create, maybe a docker slowness? |
|
Seems like slow Docker: |
|
thanks @mfojtik. |
|
yet again https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2682/ @mfojtik devicemapper connected? btw. twice in a row on #14773 |
|
I wonder whether the rather broken implementation of WaitForADeployment could be at least partially responsible for this, in which case merging #14885 should help |
|
@tnozicka the devicemapper thing is a very old red herring at this point i believe, we should probably remove it from the jenkins cause analysis list entirely. the yum flake is a "sometimes" root cause but generally it's obvious if it was. since your job actually ran some tests, that is not likely relevant either. |
bparees
removed
the
kind/test-flake
|
i removed the test flake label since we don't want to ignore this as a flake. also i removed the test case in question from conformance so it should no longer be flaking on people. |
|
once we have registry rebuilt with #14882 in place and the playbooks for GCE are updated, we can re-test if this is fixed. |
|
I have a cluster up that can reproduce it 80% of the time, ping me and I'll
give you access
On Thu, Jun 29, 2017 at 6:02 PM, Clayton Coleman <[email protected]>
wrote:
… More unexpected behavior. If I delete the pod, then tag again, I don't
get a second deployment (which is definitely 100% a bug, which I'm
surprised wasn't fixed)
On Thu, Jun 29, 2017 at 5:59 PM, Clayton Coleman ***@***.***>
wrote:
> So to try this out locally I'm starting the master only, then running:
>
> 1. oc create -f test/extended/testdata/deploym
> ents/deployment-trigger.yaml
> 2. oc set triggers dc/example
> 3. oc tag --source=docker mysql:5.7.11 test:v1
>
> I haven't seen it do the double deployment yet.
>
> However, I did notice that if i deleted the pod (before it was scheduled,
> since master was only started), the deployment controller doesn't notice
> right away, and doesn't fail the deployment until the resync interval.
>
>
> On Thu, Jun 29, 2017 at 4:02 PM, Ben Parees ***@***.***>
> wrote:
>
>> So again, to fix the flake i'm loosening the restrictions in the test,
>> but deployments should have a test case that ensures this is not happening
>> (and since @mfojtik <https://github.com/mfojtik> is still seeing this
>> flake in #14910 <#14910>, i'm
>> not convinced that PR prevents this from happening).
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#14043 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/ABG_p1uInj4ts1WYlcN912BaDCTY3Jd6ks5sJALlgaJpZM4NQkHX>
>> .
>>
>
>
|
|
When this issue is resolved we need to move the new-app test back into the conformance bucket (and i still think we need a new deployment specific test that will do a better job of validating the behavior...) |
|
@bparees I think we need to cut a new 3.6 release and rebuilt the registry image to make this work. I will watch that and once we have new registry image out I will re-enable the test. |
|
I think with the fix I put in to tolerate multiple deployments we might
actually be ok to re-enable this now. But i'm OK with waiting.
Again what we really need is a new extended test(s) for deploymentconfigs
that explicitly tests for this behavior. Chasing it down via the new-app
test was painful.
Ben Parees | OpenShift
…On Jul 3, 2017 04:10, "Michal Fojtik" ***@***.***> wrote:
@bparees <https://github.com/bparees> I think we need to cut a new 3.6
release and rebuilt the registry image to make this work. I will watch that
and once we have new registry image out I will re-enable the test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14043 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEvl3t1NLAYp1rLk5d7xFnBuRLofsfHgks5sKKHigaJpZM4NQkHX>
.
|
|
@bparees why we should tolerate multiple deployments? that failure was legit, it pointed us to pretty much a release blocker problem :-) |
|
agree we need DC test |
@mfojtik we don't want to, but i wanted the test to start passing again (so that it's failure wasn't covering up other issues) and the main point of the test is not to check if deployments are working. hence: |
|
I'm going to cut an rc.0 candidate this afternoon.
…On Mon, Jul 3, 2017 at 11:01 AM, Ben Parees ***@***.***> wrote:
@bparees <https://github.com/bparees> why we should tolerate multiple
deployments? that failure was legit, it pointed us to pretty much a release
blocker problem :-)
@mfojtik <https://github.com/mfojtik> we don't, but i wanted the test to
start passing again (so that it's failure wasn't covering up other issues)
and the main point of the test is not to check if deployments are working.
hence:
https://github.com/openshift/origin/blob/master/test/
extended/util/framework.go#L741-L747
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14043 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p0-JOrnYzFGcMB5Aiv7cqgyEFDmiks5sKQJNgaJpZM4NQkHX>
.
|
|
@bparees i see the test is re-enabled and everything seems to operate normally, ok to close this? |
|
@mfojtik it's certainly not a p0 anymore, but you should still use either this issue or a new issue to:
|
|
@enj you said this was happening now because we need to fix openshift/openshift-ansible#5021 ? |
|
No it's only consistent on #15021 because we need the 3.7 release tag. openshift/openshift-ansible#5021 is related but not to this flake. |
|
We need to tighten this check.
…On Fri, Aug 11, 2017 at 8:35 AM, Mo Khan ***@***.***> wrote:
No it's only consistent on #15021
<#15021> because we need the 3.7
release tag. openshift/openshift-ansible#5021
<openshift/openshift-ansible#5021> is related
but not to this flake.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14043 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p2h9jpSCTVEiCSe1d6JXzM_yiGNmks5sXEqogaJpZM4NQkHX>
.
|
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
/close
Ben Parees | OpenShift
…On Feb 20, 2018 21:11, "OpenShift Bot" ***@***.***> wrote:
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually
close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14043 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEvl3kLHURTSVDrdIKiFpQZZxQ0haOOCks5tW6VagaJpZM4NQkHX>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extended.[builds][Conformance] oc new-app should succeed with a --name of 58 characters
https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/1132/
The text was updated successfully, but these errors were encountered: