[openstack-dev] [Ceilometer] use stevedore to upload event format

[li . yuanzhen]

Hi Ceilometer,
How about modify Ceilometer to use stevedore to 
  upload the event format?


Now when Ceilometer handles the conversion of 
Notifications from openstack systems into 
Ceilometer Events, the structure of event 
format is constant.

 But in some scenario, the consumer hope the
received events conform to an unified format,
such as ves[1], which is different with the 
current event format.
 So how about use stevedore to upload the event
format of Ceilometer,
such as:
[ceilometer.event.format]
common = ceilometer.event.format:CommonEvent
 ves = ceilometer.event.format:VESEvent
In this case, user can develop his/her event-format 
plugin, and replace with it by adding a config in
ceilometer.conf file:
[default]
 event_format=ves

[1]: https://wiki.opnfv.org/display/ves

 BRs,
Liyuanzhen__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [devstack] let's give a different warning message for different OS_PROJECT_NAME ?

[li . yuanzhen]

Hi All, 
A warning message leave me a doubt.
 
After having installed openstack by devstack, when I use the cmd 
"source openrc", a warning message is 
printed in the terminal that "WARNING: setting legacy 
OS_TENANT_NAME to support cli tools." 
and then when I execute the cmd "source openrc admin admin", it 
give the same info.
 
at first, I think I make a failure in "source openrc" or 
installing openstack, after read the openrc script,
I know this message will be printed no matter what openrc's 
arguments are injected.

So I think, this message have an ambiguity for user. could we 
ignore this info 'echo "WARNING: setting legacy OS_TENANT_NAME to support 
cli tools." ' or make some different info 
for different arguments, such as:
echo "WARNING: setting legacy 
OS_TENANT_NAME=$OS_PROJECT_NAME to support cli tools."

what do you think?

BR,
Rajen

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [aodhclient] does the aodh have the feature for import/export batch alarms?

[li . yuanzhen]

Hi, 
Thank you for giving me a good solution, 
although now I'm not familiar with Heat Template too much, I will 
research it to implement the requirement. 

BR, 
Rajen



> 
> 
> Hi,
> 
> 
> I also agree with ZhiQiang.
> 
> How about using Heat Template which improve portability of app and 
configs?
> 
> 
> Cheers,
> Ryota
> 
> > -Original Message-
> > From: ZhiQiang Fan [mailto:aji.zq...@gmail.com]
> > Sent: Friday, May 20, 2016 11:42 AM
> > To: li.yuanz...@zte.com.cn
> > Cc: OpenStack Development Mailing List; Ildikó Váncsa; 
lianhao...@intel.com; Sheng Liu; Mibu Ryota(壬生 亮太); Julien
> > Danjou
> > Subject: Re: [openstack-dev] [aodhclient] does the aodh have the 
feature for import/export batch alarms?
> > 
> > batch alarm is not supported, and I think it is a burden instead of 
good feature to implement it in aodh
> > 
> > import/export alarm is not supported, considering dump db and restore 
it in new env? or you can get alarm list from old
> > env and create new alarm in new env via REST API if data set is not 
too large.
> > 
> > On Fri, May 20, 2016 at 9:37 AM,  wrote:
> > 
> > 
> >  HI All,
> > 
> >  in the aodh/aodhclient, I not find the feature 
for import/export batch alarms.
> > 
> >  I mainly want to use it to implement the 
following requirement:
> >  In "migrate alarms from one openstack env to 
another openstack env" scenario, I would like to do this
> > requirement
> > by a simple method, such as exporting/downloading 
the alarms from one env and then importing these alarms
> > to a new env.
> > 
> >  currently, does the aodh have the similar command 
for import/export batch alarms?
> >  or does have an alternative method to implement 
this requirement?
> >  If not have, does the feature need to add in 
aodh/aodhclient?
> > 
> >  Rajen(liyuanzhen)
> > 
> > 
> >  
> >  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.
> > 
> > 
> > 
> > 
> 
> 
> 

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [aodhclient] does the aodh have the feature for import/export batch alarms?

[li . yuanzhen]

HI All,
 
in the aodh/aodhclient, I not find the feature for import/export 
batch alarms.

I mainly want to use it to implement the following requirement:
In "migrate alarms from one openstack env to another openstack 
env" scenario, I would like to do this requirement
   by a simple method, such as exporting/downloading the alarms from 
one env and then importing these alarms to a new env.

currently, does the aodh have the similar command for 
import/export batch alarms?
or does have an alternative method to implement this requirement?
If not have, does the feature need to add in aodh/aodhclient?

Rajen(liyuanzhen)

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [AodhClient] "composite alarm" unit test missing in aodhclient ?

[li . yuanzhen]

