DNS names are wrong. Prefixed in dnsmasq, not prefixed in heat output about openshift-on-openstack HOT 3 CLOSED

Hi Judd,
openshift-lb.example.com is an "entry point" for users/world when talking to openshift console/api. So DNS record of openshift-lb.example.com needs to be set on DNS server you use (or in your /etc/hosts), we do not (and can not) do this automatically I'm afraid.

from openshift-on-openstack.

Hi Jan,

Let me know if I have this straight: the lb.example.com name is for setting on whatever external DNS that world is talking to, while openshift-lb.example.com is for DNS internal to OpenShift.

Secondly, if I seek integration with an IaaS service such as OpenStack would that require yet another DNS host or domain? Are there docs for this?

Thanks so much, I'm overjoyed to have the deployment working! Summit is going to be great!
-Judd

from openshift-on-openstack.

Reopening this. I misread your output yesterday - yes, this is a bug: there should be "openshift-lb.example.com" everywhere (I sent a patch for this).

Anyway openshift-lb.example.com still has to be set on an external DNS if you want to access openshfit from outside. openshift-lb.example.com is for setting on whatever external DNS that world is talking to, also this address is set on internal DNS being set for resolving openshift nodes, the reason is that openshift ndoes have this address set as public url so they need to resolve it (and we can't rely on fact that it will be set properly on an external DNS). BTW we are moving toward delegate DNS setup to openshift-ansible #119

Re: IaaS - (correct me if I misunderstood question) - I don't think any additional VM, domain would help, you just need a working DNS record for openshift entry point. Speaking particulary about OpenStack there is DNSaaS (Designate) which would be used for this situation. We actually had a working POC which used designate-sink for automating DNS records setup for openshift nodes. Integration with Designate is on TODO list but not sure when we get to it (patches welcome), this integration will have to be optional. Good news is that there is designate support in heat resource types (http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Designate::Record). For making this optional I can imagine we could use same approach as with loadbalancers - in loadbalancer template we would create a OOshift::DNSRecord which would map either to a fake resource type or to real OS::Designate::Record.

from openshift-on-openstack.