<font size=3>> Hmm, I see. There's this spec[1] that was discussed
in the past with a similar proposal. There's a SPEC with some other points
on the discussion, I think Janice </font>
<br><font size=3>> forgot to mention.</font>
<br>
<br><font size=3>> Erlon</font>
<br>
<br><font size=3>> [1] </font><a href=https://review.openstack.org/#/c/176233/><font size=3 color=blue><u>https://review.openstack.org/#/c/176233/</u></font></a>
<br><font size=3>> [2] </font><a href=https://review.openstack.org/#/c/258968/><font size=3 color=blue><u>https://review.openstack.org/#/c/258968/</u></font></a>
<br>
<br><font size=3>> On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko <</font><a href=mailto:michal.dulko@intel.com><font size=3 color=blue><u>michal.dulko@intel.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>> On 12/22/2015 01:29 PM, Erlon Cruz wrote:<br>
> > Hi Li,<br>
> ><br>
> > Can you give a quick background on servicegroups (or links to.
The<br>
> > spec you linked only describe the process on Nova to change from
what<br>
> > they are using to tooz)? Also, what are the use cases and benefits
of<br>
> > using this?<br>
> ><br>
> > Erlon<br>
> ><br>
<br>
> This is simply and idea to be able to use something more sophisticated<br>
> than DB heartbeats to monitor services states. With Tooz implemented
for<br>
> that we would be able to use for example ZooKeeper to know about service<br>
> failure in a matter of seconds instead of around a minute. This would<br>
> shrink the window in which c-sch doesn't-know-yet that c-vol failed
and<br>
> sends RPC messages to a service that will never answer. I think there<br>
> are more use cases related to service monitoring and failover.<br>
<br>
> Service groups isn't probably a correct name for proposed enhancement
-<br>
> we have this concept somehow implemented, but proposed idea seems
to be<br>
> related to making it pluggable.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Hi Erlon and Michal,</font>
<br><font size=2 face="sans-serif"> Sorry
for response you so late.</font>
<br><font size=2 face="sans-serif">
</font>
<br><font size=2 face="sans-serif"> The
Cinder ServiceGroup is used for getting the state of services quickly.</font>
<br><font size=2 face="sans-serif"> use
case such as:</font>
<br><font size=2 face="sans-serif">
1) As an admin, I want to know each cinder service state, so that
I can take some</font>
<br><font size=2 face="sans-serif">
actions to keep cloud in high availability if any service is down.</font>
<br><font size=2 face="sans-serif">
2) As an user, I want my volumes not to be scheduled to failed cinder-volume</font>
<br><font size=2 face="sans-serif">
instances.</font>
<br><font size=2 face="sans-serif"> My
colleague and I, have posted the specs[1] of ServiceGroup in Cinder.</font>
<br>
<br><font size=2 face="sans-serif">Janice</font>
<br>
<br><font size=2 face="sans-serif">[1] </font><a href=https://review.openstack.org/#/c/258968/><font size=3 color=blue><u>https://review.openstack.org/#/c/258968/</u></font></a><font size=2 face="sans-serif"><br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">发件人:
</font><font size=1 face="sans-serif">Erlon Cruz
<sombrafam@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">收件人:
</font><font size=1 face="sans-serif">"OpenStack
Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">日期:
</font><font size=1 face="sans-serif">2015/12/23
04:04</font>
<br><font size=1 color=#5f5f5f face="sans-serif">主题:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[cinder] [nova] whether the ServiceGroup in Cinder is necessary</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Hmm, I see. There's this spec[1] that was discussed in
the past with a similar proposal. There's a SPEC with some other points
on the discussion, I think Janice forgot to mention.</font>
<br>
<br><font size=3>Erlon</font>
<br>
<br><font size=3>[1] </font><a href=https://review.openstack.org/#/c/176233/><font size=3 color=blue face="sans-serif"><u>https://review.openstack.org/#/c/176233/</u></font></a>
<br><font size=3>[2] </font><a href=https://review.openstack.org/#/c/258968/><font size=3 color=blue face="sans-serif"><u>https://review.openstack.org/#/c/258968/</u></font></a>
<br>
<br><font size=3>On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko <</font><a href=mailto:michal.dulko@intel.com target=_blank><font size=3 color=blue><u>michal.dulko@intel.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>On 12/22/2015 01:29 PM, Erlon Cruz wrote:<br>
> Hi Li,<br>
><br>
> Can you give a quick background on servicegroups (or links to. The<br>
> spec you linked only describe the process on Nova to change from what<br>
> they are using to tooz)? Also, what are the use cases and benefits
of<br>
> using this?<br>
><br>
> Erlon<br>
><br>
<br>
This is simply and idea to be able to use something more sophisticated<br>
than DB heartbeats to monitor services states. With Tooz implemented for<br>
that we would be able to use for example ZooKeeper to know about service<br>
failure in a matter of seconds instead of around a minute. This would<br>
shrink the window in which c-sch doesn't-know-yet that c-vol failed and<br>
sends RPC messages to a service that will never answer. I think there<br>
are more use cases related to service monitoring and failover.<br>
<br>
Service groups isn't probably a correct name for proposed enhancement -<br>
we have this concept somehow implemented, but proposed idea seems to be<br>
related to making it pluggable.</font>
<br><font size=3><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target=_blank><font size=3 color=blue><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target=_blank><font size=3 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a>
<br><tt><font size=2>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
</font></pre><br>