Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1358360 - SkyDNS: service discovery is not able to resolve pod names
Summary: SkyDNS: service discovery is not able to resolve pod names
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 3.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Derek Carr
QA Contact: Johnny Liu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-20 14:56 UTC by jritenou
Modified: 2017-09-04 11:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-04 11:20:26 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github kubernetes kubernetes issues 13552 None None None 2016-07-20 14:56:25 UTC

Description jritenou 2016-07-20 14:56:25 UTC
1. SkyDNS: service discovery should be able to resolve pod names  
  
  
2. Who is the customer behind the request?  
Account: Citigroup 411070
  
TAM customer: yes  
SRM customer: yes  
Strategic: yes  
  
3. What is the nature and description of the request?  
Customer sees value in pods having entries in SkyDNS, forward & reverse (in addition to the service layer, as is currently)
  
4. Why does the customer need this? (List the business requirements here)  
There are some use cases, such as Symphony, where pods being resolvable is desirable
  
5. How would the customer like to achieve this? (List the functional requirements here)  
  
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.  

pod_name.project_name.pod.cluster.local => pod_ip
and we need forward and reverse entries.
  
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?  Upstream Kubernetes RFE - https://github.com/kubernetes/kubernetes/issues/13552
  
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  Nothing specific
  
9. Is the sales team involved in this request and do they have any additional input?  Johnray Fuller (SA for the account) is aware of this request
  
10. List any affected packages or components.  
atomic-openshift-master
  
11. Would the customer be able to assist in testing this functionality if implemented?  
Yes

Comment 1 Andy Goldstein 2016-07-20 15:43:27 UTC
We only support reverse pod IP lookups. We don't support forward lookups from pod name. We plan on supporting forward lookups such as <identity>.<service>.<namespace>.svc.cluster.local, where <identity> is the "hostname" set via the annotation pod.beta.kubernetes.io/hostname on a pod (or the hostname field in the pod spec, once that's supported), and <service> is the name of the service the pod belongs to. The intent here is to make services resilient but allow pods to come and go, and if you need to access a specific member of the service, you can do it this way. PetSets may also provide the support you need, but it's hard to say without hearing more about the desired use cases.

Could we please get some more information on what the specific use cases are?


Note You need to log in before you can comment on or make changes to this bug.