andrew at beekhof
Jul 31, 2011, 3:44 PM
Post #6 of 6
On 27/07/2011, at 7:29 PM, Lars Marowsky-Bree wrote:
Re: RA Spec: A new API for utilization probe
[In reply to]
> On 2011-07-27T11:18:59, Andrew Beekhof <andrew [at] beekhof> wrote:
>> The options seem to be:
>> a) do it as part of the start operation, or
>> b) teach the PE about a new operation*
>> a) means blindly starting resources (and those that depend on it),
>> hoping that the host has enough capacity (and restart the transition
>> every time new utilisation data is uploaded)
>> b) gives you a slower startup and only tells us if the destination has
>> the capacity to host that one resource, not those that depend on it
>> too. it does give less random transition restarts though.
> I thought I'd lean towards b, and wrote a longish mail about how the
> semantics of such a "discover" operation could work, how the PE would
> handle it etc - just to realize it is mostly pointless.
> Because this only matters if the resource is activated for the very
> first time, normally. Very few resources are going to change in their
> load data frequently.
> So for those, we're talking about a mandatory "go back to the PE" cycle
> for the first round - but a "start" that updates the capacity data would
> already cause that, anyway.
> For those that *are* dynamically updated, a "discover" call preceding
> start wouldn't be enough anyway, since either their start or monitor
> calls would adjust the capacity requirements more often anyway.
> Right now, I'm leaning towards a); the agent can update the utilization
> data if it has changed ("previously unset" to "now set" would count as a
> change, obviously), and then we need to go back to the PE anyway. As an
> optimization, it'd be nice if the "start" were allowed to return
> "OCF_NOT_RUNNING" so that we don't need to bother with the "stop".
> This is "efficient enough" if we assume resources are added one by one,
> or at least in smaller numbers.
> For "bulk add", a "discover" operation would have an advantage; we could
> bring all resources to the state where their dependencies are satisfied,
> schedule "discover", and hand it back to the PE then; that would be
> quite a win in number of transitions. But I don't think the complexity
> added to the PE justifies the gain.
> But. To still get the savings, what if the _UI_ called "discover" on
> those agents (bypassing the Pacemaker), so that it could directly add
> the resources with the appropriate utilization data? Then the bulk-add
> wouldn't cause the problem either.
Presumably after everything was started?
> Maybe we could extend the "validate-all" or "discover"
not validate-all please
> semantics to
> return more elaborate status (say, "key=value" on stdout/stderr) that
> the UI could interpret accordingly - at least for the agents that want
I really detest stderr/stdout parsing, but if we have to have it I think XML is the right format (like metadata).
> Architect Storage/HA, OPS Engineering, Novell, Inc.
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
> ha-wg-technical mailing list
> ha-wg-technical [at] lists
ha-wg-technical mailing list
ha-wg-technical [at] lists