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

Re: Support for distributed applications



That sort of multiapp (domain level) ensemble is much further out.  No recommendations there, but feel free to work through the combinations.

Intra-domain/Inter-domain communication between apps is an open topic.  Any discovery has to be balanced by configurability.  Jenkins-server/jenkins-client is the bare minimum example of this sort of interaction - see the thread on ACL and Jenkins for some thoughts on interapp connectivity.  We do prefer to use the domain to support ensembles - it is certainly possible for you to (from the app's gear) make a REST API call to the broker to get the other apps in the domain, although we may limit that more strictly in the future.

----- Original Message -----
> That REST api sounds very sensible and very useful have this in the
> platform. I'm afraid there are no timelines for this feature yet, so if I
> want to start work on prototyping Erlang applications internally, what
> should I do? It's not difficult to create a temporary gearfinder
> application after all.
> 
> Assuming we have solved both the intra-app distribution and inter-app
> discovery/connections, the next problem will be that we want to specify
> ensembles of applications. For example a product exists of appa + appb +
> appc. Each app lists it's internal requirements (endpoints / events) as
> usual. A meta-repository where you can specify that certain applications
> should be deployed together. Other users could then pick from this
> meta-repository a logical bundle that works well together and start to
> develop on it.
> 
> 
> On Wed, Jul 10, 2013 at 7:36 PM, Clayton Coleman <ccoleman redhat com>wrote:
> 
> > It's a bit difficult to get endpoints today from the REST API.  You can
> > listen to the publish-http-endpoint-url event sent to HAProxy in order to
> > collect those on the gear, but it's harder to get from externally.  The
> > gear_groups API lists the gears, but not the ports.
> >
> > As part of the HA pep, we will expose an endpoints REST API call that
> > returns a hostname, port, protocol, type, cart, and gear id for each
> > visible endpoint.  That'll assist in getting that info.  (
> > https://github.com/openshift/openshift-pep/blob/master/openshift-pep-005.md#routing-table-data-model-wip
> > )
> >
> > For now, there is no great option.
> 


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