Yes, right, the "composite_rule" should be None in def 
test_alarm_from_args  :-)

In addition, read the unit tests in "test_alarm_cli.py", there is no 
composite test,
(like "def test_validate_args_composite", similar with 
"test_validate_args_threshold, 
test_validate_args_gnocchi_resources_threshold " ), 
which is corresponding to composite alarm.

So, I think the "def test_validate_args_composite" may be needed, What do 
you think?

thank you

best regards

Rajen

> 
> Hi,
> 
> 
> The test case you pointed is for threshold alarm, so it is OK and 
expected that "composite_rule" is None.
> 
> Checking test codes is good idea. You can add new tests when you found 
something missing by posting new patch.
> 
> 
> BR,
> Ryota
> 
> > -Original Message-
> > From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn]
> > Sent: Thursday, May 19, 2016 12:27 PM
> > To: openstack-dev@lists.openstack.org
> > Cc: aji.zq...@gmail.com; ildiko.van...@ericsson.com; 
lianhao...@intel.com; liusheng2...@gmail.com; Mibu Ryota(壬生 亮
> > 太); Julien Danjou
> > Subject: [Openstack] [AodhClient] "composite alarm" unit test missing 
in aodhclient ?
> > 
> > HI All,
> > in aodhclient/tests/unit/test_alarm_cli.py[1]
> > <
https://review.openstack.org/#/c/284022/7/aodhclient/tests/unit/test_alarm_cli.py
> , the "composite_rule" is None.
> > is the composite_rule test missing? and should we add it ?
> > 
> > [1] 
https://github.com/openstack/python-aodhclient/blob/master/aodhclient/tests/unit/test_alarm_cli.py
> > <
https://github.com/openstack/python-aodhclient/blob/master/aodhclient/tests/unit/test_alarm_cli.py
>
> > 
> > Rajen(liyuanzhen)
> > 
> > 
> > 
> > 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.
> > 
> > 
> 
> 
> 

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [aodhclient] "composite alarm" unit test missing in aodhclient ?

[li . yuanzhen]

HI All,
in aodhclient/tests/unit/test_alarm_cli.py[1], the 
"composite_rule" is None.
is the composite_rule test missing? and should we add it ?

[1] 
https://github.com/openstack/python-aodhclient/blob/master/aodhclient/tests/unit/test_alarm_cli.py

Rajen(liyuanzhen)

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack] [AodhClient] "composite alarm" unit test missing in aodhclient ?

[li . yuanzhen]

HI All,
in aodhclient/tests/unit/test_alarm_cli.py[1], the 
"composite_rule" is None.
is the composite_rule test missing? and should we add it ?

[1] 
https://github.com/openstack/python-aodhclient/blob/master/aodhclient/tests/unit/test_alarm_cli.py

Rajen(liyuanzhen)

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [Aodh] add "meter-list" command in Aodh CLI

[li . yuanzhen]

Ok, Perfect. 
I like this solution. subsequently, I would like to add this message in 
aodhclient. 

Thank you very much

Best Regards
Rajen


