xen ocf resource agent - xmfile parameter [wd-vc]

[Rainer.Brunold]

Hello,

the current version of the xen resource agent still uses the old fashioned
config file for the xen guest (domU). That file needs to be configured as
the xmfile option and is used when heartbeat starts the domU.

The problem with this file is that once the domU is created and started
that information is stored in the xen store. If you use any xen gui tool
like virt-manager to eg. attach another disk, that information is not
written to the old config file but it is written to the xen store. So it
can happen that you make changes to the running domU but do not update the
config file manually and when you migrate the domU you are wondering why it
does not work.

The xen command "xm list --long <domU>" exports the whole domU config from
the xen store (including the changes made by the gui) and writes them to
stdout in a xml near format called sxp. If you delete the domU from the xen
store, that output can be used to recreate the domU configuration.

So the current ocf resource agent uses the "xm create <domU config file>"
option to create and start the domU. The create option uses the old
fashioned formatted file, whereas "xm new -F <domU config file>" uses the
sxp formatted file and creates and starts he domU as well.

Would it be possible to extend the xen ocf resource agent to add another
parameter like "xmfiletype" which can be either "traditional" or "sxp" and
depending on, that the xen start command would be "xm create ..." or "xm
new ..." ?

This does not prevent that the administrator has to modify that xen domU
config file, but he can simply export the domU config and pipe it to that
text file, whereas the old fashioned file always needs manually changes.
There is no way to export it in that old fashioned way.

For backward compatibility that option could be set to "traditional" so no
old installations would break.

Would this be an option ?

If it would, I can enhance the ocf script and provide a patch for it.

Rainer


Allianz Elementar Versicherungs-Aktiengesellschaft
A-1130 Wien, Hietzinger Kai 101-105
FN 34004g, Handelsgericht Wien
UID: ATU 1536 4406; DVR: 0003565
http://www.allianz.at

********************************************************
Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
enthalten Informationen, die vertraulich und
ausschliesslich fuer den (die) bezeichneten Adressaten
bestimmt sind.
Wenn Sie nicht der genannte Adressat sind, darf dieses
E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
Personen zugaenglich gemacht noch in anderer Weise
verwertet werden.
Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
wir Sie, dieses E-Mail und saemtliche angeschlossene
Anhaenge zu loeschen.

Please note: This email and any files transmitted with it is
intended only for the named recipients and may contain
confidential and/or privileged information. If you are not the
intended recipient, please do not read, copy, use or disclose
the contents of this communication to others and notify the
sender immediately. Then please delete the email and any
copies of it. Thank you.
********************************************************

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Ciro Iriarte]

2008/9/7  <Rainer.Brunold@...>:

>
> Hello,
>
> the current version of the xen resource agent still uses the old fashioned
> config file for the xen guest (domU). That file needs to be configured as
> the xmfile option and is used when heartbeat starts the domU.
>
> The problem with this file is that once the domU is created and started
> that information is stored in the xen store. If you use any xen gui tool
> like virt-manager to eg. attach another disk, that information is not
> written to the old config file but it is written to the xen store. So it
> can happen that you make changes to the running domU but do not update the
> config file manually and when you migrate the domU you are wondering why it
> does not work.
>
> The xen command "xm list --long <domU>" exports the whole domU config from
> the xen store (including the changes made by the gui) and writes them to
> stdout in a xml near format called sxp. If you delete the domU from the xen
> store, that output can be used to recreate the domU configuration.
>
> So the current ocf resource agent uses the "xm create <domU config file>"
> option to create and start the domU. The create option uses the old
> fashioned formatted file, whereas "xm new -F <domU config file>" uses the
> sxp formatted file and creates and starts he domU as well.
>
> Would it be possible to extend the xen ocf resource agent to add another
> parameter like "xmfiletype" which can be either "traditional" or "sxp" and
> depending on, that the xen start command would be "xm create ..." or "xm
> new ..." ?
>
> This does not prevent that the administrator has to modify that xen domU
> config file, but he can simply export the domU config and pipe it to that
> text file, whereas the old fashioned file always needs manually changes.
> There is no way to export it in that old fashioned way.
>
> For backward compatibility that option could be set to "traditional" so no
> old installations would break.
>
> Would this be an option ?
>
> If it would, I can enhance the ocf script and provide a patch for it.
>
> Rainer
>
>
> Allianz Elementar Versicherungs-Aktiengesellschaft
> A-1130 Wien, Hietzinger Kai 101-105
> FN 34004g, Handelsgericht Wien
> UID: ATU 1536 4406; DVR: 0003565
> http://www.allianz.at
>

