Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
On May 21, 2006, at 4:12 PM, Lars Marowsky-Bree wrote:On 2006-05-21T16:04:24, Andrew Beekhof <[EMAIL PROTECTED]> wrote: Though still, how would the RA inform the tools about description &defaults for this? this is where i'm a bit lost... these aren't RA parameters so in theory there's nothing to change right? Ah, but they are. For example, the RAs currently use their metadata totell the GUI what defaults to set for clone_max, clone_node_max already,and I'd expect that a drbd RA would also wish to tell us that yes, itwould want to have notifications enabled by default pretty please, andthat yes, it's a master-slave one. (Currently, this is indicated by thepromote/demote/notify ops being in the metadata.)If we move it out of the regular namespace, it follows they shouldn't bedescribed within the regular section in the metadataeither. So we need to put them somewhere else...i think the best way forward (for now) is to have the PE support the meta_attributes stuff but not use it by default. just have it available as an "advanced" option when people run into conflicts.ie. no changes required for the RAs in the short term -- Andrew Beekhof "Would the last person to leave please turn out the enlightenment?" - TISM ___ 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: crm by andrew from
On 2006-05-21T16:04:24, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > >Though still, how would the RA inform the tools about description & > >defaults for this? > this is where i'm a bit lost... these aren't RA parameters so in > theory there's nothing to change right? Ah, but they are. For example, the RAs currently use their metadata to tell the GUI what defaults to set for clone_max, clone_node_max already, and I'd expect that a drbd RA would also wish to tell us that yes, it would want to have notifications enabled by default pretty please, and that yes, it's a master-slave one. (Currently, this is indicated by the promote/demote/notify ops being in the metadata.) If we move it out of the regular namespace, it follows they shouldn't be described within the regular section in the metadata either. So we need to put them somewhere else... 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: crm by andrew from
On May 21, 2006, at 3:44 PM, Lars Marowsky-Bree wrote:On 2006-05-20T16:52:51, Andrew Beekhof <[EMAIL PROTECTED]> wrote: Prop 1: I set up a "meta" hashtable and populate it with meta_attributes (and for backwards compatibility copy in any unset attributes from the regular hashtable).From then on i just look up the name at the meta hashtable. "and add the crm-meta- prefix at the end"i think thats the bit we diverged on (because i didnt say it).so the admin would still configure end the code would still look for Xthe only change is that when we're creating the list of parameters to pass to the lrm, we prefix them with "crm-meta-"... so X comes out as crm-meta-X (and if you configured it in the old way, as X too for backwards compatibility) Ah, I see.Well, that makes more sense.So, as soon as a meta-section is seen, the "automatic" population of itfrom the regular name-space is turned off for that resource?yepMakes sense, yes. I think now I get what you say.Though still, how would the RA inform the tools about description &defaults for this? this is where i'm a bit lost... these aren't RA parameters so in theory there's nothing to change right?And the tools like the mgmtd/GUI would still need tobe modified to set these options in a whole different section.I'd still go with simply prefixing them everywhere. -- Andrew Beekhof "Would the last person to leave please turn out the enlightenment?" - TISM ___ 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] Meta configuration namespace
On May 21, 2006, at 3:47 PM, Lars Marowsky-Bree wrote:On 2006-05-21T13:45:10, Andrew Beekhof <[EMAIL PROTECTED]> wrote: Another question... should things like an operation's interval/ timeout also show up in the meta namespace or the regular one?Momentarily ignoring issues of compatibility, I think it should be the meta namespace. Meta, clearly.ok. followup question... when do you want it? GM or SP1? -- Andrew Beekhof "Would the last person to leave please turn out the enlightenment?" - TISM ___ 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] Meta configuration namespace
On 2006-05-21T07:13:16, Alan Robertson <[EMAIL PROTECTED]> wrote: > Lars has always wanted RAs to time themselves (which I thought was > madness), so he may disagree with us on this. If you can't represent me correctly, please do not at all ;-) I prefer to speak for myself. I said that there's value in RAs having time-outs on the (possibly blocking) external commands they run in some cases, and then might escalate to a more forceful way of, say, shutting down a resource instance. (ask nicely, ask with force, kill processes - the Oracle database agent for FailSafe had such logic.) That's got nothing to do with the current discussion, though. > Do they show up in the normal namespace now? Yes. That's a "bug" though, they shouldn't. > >And even the compatibility shouldn't be too bad since the LRM gets > >these values from the CRM not the parameter list. > The one I know shows up is "target_role". This is kind of annoying in > the GUI. So in my thinking (futile and clouded though it is), it's the > example I tend to have in mind. Now that I think of it some more, whether the GUI learns to treat a meta_attributes section differently or treat attributes starting with "crm_meta_" differently probably doesn't matter one way or the other. But, how to describe defaults for these in the RA metadata then? Probably ought to go into the section in the metadata then :-/ 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] Meta configuration namespace
On 2006-05-21T13:45:10, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > Another question... should things like an operation's interval/ > timeout also show up in the meta namespace or the regular one? > > Momentarily ignoring issues of compatibility, I think it should be > the meta namespace. Meta, clearly. -- 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: crm by andrew from
On 2006-05-20T10:51:53, Alan Robertson <[EMAIL PROTECTED]> wrote: > Are you implying that the only part affected is the LRM? > > There are a couple of things that surprise me about this. > > If you leave the name spaces mingled in the GUI (and the CIB, > presumably), then the name space clashes will still happen. He's not suggesting that. This is about storing the meta attributes not within the "attributes" element within the instance_attributes, but within a new "meta_attributes". > If you put conversion logic in place that automatically converts from > the old form to the new form, then the current names are still reserved > - it's just not as obvious. This could be turned off after the setup has been sanitized, or automatically (as Andrew suggests, when the first meta_attributes section is seen for a resource). > If you wrote an external conversion script that you could run on a > one-shot basis, then that would be helpful - but wouldn't be the right > thing to do until a cluster was completely converted over to the new > names (and you'd hope you don't have to fail over in this interval). Right, a script to do this conversion could be done. > "What you're going to do, do quickly" (Jn 13:27). Because the longer > this drags on, the worse the problem will be. > > This is _exactly_ the kind of thing you'd like to have settled by the > time of a major release - so that the legacy problems will be minimal. Thanks for your guidance on this matter after the fact ;-) 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: crm by andrew from
On 2006-05-20T16:52:51, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > >Prop 1: I set up a "meta" hashtable and populate it with > >meta_attributes (and for backwards compatibility copy in any unset > >attributes from the regular hashtable). > > > >From then on i just look up the name at the meta hashtable. > > "and add the crm-meta- prefix at the end" > > i think thats the bit we diverged on (because i didnt say it). > > so the admin would still configure > > end the code would still look for X > > the only change is that when we're creating the list of parameters to > pass to the lrm, we prefix them with "crm-meta-"... so X comes out as > crm-meta-X (and if you configured it in the old way, as X too for > backwards compatibility) Ah, I see. Well, that makes more sense. So, as soon as a meta-section is seen, the "automatic" population of it from the regular name-space is turned off for that resource? Makes sense, yes. I think now I get what you say. Though still, how would the RA inform the tools about description & defaults for this? And the tools like the mgmtd/GUI would still need to be modified to set these options in a whole different section. I'd still go with simply prefixing them everywhere. 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: crm by andrew from
On 2006-05-20T15:29:12, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > >So, my proposal 1 was that in 20:20 hindsight, we'd not have polluted > >the regular instance_attributes namespace, but create a special > >meta_attributes element (and thus namespace) within. And also provide > >them to the RAs in a different namespace, not the reskeys. > > well i dont think the lrm would support a whole new namespace, so i > was settling for a sub-namespace. > > eg. OCF_RESKEY_crm-meta- Makes sense. (Except that "-" doesn't work well in variable names.) My proposal was that I'd have moved them into a different namespace, but of course, that's a bitch now. > >My proposal 2 was that we just prefix all of them with crm_, and to > >have > >an option to turn of the "compatibility" aliases at the admins > >discretion. > i think you mean turn off... because we'd have to default to on for > backwards compatibility Yup, there was a "f" missing, not a "f" instead of a "n" ;-) > >You say this is more work for you than proposal 1. And here's where I > >don't follow. To you, I'd think they are both the same. If you have to > >look for two names or in two places, how is that a difference? > > > Prop 1: I set up a "meta" hashtable and populate it with > meta_attributes (and for backwards compatibility copy in any unset > attributes from the regular hashtable). > > From then on i just look up the name at the meta hashtable. OK so far. > Prop 2: every time i need to look up X i need to look for crm-meta-X > and if thats not set, then fall back to X. You could, simply like you do with Prop 1, translate the "X" to "crm_meta_X", and then only go looking for that. (Unless, of course, said translation is turned off.) It's going to show up in the same environment and name-space everywhere else (except for the prefix), so why keep them separate here? > >In either case, everyone else can pretend you never made the change > >until they want to switch over to the new scheme. > in (my implementation of) prop 1, there'd be no switch... they'd just > start using meta_attributes sets. You'd still need to turn off populating from the regular instance parameters though, in case these have been used by the RA in question. So, this alone isn't sufficient and the option still needed. > but arent we talking about options that are for the PE not the RA? > > clone instance, notify, colocated... those things arent RA parameters > so why would they need to change/be added in the RA's metadata? Because the RA's metadata is the place where the RA tells us about the defaults it prefers, and the same would then apply to these options. That makes sense to me at least. > "short and to the point because its saturday" yes, but not "terse". What does Saturday have to do with it? Weekends are just semantics ;-) 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] Meta configuration namespace
Andrew Beekhof wrote: Another question... should things like an operation's interval/ timeout also show up in the meta namespace or the regular one? Momentarily ignoring issues of compatibility, I think it should be the meta namespace. I agree with you on this - unless the OCF spec says otherwise. Then I agree with it :-). Lars has always wanted RAs to time themselves (which I thought was madness), so he may disagree with us on this. Do they show up in the normal namespace now? And even the compatibility shouldn't be too bad since the LRM gets these values from the CRM not the parameter list. The one I know shows up is "target_role". This is kind of annoying in the GUI. So in my thinking (futile and clouded though it is), it's the example I tend to have in mind. -- 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/
[Linux-ha-dev] Meta configuration namespace
Another question... should things like an operation's interval/ timeout also show up in the meta namespace or the regular one? Momentarily ignoring issues of compatibility, I think it should be the meta namespace. And even the compatibility shouldn't be too bad since the LRM gets these values from the CRM not the parameter list. ___ 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/
