New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch default DNS plugin to CoreDNS #566

Open
justaugustus opened this Issue May 7, 2018 · 38 comments

Comments

@justaugustus
Member

justaugustus commented May 7, 2018

Feature Description

  • One-line feature description (can be used as a release note): Switch default DNS plugin to CoreDNS
  • Primary contact (assignee): @johnbelamaric
  • Responsible SIGs: sig-network, sig-cluster-lifecycle
  • Design proposal link (community repo): kubernetes/community#1100
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @bowei @thockin
  • Approver (likely from SIG/area to which feature belongs): @thockin
  • Feature target (which target equals to which milestone):
    • Stable release target: 1.12

xref: #427

/kind feature
/sig cluster-lifecycle
/sig network
/assign @johnbelamaric

@k8s-ci-robot

This comment has been minimized.

Show comment
Hide comment
@k8s-ci-robot

k8s-ci-robot May 7, 2018

Contributor

@justaugustus: GitHub didn't allow me to assign the following users: johnbelamaric.

Note that only kubernetes members and repo collaborators can be assigned.

In response to this:

Feature Description

  • One-line feature description (can be used as a release note): Switch default DNS plugin to CoreDNS
  • Primary contact (assignee): @johnbelamaric
  • Responsible SIGs: sig-network, sig-cluster-lifecycle
  • Design proposal link (community repo): kubernetes/community#1100
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @bowei @thockin
  • Approver (likely from SIG/area to which feature belongs): @thockin
  • Feature target (which target equals to which milestone):
  • Alpha release target: 1.12

/kind feature
/sig cluster-lifecycle
/sig network
/assign @johnbelamaric

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Contributor

k8s-ci-robot commented May 7, 2018

@justaugustus: GitHub didn't allow me to assign the following users: johnbelamaric.

Note that only kubernetes members and repo collaborators can be assigned.

In response to this:

Feature Description

  • One-line feature description (can be used as a release note): Switch default DNS plugin to CoreDNS
  • Primary contact (assignee): @johnbelamaric
  • Responsible SIGs: sig-network, sig-cluster-lifecycle
  • Design proposal link (community repo): kubernetes/community#1100
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @bowei @thockin
  • Approver (likely from SIG/area to which feature belongs): @thockin
  • Feature target (which target equals to which milestone):
  • Alpha release target: 1.12

/kind feature
/sig cluster-lifecycle
/sig network
/assign @johnbelamaric

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@luxas

This comment has been minimized.

Show comment
Hide comment
@luxas

luxas May 8, 2018

Member

Hi, thanks for filing this feature!
I have a couple of questions/concerns though.
Why is this marked alpha? It sounds more like it should be stable/GA when it's a default.
I don't think this even needs to be a separate features issue. The common practice is to use one issue (in this case #427) to track the full lifecycle.
If your goal is to have CoreDNS as the default DNS plugin in v1.12, I'd just adjust #427 to be "stable/GA target: v1.12"

Cheers 😄

Member

luxas commented May 8, 2018

Hi, thanks for filing this feature!
I have a couple of questions/concerns though.
Why is this marked alpha? It sounds more like it should be stable/GA when it's a default.
I don't think this even needs to be a separate features issue. The common practice is to use one issue (in this case #427) to track the full lifecycle.
If your goal is to have CoreDNS as the default DNS plugin in v1.12, I'd just adjust #427 to be "stable/GA target: v1.12"

Cheers 😄

@stp-ip

This comment has been minimized.

Show comment
Hide comment
@stp-ip

stp-ip May 8, 2018

Member

The reasoning behind the split was, that in order to make it default later on the actual plugin needs to be stable/GA already. That was the prerequisite after a bigger discussion. The result was the split into two feature issues and making the default alpha first. (Alpha might not be the best thing so.)

Member

stp-ip commented May 8, 2018

The reasoning behind the split was, that in order to make it default later on the actual plugin needs to be stable/GA already. That was the prerequisite after a bigger discussion. The result was the split into two feature issues and making the default alpha first. (Alpha might not be the best thing so.)

