Skip to content
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

Support services that reference an external service #33

Closed
18 of 20 tasks
smarterclayton opened this issue Jul 19, 2016 · 35 comments
Closed
18 of 20 tasks

Support services that reference an external service #33

smarterclayton opened this issue Jul 19, 2016 · 35 comments
Assignees
Labels
sig/network Categorizes an issue or PR as relevant to SIG Network.
Milestone

Comments

@smarterclayton
Copy link
Contributor

smarterclayton commented Jul 19, 2016

Description

Services should be able to reference an external DNS address instead of only pods, which will allow application authors to reference services that exist off platform, on other clusters, or locally.

Owner @rata

Progress Tracker

  • Before Alpha
    • Design Approval
      • Design Proposal
      • Initial API review (if API). Maybe same PR as design doc. PR-NUMBER
        • Any code that changes an API (/pkg/apis/...)
        • cc @kubernetes/api
      • Identify shepherd (your SIG lead and/or kubernetes-pm@googlegroups.com will be able to help you). My Shepherd is: @smarterclayton + @thockin
        • A shepherd is an individual who will help acquaint you with the process of getting your feature into the repo, identify reviewers and provide feedback on the feature. They are not (necessarily) the code reviewer of the feature, or tech lead for the area.
        • The shepherd is not responsible for showing up to Kubernetes-PM meetings and/or communicating if the feature is on-track to make the release goals. That is still your responsibility.
      • Identify secondary/backup contact point. My Secondary Contact Point is: replace.me@replaceme.com (and/or GH Handle)
    • Write (code + tests + docs) then get them merged. Add Service type "ExternalName" which results in CNAME DNS kubernetes#30599
      • Code needs to be disabled by default. Verified by code OWNERS
      • Minimal testing
      • Minimal docs
        • cc @kubernetes/docs on docs PR
        • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
        • New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io
      • Update release notes
  • Before Beta
    • Testing is sufficient for beta
    • User docs with tutorials
      • Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
      • cc @kubernetes/docs on docs PR
      • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
    • Thorough API review
      • cc @kubernetes/api
  • Before Stable
    • docs/proposals/foo.md moved to docs/design/foo.md
      • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
    • Soak, load testing
    • detailed user docs and examples
      • cc @kubernetes/docs
      • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

  • Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

  • Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
  • As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
    and sometimes http://github.com/kubernetes/contrib, or other repos.
  • When you are done with the code, apply the "code-complete" label.
  • When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
    check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
    testing. They won't do detailed code review: that already happened when your PRs were reviewed.
    When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

  • Write user docs and get them merged in.
  • User docs go into http://github.com/kubernetes/kubernetes.github.io.
  • When the feature has user docs, please add a comment mentioning @kubernetes/docs.
  • When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.
@ncdc
Copy link
Member

ncdc commented Jul 25, 2016

@rata do you think you'll be able to code this in time for 1.4?

@rata
Copy link
Member

rata commented Jul 25, 2016

On Mon, Jul 25, 2016 at 07:58:11AM -0700, Andy Goldstein wrote:

@rata do you think you'll be able to code this in time for 1.4?

My plan was to start working on this on Tuesday, as I have an exam on Tuesday at
university. IS this too late?

I think the change can be not so hard, for the quick look I had at th code (it
seems we just created a skydns backend in kube-dns, and seems is easy to add
another type response, CNAME, for what I looked).

But if you are concerned about this, please go ahead and work on this! I can
maybe join later and test or something :-)

@ncdc
Copy link
Member

ncdc commented Jul 25, 2016

@rata that should be fine. I was just checking in. Thanks!

@idvoretskyi
Copy link
Member

idvoretskyi commented Aug 4, 2016

@smarterclayton @rata which SIG is responsible for this feature?

@ncdc
Copy link
Member

ncdc commented Aug 4, 2016

I would assume network

@idvoretskyi
Copy link
Member

@ncdc thanks

@idvoretskyi idvoretskyi added the sig/network Categorizes an issue or PR as relevant to SIG Network. label Aug 4, 2016
@rata
Copy link
Member

rata commented Aug 4, 2016

@ncdc @smarterclayton @thockin I'm more busy than I expected (at $DAYJOB and university) and I'm not sure I'll make it on time on this. Do you want to start working on this, and if I have some time maybe jump on this later?

@rata
Copy link
Member

rata commented Aug 4, 2016

I'm really really sorry, and I wish I could work on this, but I'm already late (planned to start 2 days ago) and more busy than I expected. I think it's better to say this early so this gets implemented in 1.4. But I'm really really sorry :-/

@aronchick
Copy link
Contributor

@smarterclayton Do you think you can find someone else to tackle? Or should we just punt to 1.5.

@therc
Copy link
Member

therc commented Aug 5, 2016

I'm also working on node-local services, so perhaps I can help with this. That way, I can blame myself for the ensuing rebases. :-)

@rata
Copy link
Member

rata commented Aug 5, 2016

@therc thanks again! :)

@idvoretskyi
Copy link
Member

