Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Failing on: aks-engine-windows-master-staging aks-engine-windows-master gce-windows-master flannel-*-windows-master Which test: [sig-cli] Kubectl client [] Guestbook application should create and stop a working application [Conformance] Testgrid link: Reason for failure: Anything else we need to know: Most probably related to the recent transition to redis:5.0.5. Windows still uses a Redis port that is version 3.2 . Since there is no Windows version newer than 3.2 for windows we need to investigate how to accommodate the test within the existing image.
/cc /cc /cc
/sig windows
I am seeing fail also due to It looks like the message that Redis prints out has changed
Ah I see that there's a separate issue for that
/assign
/area conformance
After discussions with SIG-CLI and SIG-Apps they're ok with the approach of simplifying this down to something that works with agnhost. SIG-Apps asked to double check that service ip/port variables are covered elsewhere first, then tag them for review. - See Aug 14 - see Sep 9
related to /priority critical-urgent /milestone v1.17
any update on this? It's still consistently failing on our release jobs
Same as before: The reason for failure is that the agnhost image version was bumped, but it was not built and published yet. We're waiting on the kubernetes infra team to setup the automatic image building / publishing process for the kubernetes E2E test images.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen Reopening since the job is not green.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen Doesn't resolve the issue. ^^^^
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Seeing this on GCP runs. This is still skipped on Azure.
Similar failures in master-informing
i don't see this as something that needs to block 1.17.0 release. agree/disagree?
/milestone v1.18
is a test-only issue actually critical-urgent if it has been open for 6 months and has not been release-blocking?
This has been a buggy test that's taken multiple iterations of refactoring to fix. We haven't been sitting still on this, but it's been hard to get reviewers to merge everything. - are you working on driving down the flakes? this one is actionable with PRs ready to merge. I'll change the priority since we've shipped a release without fixing this test issue. /priority important-soon
/remove-priority critical-urgent This was marked critical-urgent as we were trying to get it into the 1.17 review queue. Dropping this back to important-soon

Discussion:
log.Fatalf("Error while unmarshaling master's response: %v", err) } <del> responseJSON["data"] = "something" </del> var ok bool store, ok = responseJSON["data"].(map[string]interface{}) if !ok {