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

Re: Support for distributed applications



On 10/07/13 17:59 +0200, Romain wrote:
https://github.com/smarterclayton/openshift-redis-cart/blob/master/hooks/subscribe-redis-connection-info
returns
a 404


2013/7/10 Clayton Coleman <ccoleman redhat com>

I would recommend looking at the Redis cart for an example of doing gear
discovery.


https://github.com/smarterclayton/openshift-redis-cart/blob/master/hooks/publish-redis-connection-info

https://github.com/smarterclayton/openshift-redis-cart/blob/master/hooks/subscribe-redis-connection-info


https://github.com/smarterclayton/openshift-redis-cart/blob/master/hooks/set-redis-connection-info

The hook names just need to match what they are named in the manifest
https://github.com/smarterclayton/openshift-redis-cart/blob/master/metadata/manifest.yml

There is an open story to simplify the way this info is passed to the
connection hook, and also to expose a mechanism so that the subscribe hook
can set an ENV variable that the web framework has access to.  If you're
using erlang as a web framework (vs. a connected service cartridge) then
you don't need that second part.

You could also use the broker auth key stored in the gear to make a call
to the REST API for the app and get the gear topology (via the gear-groups
call) and then generate it that way - the hooks are the *more* correct way
of doing that today.

----- Original Message -----
> Responded at the forum so those riding Google can see it too...
>
https://www.openshift.com/forums/openshift/clustered-applications-knowing-the-topology#comment-32203
>
> Can discuss here further, but I think the pub-sub cartridge capabilities
can
> get you what you need. I also think having a scalable Erlang cartridge
would
> be pretty cool :)
>
> ----- Original Message -----
> From: "Thijs Terlouw" <thijsterlouw gmail com>
> To: dev lists openshift redhat com
> Sent: Wednesday, July 10, 2013 9:56:29 AM
> Subject: Support for distributed applications
>
>
> This question is an extension from an OpenShift forum post [1].
>
> We at Spilgames are using Erlang as a core component of our
architecture. One
> of the core strengths of Erlang is the support for building distributed
> applications. Erlang also makes it trivial to hook various components
> together in a network and execute RPC calls between them. These features
all
> rely on being able to interconnect the components. A custom TCP-based
binary
> protocol is used between Erlang components. Erlang wants to build a fully
> connected network where all components can talk directly with eachother.
In
> order to do this, we need to know the endpoints of the other instances
> (host/ip + listen port).
>
> Currently in OpenShift all Gears are fully isolated containers and those
> containers normally do not talk to eachother. This prevents building any
> kind of distributed application, including distributed Erlang. We
believe we
> can work around this with custom components that register the new
instances,
> but we also believe that this functionality is generic enough that the
> platform should offer support for it. Let's first talk about the proposed
> work-around and then about let's come back to the vision that RedHat has
for
> OpenShift PaaS.
>
> For the work-around I am thinking of introducing a "gearfinder" REST
> application. This gearfinder starts in the primary gear [2] and offers a
> REST component. It is thus available through a fixed location (dns).
> Whenever a new gear starts, it attempts to register with the gearfinder.
The
> new gear also asks the gearfinder for a list of known gears, which
returns a
> list of information such as cartridge-name, gear-id, listen ip+port and
> host. My Erlang application can then get all the unique hosts and
connect to
> each of those EPMDs to get a list of nodes on that host. Next it can
connect
> to the Erlang gears indirectly via the proxy. See attached picture; the
> numbers in the notes help to understand the proposed flow. Basically this
> component is just keeping track of the gears, which is information that
is
> probably already in the system.
>
> Whether distributed applications should be supported, depends on the
vision
> that RedHat has for OpenShift. Does RedHat just want simple web-based
> applications that run in a silo? Or do you also want to offer a platform
> that can be used to build complex distributed applications. I believe
with a
> few minor tweaks it can do both. Do note that my example is probably not
> suitable for the Online platform, but those issues can be solved. I think
> distributed applications are not disallowed by the PaaS concept. A PaaS
> should try to support as many different languages and architectures as
> possible. It would also be a nice competitive advantage that OpenShift
has
> over other PaaS provider; I believe nobody offers this yet.
>
>
> [1]
>
https://www.openshift.com/forums/openshift/clustered-applications-knowing-the-topology
> [2] thinking about solutions to avoid the SPOF
>
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Attachment: pgpQr9KgZcUBT.pgp
Description: PGP signature


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