I could make use of this, it will greatly help with frequently
modified domUs (or any domU modified at least once after
installation)...

Regards,
Ciro
_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Rainer.Brunold]

Just a question, are we both the only one interested in enhancing the xen
ocf resource agent to work with the sxp files ? I thought this posting
might result in a discussion about the enhancement and hopped to get other
opinions on it.

Rainer




An: "General Linux-HA mailing list" <linux-ha@...>
Von: "Ciro Iriarte" <cyruspy@...>
Gesendet von: linux-ha-bounces@...
Datum: 11.09.2008 17:54
Thema: Re: [Linux-HA] xen ocf resource agent - xmfile parameter [wd-vc]

2008/9/7  <Rainer.Brunold@...>:
>
> Hello,
>
> the current version of the xen resource agent still uses the old
fashioned
> config file for the xen guest (domU). That file needs to be configured as
> the xmfile option and is used when heartbeat starts the domU.
>
> The problem with this file is that once the domU is created and started
> that information is stored in the xen store. If you use any xen gui tool
> like virt-manager to eg. attach another disk, that information is not
> written to the old config file but it is written to the xen store. So it
> can happen that you make changes to the running domU but do not update
the
> config file manually and when you migrate the domU you are wondering why
it
> does not work.
>
> The xen command "xm list --long <domU>" exports the whole domU config
from
> the xen store (including the changes made by the gui) and writes them to
> stdout in a xml near format called sxp. If you delete the domU from the
xen
> store, that output can be used to recreate the domU configuration.
>
> So the current ocf resource agent uses the "xm create <domU config file>"
> option to create and start the domU. The create option uses the old
> fashioned formatted file, whereas "xm new -F <domU config file>" uses the
> sxp formatted file and creates and starts he domU as well.
>
> Would it be possible to extend the xen ocf resource agent to add another
> parameter like "xmfiletype" which can be either "traditional" or "sxp"
and
> depending on, that the xen start command would be "xm create ..." or "xm
> new ..." ?
>
> This does not prevent that the administrator has to modify that xen domU
> config file, but he can simply export the domU config and pipe it to that
> text file, whereas the old fashioned file always needs manually changes.
> There is no way to export it in that old fashioned way.
>
> For backward compatibility that option could be set to "traditional" so
no

> old installations would break.
>
> Would this be an option ?
>
> If it would, I can enhance the ocf script and provide a patch for it.
>
> Rainer
>
>
> Allianz Elementar Versicherungs-Aktiengesellschaft
> A-1130 Wien, Hietzinger Kai 101-105
> FN 34004g, Handelsgericht Wien
> UID: ATU 1536 4406; DVR: 0003565
> http://www.allianz.at
>

I could make use of this, it will greatly help with frequently
modified domUs (or any domU modified at least once after
installation)...

Regards,
Ciro
_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems



Allianz Elementar Versicherungs-Aktiengesellschaft
A-1130 Wien, Hietzinger Kai 101-105
FN 34004g, Handelsgericht Wien
UID: ATU 1536 4406; DVR: 0003565
http://www.allianz.at

********************************************************
Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
enthalten Informationen, die vertraulich und
ausschliesslich fuer den (die) bezeichneten Adressaten
bestimmt sind.
Wenn Sie nicht der genannte Adressat sind, darf dieses
E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
Personen zugaenglich gemacht noch in anderer Weise
verwertet werden.
Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
wir Sie, dieses E-Mail und saemtliche angeschlossene
Anhaenge zu loeschen.

Please note: This email and any files transmitted with it is
intended only for the named recipients and may contain
confidential and/or privileged information. If you are not the
intended recipient, please do not read, copy, use or disclose
the contents of this communication to others and notify the
sender immediately. Then please delete the email and any
copies of it. Thank you.
********************************************************

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Dejan Muhamedagic]

Hi,

On Thu, Sep 11, 2008 at 09:52:09PM +0200, Rainer.Brunold@... wrote:
> Just a question, are we both the only one interested in enhancing the xen
> ocf resource agent to work with the sxp files ? I thought this posting
> might result in a discussion about the enhancement and hopped to get other
> opinions on it.

