[openstack-dev] [cinder] About how to make the vm use volume with libiscsi

Hi, All I want to make the qemu communicate with iscsi target using libiscsi directly, and I followed https://review.openstack.org/#/c/135854/ to add 'volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver’ in nova.conf and then restarted nova services and cinder services, but

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On 02/15/2016 02:48 PM, Ivan Kolodyazhny wrote: > Hi all, > > I'll talk mostly about python-cinderclient but the same question could > be related for other clients. > > Now, for python-cinderclient we've got to kinds for > functional/integrated jobs: > > 1) gate-cinderclient-dsvm-functional - a

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Mon, Feb 15, 2016 at 1:02 PM, Clark Boylan wrote: > On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote: > > Hi all, > > > > I'll talk mostly about python-cinderclient but the same question could be > > related for other clients. > > > > Now, for

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote: > Hi all, > > I'll talk mostly about python-cinderclient but the same question could be > related for other clients. > > Now, for python-cinderclient we've got to kinds for functional/integrated > jobs: > > 1)

[openstack-dev] [cinder][all] Integration python-*client tests on gates

Hi all, I'll talk mostly about python-cinderclient but the same question could be related for other clients. Now, for python-cinderclient we've got to kinds for functional/integrated jobs: 1) gate-cinderclient-dsvm-functional - a very limited (for now) set of functional tests, most of them were

Re: [openstack-dev] [cinder] v2 image upload from url

Hi Kevin, I am executing command from glance and referring this command. glance --os-image-api-version 2 location-add --url [--metadata ] and glance --os-image-api-version 2 md-resource-type-associate Thanks for supporting us. Thanks & Regards, Pankaj On Mon, Feb 8, 2016 at 6:34 PM,

Re: [openstack-dev] [cinder] v2 image upload from url

Sorry, Looping to Kevin Thanks, Pankaj On Mon, Feb 8, 2016 at 6:54 PM, Pankaj Mishra wrote: > Hi Kevin, > > I am executing command from glance and referring this command. > > glance --os-image-api-version 2 location-add --url [--metadata > ] > > > and > > glance

Re: [openstack-dev] [cinder] v2 image upload from url

Sorry, can you give an example of the exact command you are using, please? On 5 Feb 2016 22:45, "Fox, Kevin M" wrote: We've been using the upload image from http url for a long time and when we upgraded to liberty we noticed it broke because the client's defaulting to v2

Re: [openstack-dev] [cinder] v2 image upload from url

Sorry, can you give an example of the exact command you are using, please? On 5 Feb 2016 22:45, "Fox, Kevin M" wrote: > We've been using the upload image from http url for a long time and when > we upgraded to liberty we noticed it broke because the client's defaulting > to

[openstack-dev] [cinder] v2 image upload from url

We've been using the upload image from http url for a long time and when we upgraded to liberty we noticed it broke because the client's defaulting to v2 now. How do you do image upload via http with v2? Is there a different command/method? Thanks, Kevin

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

On Sat, Jan 30, 2016 at 01:04:58AM +0100, Sean McGinnis wrote: > Patrick has been a strong contributor to Cinder over the last few releases, > both with great code submissions and useful reviews. He also participates > regularly on IRC helping answer questions and providing valuable feedback. >

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

A late +1. Congrats Patrick! Welcome to the core team. Xing > On Feb 4, 2016, at 9:31 AM, Sean McGinnis wrote: > >> On Sat, Jan 30, 2016 at 01:04:58AM +0100, Sean McGinnis wrote: >> Patrick has been a strong contributor to Cinder over the last few releases, >> both

Re: [openstack-dev] [Cinder] Cinder Mitaka Midcycle Summary

Thanks a lot for this summary. I enjoyed the reading. Jordan On Tue, Feb 2, 2016 at 10:14 PM, Sean McGinnis wrote: > War and Peace > or > Notes from the Cinder Mitaka Midcycle Sprint > January 26-29 > > Etherpads from discussions: > *

[openstack-dev] [Cinder] Cinder Mitaka Midcycle Summary

