Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
Andrew Beekhof wrote: On Jan 27, 2006, at 3:23 PM, Alan Robertson wrote: Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: CTS testers please note this commit. In order to run the same tests as you used to, you need to specify: enable_config_writes off in ha.cf Why is this an ha.cf option. It's clearly a CIB option - so I would think it belongs in the CIB. It makes no sense there... We discussed some things, but I don't remember this one. Four reasons: - the CIB is intended to be policy free (and at the moment is IIRC) BUT this is a CIB policy - hence it must be enforced and carried out by the CIB. - correct interpretation of options in the CIB requires linking against the PE (or worse, duplicating slabs of its code) I don't follow this at all. It's the CIB that writes the CIB, isn't it? But it doesn't know what its writing. Same way the LRM doesn't know what its starting. But, the LRM does have to make special cases which make it somewhat conceptually impure. Remember all options can be time, host and phase of the moon dependent. In order to understand what the option is actually set to, it needs to be able to evaluate all those expressions and rule sets - a fair chunk of the PE. Plus its a waste to do this every time the CIB is updated. This sure looks like a combination of the false dichotomy and straw man logical fallacies. But, perhaps I'm missing something - because you are in fact the expert on the CIB. So, why wouldn't calling get_xml_attr_nested() and friends return the data you want? you would know if you paid attention for even half a second: Remember all options can be time, host and phase of the moon dependent. If you say because the XML section you'd choose to put it inside of has complicated semantics, then don't do that. If you added a section, that would certainly solve any potential problem of complexity - and it would be readily extensible to new things as they come up. The environment variables can't create a complicated policy do or do not write to disk... gee thats complicated So, in this you agree with me. It would be helpful if you read what I wrote, and not the opposite of what I wrote. - so saying you _have_ to have a complicated policy if its a cluster option then it has the same properties as all the others including resource stickiness which you seemed to be rather fond of being able to set differently depending on the time. But, again, you didn't read what I wrote. Sigh... If making it a "cluster option" doesn't work, then don't make it a cluster option. It's the false dichotomy peeking it's head in again. Making it a part of the cluster options section isn't the only answer of where to put it. I suggested a section rooted immediately below . Make your own name if you don't like mine - but _whatever_ you do - don't put it in the existing cluster options section. There's no point in you arguing against your straw man proposal - because I don't care if some irrelevant straw-man proposal doesn't work. So what? If you invent a new section, it doesn't have to have all the complexity you want to get away from. You can make it as simple as you like. now that you move it into the CIB doesn't obviously follow. If you didn't need it before, you don't need it now. we did need it was before... it was broken and I just didnt know it yet. I don't think you read what I wrote. These words were in response to something I didn't say. I'm not sure exactly what, but I can't see any relationship to anything I said. So, it's impossible to respond to this. There may be in fact, really convincing arguments you haven't presented so far. But, you're going to have to do something better than wave your hands and say "trust me I'm the expert here". i didnt do that. i tried to explain it and you threatened to back out the changes. For those not on IRC earlier today: The conversation went like this: Alan: it's a bug Andrew: it's not a bug repeat above 2 lines ad nauseum There wasn't much give and take going on on either side. But, in any case, I wasn't referring to IRC, I was referring to the email chain - since it doesn't make sense to drag in IRC without any kind of references to what was going on. The lines in your original email offered no explanations other than "it would be hard". Your lines above offer nothing new. And, since the lack of these options appears to affect STONITH behavior in an undocumented way, there's also a lot more here than you've talked about. I'd be very interested to hear more on that subject as well. ooo here's a node we dont know about... what should we do? we should know what we dont know and shoot the thing so that we do know. I'm not sure how one can "know wh
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
On Jan 27, 2006, at 3:23 PM, Alan Robertson wrote: Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: CTS testers please note this commit. In order to run the same tests as you used to, you need to specify: enable_config_writes off in ha.cf Why is this an ha.cf option. It's clearly a CIB option - so I would think it belongs in the CIB. It makes no sense there... We discussed some things, but I don't remember this one. Four reasons: - the CIB is intended to be policy free (and at the moment is IIRC) BUT this is a CIB policy - hence it must be enforced and carried out by the CIB. - correct interpretation of options in the CIB requires linking against the PE (or worse, duplicating slabs of its code) I don't follow this at all. It's the CIB that writes the CIB, isn't it? But it doesn't know what its writing. Same way the LRM doesn't know what its starting. But, the LRM does have to make special cases which make it somewhat conceptually impure. Remember all options can be time, host and phase of the moon dependent. In order to understand what the option is actually set to, it needs to be able to evaluate all those expressions and rule sets - a fair chunk of the PE. Plus its a waste to do this every time the CIB is updated. This sure looks like a combination of the false dichotomy and straw man logical fallacies. But, perhaps I'm missing something - because you are in fact the expert on the CIB. So, why wouldn't calling get_xml_attr_nested() and friends return the data you want? you would know if you paid attention for even half a second: Remember all options can be time, host and phase of the moon dependent. If you say because the XML section you'd choose to put it inside of has complicated semantics, then don't do that. If you added a section, that would certainly solve any potential problem of complexity - and it would be readily extensible to new things as they come up. The environment variables can't create a complicated policy do or do not write to disk... gee thats complicated - so saying you _have_ to have a complicated policy if its a cluster option then it has the same properties as all the others including resource stickiness which you seemed to be rather fond of being able to set differently depending on the time. now that you move it into the CIB doesn't obviously follow. If you didn't need it before, you don't need it now. we did need it was before... it was broken and I just didnt know it yet. There may be in fact, really convincing arguments you haven't presented so far. But, you're going to have to do something better than wave your hands and say "trust me I'm the expert here". i didnt do that. i tried to explain it and you threatened to back out the changes. And, since the lack of these options appears to affect STONITH behavior in an undocumented way, there's also a lot more here than you've talked about. I'd be very interested to hear more on that subject as well. ooo here's a node we dont know about... what should we do? we should know what we dont know and shoot the thing so that we do know. if we dont write to disk... then we have no record of any other nodes do we (unless the admin included them in the on-disk version) so there is no-one to shoot . you know about this so please stop acting so surprised it would be helpful if you paid attention the first few times we have these sorts of conversations. you're clearly in one of those moods again and now I am too. see you monday, i'm going skiing. -- Andrew Beekhof "I like your old stuff better than your new stuff" - Regurgitator ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: CTS testers please note this commit. In order to run the same tests as you used to, you need to specify: enable_config_writes off in ha.cf Why is this an ha.cf option. It's clearly a CIB option - so I would think it belongs in the CIB. It makes no sense there... We discussed some things, but I don't remember this one. Four reasons: - the CIB is intended to be policy free (and at the moment is IIRC) BUT this is a CIB policy - hence it must be enforced and carried out by the CIB. - correct interpretation of options in the CIB requires linking against the PE (or worse, duplicating slabs of its code) I don't follow this at all. It's the CIB that writes the CIB, isn't it? But it doesn't know what its writing. Same way the LRM doesn't know what its starting. But, the LRM does have to make special cases which make it somewhat conceptually impure. Remember all options can be time, host and phase of the moon dependent. In order to understand what the option is actually set to, it needs to be able to evaluate all those expressions and rule sets - a fair chunk of the PE. Plus its a waste to do this every time the CIB is updated. This sure looks like a combination of the false dichotomy and straw man logical fallacies. But, perhaps I'm missing something - because you are in fact the expert on the CIB. So, why wouldn't calling get_xml_attr_nested() and friends return the data you want? If you say because the XML section you'd choose to put it inside of has complicated semantics, then don't do that. If you added a section, that would certainly solve any potential problem of complexity - and it would be readily extensible to new things as they come up. The environment variables can't create a complicated policy - so saying you _have_ to have a complicated policy now that you move it into the CIB doesn't obviously follow. If you didn't need it before, you don't need it now. There may be in fact, really convincing arguments you haven't presented so far. But, you're going to have to do something better than wave your hands and say "trust me I'm the expert here". And, since the lack of these options appears to affect STONITH behavior in an undocumented way, there's also a lot more here than you've talked about. I'd be very interested to hear more on that subject as well. For those who aren't familiar with the English terms for these logical fallacies, I offer these definitions: The false dichotomy fallacy involves enumerating a small number of possible options, and eliminating all but one of these options through a logical arguments, then stating that the only possible solution then is the one remaining option. This is a logical fallacy when the enumerated set is incomplete. In computer science, it is usually impossible to enumerate all possible solutions, therefore it often occurs. The straw man fallacy is closely related. It involves setting up a weak argument for a particular proposition and then proceeding to demolish the weak argument, then claiming (falsely) that the proposition must therefore be false. This weak argument is referred to as a "straw man" argument, since anyone can defeat a man made of straw. -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: > Andrew Beekhof wrote: > > On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: > >> Andrew Beekhof wrote: > >>> CTS testers please note this commit. > >>> > >>> In order to run the same tests as you used to, you need to specify: > >>> enable_config_writes off > >>> in ha.cf > >> Why is this an ha.cf option. It's clearly a CIB option - so I would > >> think it belongs in the CIB. It makes no sense there... We discussed > >> some things, but I don't remember this one. > > > > Four reasons: > > - the CIB is intended to be policy free (and at the moment is IIRC) > > BUT this is a CIB policy - hence it must be enforced and carried out by > the CIB. > > > - correct interpretation of options in the CIB requires linking against > > the PE > >(or worse, duplicating slabs of its code) > > I don't follow this at all. It's the CIB that writes the CIB, isn't it? But it doesn't know what its writing. Same way the LRM doesn't know what its starting. Remember all options can be time, host and phase of the moon dependent. In order to understand what the option is actually set to, it needs to be able to evaluate all those expressions and rule sets - a fair chunk of the PE. Plus its a waste to do this every time the CIB is updated. > > - because we may want different values for different hosts > > - because this isn't something that needs to be changed on the fly > > > > Mostly reasons 1 and 2 were the driving factors. > > You had said you weren't opposed to new options and lmb concurred with > > my reasons at the time - so I didn't think it would be a big deal. > > > >> With regard to the other logging options. Which do I have to set to get > >> CIB to work? I'm currently setting debug to 1. Is that sufficient? > > > > The CIB will function no matter what. > > If you set the other options to "on" then it will function AND I'll be > > able to help if something goes wrong (regardless of the value for > > debug). ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
On 2006-01-26T12:06:33, Alan Robertson <[EMAIL PROTECTED]> wrote: > >Four reasons: > > - the CIB is intended to be policy free (and at the moment is IIRC) > BUT this is a CIB policy - hence it must be enforced and carried out by > the CIB. > > > - correct interpretation of options in the CIB requires linking against > > the PE > > (or worse, duplicating slabs of its code) > > I don't follow this at all. It's the CIB that writes the CIB, isn't it? Yeah, but to the CIB, the data in the CIB is opaque. (Minus the generation counters.) Iff the CIB was to interpret itself, it would have to have the pengine smarts to figure out which option actually applied at any given time. I second Andrew's motion that this isn't a good idea from a design point of view. I second Alan's motion that the current solution ain't perfect yet either. ;-) Ultimately, I want the logging system itself (ie, ha_logd and cl_log.*) to have flags and different levels, so we can tune logging at a much finer granularity. ie, log everything with an importance of warn and up; comm layer info and up; log all things related to communication with debug; log CIB stuff at debug2. Then you could easily say "config changes: yes, log them"... Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
Andrew Beekhof wrote: On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: Andrew Beekhof wrote: CTS testers please note this commit. In order to run the same tests as you used to, you need to specify: enable_config_writes off in ha.cf Why is this an ha.cf option. It's clearly a CIB option - so I would think it belongs in the CIB. It makes no sense there... We discussed some things, but I don't remember this one. Four reasons: - the CIB is intended to be policy free (and at the moment is IIRC) BUT this is a CIB policy - hence it must be enforced and carried out by the CIB. - correct interpretation of options in the CIB requires linking against the PE (or worse, duplicating slabs of its code) I don't follow this at all. It's the CIB that writes the CIB, isn't it? - because we may want different values for different hosts - because this isn't something that needs to be changed on the fly Mostly reasons 1 and 2 were the driving factors. You had said you weren't opposed to new options and lmb concurred with my reasons at the time - so I didn't think it would be a big deal. With regard to the other logging options. Which do I have to set to get CIB to work? I'm currently setting debug to 1. Is that sufficient? The CIB will function no matter what. If you set the other options to "on" then it will function AND I'll be able to help if something goes wrong (regardless of the value for debug). -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
On 1/26/06, Alan Robertson <[EMAIL PROTECTED]> wrote: > Andrew Beekhof wrote: > > CTS testers please note this commit. > > > > In order to run the same tests as you used to, you need to specify: > > enable_config_writes off > > in ha.cf > > Why is this an ha.cf option. It's clearly a CIB option - so I would > think it belongs in the CIB. It makes no sense there... We discussed > some things, but I don't remember this one. Four reasons: - the CIB is intended to be policy free (and at the moment is IIRC) - correct interpretation of options in the CIB requires linking against the PE (or worse, duplicating slabs of its code) - because we may want different values for different hosts - because this isn't something that needs to be changed on the fly Mostly reasons 1 and 2 were the driving factors. You had said you weren't opposed to new options and lmb concurred with my reasons at the time - so I didn't think it would be a big deal. > With regard to the other logging options. Which do I have to set to get > CIB to work? I'm currently setting debug to 1. Is that sufficient? The CIB will function no matter what. If you set the other options to "on" then it will function AND I'll be able to help if something goes wrong (regardless of the value for debug). Eventually we'll probably have this log to disk or something as we discussed. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: heartbeat by andrew from
Andrew Beekhof wrote: CTS testers please note this commit. In order to run the same tests as you used to, you need to specify: enable_config_writes off in ha.cf Why is this an ha.cf option. It's clearly a CIB option - so I would think it belongs in the CIB. It makes no sense there... We discussed some things, but I don't remember this one. With regard to the other logging options. Which do I have to set to get CIB to work? I'm currently setting debug to 1. Is that sufficient? -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