Makes me wonder too ;-)

Sorry, for being so late with the reply.

This should be taken care of, but I'm not sure if the solution
you proposed is optimal. What I'm worried about is that people
will simply forget to update the configuration file when they
change the xen store. What would be great is to devise a way to
have this happen automatically for certain xen configurations,
i.e. those marked as managed by the cluster. I don't have any
experience with the xen store. Any ideas?

Thanks,

Dejan

> Rainer
>
>
>
>
> An: "General Linux-HA mailing list" <linux-ha@...>
> Von: "Ciro Iriarte" <cyruspy@...>
> Gesendet von: linux-ha-bounces@...
> Datum: 11.09.2008 17:54
> Thema: Re: [Linux-HA] xen ocf resource agent - xmfile parameter [wd-vc]
>
> 2008/9/7  <Rainer.Brunold@...>:
> >
> > Hello,
> >
> > the current version of the xen resource agent still uses the old
> fashioned
> > config file for the xen guest (domU). That file needs to be configured as
> > the xmfile option and is used when heartbeat starts the domU.
> >
> > The problem with this file is that once the domU is created and started
> > that information is stored in the xen store. If you use any xen gui tool
> > like virt-manager to eg. attach another disk, that information is not
> > written to the old config file but it is written to the xen store. So it
> > can happen that you make changes to the running domU but do not update
> the
> > config file manually and when you migrate the domU you are wondering why
> it
> > does not work.
> >
> > The xen command "xm list --long <domU>" exports the whole domU config
> from
> > the xen store (including the changes made by the gui) and writes them to
> > stdout in a xml near format called sxp. If you delete the domU from the
> xen
> > store, that output can be used to recreate the domU configuration.
> >
> > So the current ocf resource agent uses the "xm create <domU config file>"
> > option to create and start the domU. The create option uses the old
> > fashioned formatted file, whereas "xm new -F <domU config file>" uses the
> > sxp formatted file and creates and starts he domU as well.
> >
> > Would it be possible to extend the xen ocf resource agent to add another
> > parameter like "xmfiletype" which can be either "traditional" or "sxp"
> and
> > depending on, that the xen start command would be "xm create ..." or "xm
> > new ..." ?
> >
> > This does not prevent that the administrator has to modify that xen domU
> > config file, but he can simply export the domU config and pipe it to that
> > text file, whereas the old fashioned file always needs manually changes.
> > There is no way to export it in that old fashioned way.
> >
> > For backward compatibility that option could be set to "traditional" so
> no
> > old installations would break.
> >
> > Would this be an option ?
> >
> > If it would, I can enhance the ocf script and provide a patch for it.
> >
> > Rainer
> >
> >
> > Allianz Elementar Versicherungs-Aktiengesellschaft
> > A-1130 Wien, Hietzinger Kai 101-105
> > FN 34004g, Handelsgericht Wien
> > UID: ATU 1536 4406; DVR: 0003565
> > http://www.allianz.at
> >
>
> I could make use of this, it will greatly help with frequently
> modified domUs (or any domU modified at least once after
> installation)...
>
> Regards,
> Ciro
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@...
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
>
>
> Allianz Elementar Versicherungs-Aktiengesellschaft
> A-1130 Wien, Hietzinger Kai 101-105
> FN 34004g, Handelsgericht Wien
> UID: ATU 1536 4406; DVR: 0003565
> http://www.allianz.at
>
> ********************************************************
> Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
> enthalten Informationen, die vertraulich und
> ausschliesslich fuer den (die) bezeichneten Adressaten
> bestimmt sind.
> Wenn Sie nicht der genannte Adressat sind, darf dieses
> E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
> Personen zugaenglich gemacht noch in anderer Weise
> verwertet werden.
> Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
> wir Sie, dieses E-Mail und saemtliche angeschlossene
> Anhaenge zu loeschen.
>
> Please note: This email and any files transmitted with it is
> intended only for the named recipients and may contain
> confidential and/or privileged information. If you are not the
> intended recipient, please do not read, copy, use or disclose
> the contents of this communication to others and notify the
> sender immediately. Then please delete the email and any
> copies of it. Thank you.
> ********************************************************
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@...
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Rainer.Brunold]