War and Peace or Notes from the Cinder Mitaka Midcycle Sprint January 26-29 Etherpads from discussions: * https://etherpad.openstack.org/p/mitaka-cinder-midcycle-day-1 * https://etherpad.openstack.org/p/mitaka-cinder-midcycle-day-2 * https://etherpad.openstack.org/p/mitaka-cinder-midcycle-day-3 *

Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

On 01/31/2016 10:43 PM, dong.wenj...@zte.com.cn wrote: > > Hi all, > > I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1]. > > Project doctor[2] in OPNFV community is its upstream. > The goal of this project is to build fault management and > maintenance framework for high

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

On 01:04 Jan 30, Sean McGinnis wrote: > Patrick has been a strong contributor to Cinder over the last few releases, > both with great code submissions and useful reviews. He also participates > regularly on IRC helping answer questions and providing valuable feedback. > > I would like to add

Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

Hi Dulko, A VIM can't not detect certain NFVI fault. The external systems don't monitor the servise state. Fault as CPU failure, CPU condition not OK, Memory failure and network card failure, e.g. If the external systems detect the storage controller failure, Live migration if storage is still

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

+1 from me. Patrick has done a great job the last several releases and his dedication to making Cinder better has been very visible. Patrick has been a strong contributor to Cinder over the last few releases, both with great code submissions and useful reviews. He also participates

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

On 01/29/2016 07:04 PM, Sean McGinnis wrote: > Patrick has been a strong contributor to Cinder over the last few releases, > both with great code submissions and useful reviews. He also participates > regularly on IRC helping answer questions and providing valuable feedback. > > I would like to

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

On Sat, Jan 30, 2016 at 12:58 PM, Jay Bryant wrote: > +1. Patrick's contributions to Cinder have been notable since he joined us > and he is a pleasure to work with! Welcome to the core team Patrick! > > Jay > > > On Fri, Jan 29, 2016, 19:05 Sean McGinnis

[openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

Hi all, I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1]. Project doctor[2] in OPNFV community is its upstream. The goal of this project is to build fault management and maintenance framework for high availability of Network Services on top of virtualized

Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

Hi, dong.wenjuan Sounds very interesting about "doctor" project. What's timezone about the weekly meeting? I want to join it if I have time by then. Thanks Wang Hao 2016-02-01 14:43 GMT+08:00 : > > Hi all, > > I proposed the spec of Add-ServiceGroup-using-Tooz in

Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

Hi Whang Hao, OPNFV Doctor meeting details can be found here: https://wiki.opnfv.org/meetings/doctor Br, Tomi From: EXT hao wang [mailto:sxmatch1...@gmail.com] Sent: Monday, February 01, 2016 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

+1. Patrick's contributions to Cinder have been notable since he joined us and he is a pleasure to work with! Welcome to the core team Patrick! Jay On Fri, Jan 29, 2016, 19:05 Sean McGinnis wrote: > Patrick has been a strong contributor to Cinder over the last few >

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

+1 He's been doing great work, and is a pleasure to work with. On 29 Jan 2016 19:05, "Sean McGinnis" wrote: > Patrick has been a strong contributor to Cinder over the last few > releases, both with great code submissions and useful reviews. He also > participates

Re: [openstack-dev] [cinder] Testing Cinder upgrades - c-bak upgrade

On 29 Jan 2016 19:37, "Michał Dulko" wrote: > > Resolution on this matter from the Cinder mid-cycle is that we're fine > as long as we safely fail in case of upgrade conducted in an improper > order. And it seems we can implement that in a simple way by raising an >

[openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

Patrick has been a strong contributor to Cinder over the last few releases, both with great code submissions and useful reviews. He also participates regularly on IRC helping answer questions and providing valuable feedback. I would like to add Patrick to the core reviewers for Cinder. Per our

Re: [openstack-dev] [cinder] Testing Cinder upgrades - c-bak upgrade

On 01/20/2016 09:11 PM, Li, Xiaoyan wrote: > @ DuncanT and @dule: > > I noticed from IRC log that you are discussing about c-bak upgrade, and I am > working on this, please see following message. Hope I don't miss anything. > > As you know, currently c-bak and c-vol are in same nodes. c-bak

[openstack-dev] [Cinder] No weekly meeting Jan 27

Just an official notice - there will be no weekly meeting January 27th due to the Mitaka Midcycle. Regular weekly meetings will continue the first week of February. Thanks! Sean McGinnis (smcginnis) __ OpenStack Development

[openstack-dev] [cinder] Core/minimum features requirements for Cinder Driver

Hey Guys, I would like to know the requirement for core/minimum features that any new Cinder driver should implement. Provided lot many features have been added in Cinder since Icehouse release, Is the core feature requirements mentioned in [1] still valid for recent and upcoming releases or

Re: [openstack-dev] [cinder] Core/minimum features requirements for Cinder Driver

On 01/22/2016 01:17 PM, vishal yadav wrote: > Hey Guys, > > I would like to know the requirement for core/minimum features that > any new Cinder driver should implement. Provided lot many features > have been added in Cinder since Icehouse release, Is the core feature > requirements mentioned in

[openstack-dev] [cinder][bugs] volume:create_snapshot is missing from etc/cinder/policy.json

Found that the "volume:create_snapshot": "rule:admin_or_owner", action was missing from the cinder policy.json file. I am looking for someone to review the change and close the bug. Any help would be appreciated. Original Bug https://bugs.launchpad.net/cinder/+bug/1530196 Gerrit review

Re: [openstack-dev] [cinder] Testing Cinder upgrades - c-bak upgrade

@ DuncanT and @dule: I noticed from IRC log that you are discussing about c-bak upgrade, and I am working on this, please see following message. Hope I don't miss anything. As you know, currently c-bak and c-vol are in same nodes. c-bak depends on c-vol service. But it is not necessary that

Re: [openstack-dev] [cinder] Object backporting and the associated service

On 5 January 2016 at 18:55, Ryan Rossiter wrote: > This is definitely good to know. Are you planning on setting up something > off to the side of o.vo within that holds a dictionary of all values for a > release? Something like: > > {‘liberty’: {‘volume’: ‘1.3’, …},

Re: [openstack-dev] [cinder] Object backporting and the associated service

On 01/18/2016 03:31 PM, Duncan Thomas wrote: > On 5 January 2016 at 18:55, Ryan Rossiter > wrote: > > This is definitely good to know. Are you planning on setting up > something off to the side of o.vo within that holds a

Re: [openstack-dev] [cinder] Should we fix XML request issues?

Excerpts from Michał Dulko's message of 2016-01-15 09:08:54 +0100: > On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > > Hi Devs, > > > > I have come across a few 500 response issues while sending request > > body as XML to cinder service. For example: > > > > > > > > I can see that XML

Re: [openstack-dev] [cinder] Should we fix XML request issues?

On Fri, Jan 15, 2016 at 09:08:54AM +0100, Michał Dulko wrote: > On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > > Hi Devs, > > > > I have come across a few 500 response issues while sending request > > body as XML to cinder service. For example: > > > > > > > > I can see that XML

Re: [openstack-dev] [cinder] Should we fix XML request issues?

500 error is bad for any API. IMO, I'm OK to fix it Mitaka. Deprecated means that it could be dropped soon. It doesn't mean that it's not working at all. BTW, XML API almost has no tests so I'm not surprised that it's broken Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Jan 15, 2016

Re: [openstack-dev] [cinder] Should we fix XML request issues?

On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > Hi Devs, > > I have come across a few 500 response issues while sending request > body as XML to cinder service. For example: > > > > I can see that XML support has been marked as depricated and will be > removed in 'N' release. So is it

[openstack-dev] [cinder] Should we fix XML request issues?

Hi Devs, I have come across a few 500 response issues while sending request body as XML to cinder service. For example: -- openstack@openstack-136:/opt/stack/cinder$ curl -i -X PUT -H "X-Auth-Token: 79e6f8f529d2494b81dbd1a6ea5e077d" -H "Accept: application/xml"

[openstack-dev] [Cinder] [Ironic] Attach Cinder Volume to the Ironic Instance without Nova Step-by-Step guide

Hi team, In scope of 'use-cinder-without-nova' blueprint [1] I've created PoC code [2] with detailed instructions how to attach volumes inside Ironic or Nova instances. Detailed instructions could be found on my blog [3]. Any feedback are welcome! [1]

[openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

Hi all, The physical equipment that runs the NetApp CI system is scheduled to be moved to a new building next week. In order to accommodate this move we will be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to have it back up and running by EOB on Monday Jan 25. I just

Re: [openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

On 01/13/2016 10:43 AM, Kerr, Andrew wrote: > Hi all, > > The physical equipment that runs the NetApp CI system is scheduled to be > moved to a new building next week. In order to accommodate this move we will > be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to > have

Re: [openstack-dev] Cinder as generic volume manager

Hi Team, Let me introduce updates related to use-cinder-without-nova blueprint [1]. According to spec [2] we've introduced new python-brick-cinderclient-ext project [3]. It's an official Cinder project and implemented as an extension to python-cinderclient. For now, it supports only

[openstack-dev] [cinder]How to create volume type with extra_specs by using cinder-client?

Hi guys, When creating volume type, extra_specs is optional in body, as can be seen from API document, http://developer.openstack.org/api-ref-blockstorage-v2.html but I notice that in cinder-client, the method of create in VolumeTypeManager dose not take extra_specs in body,

[openstack-dev] [cinder] Should we add 'os-initialize_connection' to Blockstorage API Document?

Hi, 'os-initialize_connection' is a important API for Cinder to complete the volume attach operation, but there is no record in Cinder(Blockstorage) API Document(1). Also some developers want to find the description for the 'os-initialize_connection' API. So should we add this API to the

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

Sorry, of course this https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L575 On Wed, Jan 6, 2016 at 5:57 PM, Yuriy Nesenenko wrote: > You can use this function > https://github.com/openstack/cinder/blob/master/cinder/volume/utils.py#L5 > > On Wed,

[openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

Hello, >From CLI, I can see the host-name in the cinder show command as follows: | os-vol-host-attr:host | openstack4@mySCSIBackend#pool1 | How this info can be accessed from the cinder python client? I can access other information (id, size, name etc.) as follows: >>>

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

Try client.volumes..get(id).__dict__[' *os-vol-host-attr:host'] * *Ugly, but it seems to work* On 6 January 2016 at 18:20, Pradip Mukhopadhyay wrote: > Thanks, Yuriy. > > My question was: how can I retrieve the "host@backend#pool" from the > pythonclient API of

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

Thanks, Yuriy. My question was: how can I retrieve the "host@backend#pool" from the pythonclient API of volume listing? Once I have that, I should use this method to extract the pool-name. But how can I access this info? CLI is showing this as in the following field:

Re: [openstack-dev] [cinder][python-client-api] Retrieve host-name attribute of Cinder Volume

Thanks a ton Duncan. It's just awesome. >>> volumes[0].__dict__['os-vol-host-attr:host'] u'openstack4@cmodeSCSIBackend#pool1' >>> --pradip On Thu, Jan 7, 2016 at 12:53 AM, Duncan Thomas wrote: > Try client.volumes..get(id).__dict__[' > > *os-vol-host-attr:host'] *

Re: [openstack-dev] [cinder] Object backporting and the associated service

> On Jan 5, 2016, at 7:13 AM, Michał Dulko wrote: > > On 01/04/2016 11:41 PM, Ryan Rossiter wrote: >> My first question is: what will be handling the object backports that the >> different cinder services need? In Nova, we have the conductor service, >> which handles

[openstack-dev] [cinder] oslo_config.PortOp is undefined

Hello, I have a devstack created on 12/22/15. Just seeing that (after a vacation) it stops working. Tried to restart the cinder services, getting the error: stack@openstack4:~/devstack$ /usr/local/bin/cinder-api --config-file /etc/cinder/cinder.conf & echo $!

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

I did not do anything specific. Oslo Config has IntOpt, not PortOpt. Any clue how can I upgrade oslo.config? --pradip On Tue, Jan 5, 2016 at 4:43 PM, Julien Danjou wrote: > On Tue, Jan 05 2016, Pradip Mukhopadhyay wrote: > > Upgrade oslo.config? > > > Hello, > > > > >

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

PortOpt definitely exists in oslo.config [1]. Try executing "pip install -U -r /opt/stack/cinder/requirements.txt". [1] https://github.com/openstack/oslo.config/blob/f5e2fab3ae5af5bd47fe3526a73f13fbaa27c1f0/oslo_config/cfg.py#L1180-L1216 On 01/05/2016 12:33 PM, Pradip Mukhopadhyay wrote: > I did

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

On Tue, Jan 05 2016, Pradip Mukhopadhyay wrote: Upgrade oslo.config? > Hello, > > > I have a devstack created on 12/22/15. Just seeing that (after a vacation) > it stops working. > > Tried to restart the cinder services, getting the error: > > stack@openstack4:~/devstack$

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

After upgrading all the oslo.config, oslo.service and oslo.log, now c-sch and c-vol running well. Buit c-api is failing with this stack-trace: stack@openstack4:~/devstack$ screen -x 2016-01-05 06:44:18.544 TRACE cinder return self.object_type.invoke(self) 2016-01-05 06:44:18.544 TRACE cinder

Re: [openstack-dev] [cinder] Object backporting and the associated service

On 01/04/2016 11:41 PM, Ryan Rossiter wrote: > My first question is: what will be handling the object backports that the > different cinder services need? In Nova, we have the conductor service, which > handles all of the messy RPC and DB work. When anyone needs something > backported, they ask

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

Thanks. Tried this. Still getting the same error on c-api installation. The pip upgrade shown some issues as follows: Installing collected packages: lxml, oslo.middleware, pyparsing, requests, python-keystoneclient, SQLAlchemy, urllib3 Found existing installation: lxml 3.3.3 Uninstalling

Re: [openstack-dev] [cinder] oslo_config.PortOp is undefined

Oops. sorry. I was as stack user. It works now (with a sudo). All the three cinder services are running. Thanks a ton for the help, Pradip On Tue, Jan 5, 2016 at 5:51 PM, Pradip Mukhopadhyay < pradip.inte...@gmail.com> wrote: > Thanks. Tried this. Still getting the same error on c-api

[openstack-dev] [cinder] Object backporting and the associated service

Hey everybody, your favorite versioned objects guy is back! So as I’m helping out more and more with the objects stuff around Cinder, I’m starting to notice something that may be a problem with rolling upgrades/object backporting. Feel free to say “you’re wrong” at any point during this email,

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

On 12/28/2015 05:03 AM, hao wang wrote: > 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

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

instances. > My colleague and I, have posted the specs[1] of ServiceGroup in > Cinder. > > Janice > > [1] https://review.openstack.org/#/c/258968/ > > > > > 发件人: Erlon Cruz <sombra...@gmail.com> > 收件人: "OpenStack Develop

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

Erlon Cruz <sombra...@gmail.com> 收件人: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, 日期: 2015/12/23 04:04 主题: Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary Hmm, I see.

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

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

[openstack-dev] [Cinder] No IRC meeting December 30

Hey all, Do to the holidays and travel there will be no meeting next Wednesday, December 30th. We will resume the following week. Have a good break! Sean (smcginnis) __ OpenStack Development Mailing List (not for usage

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

On 12/22/2015 09:01 PM, Erlon Cruz wrote: > 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]

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,

Re: [openstack-dev] [Cinder][DRBD] questions about pep8/flake8 etc.

On 21/12, Walter A. Boring IV wrote: > On 12/21/2015 06:40 AM, Philipp Marek wrote: > >Hi everybody, > > > >in the current patch https://review.openstack.org/#/c/259973/1 the test > >script needs to use a lot of the constant definitions of the backend driver > >it's using (DRBDmanage). > > > >As

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

On 12/17/2015 04:49 AM, li.yuanz...@zte.com.cn wrote: > 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

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

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

Re: [openstack-dev] [Cinder][DRBD] questions about pep8/flake8 etc.

On 12/21/2015 06:40 AM, Philipp Marek wrote: Hi everybody, in the current patch https://review.openstack.org/#/c/259973/1 the test script needs to use a lot of the constant definitions of the backend driver it's using (DRBDmanage). As the DRBDmanage libraries need not be installed on the CI

[openstack-dev] [Cinder][DRBD] questions about pep8/flake8 etc.

Hi everybody, in the current patch https://review.openstack.org/#/c/259973/1 the test script needs to use a lot of the constant definitions of the backend driver it's using (DRBDmanage). As the DRBDmanage libraries need not be installed on the CI nodes, I'm providing a minimum of upstream

Re: [openstack-dev] [cinder] Custom fields for versioned objects

On 15/12, Ryan Rossiter wrote: > Thanks for the review Michal! As for the bp/bug report, there’s four options: > > 1. Tack the work on as part of bp cinder-objects > 2. Make a new blueprint (bp cinder—object-fields) I think #2 would be the best option, as this is not part of the effort to move

Re: [openstack-dev] [cinder] Custom fields for versioned objects

Sean, Just an FYI that I have created a work item for my team to start working this. So, watch for patches from Slade, Kendall, Ryan, Jacob and I to get this implemented. Thanks, Jay On 12/15/2015 10:31 AM, Sean McGinnis wrote: On Tue, Dec 15, 2015 at 04:46:02PM +0100, Micha?? Dulko

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

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

Re: [openstack-dev] [Cinder] Rolling upgrades

On Tue, Dec 15, 2015 at 01:09:10PM +0100, Micha?? Dulko wrote: > Hi, > > At the meeting recently it was mentioned that our rolling upgrades > efforts are pursuing an "elusive unicorn" that makes development a lot > more complicated and restricted. I want to try to clarify this a bit, > explain

Re: [openstack-dev] [cinder] Custom fields for versioned objects

On Tue, Dec 15, 2015 at 04:46:02PM +0100, Micha?? Dulko wrote: > On 12/15/2015 04:08 PM, Ryan Rossiter wrote: > > Thanks for the review Michal! As for the bp/bug report, there???s four > > options: > > > > 1. Tack the work on as part of bp cinder-objects > > 2. Make a new blueprint (bp

Re: [openstack-dev] [cinder] Custom fields for versioned objects

On 12/14/2015 03:59 PM, Ryan Rossiter wrote: > Hi everyone, > > I have a change submitted that lays the groundwork for using custom enums and > fields that are used by versioned objects [1]. These custom fields allow for > verification on a set of valid values, which prevents the field from

[openstack-dev] [Cinder] Rolling upgrades

Hi, At the meeting recently it was mentioned that our rolling upgrades efforts are pursuing an "elusive unicorn" that makes development a lot more complicated and restricted. I want to try to clarify this a bit, explain the strategy more and give an update on the status of the whole affair. So

Re: [openstack-dev] [cinder] Custom fields for versioned objects

On 12/15/2015 04:08 PM, Ryan Rossiter wrote: > Thanks for the review Michal! As for the bp/bug report, there’s four options: > > 1. Tack the work on as part of bp cinder-objects > 2. Make a new blueprint (bp cinder—object-fields) > 3. Open a bug to handle all changes for enums/fields > 4. Open a

Re: [openstack-dev] [cinder] Custom fields for versioned objects

Thanks for the review Michal! As for the bp/bug report, there’s four options: 1. Tack the work on as part of bp cinder-objects 2. Make a new blueprint (bp cinder—object-fields) 3. Open a bug to handle all changes for enums/fields 4. Open a bug for each changed enum/field Personally, I’m partial

Re: [openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

On 11/12, mtanino wrote: > Hi Thang, Vincent, > > I guess the root cause is that finish_volume_migration() still > handles a volume as a dictionary instead of volume object and > the method returns dict volume. > > And then, 'rpcapi.delete_volume()' in migrate_volume_completion() > tries to

[openstack-dev] [cinder] Custom fields for versioned objects

Hi everyone, I have a change submitted that lays the groundwork for using custom enums and fields that are used by versioned objects [1]. These custom fields allow for verification on a set of valid values, which prevents the field from being mistakenly set to something invalid. These custom

Re: [openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

Thank you for the explanation, Gorka! Mitsuhiro On 12/14/2015 05:00 AM, Gorka Eguileor wrote: On 11/12, mtanino wrote: Hi Thang, Vincent, I guess the root cause is that finish_volume_migration() still handles a volume as a dictionary instead of volume object and the method returns dict

Re: [openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

Hi Thang, Vincent, I guess the root cause is that finish_volume_migration() still handles a volume as a dictionary instead of volume object and the method returns dict volume. And then, 'rpcapi.delete_volume()' in migrate_volume_completion() tries to delete dict volume but it fails due to the

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

On 10 December 2015 at 04:48, Li, Xiaoyan wrote: > > This leads to a problem like extending volume. Extending a volume in an > incremental snapshot fails > in vendor storage. And then the cinder volume goes into error_extending > status. From my opinion this is not good. >

[openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

Hi Mitsuhiro, Thang The patch https://review.openstack.org/#/c/228916 is merged, but sadly it does not cover the issue https://bugs.launchpad.net/cinder/+bug/1520102. This bug is still valid. As far as you know, is there someone working on this issue? If not, I am gonna fix it. Best wishes,

Re: [openstack-dev] [Cinder] Is there anyone truly working on this issue https://bugs.launchpad.net/cinder/+bug/1520102?

I have to try it again myself. What errors are you seeing? Is it the same? Feel free to post a patch if you already have one that would solve it. Regards, Thang On Thu, Dec 10, 2015 at 10:51 PM, Sheng Bo Hou wrote: > Hi Mitsuhiro, Thang > > The patch

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan wrote: > Hi all, > > Currently when deleting a volume, it checks whether there are snapshots > created from it. If yes deletion is prohibited. But it allows to extend > the volume, no check whether there are snapshots from it. >

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

questions) Subject: [openstack-dev] [cinder] Dependencies of snapshots on volumes Hi all, Currently when deleting a volume, it checks whether there are snapshots created from it. If yes deletion is prohibited. But it allows to extend the volume, no check whether there are snapshots from it. The two

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

On 09:27 Dec 09, John Griffith wrote: > On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan wrote: > > As a result, this raises two concerns here: > > 1. Let such operations behavior same in Cinder. > > 2. I prefer to let storage driver decide the dependencies, not in the > >

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

On Dec 10, 2015 06:34, Mike Perez wrote: > On 09:27 Dec 09, John Griffith wrote: >> On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan > wrote: > > > >>> As a result, this raises two concerns here: >>> 1. Let such operations behavior same in Cinder. >>> 2. I prefer to let

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

On 12/09/2015 10:27 AM, John Griffith wrote: On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan > wrote: Hi all, Currently when deleting a volume, it checks whether there are snapshots created from it. If yes deletion is prohibited.

Re: [openstack-dev] [cinder] Dependencies of snapshots on volumes

Hi, FWIW, I completely agree with what John said. All of it. Please don't do that. Jordan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [cinder] Dependencies of snapshots on volumes

Hi all, Currently when deleting a volume, it checks whether there are snapshots created from it. If yes deletion is prohibited. But it allows to extend the volume, no check whether there are snapshots from it. The two behaviors in Cinder are not consistent from my viewpoint. In backend

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 12/2/15, 4:01 PM, "Ben Swartzlander" wrote: >On 11/30/2015 09:04 AM, Coffman, Joel M. wrote: >> >> >> On 11/25/15, 11:33 AM, "Ben Swartzlander" > > wrote: >> >> On 11/24/2015 03:27 PM, Nathan Reller wrote: >> >>

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

> -Original Message- > From: Ben Swartzlander [mailto:b...@swartzlander.org] > Sent: Friday, December 4, 2015 2:45 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick > > O

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 3 December 2015 at 11:14, Li, Xiaoyan wrote: > Just to clear the data operations cinder needs to touch plaintext data are: > 1) Create volume from glance image > 2) Create glance image from volume > 3) Retype encrypted volumes. That is to change a volume from

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

Thank you, Ben. I agree with you, and just to clear the cinder operations which needs to decrypt volumes in following. On Dec 3, 2015 05:01, Ben Swartzlander wrote: > On 11/30/2015 09:04 AM, Coffman, Joel M. wrote: >> >> >> On 11/25/15, 11:33 AM, "Ben Swartzlander" >

<    6   7   8   9   10   11   12   13   14   15   >