[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Routing SPI




----- Original Message -----
> Thank you for all your answers.
> 
> I have started an simple routing implementation with nginx here :
> https://github.com/worldline/openshift-nginx-routing
> I get it very quickly and it works like a charm ;)
> 
> Now I would like to add the init configuration via a call to the gear_group.
> Unfortunately I don't see how I can get the PORT of the web gear. But
> temporarily I can point to the Node Apache (port 80), and refactor it when
> the rest endpoint will be available.

You need to add ?include=endpoints (missed that in my initial post)
 
> 
> About the DNS entry, if I understand well, every ha-xxxxx applications have a
> CNAME entry pointing to ROUTER_HOSTNAME (in broker.conf) ?
> 
> Thank you so much for the Routing SPI. It's very easy to use :)
> 
> Cheers
> Romain
> 
> -----Message d'origine-----
> De : Rajat Chopra [mailto:rchopra redhat com]
> Envoyé : lundi 11 novembre 2013 22:58
> À : Clayton Coleman
> Cc : Philibert Romain; dev lists openshift redhat com
> Objet : Re: Routing SPI
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "Philibert Romain" <romain philibert worldline com>
> > Cc: dev lists openshift redhat com
> > Sent: Monday, November 11, 2013 7:11:00 AM
> > Subject: Re: Routing SPI
> >
> > Hey Romain - didn't see any responses to the public list, so I'll
> > throw a couple of answers in where I know.
> >
> > On Nov 6, 2013, at 9:10 AM, Philibert Romain <
> > romain philibert worldline com
> > > wrote:
> >
> >
> >
> >
> >
> >
> > Hello everyone,
> >
> >
> >
> > We are currently playing with the Routing SPI, on the latest master of
> > origin.
> >
> >
> >
> > It works quite well. I published a gist explaining how to use it :
> > https://gist.github.com/Filirom1/7334311
> >
> >
> >
> > Our goal is to build an nginx OpenShift LoadBalancer that will bypass
> > Node Apache, HAProxy and Node Proxy.
> >
> > Nginx will be highly available because configured behind LVS, and the
> > configuration will be sharded amoung severals servers.
> >
> >
> >
> > This project was done internally and is now open-sourced :
> > https://github.com/worldline/paas-rproxy-agent
> >
> > This project doesn’t use the routing SPI, instead it spies mcollective
> > messages and transmit configuration messages to another mcollective
> > agent that will create nginx configuration… This source code doesn’t
> > work anymore with the latest origin, this is the reason why we are
> > looking at the Routing SPI now. It will make our code robust to future
> > origin internal changes.
> >
> > Very awesome - that's an awesome integration, and should be useful to
> > many people.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Before starting our implementation with the routing SPI, I was
> > wondering if there is a REST API to retrieve the whole routing table ?
> > It would be useful to init nginx configuration before adding it to the
> > cluster.
> >
> > gear-groups should be returning the endpoints of each gear in the
> > application. We had been discussing a new rest endpoint that was
> > easier to use but it hasn't been implemented yet.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Another thing I notice, is that `add_gear` and `delete_gear` messages
> > are only published if the application is HA. Is it wanted ?
> >
> > Sounds like a bug - I'll make sure one is filed.
> >
> >
> 
> 
> It is an intended outcome. Not a bug. Isn't the entire routing SPI meant for
> applications who want to have the HA routing layer? So we skip the hassle
> for those who are not designated so.
> We can always change the behaviour, counter-arguments please?
> 
> 
> >
> >
> >
> >
> >
> >
> >
> >
> > The last question is how can I force every http request to pass
> > through the nginx (nginx servers are different from node servers), and
> > ssh/git requests to access the node directly ? Currently we solved
> > this with this Pull Request :
> > https://github.com/openshift/origin-server/pull/2877 . It replaces ssh node
> > names by node IP, but it creates problems when moving gears.
> > `.git/config` reference an IP (not a name anymore) that changed when
> > the gear was moved.
> >
> > Will look to see if there's a good answer - it sounds reasonable.
> 
> 
> The difference between web requests vs ssh/git requests should be resolved
> using the DNS entries.
> There should be one DNS meant for web requests and another for ssh/git. And
> that is what the event 'make-ha' does.
> 
>  - A given app's default dns is not HA, because it points to the
>  first-gear/head-gear/deploy-gear of the app. e.g.
>  appname-namespace.rhcloud.com
>  - If one uses the appname-namespace.rhcloud.com DNS then both the git/ssh
>  and web/http requests land on the first gear without the router knowing
>  anything about it.
>  - Enter the HA DNS entry - ha-appname-namespace.rhcloud.com ! This dns
>  points to the router with the assumption that some
>  vhost/mod-rewrite/nginx-http-rewrite exists in the router to do
>  forward/reverse proxy with the appropriate url mapping.
> 
> With two DNS entries, one pointing to the router and the other to the
> head-gear, we do not have to worry about 'move' etc. The fallout is that
> git-push/ssh is not HA. Only the web requests become HA. Eventually we can
> figure out how to resolve/re-map git/ssh DNS if the head gear/node goes
> down.
> 
> 
> Hope I helped.
> Rajat
> 
> 
> 
> 
> 
> 
> >
> > Thanks Romain!
> >
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >
> 
> 
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
> être recherchée quant au contenu de ce message. Bien que les meilleurs
> efforts soient faits pour maintenir cette transmission exempte de tout
> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> responsabilité ne saurait être recherchée pour tout dommage résultant d'un
> virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail in
> error, please notify the sender immediately and destroy it. As its integrity
> cannot be secured on the Internet, the Worldline liability cannot be
> triggered for the message content. Although the sender endeavours to
> maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]