> Hi,
> 
> 
> We shouldn't have 'meter-list' in aodhclient.
> 
> Nova have API and function to show image list, and 'nova image-list' is 
talking to nova, not glance. It would be strange if '$ aodh meter-list' 
(aodhclient) made request to ceilometer.
> 
> On the other hand, I understand your concern. We can improve aodh 
document and/or add help message of aodhclient, saying like 'meter can be 
found in ceilometer'. What do you think?
> 
> 
> Cheers,
> Ryota
> 
> > -Original Message-
> > From: li.yuanz...@zte.com.cn [mailto:li.yuanz...@zte.com.cn]
> > Sent: Wednesday, May 18, 2016 11:52 AM
> > To: Julien Danjou; openstack-dev@lists.openstack.org
> > Cc: openstack-dev@lists.openstack.org; liusheng2...@gmail.com; 
aji.zq...@gmail.com; ildiko.van...@ericsson.com;
> > lianhao...@intel.com; Mibu Ryota(壬生 亮太); zhang.yuj...@zte.com.cn
> > Subject: [Openstack] [Aodh] add "meter-list" command in Aodh CLI
> > 
> > So sorry, my mistake when create the link.
> > 
> > 
> > > On Tue, May 17 2016, li.yuanz...@zte.com.cn wrote:
> > >
> > > > Now, in Aodh CLI, when create a threshold alarm, the
> > > > -m/--meter-name must be required.
> > > > But, if the user is not familiar with ceilometer or aodh,
> > > > the user is not sure what value should give to -m/--meter-name.
> > > > So the command "aodh meter list", I think, is needed.
> > 
> > > I don't think so, that's a Ceilometer command. There's no need for
> > > Aodh client to talk to Ceilometer.
> > 
> > Thank you for your suggestion, but I have a different opinion.
> > meter list, I think, is not exclusive for ceilometer command, 
especially after aodh is seperated from ceilometer.
> > Add meter list in Aodh CLI can make user more convenience and easy to 
use Aodh, such as when users create a threshold
> > alarm and don't know which kind of meter is supported, users can 
easily query it by meter-list.
> > For example, "nova image-list ", as well as "glance list"command, can 
get the image value, which is required for creating
> > a instance by "nova boot --image  ".
> > 
> > But there is really an ambiguity for the " migrate meter-list command 
from ceilometer CLI to Aodh CLI ", my miss.
> > May "add meter-list in Aodh CLI" is more appropriate.
> > 
> > 
> > 
> > 
> > 
> > >
> > > > I create a bp[1], to migrate "meter-list" command from
> > > > ceilometer CLI to Aodh CLI.
> > > > Is there any suggestion for this bp? or is the bp 
necessary?
> > > >
> > > > [1]:
> > > > 
https://blueprints.launchpad.net/cinder/+spec/migrate-meter-list-com
> > > > mand-from-ceilometer-cli-to-aodh-cli
> > > > <
https://blueprints.launchpad.net/cinder/+spec/migrate-meter-list-co
> > > > mmand-from-ceilometer-cli-to-aodh-cli>
> > 
> > > Thanks for your effort! Though I'd like to point a few problems 
here:
> > > 1. This blueprint is created in Cinder 2. You sent this mail to the
> > > *user* mailing list, and not to the
> > >developer mailing list (openstack-dev@lists.openstack.org)
> > > 3. You did not discuss anything on the dev mailing list with any of 
the
> > >   active Telemetry developer before, and just took action before we 
can
> > >   comment and state that this is a bad idea (like I just did). Not 
the
> > >   best move.
> > > 4. Cc'ing individuals is not the best move (again, dev mailing list 
is
> > >the right medium)
> > >
> > > Cheers,
> > > --
> > > Julien Danjou
> > 
> > I will obsolete the link in cinder, and thank you for your suggestion 
again.
> > 
> > 
> > 
> > 
> > 
> > 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.
> > 
> > 
> 
> 

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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [Openstack] [Aodh] add "meter-list" command in Aodh CLI

[li . yuanzhen]

So sorry, my mistake when create the link.


> On Tue, May 17 2016, li.yuanz...@zte.com.cn wrote:
> 
> > Now, in Aodh CLI, when create a threshold alarm, the 
> > -m/--meter-name must be required.
> > But, if the user is not familiar with ceilometer or aodh, the 
user 
> > is not sure what value should give to -m/--meter-name.
> > So the command "aodh meter list", I think, is needed.

> I don't think so, that's a Ceilometer command. There's no need for Aodh
> client to talk to Ceilometer.

Thank you for your suggestion, but I have a different opinion.
meter list, I think, is not exclusive for ceilometer command, especially 
after aodh is seperated from ceilometer. 
Add meter list in Aodh CLI can make user more convenience and easy to use 
Aodh, such as when users create a threshold
alarm and don't know which kind of meter is supported, users can easily 
query it by meter-list.
For example, "nova image-list ", as well as "glance list"command, can get 
the image value, which is required for
creating a instance by "nova boot --image  ".

But there is really an ambiguity for the " migrate meter-list command from 
ceilometer CLI to Aodh CLI ", my miss.
May "add meter-list in Aodh CLI" is more appropriate.





> 
> > I create a bp[1], to migrate "meter-list" command from 
ceilometer 
> > CLI to Aodh CLI.
> > Is there any suggestion for this bp? or is the bp necessary?
> >
> > [1]:
> > 
https://blueprints.launchpad.net/cinder/+spec/migrate-meter-list-command-from-ceilometer-cli-to-aodh-cli


> Thanks for your effort! Though I'd like to point a few problems here:
> 1. This blueprint is created in Cinder
> 2. You sent this mail to the *user* mailing list, and not to the
>developer mailing list (openstack-dev@lists.openstack.org)
> 3. You did not discuss anything on the dev mailing list with any of the
>   active Telemetry developer before, and just took action before we can
>   comment and state that this is a bad idea (like I just did). Not the
>   best move.
> 4. Cc'ing individuals is not the best move (again, dev mailing list is
>the right medium)
>
> Cheers,
> -- 
> Julien Danjou

I will obsolete the link in cinder, and thank you for your suggestion 
again.


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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[li . yuanzhen]

> 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.

> Erlon

> [1] https://review.openstack.org/#/c/176233/
> [2] https://review.openstack.org/#/c/258968/