@therc thank you for your help, assigned you as an assignee.

therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 14, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 16, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 17, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
@goltermann
Copy link
Contributor

In a meeting today, it was mentioned that this is missing v1.4. I'm moving to the v1.5 milestone. Please bring back to v1.4 if that's not accurate.

@goltermann goltermann modified the milestones: v1.5, v1.4 Aug 17, 2016
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 18, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 18, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 19, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
therc pushed a commit to Clarifai/kubernetes that referenced this issue Aug 19, 2016
ExternalName allows kubedns to return CNAME records for external
services. No proxying is involved.

See original issue at
kubernetes#13748

Feature tracking at
kubernetes/enhancements#33
@thockin
Copy link
Member

thockin commented Oct 13, 2016

kubectl create service is the correct command tree to explore

On Thu, Oct 13, 2016 at 9:04 AM, Rudi C notifications@github.com wrote:

This is mostly working already in 1.4, but it occurred to me that there's
no way to create such a service from the command line without using a
YAML/JSON file.

kubectl expose doesn't feel exactly right, because the whole point of
ExternalName services is that there are no pods to be exposed. If that's
still the way it's going to be done, the command line syntax will have to
be changed from (-f FILENAME | TYPE NAME) ... to (-f FILENAME |
--external-name NAME | TYPE NAME) ....

Opening an issue for that.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#33 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVPmK08AXwK1Yw0eao88qgktxZ2Qiks5qzlaXgaJpZM4JQHJ2
.

@aglassman
Copy link

Thanks for working on this feature, it's been very helpful.

@thockin
Copy link
Member

thockin commented Nov 28, 2016

@therc I don't think the CLI for this went in, did it? Any reason to not call what we have GA, anyway? Are you active on the CLI part or should we just open a new issue for it?

@jimmycuadra
Copy link

This is stable in 1.5? Are there docs?

@thockin
Copy link
Member

thockin commented Dec 13, 2016 via email

@idvoretskyi
Copy link
Member

@smarterclayton @therc can you confirm the feature development has been completed and issue can be closed?

@idvoretskyi idvoretskyi modified the milestones: next-milestone, v1.5 Dec 13, 2016
@thockin
Copy link
Member

thockin commented Dec 28, 2016

@therc Can we count on you for CLI wrapup? would love to close this...

@idvoretskyi
Copy link
Member

@thockin @therc sooo, any final decision?

@thockin
Copy link
Member

thockin commented Jan 24, 2017 via email

@therc
Copy link
Member

therc commented Jan 24, 2017

Just got back from vacation and a hectic office move, working my way through email backlog.
I can pick up any leftover items, but I think kubectl create support was implemented by @adohe in kubernetes/kubernetes#34789
Was there anything else you had in mind? My next related step was allowing the built-in kubernetes.default service to also be an ExternalName service, to pave the way for a migration to api.kube-system or something along those lines. But if you have something else that's higher priority, I can tackle that first.

@thockin
Copy link
Member

thockin commented Jan 24, 2017 via email

@therc
Copy link
Member

therc commented Jan 25, 2017

Unfortunately, I think only Clayton or another owner can edit the issue description. I just went through the checklist and it looks to me like everything can be ticked off.

Regarding "detailed docs and examples", I have something with more use cases, originally for internal use, that I have almost entirely re-purposed as a blog post. I'm not sure how kosher it is to add links from Kubernetes docs to random external blog posts; I suspect not very, given link rot and the like. Perhaps I could re-adapt it again as a tutorial in the docs repo? This issue can be closed anyway.

@thockin
Copy link
Member

thockin commented Jan 25, 2017

DONE

@thockin thockin closed this as completed Jan 25, 2017
@idvoretskyi
Copy link
Member

@therc @thockin does this feature target 1.6 (as per @mdelio modified milestone) or it has been finally implemented in 1.5 yet?

If this is still 1.6, I'd like to reopen it and keep in this state during the release.

@therc
Copy link
Member

therc commented Jan 26, 2017

The main feature is in 1.5 already and can be used through YAML files. It's the kubectl support that will land in 1.6. I think it'd be worthy of a 1.5 cherrypick.

@adohe-zz
Copy link

adohe-zz commented Feb 4, 2017

@idvoretskyi @therc yes, the kubectl support land in 1.6, shall we cherrypick it against 1.5?

@liggitt
Copy link
Member

liggitt commented Feb 4, 2017

We don't typically backport new features

@adohe-zz
Copy link

adohe-zz commented Feb 4, 2017

Get it~

ingvagabund pushed a commit to ingvagabund/enhancements that referenced this issue Apr 2, 2020
add open questions to the template
howardjohn pushed a commit to howardjohn/enhancements that referenced this issue Oct 21, 2022
* Make TOC approval required for features in root

Until we have better owners for the root of this, require TOC approval for changes. Also allow any maintainers to approve changes to /features.

* Update CODEOWNERS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/network Categorizes an issue or PR as relevant to SIG Network.
Projects
None yet
Development

No branches or pull requests