@stp-ip

This comment has been minimized.

Show comment
Hide comment
@stp-ip

stp-ip May 8, 2018

Member

Reading all your other comments on the other thread (#427 (comment)) your comment is much clearer in my head. As CoreDNS is such a central place it make still make sense to track the state of being the default.

Member

stp-ip commented May 8, 2018

Reading all your other comments on the other thread (#427 (comment)) your comment is much clearer in my head. As CoreDNS is such a central place it make still make sense to track the state of being the default.

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Jul 18, 2018

Member

@johnbelamaric @cmluciano --

It looks like this feature is currently in the Kubernetes 1.12 Milestone.

If that is still accurate, please ensure that this issue is up-to-date with ALL of the following information:

  • One-line feature description (can be used as a release note):
  • Primary contact (assignee):
  • Responsible SIGs:
  • Design proposal link (community repo):
  • Link to e2e and/or unit tests:
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
  • Approver (likely from SIG/area to which feature belongs):
  • Feature target (which target equals to which milestone):
    • Alpha release target (x.y)
    • Beta release target (x.y)
    • Stable release target (x.y)

Set the following:

  • Description
  • Assignee(s)
  • Labels:
    • stage/{alpha,beta,stable}
    • sig/*
    • kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

  • Docs deadline (open placeholder PRs): 8/21
  • Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

Member

justaugustus commented Jul 18, 2018

@johnbelamaric @cmluciano --

It looks like this feature is currently in the Kubernetes 1.12 Milestone.

If that is still accurate, please ensure that this issue is up-to-date with ALL of the following information:

  • One-line feature description (can be used as a release note):
  • Primary contact (assignee):
  • Responsible SIGs:
  • Design proposal link (community repo):
  • Link to e2e and/or unit tests:
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
  • Approver (likely from SIG/area to which feature belongs):
  • Feature target (which target equals to which milestone):
    • Alpha release target (x.y)
    • Beta release target (x.y)
    • Stable release target (x.y)

Set the following:

  • Description
  • Assignee(s)
  • Labels:
    • stage/{alpha,beta,stable}
    • sig/*
    • kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

  • Docs deadline (open placeholder PRs): 8/21
  • Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@luxas

This comment has been minimized.

Show comment
Hide comment
@luxas

luxas Jul 30, 2018

Member

I assume this is beta in v1.12? kubeadm has used it on a GA/beta level already since v1.11 fwiw

Member

luxas commented Jul 30, 2018

I assume this is beta in v1.12? kubeadm has used it on a GA/beta level already since v1.11 fwiw

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Jul 31, 2018

Member

@johnbelamaric / @cmluciano / @luxas / @thockin --
So this is a case where the "graduation" of the feature is actually flipping the bit for it to be the default DNS plugin.
As CoreDNS is already GA, what should we do here?

  • Straight to GA?
  • Set to Beta to soak for a release and then graduate to GA?
  • Something else entirely?

/assign @johnbelamaric
/remove-stage alpha

Member

justaugustus commented Jul 31, 2018

@johnbelamaric / @cmluciano / @luxas / @thockin --
So this is a case where the "graduation" of the feature is actually flipping the bit for it to be the default DNS plugin.
As CoreDNS is already GA, what should we do here?

  • Straight to GA?
  • Set to Beta to soak for a release and then graduate to GA?
  • Something else entirely?

/assign @johnbelamaric
/remove-stage alpha

@stp-ip

This comment has been minimized.

Show comment
Hide comment
@stp-ip

stp-ip Jul 31, 2018

Member

As the point for switching the flip was mainly to separate GA of CoreDNS and the actual config switch it seems like moving to beta is another step, that might not be necessary especially considering it's already GA/beta in kubeadm.

Should go GA in v1.12 in my view fwiw.

Member

stp-ip commented Jul 31, 2018

As the point for switching the flip was mainly to separate GA of CoreDNS and the actual config switch it seems like moving to beta is another step, that might not be necessary especially considering it's already GA/beta in kubeadm.

Should go GA in v1.12 in my view fwiw.

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Jul 31, 2018

Member

Just to clarify for passerbys...
Adding CoreDNS as a DNS plugin was tracked on #427. There is a process for moving features through stages (alpha --> beta --> stable), which again was tracked on #427.

This Feature issue is unique in the fact that here, we're not actually tracking the development state of the feature (as it's already been developed), but instead we're tracking the process of deciding in which release it should be enabled as the default DNS plugin. AFAIK, we don't have an official graduation process for "flipping a bit".

While developing kubeadm is a separate concern, @stp-ip is right; this has already had some soak time as CoreDNS was selected as the default DNS plugin for kubeadm in Kubernetes 1.11.

FWIW, I would also vote to mark this as GA for 1.12, but I'll wait for the powers that be (@kubernetes/sig-network-misc) to make a call on that.

Member

justaugustus commented Jul 31, 2018

Just to clarify for passerbys...
Adding CoreDNS as a DNS plugin was tracked on #427. There is a process for moving features through stages (alpha --> beta --> stable), which again was tracked on #427.

This Feature issue is unique in the fact that here, we're not actually tracking the development state of the feature (as it's already been developed), but instead we're tracking the process of deciding in which release it should be enabled as the default DNS plugin. AFAIK, we don't have an official graduation process for "flipping a bit".

While developing kubeadm is a separate concern, @stp-ip is right; this has already had some soak time as CoreDNS was selected as the default DNS plugin for kubeadm in Kubernetes 1.11.

FWIW, I would also vote to mark this as GA for 1.12, but I'll wait for the powers that be (@kubernetes/sig-network-misc) to make a call on that.

@chrisohaver

This comment has been minimized.

Show comment
Hide comment
@chrisohaver

chrisohaver Jul 31, 2018

How does this process relate to the KEP process?

The KEP for graduating CoreDNS to default DNS server, is here ...
https://github.com/kubernetes/community/blob/master/keps/sig-network/0012-20180518-coredns-default-proposal.md

chrisohaver commented Jul 31, 2018

How does this process relate to the KEP process?

The KEP for graduating CoreDNS to default DNS server, is here ...
https://github.com/kubernetes/community/blob/master/keps/sig-network/0012-20180518-coredns-default-proposal.md

@cmluciano

This comment has been minimized.

Show comment
Hide comment
@cmluciano

cmluciano Jul 31, 2018

Member

I agree that switching to default based on kubeadm results is great progress. Do we have any preliminary results from cloud-providers or other large deploys on stability.

It may be a "flipping in bit" in docs, but often features are not used in k8s until they reach beta stage.

Member

cmluciano commented Jul 31, 2018

I agree that switching to default based on kubeadm results is great progress. Do we have any preliminary results from cloud-providers or other large deploys on stability.

It may be a "flipping in bit" in docs, but often features are not used in k8s until they reach beta stage.

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Aug 4, 2018

Member

@johnbelamaric @cmluciano -- we still need to make a call on this. I'm tentatively setting this to GA on the sheet, but let me know if you feel differently.

/stage stable
cc: @kacole2 @wadadli @robertsandoval @rajendar38

Member

justaugustus commented Aug 4, 2018

@johnbelamaric @cmluciano -- we still need to make a call on this. I'm tentatively setting this to GA on the sheet, but let me know if you feel differently.

/stage stable
cc: @kacole2 @wadadli @robertsandoval @rajendar38

@chrisohaver

This comment has been minimized.

Show comment
Hide comment
@chrisohaver

chrisohaver Aug 6, 2018

The KEP lists the following criteria for graduating coredns to "default"...

  • Add CoreDNS image in a Kubernetes repository (To Be Defined) and ensure a workflow/process to update the CoreDNS versions in the future.
  • Have a certain number (To Be Defined) of clusters of significant size (To Be Defined) adopting and running CoreDNS as their default DNS.

The first is, I believe, satisfied.
For the second, we (CoreDNS team + CNCF) are conducting a survey of k8s+coredns users to gauge coredns adoption in large clusters. Just pushed it out recently. We do not have survey results yet.

chrisohaver commented Aug 6, 2018

The KEP lists the following criteria for graduating coredns to "default"...

  • Add CoreDNS image in a Kubernetes repository (To Be Defined) and ensure a workflow/process to update the CoreDNS versions in the future.
  • Have a certain number (To Be Defined) of clusters of significant size (To Be Defined) adopting and running CoreDNS as their default DNS.

The first is, I believe, satisfied.
For the second, we (CoreDNS team + CNCF) are conducting a survey of k8s+coredns users to gauge coredns adoption in large clusters. Just pushed it out recently. We do not have survey results yet.

@fturib

This comment has been minimized.

Show comment
Hide comment
@fturib

fturib Aug 6, 2018

@justaugustus : I try to push an email on this subject with Tim, John, I will add @cmluciano .. but I cannot find any email for yourself. Can your provide one ? Thanks !

fturib commented Aug 6, 2018

@justaugustus : I try to push an email on this subject with Tim, John, I will add @cmluciano .. but I cannot find any email for yourself. Can your provide one ? Thanks !

@fturib

This comment has been minimized.

Show comment
Hide comment
@fturib

fturib Aug 6, 2018

for info, the survey for feedback on CoreDNS adoption is available here : https://www.surveymonkey.com/r/SKZQSLK

fturib commented Aug 6, 2018

for info, the survey for feedback on CoreDNS adoption is available here : https://www.surveymonkey.com/r/SKZQSLK

@johnbelamaric

This comment has been minimized.

Show comment
Hide comment
@johnbelamaric

johnbelamaric Aug 6, 2018

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

johnbelamaric commented Aug 6, 2018

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

@dixudx

This comment has been minimized.

Show comment
Hide comment
@dixudx

dixudx Aug 15, 2018

Member

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

Agree.

Member

dixudx commented Aug 15, 2018

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

Agree.

@chrisohaver

This comment has been minimized.

Show comment
Hide comment
@chrisohaver

chrisohaver Aug 15, 2018

Going GA with this feature means deprecating kube-dns

I was thinking that first CoreDNS would become default, then in a following release, kube-dns would become officially deprecated. Kube-dns deprecation schedule is not covered in the KEP, or this feature. I think it's acceptable to have two supported GA DNS solutions during transition time (as we have now in k8s 1.11).

chrisohaver commented Aug 15, 2018

Going GA with this feature means deprecating kube-dns

I was thinking that first CoreDNS would become default, then in a following release, kube-dns would become officially deprecated. Kube-dns deprecation schedule is not covered in the KEP, or this feature. I think it's acceptable to have two supported GA DNS solutions during transition time (as we have now in k8s 1.11).

@zparnold

This comment has been minimized.

Show comment
Hide comment
@zparnold

zparnold Aug 20, 2018

Member

Hey there! @justaugustus I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

Member

zparnold commented Aug 20, 2018

Hey there! @justaugustus I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

@jimangel

This comment has been minimized.

Show comment
Hide comment
@jimangel

jimangel Aug 27, 2018

Member

@johnbelamaric @cmluciano Bump for docs ☝️

Member

jimangel commented Aug 27, 2018

@johnbelamaric @cmluciano Bump for docs ☝️

@johnbelamaric

This comment has been minimized.

Show comment
Hide comment
@johnbelamaric

johnbelamaric Aug 27, 2018

johnbelamaric commented Aug 27, 2018

@johnbelamaric

This comment has been minimized.

Show comment
Hide comment
@johnbelamaric

johnbelamaric Aug 27, 2018

It's not noted on here so let me just be sure everyone is aware we are moving forward with CoreDNS as the default in 1.12 per last week's sig-network meeting.

johnbelamaric commented Aug 27, 2018

It's not noted on here so let me just be sure everyone is aware we are moving forward with CoreDNS as the default in 1.12 per last week's sig-network meeting.

k8s-merge-robot added a commit to kubernetes/kubernetes that referenced this issue Aug 29, 2018

Merge pull request #67569 from fturib/coredns-default
Automatic merge from submit-queue (batch tested with PRs 67745, 67432, 67569, 67825, 67943). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Enable CoreDNS as default for kube-up deployments

**What this PR does / why we need it**:
Enable CoreDNS as default (for kube-up installations)
It will allow to run CI tests to prepare graduation criteria for CoreDNS as Default

see : KEP - https://github.com/kubernetes/community/blob/master/keps/sig-network/0012-20180518-coredns-default-proposal.md
see also : kubernetes/features#566

NOTE for release : I guess that CoreDNS as default server for k8s needs a longer description. This specific PR is to ensure we validate all e2e.

```release-note
Make CoreDNS be the default DNS server in kube-up (instead of kube-dns formerly). 
It is still possible to deploy kube-dns by setting CLUSTER_DNS_CORE_DNS=false.
```
@zparnold

This comment has been minimized.

Show comment
Hide comment
@zparnold

zparnold Sep 1, 2018

Member

Awesome @johnbelamaric! Is there a place this needs to be updated in k/website?

Member

zparnold commented Sep 1, 2018

Awesome @johnbelamaric! Is there a place this needs to be updated in k/website?

@nikopen

This comment has been minimized.

Show comment
Hide comment
@rajansandeep

This comment has been minimized.

Show comment
Hide comment
@rajansandeep
Member

rajansandeep commented Sep 4, 2018

@zparnold

This comment has been minimized.

Show comment
Hide comment
@zparnold

zparnold Sep 4, 2018

Member
Member

zparnold commented Sep 4, 2018

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Sep 5, 2018

Member

@thockin @nikopen @johnbelamaric @kubernetes/sig-network-feature-requests -- hmmm... did we actually come to a decision on deprecating kube-dns? Seems to me, that any decision on that should be echoed here, at the very least.

Is it in-scope for CoreDNS going GA? If not, we should get a separate KEP opened for that, linked here and have an additional feature tracking issue for it.

w.r.t. CoreDNS going default for 1.12, is that still on track?

Member

justaugustus commented Sep 5, 2018

@thockin @nikopen @johnbelamaric @kubernetes/sig-network-feature-requests -- hmmm... did we actually come to a decision on deprecating kube-dns? Seems to me, that any decision on that should be echoed here, at the very least.

Is it in-scope for CoreDNS going GA? If not, we should get a separate KEP opened for that, linked here and have an additional feature tracking issue for it.

w.r.t. CoreDNS going default for 1.12, is that still on track?

@chrisohaver

This comment has been minimized.

Show comment
Hide comment
@chrisohaver

chrisohaver Sep 5, 2018

I’m looking into the auto scale and debugging articles.

chrisohaver commented Sep 5, 2018

I’m looking into the auto scale and debugging articles.

@johnbelamaric

This comment has been minimized.

Show comment
Hide comment
@johnbelamaric

johnbelamaric Sep 5, 2018

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

johnbelamaric commented Sep 5, 2018

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

@justaugustus

This comment has been minimized.

Show comment
Hide comment
@justaugustus

justaugustus Sep 6, 2018

Member

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

@johnbelamaric -- Got it. Noting again that we need to coalesce a plan for kube-dns deprecation sooner rather than later, as it's a multi-release event.

Member

justaugustus commented Sep 6, 2018

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

@johnbelamaric -- Got it. Noting again that we need to coalesce a plan for kube-dns deprecation sooner rather than later, as it's a multi-release event.

@tfogo

This comment has been minimized.

Show comment
Hide comment
@tfogo

tfogo Sep 7, 2018

Member

Hi @rajansandeep, @johnbelamaric,

How are docs looking for this? Is there a PR open in k/website?

Member

tfogo commented Sep 7, 2018

Hi @rajansandeep, @johnbelamaric,

How are docs looking for this? Is there a PR open in k/website?

@rajansandeep

This comment has been minimized.

Show comment
Hide comment
@rajansandeep

rajansandeep Sep 7, 2018

Member

I forgot to refer the PR for this.
kubernetes/website#10228 is ready for review.

Member

rajansandeep commented Sep 7, 2018

I forgot to refer the PR for this.
kubernetes/website#10228 is ready for review.

@chrisohaver

This comment has been minimized.

Show comment
Hide comment

chrisohaver commented Sep 7, 2018

@tpepper

This comment has been minimized.

Show comment
Hide comment
@tpepper

tpepper Sep 13, 2018

Contributor

warning this is now at risk, see:

kubernetes/kubernetes#68629
kubernetes/kubernetes#68613

Contributor

tpepper commented Sep 13, 2018

warning this is now at risk, see:

kubernetes/kubernetes#68629
kubernetes/kubernetes#68613

@kacole2

This comment has been minimized.

Show comment
Hide comment
@kacole2

kacole2 Sep 17, 2018

Contributor

/milestone v1.13

Contributor

kacole2 commented Sep 17, 2018

/milestone v1.13

@AishSundar

This comment has been minimized.

Show comment
Hide comment
@AishSundar

AishSundar Oct 4, 2018

@bowei @chrisohaver can you plz update this issue with your level of confidence, whats pending in terms of PR, test and docs for this feature to wrap in 1.13? Considering the last minute Scalability and memory constraints we ran into last cycle, it will be great to land the open PRs sooner in this cycle to we have enough time to watch the CI signals and stabilize.

Currently Code Slush for 1.13 is Nov 9th and Freeze starts on Nov 15th. Thanks

AishSundar commented Oct 4, 2018

@bowei @chrisohaver can you plz update this issue with your level of confidence, whats pending in terms of PR, test and docs for this feature to wrap in 1.13? Considering the last minute Scalability and memory constraints we ran into last cycle, it will be great to land the open PRs sooner in this cycle to we have enough time to watch the CI signals and stabilize.

Currently Code Slush for 1.13 is Nov 9th and Freeze starts on Nov 15th. Thanks

@fturib

This comment has been minimized.

Show comment
Hide comment
@fturib

fturib Oct 4, 2018

@AishSundar : We have been investigating the scale issue and memory constraint. We found some optimization and know now we can make it. However we need to wrap up the changes and publish a new release of CoreDNS.
I cannot provide a date yet, but I expect to be by Oct 15th.

We then need:

  • re-publish the PR for CoreDNS as default, with the new image. (pretty simple - no delay)
  • e2e test will validate after that merge. (2 PR already presented - see below)
  • about doc, I think all docs expected were finally merged in 1.12 (because still valid whatever CoreDNS is default or not for GCE). We may need to have another look.

I agree completely on the need to have this feature checked-in asap. We had a sync-up with @thockin from SIG-Network last Tuesday on this subject.
Thanks to remind the code slush date. I plan to be much ahead of these dates.

PR needed for validation e2e tests at scale:

fturib commented Oct 4, 2018

@AishSundar : We have been investigating the scale issue and memory constraint. We found some optimization and know now we can make it. However we need to wrap up the changes and publish a new release of CoreDNS.
I cannot provide a date yet, but I expect to be by Oct 15th.

We then need:

  • re-publish the PR for CoreDNS as default, with the new image. (pretty simple - no delay)
  • e2e test will validate after that merge. (2 PR already presented - see below)
  • about doc, I think all docs expected were finally merged in 1.12 (because still valid whatever CoreDNS is default or not for GCE). We may need to have another look.

I agree completely on the need to have this feature checked-in asap. We had a sync-up with @thockin from SIG-Network last Tuesday on this subject.
Thanks to remind the code slush date. I plan to be much ahead of these dates.

PR needed for validation e2e tests at scale:

@AishSundar

This comment has been minimized.

Show comment
Hide comment
@AishSundar

AishSundar Oct 4, 2018

Thanks @fturib for the detailed status and good to know that we have a path forward. I will check on the status again post Oct mid.

AishSundar commented Oct 4, 2018

Thanks @fturib for the detailed status and good to know that we have a path forward. I will check on the status again post Oct mid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment