On 16/06/13 22:34, Robert Collins wrote: > I thought the standard design pattern for that was zones. > say your cloud is cloud.example.com > so SRV for cloud.example.com would be keystone public > SRV for _compute._pub_endpoints.cloud.example.com -> compute public endpoint > SRV for _compute._priv_endpoints.cloud.example.com -> compute private > endpoint (and btw you can use split views to hide that from the > outside world) > > SRV for _network._pub_endpoints.cloud.example.com -> openstack network > public endpoint > etc.
Pretty much - it's expected that SRV records will follow this pattern: _<service>._<protocol>.something, where .something doesn't have to be "provider.com", it could be "internal.provider.com", or "region-a.provider.com" etc. I would personally advocate for <service> being "openstack-identity" + "openstack-identity-admin" + "openstack-identity-internal" etc rather then nesting unnecessarily. > > > E.g. known, solved thing, nothing to see here, move along. > > -Rob Thanks, Kiall _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
