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

Re: gear creation on nodes




----- Original Message -----
> Dan's latest change adds some caching of discovered nodes to enable
> the distribution model for new gears to be faster.  The cache is
> short, so there's a period where new nodes aren't immediately
> available.

I actually had to disable this.  I realized after the first pass that direct addressing doesn't accept additional filters.  I have some ideas about how I could still use it but for now there isn't a cache.

> 
> ----- Original Message -----
> > 
> > 
> > I'll let someone jump in and correct if this is wrong but I believe
> > the model is still:
> > 
> > - When a new node is added, it connects to the ActiveMQ topic which
> > in turn makes that node respond to MCollective requests
> > - All requests for new gears (e.g. new app, scaling, etc) go
> > through
> > the broker and for each request the broker queries MCollective for
> > the best fit node per the algorithm below
> > 
> > Given that, when a new node registers with the message bus, it
> > should
> > immediately be applicable for new gears. Some caveats if you are
> > using custom gear types as the new node would also need to support
> > that gear type.

Small note here.  As soon as you create districts, you must also add the new node to a district before the find available node algorithm will ever use it.

It's also worth mentioning that with the latest in OpenShift Origin the additional requirement for picking a node is that for scaled components, gears for the same gear group (scaled php, jboss, etc) will not be added to the same node unless no other options are available.

> > 
> > -Matt
> > 
> > On 01/28/2013 08:49 PM, Meghdoot wrote:
> > 
> > 
> > 
> > Great. Good to know.
> > What about node discovery part?
> > 
> > Sent from my iPhone
> > 
> > On Jan 28, 2013, at 5:28 PM, Grant Shipley < gshipley redhat com >
> > wrote:
> > 
> > 
> > 
> > 
> > Algorithm for finding an available node
> > 
> > 
> > • Find the district with the most available UUIDs.
> > 
> > • Find the nodes within that district that have the least
> > active_capacity.
> > 
> > • If some nodes still have active capacity, randomly pick one of
> > the
> > nodes with the lower levels of active_capacity.
> > 
> > • If no nodes in that district have active capacity, find nodes
> > within any district (with available UUIDs) that have available
> > capacity and randomly pick one of the nodes with the lower levels
> > of
> > active_capacity.
> > This algorithm means that applications are created on the districts
> > with the most available UUIDs first, and districts that have
> > available, non-active capacity are preferred.
> > 
> > 
> > 
> > 
> > --
> > gs
> > 
> > 
> > On Jan 28, 2013, at 7:40 PM, meghdoot bhattacharya <
> > meghdoot_b yahoo com > wrote:
> > 
> > 
> > 
> > 
> > 
> > Hi,
> > Given a set of nodes, when new gears are about to be created, what
> > is
> > the algorithm used to select the node?
> > 
> > 
> > If brand new nodes/VM's are added later, how do those new nodes get
> > discovered and made available to haproxy for future gear creation
> > on
> > those nodes? Does the mcollective in broker periodically send
> > messages to discover new nodes or figure out if nodes are gone?
> > 
> > 
> > Thx. _______________________________________________
> > 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
>


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