Dejan,

thanks for replying ...

> This should be taken care of, but I'm not sure if the solution
> you proposed is optimal. What I'm worried about is that people
> will simply forget to update the configuration file when they
> change the xen store. What would be great is to devise a way to
> have this happen automatically for certain xen configurations,
> i.e. those marked as managed by the cluster. I don't have any
> experience with the xen store. Any ideas?

I wanted to ask about this after getting the first responses on the general
question.
With just adding the ability to use the new sxp format, a lot of people
might benefit from.
But having later on a solution that also synchronizes the xen store
frequently with the config file would be much better. The problem that I
see on this is that different people use different methods to adopt the
domU config. Some use the virt-manager, some use pure command line tools
and so on. So from my point as administrator I simply would add another
operation to the ocf resource agent like monitor that's maybe called
synhronize or so, that compares the xen store config on a time based
interval with the config file and if something has changed update that one.
I know the ocf resource agents because I have written a few for our company
(after attending heartbeat Session from Lars) but I'm not sure if the
operations a ocf script can support is limited. Adding such a new operation
might be an easy but dirty way, so not sure about this.

Rainer



-----linux-ha-bounces@... schrieb: -----

An: General Linux-HA mailing list <linux-ha@...>
Von: Dejan Muhamedagic <dejanmm@...>
Gesendet von: linux-ha-bounces@...
Datum: 12.09.2008 12:33
Thema: Re: [Linux-HA] xen ocf resource agent - xmfile parameter [wd-vc]

Hi,

On Thu, Sep 11, 2008 at 09:52:09PM +0200, Rainer.Brunold@... wrote:
> Just a question, are we both the only one interested in enhancing the xen
> ocf resource agent to work with the sxp files ? I thought this posting
> might result in a discussion about the enhancement and hopped to get
other
> opinions on it.

Makes me wonder too ;-)

Sorry, for being so late with the reply.

This should be taken care of, but I'm not sure if the solution
you proposed is optimal. What I'm worried about is that people
will simply forget to update the configuration file when they
change the xen store. What would be great is to devise a way to
have this happen automatically for certain xen configurations,
i.e. those marked as managed by the cluster. I don't have any
experience with the xen store. Any ideas?

Thanks,

Dejan

> Rainer
>
>
>
>
> An: "General Linux-HA mailing list" <linux-ha@...>
> Von: "Ciro Iriarte" <cyruspy@...>
> Gesendet von: linux-ha-bounces@...
> Datum: 11.09.2008 17:54
> Thema: Re: [Linux-HA] xen ocf resource agent - xmfile parameter [wd-vc]
>
> 2008/9/7  <Rainer.Brunold@...>:
> >
> > Hello,
> >
> > the current version of the xen resource agent still uses the old
> fashioned
> > config file for the xen guest (domU). That file needs to be configured

as
> > the xmfile option and is used when heartbeat starts the domU.
> >
> > The problem with this file is that once the domU is created and started
> > that information is stored in the xen store. If you use any xen gui
tool
> > like virt-manager to eg. attach another disk, that information is not
> > written to the old config file but it is written to the xen store. So
it
> > can happen that you make changes to the running domU but do not update
> the
> > config file manually and when you migrate the domU you are wondering
why
> it
> > does not work.
> >
> > The xen command "xm list --long <domU>" exports the whole domU config
> from
> > the xen store (including the changes made by the gui) and writes them
to
> > stdout in a xml near format called sxp. If you delete the domU from the
> xen
> > store, that output can be used to recreate the domU configuration.
> >
> > So the current ocf resource agent uses the "xm create <domU config
file>"
> > option to create and start the domU. The create option uses the old
> > fashioned formatted file, whereas "xm new -F <domU config file>" uses
the
> > sxp formatted file and creates and starts he domU as well.
> >
> > Would it be possible to extend the xen ocf resource agent to add
another
> > parameter like "xmfiletype" which can be either "traditional" or "sxp"
> and
> > depending on, that the xen start command would be "xm create ..." or
"xm
> > new ..." ?
> >
> > This does not prevent that the administrator has to modify that xen
domU
> > config file, but he can simply export the domU config and pipe it to
that
> > text file, whereas the old fashioned file always needs manually
changes.

