Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
On 7/27/06, Lars Marowsky-Bree [EMAIL PROTECTED] wrote: On 2006-07-27T03:26:15, linux-ha-cvs@lists.linux-ha.org wrote: linux-ha CVS committal Author : andrew Host: Project : linux-ha Module : crm Dir : linux-ha/crm/crmd Modified Files: lrm.c Log Message: Send filtered resource stops as successes Bugzilla? What broken behaviour does this fix? Sorry, I'm trying to assemble a changelog ;-) np. its a fix for the previous commit which was for: OSDL #1369 - Node status ___ 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 Jun 8, 2006, at 3:58 PM, Lars Marowsky-Bree wrote:On 2006-06-08T07:39:15, linux-ha-cvs@lists.linux-ha.org wrote: linux-ha CVS committalAuthor : andrewHost : Project : linux-haModule : crmDir : linux-ha/crm/pengine/testcasesModified Files: 797.dot 797.exp bad3.dot bad3.exp bad4.dot bad4.exp bad6.dot bad6.exp master-10.dot master-2.dot notify-1.dot notify-2.dot notify-3.dot orphan-1.dot orphan-1.exp params-1.dot params-1.exp params-2.dot params-2.exp probe-0.dot rec-rsc-2.dot rec-rsc-2.exp Log Message:Shift more non-status functionality out of the lib directory That may be a silly observation, but if you're only shifting codearound, why does this affect the testcases?not silly at all dear chap...it changes the oder actions are created in, thus the IDs they get and the order they show up in the .dot file.annoying but true (yes I checked that changing the order was all it did). -- 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 Jun 8, 2006, at 4:25 PM, Lars Marowsky-Bree wrote:On 2006-06-08T15:58:44, Andrew Beekhof [EMAIL PROTECTED] wrote: That may be a silly observation, but if you're only shifting codearound, why does this affect the testcases? not silly at all dear chap...it changes the oder actions are created in, thus the IDs they get and the order they show up in the .dot file. Should we normalize this then somehow to be more robust against this inthe future?its better than what it was... at least now they're (mostly) sorted by resource id.but yes, this is a good idea.For example, when we start the PE rewrite (ok, so, when you do), I'dlove it if the same regression tests passed with both (except of coursefor the explicit cases where features were added/fixed/modified onpurpose).that would make sense annoying but true (yes I checked that changing the order was all it did). OK, that was also the impression I got, but wanted to make sure.np -- 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 parameters 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 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 parameters 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 May 20, 2006, at 12:26 PM, Lars Marowsky-Bree wrote:On 2006-05-20T11:24:37, Andrew Beekhof [EMAIL PROTECTED] wrote: properties take precedence over instance_parameters which takeprecedence over a parent's properties and instance_parameters Ok. Second, I don't think these _should_ be instance parameters. These areoptions which don't make _sense_ to be affectable by rules and stuff, Ithink. (This would be a dividing line.) my preference would be to make them all instance parameters I'm just frightened by giving them so much rope, but I guess that makessense and would at least be consistent... the only reason many are able to be set as properties is that we hadno easy way to set parameters (we do now though) No, the _real_ reason (before the code came ;-) was that instanceparameters were meant to be exclusively meaningful to the RA, not to us(and we'd rely on the attributes). Then we wanted to make some of the attributes subject to the rules andalso make them available to the RA and configurable via the GUI (3 goodreasons), but that's where we went wrong and threw them into the samename-space as the "regular" instance parameters.If we'd been smart, we'd have changed "instance_attributes" to not onlycontain (rule*, attributes), but (rule*, attributes?, meta_attributes?)and also put these not into the OCF_RESKEY_... space in the environmentbut, say, CRM_PARMS_... or something and avoided this whole mess ;-)20:20 hindsight is always different.well would could still do something like this. sounds pretty sensible and for backwards compatibility we can populate missing meta_attributes from the instance_attributes.actually this makes a lot of sense to meSo, given that we made that choice, putting them all into the instanceparameters list is probably the sanest we can do. We really, really need to fix that with the crm_ prefix to these.We're already in deep shit because we've quite a number of reservedwords, but we mustn't add more. (This doesn't apply so much to thischange, just to the future...) nod, we need to look into this and figure out how to sanely supportboth the old and new names. Well, the new names is easy. Even having them both as aliases is easyenough. (And something we should do, I think.)The real issue comes up when the RA indeed _does_ want to use one of our"reserved" keys. I assume that we should have a configuration option to turn off the oldaliases, which the admin should turn on after they have sanitized theinstance attributes accordingly. It's simply not something we can figureout entirely automatically.Sincerely, Lars Marowsky-Brée-- High Availability ClusteringSUSE Labs, Research and DevelopmentSUSE 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.orghttp://lists.linux-ha.org/mailman/listinfo/linux-ha-devHome Page: http://linux-ha.org/ -- 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-20T12:45:36, Andrew Beekhof [EMAIL PROTECTED] wrote: If we'd been smart, we'd have changed instance_attributes to not only contain (rule*, attributes), but (rule*, attributes?, meta_attributes?) and also put these not into the OCF_RESKEY_... space in the environment but, say, CRM_PARMS_... or something and avoided this whole mess ;-) 20:20 hindsight is always different. well would could still do something like this. sounds pretty sensible and for backwards compatibility we can populate missing meta_attributes from the instance_attributes. actually this makes a lot of sense to me I'm reasonably afraid of the havoc this will wreck on the GUI and so far existing scripts. This is too late for the release. Which is why I proposed the other, slightly less intrusive option, which we can simply put in reasonably soon, and then, with more time at our hands, look at the above. 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-08T09:39:55, Andrew Beekhof [EMAIL PROTECTED] wrote: Zhenh, for the GUI to take advantage of this it needs three options: Stop : target_role = Stopped Start : target_role = Started Automatic : target_role = default (or delete the target_role nvpair completely which I believe is what you do now.) crm_target_role St(opp|art)ed - st... At least the aliases ought to be supported, or the comparison made case insensitive... 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-08T13:26:17, Andrew Beekhof [EMAIL PROTECTED] wrote: At least the aliases ought to be supported, or the comparison made case insensitive... you obviously didnt see the rather large s/strcmp/strcasecmp/ commit earlier today ;-) Ah, that came after the mail I replied to. Thanks! ;-) you can update the dtd though if you like... Good point. 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 8, 2006, at 2:44 PM, Lars Marowsky-Bree wrote: On 2006-05-08T14:16:15, Andrew Beekhof [EMAIL PROTECTED] wrote: Good point. we also need to find a way to have it ignore the order things appear in... thats going to be a major PITA You mean within the CIB? Well, the order is defined, doesn't matter too much, or does it? the problem is when you replace things (normally by removing the old and adding the new) you can affect the order things in the CIB occur in. the CIB doesn't care, but the DTD will and if you have dtd validation turned on... So instead of: !ELEMENT configuration (nodes, resources, constraints, metadata, crm_config) You need: !ELEMENT configuration (nodes|resources|constraints|metadata| crm_config)+ Which no longer ensures you have exactly one of each. I just finished reading a thread from 2000 where this problem was discussed and the response was tough luck. It appears nothing has changed in the last 6 years. -- Andrew Beekhof Too much knowledge leads to confusion; Too many guitar lessons lead to jazz-fusion! - 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 5/8/06, Matthew Soffen [EMAIL PROTECTED] wrote: Has using an XSL been considered instead of a DTD ? Matt my understanding is that XSL will let you transform XML from one format to another. but that doesn't do validation as far as i can tell. btw. were the extra changes to bootstrap ok for you? I tried to email you directly but it bounced. On Mon, 2006-05-08 at 15:00 +0200, Andrew Beekhof wrote: On May 8, 2006, at 2:44 PM, Lars Marowsky-Bree wrote: On 2006-05-08T14:16:15, Andrew Beekhof [EMAIL PROTECTED] wrote: Good point. we also need to find a way to have it ignore the order things appear in... thats going to be a major PITA You mean within the CIB? Well, the order is defined, doesn't matter too much, or does it? the problem is when you replace things (normally by removing the old and adding the new) you can affect the order things in the CIB occur in. the CIB doesn't care, but the DTD will and if you have dtd validation turned on... So instead of: !ELEMENT configuration (nodes, resources, constraints, metadata, crm_config) You need: !ELEMENT configuration (nodes|resources|constraints|metadata| crm_config)+ Which no longer ensures you have exactly one of each. I just finished reading a thread from 2000 where this problem was discussed and the response was tough luck. It appears nothing has changed in the last 6 years. -- Andrew Beekhof Too much knowledge leads to confusion; Too many guitar lessons lead to jazz-fusion! - 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/ ___ 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: 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
Correction: My Bad. I meant XSD ( XML Schema Definition). This is an example of one I wrote for something at ISO. It allows you to define how many of a field may exist, if it is required or not. Its pretty flexible ( at least I think). Matt ?xml version=1.0 encoding=ISO-8859-1 ? xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema elementFormDefault=qualified xsd:element name=LRPMeteringData xsd:complexType xsd:sequence minOccurs=0 maxOccurs=unbounded xsd:element name=Event type=EventType/ /xsd:sequence xsd:attribute name=Component type=ComponentType use=required/ xsd:attribute name=FileType type=FileTypeType use=required/ xsd:attribute name=CreateTime type=xsd:dateTime use=required/ /xsd:complexType /xsd:element xsd:element name=LRPSummaryData xsd:complexType xsd:sequence minOccurs=0 maxOccurs=unbounded xsd:element name=Event type=EventSummaryType / /xsd:sequence xsd:attribute name=CreateTime type=xsd:dateTime use=required/ /xsd:complexType /xsd:element xsd:element name=MeterReaders xsd:complexType xsd:sequence minOccurs=0 maxOccurs=unbounded xsd:element name=MeterReader type=MeterReaderType/ /xsd:sequence xsd:attribute name=EffectiveDate type=xsd:date use=required/ /xsd:complexType /xsd:element xsd:complexType name=ContactType xsd:sequence xsd:element name=FirstName type=xsd:string/ xsd:element name=LastName type=xsd:string/ xsd:element name=Phone type=xsd:positiveInteger minOccurs=0/ xsd:element name=PhoneExt type=xsd:positiveInteger minOccurs=0/ xsd:element name=Fax type=xsd:positiveInteger minOccurs=0/ xsd:element name=Email type=xsd:string minOccurs=0/ xsd:element name=Pager type=xsd:string minOccurs=0/ /xsd:sequence /xsd:complexType xsd:complexType name=MeterReaderType xsd:sequence xsd:element name=CustomerID type=xsd:positiveInteger/ xsd:element name=Name type=xsd:string/ xsd:element name=IbcsProvider type=YNType/ xsd:sequence minOccurs=0 maxOccurs=unbounded xsd:element name=Contact type=ContactType/ /xsd:sequence /xsd:sequence /xsd:complexType On Mon, 2006-05-08 at 15:42 +0200, Andrew Beekhof wrote: On 5/8/06, Matthew Soffen [EMAIL PROTECTED] wrote: Has using an XSL been considered instead of a DTD ? Matt my understanding is that XSL will let you transform XML from one format to another. but that doesn't do validation as far as i can tell. btw. were the extra changes to bootstrap ok for you? I tried to email you directly but it bounced. On Mon, 2006-05-08 at 15:00 +0200, Andrew Beekhof wrote: On May 8, 2006, at 2:44 PM, Lars Marowsky-Bree wrote: On 2006-05-08T14:16:15, Andrew Beekhof [EMAIL PROTECTED] wrote: Good point. we also need to find a way to have it ignore the order things appear in... thats going to be a major PITA You mean within the CIB? Well, the order is defined, doesn't matter too much, or does it? the problem is when you replace things (normally by removing the old and adding the new) you can affect the order things in the CIB occur in. the CIB doesn't care, but the DTD will and if you have dtd validation turned on... So instead of: !ELEMENT configuration (nodes, resources, constraints, metadata, crm_config) You need: !ELEMENT configuration (nodes|resources|constraints|metadata| crm_config)+ Which no longer ensures you have exactly one of each. I just finished reading a thread from 2000 where this problem was discussed and the response was tough luck. It appears nothing has changed in the last 6 years. -- Andrew Beekhof Too much knowledge leads to confusion; Too many guitar lessons lead to jazz-fusion! - 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/ ___ 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: 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: 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
do you know what can we use to validate xml against it?i dont see xsd in xmllintOn May 8, 2006, at 3:45 PM, Matthew Soffen wrote: Correction: My Bad. I meant XSD ( XML Schema Definition). This is an example of one I wrote for something at ISO. It allows you to define how many of a field may exist, if it is required or not. Its pretty flexible ( at least I think). Matt ?xml version="1.0" encoding="ISO-8859-1" ? xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xsd:element name="LRPMeteringData" xsd:complexType xsd:sequence minOccurs="0" maxOccurs="unbounded" xsd:element name="Event" type="EventType"/ /xsd:sequence xsd:attribute name="Component" type="ComponentType" use="required"/ xsd:attribute name="FileType" type="FileTypeType" use="required"/ xsd:attribute name="CreateTime" type="xsd:dateTime" use="required"/ /xsd:complexType /xsd:element xsd:element name="LRPSummaryData" xsd:complexType xsd:sequence minOccurs="0" maxOccurs="unbounded" xsd:element name="Event" type="EventSummaryType" / /xsd:sequence xsd:attribute name="CreateTime" type="xsd:dateTime" use="required"/ /xsd:complexType /xsd:element xsd:element name="MeterReaders" xsd:complexType xsd:sequence minOccurs="0" maxOccurs="unbounded" xsd:element name="MeterReader" type="MeterReaderType"/ /xsd:sequence xsd:attribute name="EffectiveDate" type="xsd:date" use="required"/ /xsd:complexType /xsd:element xsd:complexType name="ContactType" xsd:sequence xsd:element name="FirstName" type="xsd:string"/ xsd:element name="LastName" type="xsd:string"/ xsd:element name="Phone" type="xsd:positiveInteger" minOccurs="0"/ xsd:element name="PhoneExt" type="xsd:positiveInteger" minOccurs="0"/ xsd:element name="Fax" type="xsd:positiveInteger" minOccurs="0"/ xsd:element name="Email" type="xsd:string" minOccurs="0"/ xsd:element name="Pager" type="xsd:string" minOccurs="0"/ /xsd:sequence /xsd:complexType xsd:complexType name="MeterReaderType" xsd:sequence xsd:element name="CustomerID" type="xsd:positiveInteger"/ xsd:element name="Name" type="xsd:string"/ xsd:element name="IbcsProvider" type="YNType"/ xsd:sequence minOccurs="0" maxOccurs="unbounded" xsd:element name="Contact" type="ContactType"/ /xsd:sequence /xsd:sequence /xsd:complexType On Mon, 2006-05-08 at 15:42 +0200, Andrew Beekhof wrote: On 5/8/06, Matthew Soffen [EMAIL PROTECTED] wrote: Has using an XSL been considered instead of a DTD ? Matt my understanding is that XSL will let you transform XML from one "format" to another. but that doesn't do validation as far as i can tell. btw. were the extra changes to bootstrap ok for you? I tried to email you directly but it bounced. On Mon, 2006-05-08 at 15:00 +0200, Andrew Beekhof wrote: On May 8, 2006, at 2:44 PM, Lars Marowsky-Bree wrote: On 2006-05-08T14:16:15, Andrew Beekhof [EMAIL PROTECTED] wrote: Good point. we also need to find a way to have it ignore the order things appear in... thats going to be a major PITA You mean within the CIB? Well, the order is defined, doesn't matter too much, or does it? the problem is when you replace things (normally by removing the old and adding the new) you can affect the order things in the CIB occur in. the CIB doesn't care, but the DTD will and if you have dtd validation turned on... So instead of: !ELEMENT configuration (nodes, resources, constraints, metadata, crm_config) You need: !ELEMENT configuration (nodes|resources|constraints|metadata| crm_config)+ Which no longer ensures you have exactly one of each. I just finished reading a thread from 2000 where this problem was discussed and the response was "tough luck". It appears nothing has changed in the last 6 years. -- Andrew Beekhof "Too much knowledge leads to confusion; Too many guitar lessons lead to jazz-fusion!" - 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/ ___ 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: 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 8, 2006, at 6:09 PM, Matthew Soffen wrote: Andrew, Mine starts: ?xml version="1.0" encoding="ISO-8859-1" ? xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" Not sure of the elementFormDefault is needed but (It cant hurt). I also don't think you can do the typing like you did. Could you try this ( Lose the extra typing ). I don't think you can define the top level elements in terms of types. OK ? doh, it was a typo! s/_/-/ ?xml version="1.0" encoding="ISO-8859-1" ? xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xsd:element name="cib" xsd:complexType xsd:sequence xsd:element name="configuration" type="ClusterConfig"/ /xsd:sequence xsd:attribute name="cib-last_written" type="xsd:string" use="required"/ xsd:attribute name="admin_epoch" type="xsd:string" use="required"/ Matt On Mon, 2006-05-08 at 17:43 +0200, Andrew Beekhof wrote: On May 8, 2006, at 4:53 PM, Matthew Soffen wrote:The other nice feature of XSD is that it is written in XML as well. You can cleanly create new types within your XSD (I have one called YNType just to ensure a field is Y or N. If you need another pair of eyes to look at it when you are done. Let me know. going ok, but I hit thisinvalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute 'cib-last-written' is not allowed.invalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute {'cib-last_written'} is required but missing.any ideas?xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsd:element name="cib" type="ReplicatedConfig"/ xsd:complexType name="ReplicatedConfig" xsd:sequence xsd:element name="configuration" type="ClusterConfig"/ !--xsd:element name="status" type="ClusterStatus"/-- /xsd:sequence xsd:attribute name="cib-last_written" type="xsd:string//" use="required"/ xsd:attribute name="admin_epoch" type="xsd:string" use="required"/ ...On Mon, 2006-05-08 at 16:50 +0200, Andrew Beekhof wrote:On May 8, 2006, at 4:46 PM, Matthew Soffen wrote: OK. My Bad. Yes. It does work to validate properly ( Had a typo in my xsd ). xmllint --schema LRPMeteringData.xsd event_summary_20050629025529.xml?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?LRPSummaryData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="LRPMeteringData.xsd" CreateTime="2005-06-29T02:55:31" Event EventID="10876" LoadZoneID="4004" Program="PRICE" StartTimeStamp="2005-06-29T16:00:00" EndTimeStamp="2005-06-29T22:00:00" NoticeType="Notice"/ Event EventID="10877" LoadZoneID="4008" Program="PRICE" StartTimeStamp="2005-06-29T16:00:00" EndTimeStamp="2005-06-29T22:00:00" NoticeType="Notice"//LRPSummaryDataevent_summary_20050629025529.xml validatesSo XSD could be an option. looks a lot more flexible, writing one now :) thanks for the tip! MattOn Mon, 2006-05-08 at 15:52 +0200, Andrew Beekhof wrote:do you know what can we use to validate xml against it? i dont see xsd in xmllint On May 8, 2006, at 3:45 PM, Matthew Soffen wrote: Correction: My Bad. I meant XSD ( XML Schema Definition). This is an example of one I wrote for something at ISO. It allows you to define how many of a field may exist, if it is required or not. Its pretty flexible ( at least I think).Matt?xml version="1.0" encoding="ISO-8859-1" ?xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xsd:element name="LRPMeteringData" xsd:complexType xsd:sequence minOccurs="0" maxOccurs="unbounded" xsd:element name="Event" type="EventType"/ /xsd:sequence xsd:attribute name="Component" type="ComponentType" use="required"/ xsd:attribute name="FileType"
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
Andrew,
What parts should fail ?
Matt
On Mon, 2006-05-08 at 18:58 +0200, Andrew Beekhof wrote:
so as far as i can tell, the attached files _should_ fail.
but they dont :-(
any thoughts?
On May 8, 2006, at 6:19 PM, Andrew Beekhof wrote:
On May 8, 2006, at 6:09 PM, Matthew Soffen wrote:
Andrew,
Mine starts:
?xml version=1.0 encoding=ISO-8859-1 ?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema elementFormDefault=qualified
Not sure of the elementFormDefault is needed but (It cant hurt).
I also don't think you can do the typing like you did.
Could you try this ( Lose the extra typing ). I don't think you can define the top level elements in terms of types. OK ?
doh, it was a typo! s/_/-/
?xml version=1.0 encoding=ISO-8859-1 ?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema elementFormDefault=qualified
xsd:element name=cib
xsd:complexType
xsd:sequence
xsd:element name=configuration type=ClusterConfig/
/xsd:sequence
xsd:attribute name=cib-last_written type=xsd:string use=required/
xsd:attribute name=admin_epoch type=xsd:string use=required/
Matt
On Mon, 2006-05-08 at 17:43 +0200, Andrew Beekhof wrote:
On May 8, 2006, at 4:53 PM, Matthew Soffen wrote:
The other nice feature of XSD is that it is written in XML as well.
You can cleanly create new types within your XSD (I have one called YNType just to ensure a field is Y or N.
If you need another pair of eyes to look at it when you are done. Let me know.
going ok, but I hit this
invalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute 'cib-last-written' is not allowed.
invalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute {'cib-last_written'} is required but missing.
any ideas?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
xsd:element name=cib type=ReplicatedConfig/
xsd:complexType name=ReplicatedConfig
xsd:sequence
xsd:element name=configuration type=ClusterConfig/
!--xsd:element name=status type=ClusterStatus/--
/xsd:sequence
xsd:attribute name=cib-last_written type=xsd:string// use=required/
xsd:attribute name=admin_epoch type=xsd:string use=required/
...
On Mon, 2006-05-08 at 16:50 +0200, Andrew Beekhof wrote:
On May 8, 2006, at 4:46 PM, Matthew Soffen wrote:
OK. My Bad. Yes. It does work to validate properly ( Had a typo in my xsd ).
xmllint --schema LRPMeteringData.xsd event_summary_20050629025529.xml
?xml version=1.0 encoding=ISO-8859-1 standalone=yes?
LRPSummaryData xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation=LRPMeteringData.xsd CreateTime=2005-06-29T02:55:31
Event EventID=10876 LoadZoneID=4004 Program=PRICE StartTimeStamp=2005-06-29T16:00:00 EndTimeStamp=2005-06-29T22:00:00 NoticeType=Notice/
Event EventID=10877 LoadZoneID=4008 Program=PRICE StartTimeStamp=2005-06-29T16:00:00 EndTimeStamp=2005-06-29T22:00:00 NoticeType=Notice/
/LRPSummaryData
event_summary_20050629025529.xml validates
So XSD could be an option.
looks a lot more flexible, writing one now :)
thanks for the tip!
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
On May 8, 2006, at 8:04 PM, Matthew Soffen wrote: Andrew, What parts should fail ?well is has two "nodes" sections despite maxOccurs="1" :-) Matt On Mon, 2006-05-08 at 18:58 +0200, Andrew Beekhof wrote: so as far as i can tell, the attached files _should_ fail. but they dont :-(any thoughts?On May 8, 2006, at 6:19 PM, Andrew Beekhof wrote:On May 8, 2006, at 6:09 PM, Matthew Soffen wrote: Andrew, Mine starts: ?xml version="1.0" encoding="ISO-8859-1" ?xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"Not sure of the elementFormDefault is needed but (It cant hurt).I also don't think you can do the typing like you did. Could you try this ( Lose the extra typing ). I don't think you can define the top level elements in terms of types. OK ?doh, it was a typo! s/_/-/ ?xml version="1.0" encoding="ISO-8859-1" ?xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xsd:element name="cib" xsd:complexType xsd:sequence xsd:element name="configuration" type="ClusterConfig"/ /xsd:sequence xsd:attribute name="cib-last_written" type="xsd:string" use="required"/ xsd:attribute name="admin_epoch" type="xsd:string" use="required"/ MattOn Mon, 2006-05-08 at 17:43 +0200, Andrew Beekhof wrote:On May 8, 2006, at 4:53 PM, Matthew Soffen wrote:The other nice feature of XSD is that it is written in XML as well. You can cleanly create new types within your XSD (I have one called YNType just to ensure a field is Y or N. If you need another pair of eyes to look at it when you are done. Let me know. going ok, but I hit thisinvalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute 'cib-last-written' is not allowed.invalid.xml:1: element cib: Schemas validity error : Element 'cib': The attribute {'cib-last_written'} is required but missing.any ideas?xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsd:element name="cib" type="ReplicatedConfig"/ xsd:complexType name="ReplicatedConfig" xsd:sequence xsd:element name="configuration" type="ClusterConfig"/ !--xsd:element name="status" type="ClusterStatus"/-- /xsd:sequence xsd:attribute name="cib-last_written" type="xsd:string//" use="required"/ xsd:attribute name="admin_epoch" type="xsd:string" use="required"/ ...On Mon, 2006-05-08 at 16:50 +0200, Andrew Beekhof wrote:On May 8, 2006, at 4:46 PM, Matthew Soffen wrote: OK. My Bad. Yes. It does work to validate properly ( Had a typo in my xsd ). xmllint --schema LRPMeteringData.xsd event_summary_20050629025529.xml?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?LRPSummaryData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="LRPMeteringData.xsd" CreateTime="2005-06-29T02:55:31" Event EventID="10876" LoadZoneID="4004" Program="PRICE" StartTimeStamp="2005-06-29T16:00:00" EndTimeStamp="2005-06-29T22:00:00" NoticeType="Notice"/ Event EventID="10877" LoadZoneID="4008" Program="PRICE" StartTimeStamp="2005-06-29T16:00:00" EndTimeStamp="2005-06-29T22:00:00" NoticeType="Notice"//LRPSummaryDataevent_summary_20050629025529.xml validatesSo XSD could be an option.
Re: [Linux-ha-dev] Re: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
On 2006-04-21T12:32:26, Andrew Beekhof [EMAIL PROTECTED] wrote: Why is that a warning? That's perfectly normal behaviour if several nodes are equal - share some common attribute etc. the extreme case is if both nodes have a score of INFINITY when you're trying to migrate a resource Hm, I think the extreme case is the only one where there's a problem, as it can't run on both nodes, while infinity implies it MUST run there. Anything below infinity isn't a problem. So I'd invert the logic to not not complain for == 0, but only for == INFINITY... 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
Good Morning, Huang Zhen wrote: It looks that the code deems the HA_CCMUID as group id and HA_APIGID as user id. Right, I just stumbled across that problem, too, The error message is: ERROR: mask(io.c:readCibXmlFile): /var/lib/heartbeat/crm/cib.xml must be owned and read/writeable by user 17, or owned and read/writable by group 65 But there is no user id 17 nor group id 65 on this system... Even doing chmod -R a+w * on /var/lib/heartbeat/crm doesn't help. Regards, Peter ___ 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 Feb 2, 2006, at 5:03 PM, Lars Marowsky-Bree wrote: On 2006-02-02T01:56:27, linux-ha-cvs@lists.linux-ha.org wrote: linux-ha CVS committal Author : andrew Host: Project : linux-ha Module : crm Dir : linux-ha/crm/crmd Modified Files: join_client.c Log Message: A small fudge to account for a situation that came up once in about 10,000 CTS iterations. === RCS file: /home/cvs/linux-ha/linux-ha/crm/crmd/join_client.c,v retrieving revision 1.37 retrieving revision 1.38 diff -u -3 -r1.37 -r1.38 --- join_client.c 17 Jan 2006 13:23:35 - 1.37 +++ join_client.c 2 Feb 2006 08:56:27 - 1.38 @@ -47,6 +47,7 @@ HA_Message *req = create_request(CRM_OP_JOIN_ANNOUNCE, NULL, NULL, CRM_SYSTEM_DC, CRM_SYSTEM_CRMD, NULL); + sleep(1); /* give the CCM time to propogate to the DC */ crm_debug(Querying for a DC); send_msg_via_ha(fsa_cluster_conn, req); Uhm can you please explain what exactly you're fixing here? Timing fixes like this always make me nervous because they're prone to rely on system/network speed, keepalive/deadtime etc... IIRC a BadNews popped up because the hey we're here (that we sent after the CCM told us we were in the membership) arrived at the DC before the CCM added the node to the membership. Everything sorted itself out so the sleep isn't really necessary, it just complained a little along the way. -- Andrew Beekhof No means no, and no means yes, and everything in between and all the rest - 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/
