4:29 a.m.
I'm working on a POC lately on a change to stats collection and retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider (nevermind what is it atm)
Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'
# Introducing 'configuration' Verb:
As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.
Host.configure(config={version: 4.2}
Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.
4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1}
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.
I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
Nevertheless it can be potentially beneficial to more functions in vdsm.
Thanks,
Roy
4:49 a.m.
On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
I'm working on a POC lately on a change to stats collection and
retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider (nevermind what is it atm)
Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'
# Introducing 'configuration' Verb:
As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.
Host.configure(config={version: 4.2}
Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.
4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1}
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.
Isn't it solved by host re-installation?
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.
I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
How do we persist this level on VDSM? Or we don't, and if VDSM is restarted
it is again back to 4.1 mode until Engine tells it otherwise?
Y.
Nevertheless it can be potentially beneficial to more functions in
vdsm.
Thanks,
Roy
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5:10 a.m.
On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com>
wrote:
I'm working on a POC lately on a change to stats collection and retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider (nevermind what is it atm)
Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'
# Introducing 'configuration' Verb:
As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.
Host.configure(config={version: 4.2}
Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.
4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1}
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.
Isn't it solved by host re-installation?
We allow maintenance + change host cluster so not always. Was this changed?
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.
I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
How do we persist this level on VDSM? Or we don't, and if VDSM is
restarted it is again back to 4.1 mode until Engine tells it otherwise?
Y.
Must persist it somehow otherwise there is a race when the engine will send
send a stats request and will get the wrong answer. I'm wondering if using
differnt endpoints is the right solution here to prevent that from
happening.
method: Host.getStats version: 4.1
Nevertheless it can be potentially beneficial to more functions in vdsm.
Thanks,
Roy
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5:16 a.m.
--Apple-Mail=_89F8B2D6-58F8-414F-A85A-238907D35FA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
=20
=20
=20
On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com =
<mailto:ykaul@redhat.com>> wrote:
On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com =
<mailto:rgolan@redhat.com>> wrote:
I'm working on a POC lately on a change to stats collection and =
retrieval by VDSM. The moto is to cut all we can from host/vm stats =
(possibly caps) and report only core-business stuff to the engine. =
Engine will retrieve the rest through a 3rd party provider
(nevermind what is it atm)
I hope it=E2=80=99s the same one as for VM stats, collectd:)
=20
Being backward compatible by design, I have to support 2 API versions =
for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff.
=
It doesn't need to sample what it doesn't report. In other words I want =
'4.1-sampling' and '4.2-sampling'
=20
# Introducing 'configuration' Verb:
=20
As engine knows always(Hosted Engine as well) what cluster version =
this host
belongs to, it can configure VDSM to operate in cluster =
version mode.
why not running it in parallel for one version?
=20
Host.configure(config=3D{version: 4.2}
=20
Consider this verb, pre-activating using 'Host.getCaps' to set the =
context.
It will set the righjt sampling method, and other stuff if needed
then =
API endpoints will have the right permutation of the api to answer it.
=20
4.2 host can operate in 4.1 mode:
Host.configure(config=3D{version: 4.1}
=20
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since =
engine needs
to know this is a new vdsm that has the verb available. One =
way to overcome that is to fire the verb for every host regardless of =
the version and disregard an error that implies the verb doesn't exist.
=20
Isn't it solved by host re-installation?
=20
We allow maintenance + change host cluster so not always. Was this =
changed?=20
=20
=20
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the =
monitoring
code the whole stats collection as it is a different task =
which is orthogonal to 'monitoring' and in 4.2 more than before.
=20
=20
I know configuration for VDSM has been discussed before and there are =
probably
tons of ways to do it. When you share your thoughts please =
remember that configuration is a by-product of the effort.
=20
How do we persist this level on VDSM? Or we don't, and if VDSM is =
restarted
it is again back to 4.1 mode until Engine tells it otherwise?
Y.
=20
Must persist it somehow otherwise there is a race when the engine will =
send send
a stats request and will get the wrong answer. I'm wondering =
if using differnt endpoints is the right solution here to prevent that =
from happening.=20
method: Host.getStats version: 4.1=20
would it be a problem? assuming that the code is easily started/stopped =
within vdsm, we can just change the behavior based on receiving one or =
the other verb for the first time after vdsm starts
Thanks,
michal
=20
=20
=20
Nevertheless it can be potentially beneficial to more functions in =
vdsm.
=20
Thanks,
Roy
=20
=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_89F8B2D6-58F8-414F-A85A-238907D35FA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 4 Apr 2017, at 12:10, Roy Golan <<a =
href=3D"mailto:rgolan@redhat.com"
class=3D"">rgolan(a)redhat.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><br
class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr"
class=3D"">On Tue, Apr 4, 2017 at =
12:49 PM Yaniv Kaul <<a href=3D"mailto:ykaul@redhat.com" =
class=3D"">ykaul(a)redhat.com</a>&gt; wrote:<br
class=3D""></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote
gmail_msg">On =
Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <span dir=3D"ltr" =
class=3D"gmail_msg"><<a href=3D"mailto:rgolan@redhat.com"
=
class=3D"gmail_msg"
target=3D"_blank">rgolan(a)redhat.com</a>&gt;</span> =
wrote:<br class=3D"gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">I'm working on a POC lately on a change to stats =
collection and retrieval by VDSM. The moto is to cut all we can from =
host/vm stats (possibly caps) and report only core-business stuff to the =
engine. Engine will retrieve the rest through a 3rd party =
provider</div></div></blockquote></div></div></div></blockquote></div></di=
v></div></blockquote><blockquote type=3D"cite"
class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">(nevermind what is it atm)<br =
class=3D"gmail_msg"></div></div></blockquote></div></div></div></blockquot=
e></div></div></div></blockquote><div><br
class=3D""></div>I hope it=E2=80=
=99s the same one as for VM stats, collectd:)</div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><blockquote class=3D"gmail_quote gmail_msg"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Being backward =
compatible by design, I have to support 2 API versions for Host.getStats =
, '4.1' and '4.2'.<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Except from supplying less parameters, I want VDSM =
to do less stuff. It doesn't need to sample what it doesn't report. In =
other words I want '4.1-sampling' and '4.2-sampling'<br =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"># Introducing 'configuration' Verb:<br =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">As engine knows always(Hosted Engine as well) what =
cluster version this host belongs to, it can configure VDSM to operate =
in cluster version mode.<br =
class=3D"gmail_msg"></div></div></blockquote></div></div></div></blockquot=
e></div></div></div></blockquote><div><br
class=3D""></div>why not =
running it in parallel for one version?</div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><blockquote class=3D"gmail_quote gmail_msg"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"> Host.configure(config=3D{version: 4.2}<br
=
class=3D"gmail_msg"></div><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Consider this verb, =
pre-activating using 'Host.getCaps' to set the context.<br =
class=3D"gmail_msg">It will set the righjt sampling method, and other =
stuff if needed then API endpoints will have the right permutation of =
the api to answer it.<br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div class=3D"gmail_msg">4.2
host can operate =
in 4.1 mode:<br class=3D"gmail_msg"> =
Host.configure(config=3D{version: 4.1}<br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Issue: moving a 4.2 =
host from 4.2 cluster to 4.1 is a problem since engine needs to know =
this is a new vdsm that has the verb available. One way to overcome that =
is to fire the verb for every host regardless of the version and =
disregard an error that implies the verb doesn't exist.<br =
class=3D"gmail_msg"></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div
class=3D"gmail_msg">Isn't it solved =
by host
re-installation?</div></div></div></div></blockquote><div
=
class=3D""><br class=3D""></div><div
class=3D"">We allow =
maintenance + change host cluster so not always. Was this changed? =
<br class=3D""></div><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><blockquote class=3D"gmail_quote
gmail_msg" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"># Engine:<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Engine will have a handling of the verb per =
version.<br class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Host/Vms =
monitoring should be changed - I suggest to move out of the monitoring =
code the whole stats collection as it is a different task which is =
orthogonal to 'monitoring' and in 4.2 more than before.<br =
class=3D"gmail_msg"><br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div class=3D"gmail_msg">I
know configuration =
for VDSM has been discussed before and there are probably tons of ways =
to do it. When you share your thoughts please remember that =
configuration is a by-product of the effort.<br =
class=3D"gmail_msg"></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div class=3D"gmail_msg">How
do we =
persist this level on VDSM? Or we don't, and if VDSM is restarted it is =
again back to 4.1 mode until Engine tells it =
otherwise?</div></div></div></div></blockquote></div></div></div></blockqu=
ote><blockquote type=3D"cite" class=3D""><div
class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_quote"><blockquote
class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><div =
class=3D"gmail_msg">Y.</div></div></div></div></blockquote><div
=
class=3D""><br class=3D""></div><div
class=3D"">Must persist it somehow =
otherwise there is a race when the engine will send send a stats request =
and will get the wrong answer. I'm wondering if using differnt =
endpoints is the right solution here to prevent that from happening. <br =
class=3D""></div><div class=3D""> method:
Host.getStats version: =
4.1 <br
class=3D""></div></div></div></div></blockquote><div><br
=
class=3D""></div>would it be a problem? assuming that the code is
easily =
started/stopped within vdsm, we can just change the behavior based on =
receiving one or the other verb for the first time after vdsm =
starts</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</div><div><br
=
class=3D""></div><div><blockquote type=3D"cite"
class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D"gmail_quote"><div =
class=3D""> <br
class=3D""></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><div class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"> </div><blockquote
class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"></blockquote></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">Nevertheless it can be potentially beneficial to =
more functions in vdsm.<br class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Thanks,<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Roy<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div></div>
<br
class=3D"gmail_msg"></blockquote></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">_______________________________________________<br=
class=3D"gmail_msg">
Devel mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:Devel@ovirt.org" class=3D"gmail_msg" =
target=3D"_blank">Devel(a)ovirt.org</a><br
class=3D"gmail_msg">
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
rel=3D"noreferrer" class=3D"gmail_msg" =
target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/de...
=
class=3D"gmail_msg"></blockquote></div><br =
class=3D"gmail_msg"></div></div>
</blockquote></div></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_89F8B2D6-58F8-414F-A85A-238907D35FA4--
5:21 a.m.
On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
I'm working on a POC lately on a change to stats collection and retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider
(nevermind what is it atm)
I hope it’s the same one as for VM stats, collectd:)
Intended for this as well.
Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'
# Introducing 'configuration' Verb:
As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.
why not running it in parallel for one version?
What is the benefit?
Host.configure(config={version: 4.2}
Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.
4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1}
Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.
Isn't it solved by host re-installation?
We allow maintenance + change host cluster so not always. Was this
changed?
# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.
I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
How do we persist this level on VDSM? Or we don't, and if VDSM is
restarted it is again back to 4.1 mode until Engine tells it otherwise?
Y.
Must persist it somehow otherwise there is a race when the engine will
send send a stats request and will get the wrong answer. I'm wondering if
using differnt endpoints is the right solution here to prevent that from
happening.
method: Host.getStats version: 4.1
would it be a problem? assuming that the code is easily started/stopped
within vdsm, we can just change the behavior based on receiving one or the
other verb for the first time after vdsm starts
But we should prefer a deliberate action. Doing that as a side effect is
surprising for an API verb. What would happen in case you invoke
'vdsm-client' ?
Thanks,
michal
Nevertheless it can be potentially beneficial to more functions in vdsm.
Thanks,
Roy
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5:28 a.m.
--Apple-Mail=_4D0244E4-4D4A-48DB-B16B-BE856667DA7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 4 Apr 2017, at 12:21, Roy Golan <rgolan(a)redhat.com> wrote:
=20
=20
=20
On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek =
<michal.skrivanek(a)redhat.com
<mailto:michal.skrivanek@redhat.com>> =
wrote:
> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com =
<mailto:rgolan@redhat.com>> wrote:
>=20
>=20
>=20
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com =
<mailto:ykaul@redhat.com>> wrote:
> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com
=
<mailto:rgolan@redhat.com>> wrote:
> I'm working on a POC lately on a change to stats collection
and =
retrieval by VDSM. The moto is to cut all we can from host/vm stats =
(possibly caps) and report only core-business stuff to the engine. =
Engine will retrieve the rest through a 3rd party provider
> (nevermind what is it atm)
=20
I hope it=E2=80=99s the same one as for VM stats, collectd:)
=20
Intended for this as well.=20
great!
=20
>=20
> Being backward compatible by design, I have to support 2 API versions =
for
Host.getStats , '4.1' and '4.2'.
> Except from supplying less parameters, I want VDSM to do less
stuff. =
It doesn't need to sample what it doesn't report. In other words I
want =
'4.1-sampling' and '4.2-sampling'
>=20
> # Introducing 'configuration' Verb:
>=20
> As engine knows always(Hosted Engine as well) what cluster version =
this host
belongs to, it can configure VDSM to operate in cluster =
version mode.
=20
why not running it in parallel for one version?
=20
What is the benefit? =20
just so you do not need any configuration verb nor persistence, not much =
else.
>=20
> Host.configure(config=3D{version: 4.2}
>=20
> Consider this verb, pre-activating using 'Host.getCaps' to set the =
context.
> It will set the righjt sampling method, and other stuff if needed
=
then API endpoints will have the right permutation of the api to answer =
it.
>=20
> 4.2 host can operate in 4.1 mode:
> Host.configure(config=3D{version: 4.1}
>=20
> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since =
engine
needs to know this is a new vdsm that has the verb available. One =
way to overcome that is to fire the verb for every host regardless of =
the version and disregard an error that implies the verb doesn't exist.
>=20
> Isn't it solved by host re-installation?
>=20
> We allow maintenance + change host cluster so not always. Was this =
changed?=20
>=20
>=20
> # Engine:
> Engine will have a handling of the verb per version.
> Host/Vms monitoring should be changed - I suggest to move out of the =
monitoring code the whole stats collection as it is a different task =
which is orthogonal to 'monitoring' and in 4.2 more than before.
>=20
>=20
> I know configuration for VDSM has been discussed before and there are =
probably tons of ways to do it. When you share your thoughts please =
remember that configuration is a by-product of the effort.
>=20
> How do we persist this level on VDSM? Or we don't, and if VDSM is =
restarted it is again back to 4.1 mode until Engine tells it otherwise?
> Y.
>=20
> Must persist it somehow otherwise there is a race when the engine =
will send
send a stats request and will get the wrong answer. I'm =
wondering if using differnt endpoints is the right solution here to =
prevent that from happening.=20
> method: Host.getStats version: 4.1=20
=20
would it be a problem? assuming that the code is easily =
started/stopped within
vdsm, we can just change the behavior based on =
receiving one or the other verb for the first time after vdsm starts
=20
But we should prefer a deliberate action. Doing that as a side effect =
is
surprising for an API verb. What would happen in case you invoke =
'vdsm-client=E2=80=99 ?
I do not mean to switch for any client, more like a single =E2=80=9Cupgrad=
e=E2=80=9D of communication once the new verb is called. So once the =
engine calls the new verb the legacy stats thread is stopped and =
vdsClient <oldVerb> stops returning meaningful data.
Actually, moving host back to older cluster doesn=E2=80=99t really need =
switching back either - you still have the new engine capable of =
handling the new verb despite older cluster.
=20
=20
Thanks,
michal
=20
> =20
>=20
> =20
> Nevertheless it can be potentially beneficial to more functions in =
vdsm.
>=20
> Thanks,
> Roy
>=20
>=20
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
>=20
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_4D0244E4-4D4A-48DB-B16B-BE856667DA7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 4 Apr 2017, at 12:21, Roy Golan <<a =
href=3D"mailto:rgolan@redhat.com"
class=3D"">rgolan(a)redhat.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><br
class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr"
class=3D"">On Tue, Apr 4, 2017 at =
1:16 PM Michal Skrivanek <<a =
href=3D"mailto:michal.skrivanek@redhat.com" =
class=3D"">michal.skrivanek(a)redhat.com</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg"><blockquote type=3D"cite"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">On 4 Apr 2017, at 12:10, Roy Golan <<a =
href=3D"mailto:rgolan@redhat.com" class=3D"gmail_msg" =
target=3D"_blank">rgolan(a)redhat.com</a>&gt;
wrote:</div><br =
class=3D"m_-4059592897398397391Apple-interchange-newline gmail_msg"><div
=
class=3D"gmail_msg"><div dir=3D"ltr"
class=3D"gmail_msg"><br =
class=3D"gmail_msg"><br class=3D"gmail_msg"><div
class=3D"gmail_quote =
gmail_msg"><div dir=3D"ltr" class=3D"gmail_msg">On Tue,
Apr 4, 2017 at =
12:49 PM Yaniv Kaul <<a href=3D"mailto:ykaul@redhat.com" =
class=3D"gmail_msg"
target=3D"_blank">ykaul(a)redhat.com</a>&gt; wrote:<br =
class=3D"gmail_msg"></div><blockquote class=3D"gmail_quote
gmail_msg" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote
gmail_msg">On =
Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <span dir=3D"ltr" =
class=3D"gmail_msg"><<a href=3D"mailto:rgolan@redhat.com"
=
class=3D"gmail_msg"
target=3D"_blank">rgolan(a)redhat.com</a>&gt;</span> =
wrote:<br class=3D"gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">I'm working on a POC lately on a change to stats =
collection and retrieval by VDSM. The moto is to cut all we can from =
host/vm stats (possibly caps) and report only core-business stuff to the =
engine. Engine will retrieve the rest through a 3rd party =
provider</div></div></blockquote></div></div></div></blockquote></div></di=
v></div></blockquote><blockquote type=3D"cite"
class=3D"gmail_msg"><div =
class=3D"gmail_msg"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><blockquote class=3D"gmail_quote gmail_msg"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_msg">(nevermind what
is it =
atm)<br =
class=3D"gmail_msg"></div></div></blockquote></div></div></div></blockquot=
e></div></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div><div
style=3D"word-wrap:break-word" =
class=3D"gmail_msg"><div class=3D"gmail_msg">I hope
it=E2=80=99s the =
same one as for VM stats, collectd:)</div></div></blockquote><div =
class=3D""><br class=3D"">Intended for this as well. <br
=
class=3D""></div></div></div></div></blockquote><div><br
=
class=3D""></div>great!</div><div><br
class=3D""><blockquote type=3D"cite"=
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg"></div></div><div
style=3D"word-wrap:break-word" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"><blockquote type=3D"cite"
class=3D"gmail_msg"><div =
class=3D"gmail_msg"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><blockquote class=3D"gmail_quote gmail_msg"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Being backward =
compatible by design, I have to support 2 API versions for Host.getStats =
, '4.1' and '4.2'.<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Except from supplying less parameters, I want VDSM =
to do less stuff. It doesn't need to sample what it doesn't report. In =
other words I want '4.1-sampling' and '4.2-sampling'<br =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"># Introducing 'configuration' Verb:<br =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">As engine knows always(Hosted Engine as well) what =
cluster version this host belongs to, it can configure VDSM to operate =
in cluster version mode.<br =
class=3D"gmail_msg"></div></div></blockquote></div></div></div></blockquot=
e></div></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div><div
style=3D"word-wrap:break-word" =
class=3D"gmail_msg"><div class=3D"gmail_msg">why not running
it in =
parallel for one version?</div><div
class=3D"gmail_msg"></div></div><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div></div></blockquote><div =
class=3D"">What is the benefit? <br =
class=3D""></div></div></div></div></blockquote><div><br
=
class=3D""></div>just so you do not need any configuration verb nor =
persistence, not much else.</div><div><br
class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D""><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg"><blockquote type=3D"cite"
class=3D"gmail_msg"><div =
class=3D"gmail_msg"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><blockquote class=3D"gmail_quote gmail_msg"
style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"> Host.configure(config=3D{version: 4.2}<br
=
class=3D"gmail_msg"></div><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Consider this verb, =
pre-activating using 'Host.getCaps' to set the context.<br =
class=3D"gmail_msg">It will set the righjt sampling method, and other =
stuff if needed then API endpoints will have the right permutation of =
the api to answer it.<br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div class=3D"gmail_msg">4.2
host can operate =
in 4.1 mode:<br class=3D"gmail_msg"> =
Host.configure(config=3D{version: 4.1}<br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Issue: moving a 4.2 =
host from 4.2 cluster to 4.1 is a problem since engine needs to know =
this is a new vdsm that has the verb available. One way to overcome that =
is to fire the verb for every host regardless of the version and =
disregard an error that implies the verb doesn't exist.<br =
class=3D"gmail_msg"></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div
class=3D"gmail_msg">Isn't it solved =
by host
re-installation?</div></div></div></div></blockquote><div
=
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">We allow maintenance + change host cluster so =
not always. Was this changed? <br
class=3D"gmail_msg"></div><blockquote =
class=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><blockquote class=3D"gmail_quote
gmail_msg" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"># Engine:<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Engine will have a handling of the verb per =
version.<br class=3D"gmail_msg"></div><div
class=3D"gmail_msg">Host/Vms =
monitoring should be changed - I suggest to move out of the monitoring =
code the whole stats collection as it is a different task which is =
orthogonal to 'monitoring' and in 4.2 more than before.<br =
class=3D"gmail_msg"><br class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div class=3D"gmail_msg">I
know configuration =
for VDSM has been discussed before and there are probably tons of ways =
to do it. When you share your thoughts please remember that =
configuration is a by-product of the effort.<br =
class=3D"gmail_msg"></div></div></blockquote><div
class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div class=3D"gmail_msg">How
do we =
persist this level on VDSM? Or we don't, and if VDSM is restarted it is =
again back to 4.1 mode until Engine tells it =
otherwise?</div></div></div></div></blockquote></div></div></div></blockqu=
ote><blockquote type=3D"cite" class=3D"gmail_msg"><div =
class=3D"gmail_msg"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><div =
class=3D"gmail_msg">Y.</div></div></div></div></blockquote><div
=
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Must persist it somehow otherwise there is a race =
when the engine will send send a stats request and will get the wrong =
answer. I'm wondering if using differnt endpoints is the right =
solution here to prevent that from happening. <br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg"> method: =
Host.getStats version: 4.1 <br =
class=3D"gmail_msg"></div></div></div></div></blockquote><div
=
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div></div></div><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg">would it be a problem? assuming that the code is =
easily started/stopped within vdsm, we can just change the behavior =
based on receiving one or the other verb for the first time after vdsm =
starts</div></div></blockquote><div class=3D""><br
class=3D""></div><div =
class=3D"">But we should prefer a deliberate action. Doing that as a =
side effect is surprising for an API verb. What would happen in case you =
invoke 'vdsm-client=E2=80=99 ?<br =
class=3D""></div></div></div></div></blockquote><div><br
=
class=3D""></div>I do not mean to switch for any client, more like a =
single =E2=80=9Cupgrade=E2=80=9D of communication once the new verb is =
called. So once the engine calls the new verb the legacy stats thread is =
stopped and vdsClient <oldVerb> stops returning meaningful =
data.</div><div>Actually, moving host back to older cluster doesn=E2=80=99=
t really need switching back either - you still have the new engine =
capable of handling the new verb despite older cluster.</div><div><br =
class=3D""></div><div><br
class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D""><div =
class=3D"gmail_quote"><div class=3D""> <br =
class=3D""></div><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"gmail_msg"><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Thanks,</div><div =
class=3D"gmail_msg">michal</div></div><div
style=3D"word-wrap:break-word" =
class=3D"gmail_msg"><div class=3D"gmail_msg"><br =
class=3D"gmail_msg"></div><div
class=3D"gmail_msg"><blockquote =
type=3D"cite" class=3D"gmail_msg"><div
class=3D"gmail_msg"><div =
dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_quote
=
gmail_msg"><div
class=3D"gmail_msg"> <br =
class=3D"gmail_msg"></div><blockquote class=3D"gmail_quote
gmail_msg" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote =
gmail_msg"><div class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"> </div><blockquote
class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"></blockquote></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"
class=3D"gmail_msg"><div =
class=3D"gmail_msg">Nevertheless it can be potentially beneficial to =
more functions in vdsm.<br class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Thanks,<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg">Roy<br
class=3D"gmail_msg"></div><div =
class=3D"gmail_msg"><br
class=3D"gmail_msg"></div></div>
<br
class=3D"gmail_msg"></blockquote></div></div></div><div
dir=3D"ltr" =
class=3D"gmail_msg"><div class=3D"gmail_extra
gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">_______________________________________________<br=
class=3D"gmail_msg">
Devel mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:Devel@ovirt.org" class=3D"gmail_msg" =
target=3D"_blank">Devel(a)ovirt.org</a><br
class=3D"gmail_msg">
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
rel=3D"noreferrer" class=3D"gmail_msg" =
target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/de...
=
class=3D"gmail_msg"></blockquote></div><br =
class=3D"gmail_msg"></div></div>
</blockquote></div></div>
_______________________________________________<br =
class=3D"gmail_msg">Devel mailing list<br
class=3D"gmail_msg"><a =
href=3D"mailto:Devel@ovirt.org" class=3D"gmail_msg" =
target=3D"_blank">Devel(a)ovirt.org</a><br
class=3D"gmail_msg"><a =
href=3D"http://lists.ovirt.org/mailman/listinfo/devel"
class=3D"gmail_msg"=
=
target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/de...
/blockquote></div><br
class=3D"gmail_msg"></div></blockquote></div></div>
</div></blockquote></div><br
class=3D""></body></html>=
--Apple-Mail=_4D0244E4-4D4A-48DB-B16B-BE856667DA7B--
6:20 a.m.
I wonder why we not go in the same approach as we went for vm status
changes. Why not to pull for older versions and expect a push from new
implementation.
This would allow as to keep current code as it is for backward
compatibility purposes and create new one (reuse parts of the old one) for
new approach.
We could change stats collection (collectd based) and still get important
data using push.
If we want to pass cluster version we could use connection negotiation like
we do for heartbeat interval. It can be passed every time engine connects
so there is no
need for persistence. We could define custom headers and as a result it
won't break vdsm-client code.
Please note that we are not good at deprecating api and I am not going to
say anything about cleanup or removal.
Whatever we introduce it is going to stay so we need to be careful.
On Tue, Apr 4, 2017 at 12:28 PM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
On 4 Apr 2017, at 12:21, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>
> I'm working on a POC lately on a change to stats collection and retrieval
> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
> and report only core-business stuff to the engine. Engine will retrieve the
> rest through a 3rd party provider
>
> (nevermind what is it atm)
>
>
> I hope it’s the same one as for VM stats, collectd:)
>
Intended for this as well.
great!
>
> Being backward compatible by design, I have to support 2 API versions for
> Host.getStats , '4.1' and '4.2'.
> Except from supplying less parameters, I want VDSM to do less stuff. It
> doesn't need to sample what it doesn't report. In other words I want
> '4.1-sampling' and '4.2-sampling'
>
> # Introducing 'configuration' Verb:
>
> As engine knows always(Hosted Engine as well) what cluster version this
> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>
> why not running it in parallel for one version?
>
> What is the benefit?
just so you do not need any configuration verb nor persistence, not much
else.
> Host.configure(config={version: 4.2}
>
> Consider this verb, pre-activating using 'Host.getCaps' to set the
> context.
> It will set the righjt sampling method, and other stuff if needed then
> API endpoints will have the right permutation of the api to answer it.
>
> 4.2 host can operate in 4.1 mode:
> Host.configure(config={version: 4.1}
>
> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
> engine needs to know this is a new vdsm that has the verb available. One
> way to overcome that is to fire the verb for every host regardless of the
> version and disregard an error that implies the verb doesn't exist.
>
>
> Isn't it solved by host re-installation?
>
>
> We allow maintenance + change host cluster so not always. Was this
> changed?
>
>
>
> # Engine:
> Engine will have a handling of the verb per version.
> Host/Vms monitoring should be changed - I suggest to move out of the
> monitoring code the whole stats collection as it is a different task which
> is orthogonal to 'monitoring' and in 4.2 more than before.
>
>
> I know configuration for VDSM has been discussed before and there are
> probably tons of ways to do it. When you share your thoughts please
> remember that configuration is a by-product of the effort.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>
> Y.
>
>
> Must persist it somehow otherwise there is a race when the engine will
> send send a stats request and will get the wrong answer. I'm wondering if
> using differnt endpoints is the right solution here to prevent that from
> happening.
> method: Host.getStats version: 4.1
>
>
> would it be a problem? assuming that the code is easily started/stopped
> within vdsm, we can just change the behavior based on receiving one or the
> other verb for the first time after vdsm starts
>
But we should prefer a deliberate action. Doing that as a side effect is
surprising for an API verb. What would happen in case you invoke
'vdsm-client’ ?
I do not mean to switch for any client, more like a single “upgrade” of
communication once the new verb is called. So once the engine calls the new
verb the legacy stats thread is stopped and vdsClient <oldVerb> stops
returning meaningful data.
Actually, moving host back to older cluster doesn’t really need switching
back either - you still have the new engine capable of handling the new
verb despite older cluster.
>
> Thanks,
> michal
>
>
>
>
>
>
> Nevertheless it can be potentially beneficial to more functions in vdsm.
>
> Thanks,
> Roy
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
6:38 a.m.
On Tue, Apr 4, 2017 at 2:20 PM Piotr Kliczewski <pkliczew(a)redhat.com> wrote:
I wonder why we not go in the same approach as we went for vm status
changes. Why not to pull for older versions and expect a push from new
implementation.
This would allow as to keep current code as it is for backward
compatibility purposes and create new one (reuse parts of the old one) for
new approach.
We could change stats collection (collectd based) and still get important
data using push.
If we want to pass cluster version we could use connection negotiation
like we do for heartbeat interval. It can be passed every time engine
connects so there is no
need for persistence. We could define custom headers and as a result it
won't break vdsm-client code.
Passing the cluster version isn't a problem. The main benefit would be to
spare precious cpu and memory for vdsm and for virtualization.
Please note that we are not good at deprecating api and I am not
going to
say anything about cleanup or removal.
Whatever we introduce it is going to stay so we need to be careful.
On Tue, Apr 4, 2017 at 12:28 PM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
> On 4 Apr 2017, at 12:21, Roy Golan <rgolan(a)redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
>
>> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>>
>>
>>
>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>
>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>
>> I'm working on a POC lately on a change to stats collection and
>> retrieval by VDSM. The moto is to cut all we can from host/vm stats
>> (possibly caps) and report only core-business stuff to the engine. Engine
>> will retrieve the rest through a 3rd party provider
>>
>> (nevermind what is it atm)
>>
>>
>> I hope it’s the same one as for VM stats, collectd:)
>>
>
> Intended for this as well.
>
>
> great!
>
>
>>
>> Being backward compatible by design, I have to support 2 API versions
>> for Host.getStats , '4.1' and '4.2'.
>> Except from supplying less parameters, I want VDSM to do less stuff. It
>> doesn't need to sample what it doesn't report. In other words I want
>> '4.1-sampling' and '4.2-sampling'
>>
>> # Introducing 'configuration' Verb:
>>
>> As engine knows always(Hosted Engine as well) what cluster version this
>> host belongs to, it can configure VDSM to operate in cluster version mode.
>>
>>
>> why not running it in parallel for one version?
>>
>> What is the benefit?
>
>
> just so you do not need any configuration verb nor persistence, not much
> else.
>
>
>> Host.configure(config={version: 4.2}
>>
>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>> context.
>> It will set the righjt sampling method, and other stuff if needed then
>> API endpoints will have the right permutation of the api to answer it.
>>
>> 4.2 host can operate in 4.1 mode:
>> Host.configure(config={version: 4.1}
>>
>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>> engine needs to know this is a new vdsm that has the verb available. One
>> way to overcome that is to fire the verb for every host regardless of the
>> version and disregard an error that implies the verb doesn't exist.
>>
>>
>> Isn't it solved by host re-installation?
>>
>>
>> We allow maintenance + change host cluster so not always. Was this
>> changed?
>>
>>
>>
>> # Engine:
>> Engine will have a handling of the verb per version.
>> Host/Vms monitoring should be changed - I suggest to move out of the
>> monitoring code the whole stats collection as it is a different task which
>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>
>>
>> I know configuration for VDSM has been discussed before and there are
>> probably tons of ways to do it. When you share your thoughts please
>> remember that configuration is a by-product of the effort.
>>
>>
>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>
>> Y.
>>
>>
>> Must persist it somehow otherwise there is a race when the engine will
>> send send a stats request and will get the wrong answer. I'm wondering if
>> using differnt endpoints is the right solution here to prevent that from
>> happening.
>> method: Host.getStats version: 4.1
>>
>>
>> would it be a problem? assuming that the code is easily started/stopped
>> within vdsm, we can just change the behavior based on receiving one or the
>> other verb for the first time after vdsm starts
>>
>
> But we should prefer a deliberate action. Doing that as a side effect is
> surprising for an API verb. What would happen in case you invoke
> 'vdsm-client’ ?
>
>
> I do not mean to switch for any client, more like a single “upgrade” of
> communication once the new verb is called. So once the engine calls the new
> verb the legacy stats thread is stopped and vdsClient <oldVerb> stops
> returning meaningful data.
> Actually, moving host back to older cluster doesn’t really need switching
> back either - you still have the new engine capable of handling the new
> verb despite older cluster.
>
>
>
>
>>
>> Thanks,
>> michal
>>
>>
>>
>>
>>
>>
>> Nevertheless it can be potentially beneficial to more functions in vdsm.
>>
>> Thanks,
>> Roy
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
7:28 a.m.
On Wed, Apr 19, 2017 at 1:38 PM, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 2:20 PM Piotr Kliczewski <pkliczew(a)redhat.com>
wrote:
> I wonder why we not go in the same approach as we went for vm status
> changes. Why not to pull for older versions and expect a push from new
> implementation.
> This would allow as to keep current code as it is for backward
> compatibility purposes and create new one (reuse parts of the old one) for
> new approach.
> We could change stats collection (collectd based) and still get important
> data using push.
>
> If we want to pass cluster version we could use connection negotiation
> like we do for heartbeat interval. It can be passed every time engine
> connects so there is no
> need for persistence. We could define custom headers and as a result it
> won't break vdsm-client code.
>
>
Passing the cluster version isn't a problem. The main benefit would be to
spare precious cpu and memory for vdsm and for virtualization.
I was confused by your initial email but during vdsm meeting finally I
understood what you wanted to do.
Passing and parsing cluster version is not a problem but why not to have an
option in vdsm config file?
We could enable stats collection by default and we could disable it during
host deploy for specific cluster version.
> Please note that we are not good at deprecating api and I am not going to
> say anything about cleanup or removal.
> Whatever we introduce it is going to stay so we need to be careful.
>
>
> On Tue, Apr 4, 2017 at 12:28 PM, Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
>
>>
>> On 4 Apr 2017, at 12:21, Roy Golan <rgolan(a)redhat.com> wrote:
>>
>>
>>
>> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
>> michal.skrivanek(a)redhat.com> wrote:
>>
>>> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>>
>>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>>
>>> I'm working on a POC lately on a change to stats collection and
>>> retrieval by VDSM. The moto is to cut all we can from host/vm stats
>>> (possibly caps) and report only core-business stuff to the engine. Engine
>>> will retrieve the rest through a 3rd party provider
>>>
>>> (nevermind what is it atm)
>>>
>>>
>>> I hope it’s the same one as for VM stats, collectd:)
>>>
>>
>> Intended for this as well.
>>
>>
>> great!
>>
>>
>>>
>>> Being backward compatible by design, I have to support 2 API versions
>>> for Host.getStats , '4.1' and '4.2'.
>>> Except from supplying less parameters, I want VDSM to do less stuff. It
>>> doesn't need to sample what it doesn't report. In other words I want
>>> '4.1-sampling' and '4.2-sampling'
>>>
>>> # Introducing 'configuration' Verb:
>>>
>>> As engine knows always(Hosted Engine as well) what cluster version this
>>> host belongs to, it can configure VDSM to operate in cluster version mode.
>>>
>>>
>>> why not running it in parallel for one version?
>>>
>>> What is the benefit?
>>
>>
>> just so you do not need any configuration verb nor persistence, not much
>> else.
>>
>>
>>> Host.configure(config={version: 4.2}
>>>
>>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>>> context.
>>> It will set the righjt sampling method, and other stuff if needed then
>>> API endpoints will have the right permutation of the api to answer it.
>>>
>>> 4.2 host can operate in 4.1 mode:
>>> Host.configure(config={version: 4.1}
>>>
>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>> engine needs to know this is a new vdsm that has the verb available. One
>>> way to overcome that is to fire the verb for every host regardless of the
>>> version and disregard an error that implies the verb doesn't exist.
>>>
>>>
>>> Isn't it solved by host re-installation?
>>>
>>>
>>> We allow maintenance + change host cluster so not always. Was this
>>> changed?
>>>
>>>
>>>
>>> # Engine:
>>> Engine will have a handling of the verb per version.
>>> Host/Vms monitoring should be changed - I suggest to move out of the
>>> monitoring code the whole stats collection as it is a different task which
>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>
>>>
>>> I know configuration for VDSM has been discussed before and there are
>>> probably tons of ways to do it. When you share your thoughts please
>>> remember that configuration is a by-product of the effort.
>>>
>>>
>>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>>
>>> Y.
>>>
>>>
>>> Must persist it somehow otherwise there is a race when the engine will
>>> send send a stats request and will get the wrong answer. I'm wondering
if
>>> using differnt endpoints is the right solution here to prevent that from
>>> happening.
>>> method: Host.getStats version: 4.1
>>>
>>>
>>> would it be a problem? assuming that the code is easily started/stopped
>>> within vdsm, we can just change the behavior based on receiving one or the
>>> other verb for the first time after vdsm starts
>>>
>>
>> But we should prefer a deliberate action. Doing that as a side effect is
>> surprising for an API verb. What would happen in case you invoke
>> 'vdsm-client’ ?
>>
>>
>> I do not mean to switch for any client, more like a single “upgrade” of
>> communication once the new verb is called. So once the engine calls the new
>> verb the legacy stats thread is stopped and vdsClient <oldVerb> stops
>> returning meaningful data.
>> Actually, moving host back to older cluster doesn’t really need
>> switching back either - you still have the new engine capable of handling
>> the new verb despite older cluster.
>>
>>
>>
>>
>>>
>>> Thanks,
>>> michal
>>>
>>>
>>>
>>>
>>>
>>>
>>> Nevertheless it can be potentially beneficial to more functions in vdsm.
>>>
>>> Thanks,
>>> Roy
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>
>
6:35 a.m.
On Tue, Apr 4, 2017 at 1:28 PM Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On 4 Apr 2017, at 12:21, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>
> I'm working on a POC lately on a change to stats collection and retrieval
> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
> and report only core-business stuff to the engine. Engine will retrieve the
> rest through a 3rd party provider
>
> (nevermind what is it atm)
>
>
> I hope it’s the same one as for VM stats, collectd:)
>
Intended for this as well.
great!
>
> Being backward compatible by design, I have to support 2 API versions for
> Host.getStats , '4.1' and '4.2'.
> Except from supplying less parameters, I want VDSM to do less stuff. It
> doesn't need to sample what it doesn't report. In other words I want
> '4.1-sampling' and '4.2-sampling'
>
> # Introducing 'configuration' Verb:
>
> As engine knows always(Hosted Engine as well) what cluster version this
> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>
> why not running it in parallel for one version?
>
> What is the benefit?
just so you do not need any configuration verb nor persistence, not much
else.
I'm trying to figure out, based on fromani's work, how much overhead the
sampling cause. If it is quite a bit cpu and memory we can spare then it is
definitely worth shutting it off selectively.
> Host.configure(config={version: 4.2}
>
> Consider this verb, pre-activating using 'Host.getCaps' to set the
> context.
> It will set the righjt sampling method, and other stuff if needed then
> API endpoints will have the right permutation of the api to answer it.
>
> 4.2 host can operate in 4.1 mode:
> Host.configure(config={version: 4.1}
>
> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
> engine needs to know this is a new vdsm that has the verb available. One
> way to overcome that is to fire the verb for every host regardless of the
> version and disregard an error that implies the verb doesn't exist.
>
>
> Isn't it solved by host re-installation?
>
>
> We allow maintenance + change host cluster so not always. Was this
> changed?
>
>
>
> # Engine:
> Engine will have a handling of the verb per version.
> Host/Vms monitoring should be changed - I suggest to move out of the
> monitoring code the whole stats collection as it is a different task which
> is orthogonal to 'monitoring' and in 4.2 more than before.
>
>
> I know configuration for VDSM has been discussed before and there are
> probably tons of ways to do it. When you share your thoughts please
> remember that configuration is a by-product of the effort.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>
> Y.
>
>
> Must persist it somehow otherwise there is a race when the engine will
> send send a stats request and will get the wrong answer. I'm wondering if
> using differnt endpoints is the right solution here to prevent that from
> happening.
> method: Host.getStats version: 4.1
>
>
> would it be a problem? assuming that the code is easily started/stopped
> within vdsm, we can just change the behavior based on receiving one or the
> other verb for the first time after vdsm starts
>
But we should prefer a deliberate action. Doing that as a side effect is
surprising for an API verb. What would happen in case you invoke
'vdsm-client’ ?
I do not mean to switch for any client, more like a single “upgrade” of
communication once the new verb is called. So once the engine calls the new
verb the legacy stats thread is stopped and vdsClient <oldVerb> stops
returning meaningful data.
Actually, moving host back to older cluster doesn’t really need switching
back either - you still have the new engine capable of handling the new
verb despite older cluster.
>
> Thanks,
> michal
>
>
>
>
>
>
> Nevertheless it can be potentially beneficial to more functions in vdsm.
>
> Thanks,
> Roy
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
10:26 a.m.
On Tue, Apr 4, 2017 at 1:16 PM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>
>> I'm working on a POC lately on a change to stats collection and retrieval
>> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
>> and report only core-business stuff to the engine. Engine will retrieve the
>> rest through a 3rd party provider
>>
>> (nevermind what is it atm)
I hope it’s the same one as for VM stats, collectd:)
>>
>> Being backward compatible by design, I have to support 2 API versions for
>> Host.getStats , '4.1' and '4.2'.
>> Except from supplying less parameters, I want VDSM to do less stuff. It
>> doesn't need to sample what it doesn't report. In other words I want
>> '4.1-sampling' and '4.2-sampling'
>>
>> # Introducing 'configuration' Verb:
>>
>> As engine knows always(Hosted Engine as well) what cluster version this
>> host belongs to, it can configure VDSM to operate in cluster version mode.
why not running it in parallel for one version?
>>
>> Host.configure(config={version: 4.2}
>>
>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>> context.
>> It will set the righjt sampling method, and other stuff if needed then
>> API endpoints will have the right permutation of the api to answer it.
>>
>> 4.2 host can operate in 4.1 mode:
>> Host.configure(config={version: 4.1}
>>
>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>> engine needs to know this is a new vdsm that has the verb available. One way
>> to overcome that is to fire the verb for every host regardless of the
>> version and disregard an error that implies the verb doesn't exist.
>
>
> Isn't it solved by host re-installation?
We allow maintenance + change host cluster so not always. Was this changed?
>
>
>>
>> # Engine:
>> Engine will have a handling of the verb per version.
>> Host/Vms monitoring should be changed - I suggest to move out of the
>> monitoring code the whole stats collection as it is a different task which
>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>
>>
>> I know configuration for VDSM has been discussed before and there are
>> probably tons of ways to do it. When you share your thoughts please remember
>> that configuration is a by-product of the effort.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>
> Y.
Must persist it somehow otherwise there is a race when the engine will send
send a stats request and will get the wrong answer. I'm wondering if using
differnt endpoints is the right solution here to prevent that from
happening.
method: Host.getStats version: 4.1
would it be a problem? assuming that the code is easily started/stopped
within vdsm, we can just change the behavior based on receiving one or the
other verb for the first time after vdsm starts
It does not feel right to have a such a state in Vdsm. and making this
state depend implicitly on a verb feels even worse than an explicit
"configure" verb. We already have something like that in the
debug-oriented setLogLevel verb; but that's not how client/server
applications usually operate.
I think that the proper way to do this would be to reconfigure
vdsm.conf, set there collect_statistics=false (via ovirt-host-deploy
or Anible), and restart vdsmd+supervdsmd. This way we are sure that
all threads and services see the new config and act accordingly. This
can be done by Engine whenever a host is added to a new cluster, based
on the statistic-gathering policy in that cluster.
10:33 a.m.
On 4 Apr 2017, at 17:26, Dan Kenigsberg <danken(a)redhat.com>
wrote:
On Tue, Apr 4, 2017 at 1:16 PM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
>
> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>
>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>>
>>> I'm working on a POC lately on a change to stats collection and
retrieval
>>> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
>>> and report only core-business stuff to the engine. Engine will retrieve the
>>> rest through a 3rd party provider
>>>
>>> (nevermind what is it atm)
>
>
> I hope it’s the same one as for VM stats, collectd:)
>
>>>
>>> Being backward compatible by design, I have to support 2 API versions for
>>> Host.getStats , '4.1' and '4.2'.
>>> Except from supplying less parameters, I want VDSM to do less stuff. It
>>> doesn't need to sample what it doesn't report. In other words I want
>>> '4.1-sampling' and '4.2-sampling'
>>>
>>> # Introducing 'configuration' Verb:
>>>
>>> As engine knows always(Hosted Engine as well) what cluster version this
>>> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>
> why not running it in parallel for one version?
>
>>>
>>> Host.configure(config={version: 4.2}
>>>
>>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>>> context.
>>> It will set the righjt sampling method, and other stuff if needed then
>>> API endpoints will have the right permutation of the api to answer it.
>>>
>>> 4.2 host can operate in 4.1 mode:
>>> Host.configure(config={version: 4.1}
>>>
>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>> engine needs to know this is a new vdsm that has the verb available. One way
>>> to overcome that is to fire the verb for every host regardless of the
>>> version and disregard an error that implies the verb doesn't exist.
>>
>>
>> Isn't it solved by host re-installation?
>
>
> We allow maintenance + change host cluster so not always. Was this changed?
>>
>>
>>>
>>> # Engine:
>>> Engine will have a handling of the verb per version.
>>> Host/Vms monitoring should be changed - I suggest to move out of the
>>> monitoring code the whole stats collection as it is a different task which
>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>
>>>
>>> I know configuration for VDSM has been discussed before and there are
>>> probably tons of ways to do it. When you share your thoughts please remember
>>> that configuration is a by-product of the effort.
>>
>>
>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>
>> Y.
>
>
> Must persist it somehow otherwise there is a race when the engine will send
> send a stats request and will get the wrong answer. I'm wondering if using
> differnt endpoints is the right solution here to prevent that from
> happening.
> method: Host.getStats version: 4.1
>
>
> would it be a problem? assuming that the code is easily started/stopped
> within vdsm, we can just change the behavior based on receiving one or the
> other verb for the first time after vdsm starts
It does not feel right to have a such a state in Vdsm. and making this
state depend implicitly on a verb feels even worse than an explicit
"configure" verb. We already have something like that in the
debug-oriented setLogLevel verb; but that's not how client/server
applications usually operate.
I don’t mind either way
I think that the proper way to do this would be to reconfigure
vdsm.conf, set there collect_statistics=false (via ovirt-host-deploy
or Anible), and restart vdsmd+supervdsmd. This way we are sure that
all threads and services see the new config and act accordingly. This
can be done by Engine whenever a host is added to a new cluster, based
on the statistic-gathering policy in that cluster.
But why would you require restart for such a simple thing? We have the collection pretty
well isolated already, it’s not even using periodic sampling, there are nice-to-drop
things which can wait (repoStats, HE HA status?)
12:16 a.m.
On Tue, Apr 4, 2017 at 6:33 PM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
> On 4 Apr 2017, at 17:26, Dan Kenigsberg <danken(a)redhat.com> wrote:
>
> On Tue, Apr 4, 2017 at 1:16 PM, Michal Skrivanek
> <michal.skrivanek(a)redhat.com> wrote:
>>
>> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>>
>>
>>
>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>>
>>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>>>
>>>> I'm working on a POC lately on a change to stats collection and
retrieval
>>>> by VDSM. The moto is to cut all we can from host/vm stats (possibly
caps)
>>>> and report only core-business stuff to the engine. Engine will retrieve
the
>>>> rest through a 3rd party provider
>>>>
>>>> (nevermind what is it atm)
>>
>>
>> I hope it’s the same one as for VM stats, collectd:)
>>
>>>>
>>>> Being backward compatible by design, I have to support 2 API versions
for
>>>> Host.getStats , '4.1' and '4.2'.
>>>> Except from supplying less parameters, I want VDSM to do less stuff. It
>>>> doesn't need to sample what it doesn't report. In other words I
want
>>>> '4.1-sampling' and '4.2-sampling'
>>>>
>>>> # Introducing 'configuration' Verb:
>>>>
>>>> As engine knows always(Hosted Engine as well) what cluster version this
>>>> host belongs to, it can configure VDSM to operate in cluster version
mode.
>>
>>
>> why not running it in parallel for one version?
>>
>>>>
>>>> Host.configure(config={version: 4.2}
>>>>
>>>> Consider this verb, pre-activating using 'Host.getCaps' to set
the
>>>> context.
>>>> It will set the righjt sampling method, and other stuff if needed then
>>>> API endpoints will have the right permutation of the api to answer it.
>>>>
>>>> 4.2 host can operate in 4.1 mode:
>>>> Host.configure(config={version: 4.1}
>>>>
>>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>>> engine needs to know this is a new vdsm that has the verb available. One
way
>>>> to overcome that is to fire the verb for every host regardless of the
>>>> version and disregard an error that implies the verb doesn't exist.
>>>
>>>
>>> Isn't it solved by host re-installation?
>>
>>
>> We allow maintenance + change host cluster so not always. Was this changed?
>>>
>>>
>>>>
>>>> # Engine:
>>>> Engine will have a handling of the verb per version.
>>>> Host/Vms monitoring should be changed - I suggest to move out of the
>>>> monitoring code the whole stats collection as it is a different task
which
>>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>>
>>>>
>>>> I know configuration for VDSM has been discussed before and there are
>>>> probably tons of ways to do it. When you share your thoughts please
remember
>>>> that configuration is a by-product of the effort.
>>>
>>>
>>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>>
>>> Y.
>>
>>
>> Must persist it somehow otherwise there is a race when the engine will send
>> send a stats request and will get the wrong answer. I'm wondering if using
>> differnt endpoints is the right solution here to prevent that from
>> happening.
>> method: Host.getStats version: 4.1
>>
>>
>> would it be a problem? assuming that the code is easily started/stopped
>> within vdsm, we can just change the behavior based on receiving one or the
>> other verb for the first time after vdsm starts
>
> It does not feel right to have a such a state in Vdsm. and making this
> state depend implicitly on a verb feels even worse than an explicit
> "configure" verb. We already have something like that in the
> debug-oriented setLogLevel verb; but that's not how client/server
> applications usually operate.
I don’t mind either way
>
> I think that the proper way to do this would be to reconfigure
> vdsm.conf, set there collect_statistics=false (via ovirt-host-deploy
> or Anible), and restart vdsmd+supervdsmd. This way we are sure that
> all threads and services see the new config and act accordingly. This
> can be done by Engine whenever a host is added to a new cluster, based
> on the statistic-gathering policy in that cluster.
But why would you require restart for such a simple thing? We have the collection pretty
well isolated already, it’s not even using periodic sampling, there are nice-to-drop
things which can wait (repoStats, HE HA status?)
A specific verb for enablePeriodicStatsCollection(False) can work like that.
Roy suggested a more general configure verb, which I think can lead to
all sort of unsatisfiable assumptions.
2:02 a.m.
On Wed, Apr 5, 2017 at 7:16 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 6:33 PM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
>
>> On 4 Apr 2017, at 17:26, Dan Kenigsberg <danken(a)redhat.com> wrote:
>>
>> On Tue, Apr 4, 2017 at 1:16 PM, Michal Skrivanek
>> <michal.skrivanek(a)redhat.com> wrote:
>>>
>>> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>>>
>>>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com>
wrote:
>>>>>
>>>>> I'm working on a POC lately on a change to stats collection and
retrieval
>>>>> by VDSM. The moto is to cut all we can from host/vm stats (possibly
caps)
>>>>> and report only core-business stuff to the engine. Engine will
retrieve the
>>>>> rest through a 3rd party provider
>>>>>
>>>>> (nevermind what is it atm)
>>>
>>>
>>> I hope it’s the same one as for VM stats, collectd:)
>>>
>>>>>
>>>>> Being backward compatible by design, I have to support 2 API
versions for
>>>>> Host.getStats , '4.1' and '4.2'.
>>>>> Except from supplying less parameters, I want VDSM to do less
stuff.
It
>>>>> doesn't need to sample what it doesn't report. In other
words I want
>>>>> '4.1-sampling' and '4.2-sampling'
>>>>>
>>>>> # Introducing 'configuration' Verb:
>>>>>
>>>>> As engine knows always(Hosted Engine as well) what cluster version
this
>>>>> host belongs to, it can configure VDSM to operate in cluster
version
mode.
>>>
>>>
>>> why not running it in parallel for one version?
>>>
>>>>>
>>>>> Host.configure(config={version: 4.2}
>>>>>
>>>>> Consider this verb, pre-activating using 'Host.getCaps' to
set the
>>>>> context.
>>>>> It will set the righjt sampling method, and other stuff if needed
then
>>>>> API endpoints will have the right permutation of the api to answer
it.
>>>>>
>>>>> 4.2 host can operate in 4.1 mode:
>>>>> Host.configure(config={version: 4.1}
>>>>>
>>>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>>>> engine needs to know this is a new vdsm that has the verb
available.
One way
>>>>> to overcome that is to fire the verb for every host regardless of
the
>>>>> version and disregard an error that implies the verb doesn't
exist.
>>>>
>>>>
>>>> Isn't it solved by host re-installation?
>>>
>>>
>>> We allow maintenance + change host cluster so not always. Was this
changed?
>>>>
>>>>
>>>>>
>>>>> # Engine:
>>>>> Engine will have a handling of the verb per version.
>>>>> Host/Vms monitoring should be changed - I suggest to move out of
the
>>>>> monitoring code the whole stats collection as it is a different
task
which
>>>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>>>
>>>>>
>>>>> I know configuration for VDSM has been discussed before and there
are
>>>>> probably tons of ways to do it. When you share your thoughts please
remember
>>>>> that configuration is a by-product of the effort.
>>>>
>>>>
>>>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>>>> restarted it is again back to 4.1 mode until Engine tells it
otherwise?
>>>>
>>>> Y.
>>>
>>>
>>> Must persist it somehow otherwise there is a race when the engine will
send
>>> send a stats request and will get the wrong answer. I'm wondering if
using
>>> differnt endpoints is the right solution here to prevent that from
>>> happening.
>>> method: Host.getStats version: 4.1
>>>
>>>
>>> would it be a problem? assuming that the code is easily started/stopped
>>> within vdsm, we can just change the behavior based on receiving one or
the
>>> other verb for the first time after vdsm starts
>>
>> It does not feel right to have a such a state in Vdsm. and making this
>> state depend implicitly on a verb feels even worse than an explicit
>> "configure" verb. We already have something like that in the
>> debug-oriented setLogLevel verb; but that's not how client/server
>> applications usually operate.
>
> I don’t mind either way
>
>>
>> I think that the proper way to do this would be to reconfigure
>> vdsm.conf, set there collect_statistics=false (via ovirt-host-deploy
>> or Anible), and restart vdsmd+supervdsmd. This way we are sure that
>> all threads and services see the new config and act accordingly. This
>> can be done by Engine whenever a host is added to a new cluster, based
>> on the statistic-gathering policy in that cluster.
>
> But why would you require restart for such a simple thing? We have the
collection pretty well isolated already, it’s not even using periodic
sampling, there are nice-to-drop things which can wait (repoStats, HE HA
status?)
A specific verb for enablePeriodicStatsCollection(False) can work like
that.
Roy suggested a more general configure verb, which I think can lead to
all sort of unsatisfiable assumptions.
I wonder when we would enable and whether we want to disable it at some
point.
How would it fit in to the host life cycle? (maintenance, engine not
connected etc)
On the other hand if we want to send stats either by events or collectd we
could
do it always. If collectd is not configured the stats would not be send
(collectd's decision).
In the same way it would work for events if the engine connection is not
there they would
not be sent. The only drawback of this approach is cpu utilization to
prepare/collect
the stats. As far as I remember Yaniv B. already measured the impact.
1:43 p.m.
On Tue, Apr 4, 2017 at 5:26 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Tue, Apr 4, 2017 at 1:16 PM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
>
> On 4 Apr 2017, at 12:10, Roy Golan <rgolan(a)redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>
>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan(a)redhat.com> wrote:
>>>
>>> I'm working on a POC lately on a change to stats collection and
retrieval
>>> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
>>> and report only core-business stuff to the engine. Engine will retrieve the
>>> rest through a 3rd party provider
>>>
>>> (nevermind what is it atm)
>
>
> I hope it’s the same one as for VM stats, collectd:)
>
>>>
>>> Being backward compatible by design, I have to support 2 API versions for
>>> Host.getStats , '4.1' and '4.2'.
>>> Except from supplying less parameters, I want VDSM to do less stuff. It
>>> doesn't need to sample what it doesn't report. In other words I want
>>> '4.1-sampling' and '4.2-sampling'
>>>
>>> # Introducing 'configuration' Verb:
>>>
>>> As engine knows always(Hosted Engine as well) what cluster version this
>>> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>
> why not running it in parallel for one version?
>
>>>
>>> Host.configure(config={version: 4.2}
>>>
>>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>>> context.
>>> It will set the righjt sampling method, and other stuff if needed then
>>> API endpoints will have the right permutation of the api to answer it.
>>>
>>> 4.2 host can operate in 4.1 mode:
>>> Host.configure(config={version: 4.1}
>>>
>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>> engine needs to know this is a new vdsm that has the verb available. One way
>>> to overcome that is to fire the verb for every host regardless of the
>>> version and disregard an error that implies the verb doesn't exist.
>>
>>
>> Isn't it solved by host re-installation?
>
>
> We allow maintenance + change host cluster so not always. Was this changed?
>>
>>
>>>
>>> # Engine:
>>> Engine will have a handling of the verb per version.
>>> Host/Vms monitoring should be changed - I suggest to move out of the
>>> monitoring code the whole stats collection as it is a different task which
>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>
>>>
>>> I know configuration for VDSM has been discussed before and there are
>>> probably tons of ways to do it. When you share your thoughts please remember
>>> that configuration is a by-product of the effort.
>>
>>
>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>
>> Y.
>
>
> Must persist it somehow otherwise there is a race when the engine will send
> send a stats request and will get the wrong answer. I'm wondering if using
> differnt endpoints is the right solution here to prevent that from
> happening.
> method: Host.getStats version: 4.1
>
>
> would it be a problem? assuming that the code is easily started/stopped
> within vdsm, we can just change the behavior based on receiving one or the
> other verb for the first time after vdsm starts
It does not feel right to have a such a state in Vdsm. and making this
state depend implicitly on a verb feels even worse than an explicit
"configure" verb. We already have something like that in the
debug-oriented setLogLevel verb; but that's not how client/server
applications usually operate.
I think that the proper way to do this would be to reconfigure
vdsm.conf, set there collect_statistics=false (via ovirt-host-deploy
or Anible), and restart vdsmd+supervdsmd. This way we are sure that
all threads and services see the new config and act accordingly. This
can be done by Engine whenever a host is added to a new cluster, based
on the statistic-gathering policy in that cluster.
How that would work when we would update how we collect stats in the future?
Would it require rerun host-deploy or Ansible?
Why not to expect different data from different versions like we did
for vm status changes.
We added the new way of obtaining it but we kept the old code as it
was for backward
compatibility purposes.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2573
days inactive
2588
days old
14 comments
6 participants
participants (6)
-
Dan Kenigsberg -
Michal Skrivanek -
Piotr Kliczewski -
Piotr Kliczewski -
Roy Golan -
Yaniv Kaul