> > There is no way to export it in that old fashioned way.
> >
> > For backward compatibility that option could be set to "traditional" so
> no
> > old installations would break.
> >
> > Would this be an option ?
> >
> > If it would, I can enhance the ocf script and provide a patch for it.
> >
> > Rainer
> >
> >
> > Allianz Elementar Versicherungs-Aktiengesellschaft
> > A-1130 Wien, Hietzinger Kai 101-105
> > FN 34004g, Handelsgericht Wien
> > UID: ATU 1536 4406; DVR: 0003565
> > http://www.allianz.at
> >
>
> I could make use of this, it will greatly help with frequently
> modified domUs (or any domU modified at least once after
> installation)...
>
> Regards,
> Ciro
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@...
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
>
>
> Allianz Elementar Versicherungs-Aktiengesellschaft
> A-1130 Wien, Hietzinger Kai 101-105
> FN 34004g, Handelsgericht Wien
> UID: ATU 1536 4406; DVR: 0003565
> http://www.allianz.at
>
> ********************************************************
> Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
> enthalten Informationen, die vertraulich und
> ausschliesslich fuer den (die) bezeichneten Adressaten
> bestimmt sind.
> Wenn Sie nicht der genannte Adressat sind, darf dieses
> E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
> Personen zugaenglich gemacht noch in anderer Weise
> verwertet werden.
> Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
> wir Sie, dieses E-Mail und saemtliche angeschlossene
> Anhaenge zu loeschen.
>
> Please note: This email and any files transmitted with it is
> intended only for the named recipients and may contain
> confidential and/or privileged information. If you are not the
> intended recipient, please do not read, copy, use or disclose
> the contents of this communication to others and notify the
> sender immediately. Then please delete the email and any
> copies of it. Thank you.
> ********************************************************
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@...
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems



Allianz Elementar Versicherungs-Aktiengesellschaft
A-1130 Wien, Hietzinger Kai 101-105
FN 34004g, Handelsgericht Wien
UID: ATU 1536 4406; DVR: 0003565
http://www.allianz.at

********************************************************
Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
enthalten Informationen, die vertraulich und
ausschliesslich fuer den (die) bezeichneten Adressaten
bestimmt sind.
Wenn Sie nicht der genannte Adressat sind, darf dieses
E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
Personen zugaenglich gemacht noch in anderer Weise
verwertet werden.
Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
wir Sie, dieses E-Mail und saemtliche angeschlossene
Anhaenge zu loeschen.

Please note: This email and any files transmitted with it is
intended only for the named recipients and may contain
confidential and/or privileged information. If you are not the
intended recipient, please do not read, copy, use or disclose
the contents of this communication to others and notify the
sender immediately. Then please delete the email and any
copies of it. Thank you.
********************************************************

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Ciro Iriarte]

2008/9/12 Dejan Muhamedagic <dejanmm@...>:

> Hi,
>
> On Thu, Sep 11, 2008 at 09:52:09PM +0200, Rainer.Brunold@... wrote:
>> Just a question, are we both the only one interested in enhancing the xen
>> ocf resource agent to work with the sxp files ? I thought this posting
>> might result in a discussion about the enhancement and hopped to get other
>> opinions on it.
>
> Makes me wonder too ;-)
>
> Sorry, for being so late with the reply.
>
> This should be taken care of, but I'm not sure if the solution
> you proposed is optimal. What I'm worried about is that people
> will simply forget to update the configuration file when they
> change the xen store. What would be great is to devise a way to
> have this happen automatically for certain xen configurations,
> i.e. those marked as managed by the cluster. I don't have any
> experience with the xen store. Any ideas?
>
> Thanks,
>
> Dejan
>

Leaving out the Xen store synchronization, this patch could add
support to load SXP configuration files. "xm create" and "xm new" seem
to be the same (both accept Python style and SXP config), but only "xm
new" makes the configuration persistent on the Xen Store (please
correct me)...

Regards,
Ciro


_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Dejan Muhamedagic]

Hi,

On Fri, Sep 12, 2008 at 01:10:37PM +0200, Rainer.Brunold@... wrote:

