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

Re: gear creation on nodes

For some reason districts get more attention than they deserve. They are a resource allocation scheme to facilitate moving gears between node hosts seamlessly. That is all.

If you want to control where gears physically land, gear profiles are the only present mechanism.

----- Original Message -----
From: "meghdoot bhattacharya" <meghdoot_b yahoo com>
To: "Luke Meyer" <lmeyer redhat com>
Cc: dev lists openshift redhat com
Sent: Wednesday, January 30, 2013 12:42:16 PM
Subject: Re: gear creation on nodes

I was talking to Operations and they like the concept of districts but they are interested in pinning a certain application in a certain district of nodes. In their minds, districts are logical pools that can come and go, they would use LBaaS to dynamically point to these districts for new applications or maybe new versions of applications pushed. They literally manage thousands of app [front, mid and back today]. But as per the discussion below looks like, an app can land in gears in different districts as longs as gear profiles are compatible. But what I think would be great is we have the option to create app X with gear profile Y and additionally with district Z. Validation check will be there if that district does not support Y. Future gear creations for the app in auto scale will be only within that district. 
Is this supported by any chance? One way I think is to create a unique gear profile that only few apps want to use and be pinned into a district that is created with the unique gear profile. Then the algorithm will automatically pin the gear creation only within nodes in that district. 
Otherwise I guess we may have to add this as a feature ourselves. 

From: Luke Meyer <lmeyer redhat com> 
To: meghdoot bhattacharya <meghdoot_b yahoo com> 
Cc: dev lists openshift redhat com 
Sent: Wednesday, January 30, 2013 6:17 AM 
Subject: Re: gear creation on nodes 

Other replies have talked about current developments in Origin. If you're looking at production usage, you will probably be considering OpenShift Enterprise, which for stability will generally be a little behind. The features in discussion here won't be in OSE until version 1.2 at least. 

The existing OSE gear placement algorithm is described here: 
Krishna's pointer to the actual algorithm is good, but go back a few months if you want to see how it shipped in OSE. 

Note that there are options for enabling/disabling districts in /etc/openshift/plugins.d/openshift-origin-msg-broker-mcollective.conf as well as enabling/disabling non-district nodes when districts are enabled. The defaults should usually be reasonable. 

As far as node host discovery - until Dan's change is complete, a node host is made discoverable by subscribing itself via mcollective. Gear placement requests are broadcast with a filter for node hosts to self-select according to their facts. With districts in play, one of the filters/facts is district. Other filters are for active_capacity and gear profile. So although with districts we have a registry of known nodes, that's not directly used yet. What really allows a node host to accept gears is its subscription to the broadcasts and the matching of its facts to the request filters. 

----- Original Message ----- 
From: "meghdoot bhattacharya" < meghdoot_b yahoo com > 
To: dev lists openshift redhat com 
Sent: Monday, January 28, 2013 7:40:33 PM 
Subject: gear creation on nodes 

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? 

dev mailing list 
dev lists openshift redhat com 

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