On 8/16/06, Alan Robertson [EMAIL PROTECTED] wrote:
Andrew Beekhof wrote:
On 8/15/06, Alan Robertson [EMAIL PROTECTED] wrote:
Andrew Beekhof wrote:
On 6/28/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2006-06-15T18:26:24, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
Lack of
Andrew Beekhof wrote:
On 6/28/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2006-06-15T18:26:24, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
Lack of disagreement implies agreement.
Alan, how about we plan this as an enhancement for 2.0.7?
Unlikely.
This is a significant departure
On 8/15/06, Alan Robertson [EMAIL PROTECTED] wrote:
Andrew Beekhof wrote:
On 6/28/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2006-06-15T18:26:24, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
Lack of disagreement implies agreement.
Alan, how about we plan this as an enhancement for
Andrew Beekhof wrote:
On 8/15/06, Alan Robertson [EMAIL PROTECTED] wrote:
Andrew Beekhof wrote:
On 6/28/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2006-06-15T18:26:24, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
Lack of disagreement implies agreement.
Alan, how about we plan
On 2006-07-01T08:43:05, Andrew Beekhof [EMAIL PROTECTED] wrote:
Lack of disagreement implies agreement.
Alan, how about we plan this as an enhancement for 2.0.7?
Unlikely.
This is a significant departure from the current design and a major
piece of work.
Well, ok. So not 2.0.7. ;-)
On 2006-07-03T16:16:20, Andrew Beekhof [EMAIL PROTECTED] wrote:
think of a stack of resources and what happens when something in the
middle changes... how we pull down the stack to the resource that
changed and build it up again.
thats very different to starting at the resource that changed
On 7/3/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
On 2006-07-03T16:16:20, Andrew Beekhof [EMAIL PROTECTED] wrote:
think of a stack of resources and what happens when something in the
middle changes... how we pull down the stack to the resource that
changed and build it up again.
thats
On 2006-07-03T21:34:37, Andrew Beekhof [EMAIL PROTECTED] wrote:
No no no! The whole _point_ of reload is that _it does not affect
resources depending on it_. It is purely local to the given resource.
to which i would respond how do we know that?
we store a hash of the parameters remember...
On 2006-06-15T18:26:24, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
Lack of disagreement implies agreement.
Alan, how about we plan this as an enhancement for 2.0.7?
Sincerely,
Lars Marowsky-Brée
--
High Availability Clustering
SUSE Labs, Research and Development
SUSE LINUX Products
Many LSB init scripts implement a 'reload' action which permits them to
reread their configurations without interrupting service.
By design, OCF spec is upwards-compatible with the LSB.
I think it would be good to specifically add the reload operation to the
OCF spec.
Saying something like
On 2006-06-15T08:56:00, Alan Robertson [EMAIL PROTECTED] wrote:
Many LSB init scripts implement a 'reload' action which permits them to
reread their configurations without interrupting service.
By design, OCF spec is upwards-compatible with the LSB.
I think it would be good to
On 2006-06-15T09:58:37, Alan Robertson [EMAIL PROTECTED] wrote:
1. The administrator of course may not change the parameters so much
that the RA can no longer identify the already running resource
instance. (Do we need to provide hints in the meta data to identify
which parameters are safe to
12 matches
Mail list logo
