Open Stack

On Tue, 7 Oct 2014 10:27:44 PM Lars Kellogg-Stedman wrote:
> On Tue, Oct 07, 2014 at 06:14:22PM +1100, Angus Lees wrote:
> > What you haven't stated here is whether the catalog endpoints should be
> > reachable outside the kubernetes minions or not.
> 
> I thought I had been clear about that, but reading over the email it
> looks like the part where I made that clear was actually already iny
> my head.
> 
> This solution was meant primarily to facilitate pod-to-pod
> communication, particularly in cases where a service ends up moving
> from one minion to another.

Ah cool.  In that case a solution will only be _required_ whenever we can't 
specify the endpoint URL directly (from the usual k8s env vars). Assuming the 
software we run in pods is scripted/automated, then we can also afford for our 
solution to be a bit more verbose and unpleasant.  (Of course, we _do_ still 
need a solution)

> > 1.  Fixed hostname
> > 
> > Add something like this to the start.sh wrapper script:
> >  echo $SERVICE_HOST proxy >> /etc/hosts
> > 
> > and then use http://proxy:$port/... etc as the endpoint in keystone
> > catalog.
> This was one of my first thoughts, but according to the
> #google_containers folks, SERVICE_HOST is going away real soon now:
> 
>   https://github.com/GoogleCloudPlatform/kubernetes/pull/1402
> 
> There will be a per-service ip available, so we could still do
> something similar.

Yep, exactly.  Having just read through 
https://github.com/GoogleCloudPlatform/kubernetes/issues/1107 it looks like 
all the options under consideration are trying to make a known hostname at 
least as easy as the above.

I humbly suggest we go with the known-hostname option, and adapt the precise 
approach as kubernetes/pull/1402-and-similar evolves.  (In particular, we'll 
probably need per-service hostnames reasonably soon)

> > Create a regular OpenStack loadbalancer and configure this (possibly
> > publicly available) IP in keystone catalog.
> > 
> > I _think_ this could even be a loadbalancer controlled by the neutron we
> > just set up, assuming the the loadbalancer HA works without help and the
> > nova<-> 
> > >neutron "bootstrap" layer was setup using regular k8s service env vars
> > >and
> > 
> > not the loadbalancer IPs.
> 
> There's no guarantee that we're running Kubernetes on top of
> openstack, and I don't think we could use Neutron deployed inside
> kubernetes because we'd want the LB in place for basic services like
> keystone and the database server.

My thought was that we would use directly configured URLs (based on the usual 
k8s env vars) wherever possible.   The catalog endpoints are mostly used by 
end-user tools, and these of course can be delayed after the deployed neutron 
is functional.

What I'm unsure of, is if there is any openstack service which *must* use 
keystone catalogs (rather than explicit URL configuration) to find other 
openstack components.  I suspect there is no such service - or if there is 
(horizon?), it isn't required to create a functional neutron loadbalancer.

I agree it's a bit mind-twisting, and that in itself is a disadvantage of this 
option.

-- 
 - Gus