> Dejan,
>
> thanks for replying ...
>
> > This should be taken care of, but I'm not sure if the solution
> > you proposed is optimal. What I'm worried about is that people
> > will simply forget to update the configuration file when they
> > change the xen store. What would be great is to devise a way to
> > have this happen automatically for certain xen configurations,
> > i.e. those marked as managed by the cluster. I don't have any
> > experience with the xen store. Any ideas?
>
> I wanted to ask about this after getting the first responses on the general
> question.
> With just adding the ability to use the new sxp format, a lot of people
> might benefit from.
> But having later on a solution that also synchronizes the xen store
> frequently with the config file would be much better. The problem that I
> see on this is that different people use different methods to adopt the
> domU config. Some use the virt-manager, some use pure command line tools
> and so on. So from my point as administrator I simply would add another
> operation to the ocf resource agent like monitor that's maybe called
> synhronize or so, that compares the xen store config on a time based
> interval with the config file and if something has changed update that one.
> I know the ocf resource agents because I have written a few for our company
> (after attending heartbeat Session from Lars) but I'm not sure if the
> operations a ocf script can support is limited. Adding such a new operation
> might be an easy but dirty way, so not sure about this.

I don't think that'd be a right(tm) thing to do. Though, I still
can't think of a right solution: how to keep the sxp file in sync
with the xen store. The problem is that the configuration file
is not the origin (the store is) and the xen store is not
persistent. If you couple that with the problem of keeping the
file in sync on all nodes where the VM can run... looks like a
maintenance nightmare.

On Fri, Sep 12, 2008 at 11:49:19AM -0400, Ciro Iriarte wrote:

> 2008/9/12 Dejan Muhamedagic <dejanmm@...>:
> > Hi,
> >
> > On Thu, Sep 11, 2008 at 09:52:09PM +0200, Rainer.Brunold@... wrote:
> >> Just a question, are we both the only one interested in enhancing the xen
> >> ocf resource agent to work with the sxp files ? I thought this posting
> >> might result in a discussion about the enhancement and hopped to get other
> >> opinions on it.
> >
> > Makes me wonder too ;-)
> >
> > Sorry, for being so late with the reply.
> >
> > This should be taken care of, but I'm not sure if the solution
> > you proposed is optimal. What I'm worried about is that people
> > will simply forget to update the configuration file when they
> > change the xen store. What would be great is to devise a way to
> > have this happen automatically for certain xen configurations,
> > i.e. those marked as managed by the cluster. I don't have any
> > experience with the xen store. Any ideas?
> >
> > Thanks,
> >
> > Dejan
> >
>
> Leaving out the Xen store synchronization, this patch could add
> support to load SXP configuration files. "xm create" and "xm new" seem
> to be the same (both accept Python style and SXP config), but only "xm
> new" makes the configuration persistent on the Xen Store (please
> correct me)...

Thanks for the patch, but if we go with support for the SXP
configuration files, then I'd prefer to have the configuration
type explicitly set, e.g. OCF_RESKEY_format or similar. Parsing
python code is, well, not easy to do right.

Thanks,

Dejan

> Regards,
> Ciro


> _______________________________________________
> Linux-HA mailing list
> Linux-HA@...
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Ciro Iriarte]

2008/10/9 Dejan Muhamedagic <dejanmm@...>:

> Hi,
>
> On Fri, Sep 12, 2008 at 11:49:19AM -0400, Ciro Iriarte wrote:
>>
>> Leaving out the Xen store synchronization, this patch could add
>> support to load SXP configuration files. "xm create" and "xm new" seem
>> to be the same (both accept Python style and SXP config), but only "xm
>> new" makes the configuration persistent on the Xen Store (please
>> correct me)...
>
> Thanks for the patch, but if we go with support for the SXP
> configuration files, then I'd prefer to have the configuration
> type explicitly set, e.g. OCF_RESKEY_format or similar. Parsing
> python code is, well, not easy to do right.
>
> Thanks,
>
> Dejan
>

Hi, you stated in you first mail: "What would be great is to devise a way to
have this happen automatically for certain xen configurations",
specifying a config format as a required parameter will break already
running configurations...

The same patch is included, with the difference that this one uses "xm
create" in both cases, this way it will be backward compatible (I
think "xm new" wasn't available in older releases).

The script only checks the format of the "name" parameter on the
config file, nothing more... If there's a better solution to support
SXP config files, I would like to see it included (this is independent
of the Xen Store).

Regards,
Ciro
_______________________________________________
Linux-HA mailing list
Linux-HA@...
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems