Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

This looks good at first glance however, the additional layers it depends on look like they need some Xenial updates as well.

Namely, layer-flannel which has no systemD support templates. I'll get those hacked together and test this PR and +1 when I've got a confirmed working build.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

with juju-solutions/layer-flannel#17 landed, and i've been kicking the tires on it and running tests, I think we're good to go on this bumping up to Xenail now

+1 LGTM

Thanks for the work here @mbruzek

+1 LGTM, I had a question about why we weren't being explicit, juju deploy kubernetes vs juju deploy xenial/kubernetes but Matt explained that the charm metadata handles this now so it states what the supported series is, no need for the user to define it.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Review status: 0 of 2 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

GCE e2e build/test passed for commit 9673ceb.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@pwittrock in accordance with the Criteria for getting something into 1.4 post on google groups: https://groups.google.com/forum/#!msg/kubernetes-dev/pdMJpA0NF7I/1dXrRBriCQAJ here are the three questions with answers:

1. How risky is it to merge this change?
   Answer: This change is very low risk, as it is labeled a "small" change and is mostly documentation. Only one code change for the Juju layer configuration.
2. How easy is it to roll this change back?
   Answer: The change is very easy to roll back, one commit, and only 2 files changed.
3. What's the cost if it doesn't make the 1.4 release?
   Answer: The documentation for the juju cluster component will be incorrect and we will not be able to give people the proper steps to take in the README file.

Please consider this small PR for the exception process to get in before 1.4. Thank you Phil.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

This PR was locked out for the 1.4.0 freeze. We should keep this open to complete the review. I do not have permission to add labels yet. Please add the 'keep-open' label.

@k8s-bot test this

Jenkins unit/integration failed for commit 9673ceb. Full PR test history.

The magic incantation to run this job again is @k8s-bot unit test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

I signed the cla for the linuxfoundation today, and see the tests were failing to queue. How does one trigger a retest?

I'm going to try this:

@k8s-bot test this

-edit- looks like its failing to queue the builds (temporarily) when I told it to try that. So I'm not sure if infra related (maintenance) or if i'm carrying super cosmic bot error powers. But it did recover gracefully. so +1 to that - we'll see whats up after this run

Jenkins GKE smoke e2e failed for commit 9673ceb. Full PR test history.

The magic incantation to run this job again is @k8s-bot cvm gke e2e test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

I looked through the smoke-test failure logs and they dont appear related. I saw some infra 404's, and a rocket turnup daemon connect failure (which we aren't exercising in this pr). I feel these failures are not due in part to this change.

Therefore this is +1 LGTM. @zmerlynn is it cool for us to land this or do we need a satisfactory smoke test before we can land it?

@chuckbutler: You won't even get to the submit queue without the tests being green, though I just threw on retest-not-required to ensure SQ doesn't touch it again.

@k8s-bot cvm gke e2e test this
@k8s-bot gci gke e2e test this

@chuckbutler: SQ == submit queue. That label stops the submit queue from retesting it before merging, which it normally would, but we don't have any PR-builder tests that are influenced by what's touched in this code. As a human, I can vet that and label it so the SQ isn't wasting time retesting something.

Jenkins GCI GKE smoke e2e failed for commit 9673ceb. Full PR test history.

The magic incantation to run this job again is @k8s-bot gci gke e2e test this. Please help us cut down flakes by linking to an open flake issue when you hit one in your PR.

Automatic merge from submit-queue