Thank you everybody for all your answers.
I confirm that my goal is to develop a DIY routing/proxying based on the routing SPI.
I think I will not use the gear_group?include=endpoints API because it means a lot of requests to be sent (List users, for each user, list applications, and for each application retrieve the endpoints). I will wait for the REST endpoints API, or I will retrieve the data directly from mongodb.
But our second goal is to recommend every application to be HA.
Is there a way I can change the default setting for app creation from not-scalable & not-HA to scalable & HA ? I mean, where should I start in the source code, if I want to do that ?
I was also wondering why the HA prefix is `ha-appname-domain.example.com` and not `appname-domain.ha.example.com` ?
Having a wildcard DNS entry `*.ha.example.com` pointing to the reverse proxy would ease installing OpenShift. Public DNS delegation would become optional.
DNS entry not HA (appname-domain.example.com) would be delegated to a private DNS for ssh/git.
De : dev-bounces lists openshift redhat com [mailto:dev-bounces lists openshift redhat com]
De la part de Arunabha Ghosh
On Wed, Nov 13, 2013 at 11:15 AM, Luke Meyer <lmeyer redhat com> wrote:
> Sent: Monday, November 11, 2013 4:58:00 PM
This is not something we enable well yet. He's not talking about HA apps. He's talking about DIY routing/proxying for all apps.
For this user, it's not just HA apps. It's all ports on all apps. Whether that's a use case we want to support is not clear to me.
The only way I can see doing this is if HTTP requests and git/ssh requests have different hostnames. Which they do if it's an HA app (the ha-app-name can then be pointed to the router); otherwise not. So the only way to do it for all apps
currently is to make all apps HA. Do we want to do it for all apps?
I'd vote for this one. Reading the docs on OSO, the single namespace for both ssh and web access seemed a little bit odd as it forced both the serving of the app and dev access to the app to the same entity. Separating them out will enable quite a few useful use cases like the central load balancing. Further, one can imagine the git repo for an app to be located on a centralized service which receives the upload, packages the app and deploys it onto nodes. This would fit in very well with potential future use cases like docker based apps where the git upload is received by OSO, packaged as a docker container and deployed on the node with the app being routed to by the centralized load balancing and routing service.
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.