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

Re: Support for distributed applications



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

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


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