> On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko  
wrote:
> On 12/22/2015 01:29 PM, Erlon Cruz wrote:
> > Hi Li,
> >
> > Can you give a quick background on servicegroups (or links to. The
> > spec you linked only describe the process on Nova to change from what
> > they are using to tooz)? Also, what are the use cases and benefits of
> > using this?
> >
> > Erlon
> >

> This is simply and idea to be able to use something more sophisticated
> than DB heartbeats to monitor services states. With Tooz implemented for
> that we would be able to use for example ZooKeeper to know about service
> failure in a matter of seconds instead of around a minute. This would
> shrink the window in which c-sch doesn't-know-yet that c-vol failed and
> sends RPC messages to a service that will never answer. I think there
> are more use cases related to service monitoring and failover.

> Service groups isn't probably a correct name for proposed enhancement -
> we have this concept somehow implemented, but proposed idea seems to be
> related to making it pluggable.


Hi Erlon and Michal,
Sorry for response you so late.
 
The Cinder ServiceGroup is used for getting the state of services 
quickly.
use case such as:
   1) As an admin, I want to know each cinder service state, so 
that I can take some
   actions to keep cloud in high availability if any service is 
down.
   2) As an user, I want my volumes not to be scheduled to failed 
cinder-volume
   instances.
My colleague and I, have posted the specs[1] of ServiceGroup in 
Cinder.

Janice

[1] https://review.openstack.org/#/c/258968/




发件人: Erlon Cruz 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2015/12/23 04:04
主题:   Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in 
Cinder is necessary



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.

Erlon

[1] https://review.openstack.org/#/c/176233/
[2] https://review.openstack.org/#/c/258968/

On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko  
wrote:
On 12/22/2015 01:29 PM, Erlon Cruz wrote:
> Hi Li,
>
> Can you give a quick background on servicegroups (or links to. The
> spec you linked only describe the process on Nova to change from what
> they are using to tooz)? Also, what are the use cases and benefits of
> using this?
>
> Erlon
>

This is simply and idea to be able to use something more sophisticated
than DB heartbeats to monitor services states. With Tooz implemented for
that we would be able to use for example ZooKeeper to know about service
failure in a matter of seconds instead of around a minute. This would
shrink the window in which c-sch doesn't-know-yet that c-vol failed and
sends RPC messages to a service that will never answer. I think there
are more use cases related to service monitoring and failover.

Service groups isn't probably a correct name for proposed enhancement -
we have this concept somehow implemented, but proposed idea seems to be
related to making it pluggable.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[li . yuanzhen]

Hi hao wang,

Firstly, I agree with you that healthy backend is a requirement for 
creating 
volumes, as the same as service-up. So, monitor the state of backend is 
useful.

While, ServiceGroup is only used for detecting state of service quickly, 
So whether
backend is up or not is not taken into consideration for ServiceGroup.

So, I think there is no priority between them. 

Thank you.
Janice



> hi, Janice
>
> This idea seems to me that is useful to detect the state of
> cinder-volume process more quickly, but I feel there is another issue
> that if the back-end device go to fail you still
> can't keep cloud in ha or create volume successfully since the service
> is up but device is down.
> 
> So, what I want to say is we maybe need to consider to detect and
> report the device state priority[1] and then consider to improve
> service if we need that.

> [1]https://review.openstack.org/#/c/252921/


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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[li . yuanzhen]

Hi all,

  I'd like to start discussion on whether the servicegroup in Cinder is 
necessary.
 
  Recently, cinder can only support db driver, and doesn't have 
servicegroup concept.
  our team wants to implement the servicegroup feature using on tooz[1] 
library. Like nova[2], when the state of service is required, it can be 
got through servicegroup.
 
  Besides, due to the cinder-volume-active-active-support[3] merged, we 
think it makes the Service Group do more. 
 
  Before the cinder-volume-active-active-support was proposed, Cinder has 
no concept of cluster. Therefore, we have a doubt that, if without 
cinder-volume-active-active-support, is it necessary to add feature of 
servicegroup?
 
  Any comments or suggestions?
 
  [1] 
https://github.com/openstack/tooz/blob/master/doc/source/tutorial/group_membership.rst
  [2] 
https://github.com/openstack/nova-specs/blob/master/specs/liberty/approved/service-group-using-tooz.rst
  [3] 
https://github.com/openstack/cinder-specs/blob/master/specs/mitaka/cinder-volume-active-active-support.rst
 
 
  Best Regards,
  Janice





李媛祯  
Li Yuanzhen 无线产品经营部 / 控制器四部Product R / 
Controller IV 
 


上海市张江高科技园碧波路889号D楼 
D306, 889# Bibo Rd;Pudong District Shanghai,China,201203 
E: li.yuanz...@zte.com.cn 
www.zte.com.cn


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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev