Re: [openstack-dev] [Cinder] Mitaka RC2 available

Great, thanks! From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: 29 March 2016 4:01 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openst...@lists.openstack.org Subject: Re: [openstack-dev] [Cinder] Mitaka RC2 available That patch is now approved and in the

Re: [openstack-dev] [Cinder] Mitaka RC2 available

:thie...@openstack.org] > Sent: 29 March 2016 3:03 PM > To: OpenStack Development Mailing List ; > openst...@lists.openstack.org > Subject: [openstack-dev] [Cinder] Mitaka RC2 available > > Due to release-critical issues spotted in Cinder during RC1 testing, a new > releas

Re: [openstack-dev] [Cinder] Mitaka RC2 available

3:03 PM To: OpenStack Development Mailing List ; openst...@lists.openstack.org Subject: [openstack-dev] [Cinder] Mitaka RC2 available Due to release-critical issues spotted in Cinder during RC1 testing, a new release candidate was created for Mitaka. You can find the RC2 source code tarballs at

[openstack-dev] [Cinder] Mitaka RC2 available

Due to release-critical issues spotted in Cinder during RC1 testing, a new release candidate was created for Mitaka. You can find the RC2 source code tarballs at: https://tarballs.openstack.org/cinder/cinder-8.0.0.0rc2.tar.gz Unless new release-critical issues are found that warrant a last-min

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

On Sun, Mar 27, 2016 at 9:44 AM, Duncan Thomas wrote: > I think it is worth fixing the client to actually match the API, yes. The > client seems to be determined not to actually match the API in lots of > ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666 > OSC is opiniona

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

On Mon, Mar 28, 2016 at 4:29 AM, Duncan Thomas wrote: > Because it leads to false assumptions, and code that breaks when something > breaks those assumptions (e.g. somebody creates a volume with no name on > horizon and breaks all the users of openstackclient that expects one > because their clie

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez wrote: > On 00:40 Mar 28, Jordan Pittier wrote: > > I am going to play the devil's advocate here but why can"t > > python-openstackclient have its own opinion on the matter ? This CLI > seems > > to be for humans and humans love names/labels/tags and fi

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

Because it leads to false assumptions, and code that breaks when something breaks those assumptions (e.g. somebody creates a volume with no name on horizon and breaks all the users of openstackclient that expects one because their client suggested it was mandatory On 28 March 2016 at 01:40, Jordan

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

On 00:40 Mar 28, Jordan Pittier wrote: > I am going to play the devil's advocate here but why can"t > python-openstackclient have its own opinion on the matter ? This CLI seems > to be for humans and humans love names/labels/tags and find UUIDS hard to > remember. Advanced users who want anonymous

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

I am going to play the devil's advocate here but why can"t python-openstackclient have its own opinion on the matter ? This CLI seems to be for humans and humans love names/labels/tags and find UUIDS hard to remember. Advanced users who want anonymous volumes can always hit the API directly with cu

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

I think it is worth fixing the client to actually match the API, yes. The client seems to be determined not to actually match the API in lots of ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666 On 24 March 2016 at 19:08, Ivan Kolodyazhny wrote: > Hi team, > > From the Ci

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

); Luozhen Subject: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method? Hi Jon, My basic idea is that, when we need to migrate a volume from my (vendor of) storage array to another backend (storage array), we will fi

Re: [openstack-dev] [cinder][nova] Cinder-Nova API meeting

On 3/24/2016 4:01 AM, Ildikó Váncsa wrote: Hi All, As it was discussed several times on this mailing list there is room for improvements regarding the Cinder-Nova interaction. To fix these issues we would like to create a cross-project spec to capture the problems and ways to solve them. Th

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

件人: OpenStack Development Mailing List (not for usage questions) 抄送: Luozhen 主题: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method? * liuxinguo wrote: > Hi Cinder team, > > We are going to implement

[openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

Hi team, >From the Cinder point of view, both volumes, snapshots and backups APIs do not require name param. But python-openstackclient requires name param for these entities. I'm going to fix this inconsistency with patch [1]. Unfortunately, it's a bit more than changing required params to not r

Re: [openstack-dev] [cinder][nova] Cinder-Nova API meeting

On Thu, Mar 24, 2016 at 09:01:28AM +, Ildikó Váncsa wrote: > Hi All, > > As it was discussed several times on this mailing list there is room for > improvements regarding the Cinder-Nova interaction. To fix these issues we > would like to create a cross-project spec to capture the problems a

[openstack-dev] [Cinder] About snapshot Rollback?

Hi all: We are condering add a fucntion rollback_snapshot when we use backup. In the end user's scenario. If a vm fails, we hope that we can use snapshot to to recovery the volume's data. Beacuse it can quickly recovery our vm. But if we use the remote data to recovery. We will spend mor

[openstack-dev] [cinder][nova] Cinder-Nova API meeting

Hi All, As it was discussed several times on this mailing list there is room for improvements regarding the Cinder-Nova interaction. To fix these issues we would like to create a cross-project spec to capture the problems and ways to solve them. The current activity is captured on this etherpad

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

* liuxinguo wrote: > Hi Cinder team, > > We are going to implement storage-assisted volume migrate in our > driver between different backend storage array or even different array > of different vendors. This is really high-efficiency than the > host-copy migration between different array of diff

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

On Fri, Mar 18, 2016 at 04:05:34AM +, liuxinguo wrote: > Hi Cinder team, > > We are going to implement storage-assisted volume migrate in our driver > between different backend storage array or even different array of different > vendors. > This is really high-efficiency than the host-copy m

[openstack-dev] [Cinder] Mitaka RC1 available

Hello everyone, Cinder is the next project team to produce a release candidate for the end of the Mitaka cycle! You can find the RC1 source code tarball at: https://tarballs.openstack.org/cinder/cinder-8.0.0.0rc1.tar.gz Unless release-critical issues are found that warrant a release candidat

[openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

Hi Cinder team, We are going to implement storage-assisted volume migrate in our driver between different backend storage array or even different array of different vendors. This is really high-efficiency than the host-copy migration between different array of different vendors. To implement th

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

On Thu, Mar 17, 2016 at 10:05 PM, liuxinguo wrote: > Hi Cinder team, > > > > We are going to implement storage-assisted volume migrate in our driver > between different backend storage array or even different array of > different vendors. > > This is really high-efficiency than the host-copy migr

[openstack-dev] [Cinder] Newton Summit Sessions

Hey everyone, This was announced in our weekly meeting, but putting it out here to get a wider audience and make sure it's seen. I probably should have start here. We have started an etherpad [1] for planning out our design summit sessions. Please feel free to add any additional topics there. If

[openstack-dev] [Cinder] Ivan Kolodyazhny PTL Candidacy

Hello Team, It's a big honor for me be a part of the our Cinder community and I do my best to make Cinder better. That's why I'm I'm announcing my candidacy for Cinder PTL for the Mitaka release. That doesn't mean that I'm working at half strength now. It means that I would like to give as much be

Re: [openstack-dev] [Cinder] Mitaka RC1 available

On Thu, Mar 17, 2016 at 09:41:31AM +0100, Thierry Carrez wrote: > Hello everyone, > > Cinder is the next project team to produce a release candidate for > the end of the Mitaka cycle! You can find the RC1 source code > tarball at: > > https://tarballs.openstack.org/cinder/cinder-8.0.0.0rc1.tar.gz

Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

On 03/18/2016 10:01 AM, Sean McGinnis wrote: > On Fri, Mar 18, 2016 at 04:05:34AM +, liuxinguo wrote: >> Hi Cinder team, >> >> We are going to implement storage-assisted volume migrate in our driver >> between different backend storage array or even different array of different >> vendors. >>

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

I can do a presentation on microversions. Scott D'Angelo (scottda) -- Original Message -- >From : Gorka Eguileor Subject : [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit Hi, As you all probably know, du

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

On 16/03, D'Angelo, Scott wrote: > I can do a presentation on microversions. > "I love it when a plan comes together". This one had your name written all over it. ;-) > > > Scott D'Angelo (scottda) > > -- Original Message ------ > From

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

1407 United States From: Gorka Eguileor To: OpenStack Development Mailing List Date: 03/14/2016 03:57 PM Subject: [openstack-dev] [cinder] Let's do presentations/sessions on

[openstack-dev] [cinder] Proposal about quota-class update

Hi all, I found there is a glossary of quota-class in cinder. But only two operations implemented for it: cinder quota-class-show cinder quota-class-update I am not sure I understand it correctly, but I think we can make it working better as below. Modification: (1) Implement some ge

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

On 15/03, Michał Dulko wrote: > On 03/14/2016 09:52 PM, Gorka Eguileor wrote: > > Hi, > > > > As you all probably know, during this cycle we have introduced quite a > > big number of changes in cinder that will have a great impact in the > > development of the new functionality as well as changes t

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

On 03/14/2016 09:52 PM, Gorka Eguileor wrote: > Hi, > > As you all probably know, during this cycle we have introduced quite a > big number of changes in cinder that will have a great impact in the > development of the new functionality as well as changes to existing ones > moving forward from an i

Re: [openstack-dev] [Cinder] PTL Candidacy

On 03/11/2016 01:41 PM, Sean McGinnis wrote: > Hey everyone, > > Wow, how six months flies! I'd like to announce my candidacy to continue on as > Cinder PTL for the Newton release cycle. > > A lot has been accomplished in the Mitaka cycle. After a lot of work by many > folks, over a couple deve

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

Great idea Gorka! I know I could benefit from this as a reviewer. Thanks for proposing it. Jay On Mon, Mar 14, 2016 at 3:52 PM Gorka Eguileor wrote: > Hi, > > As you all probably know, during this cycle we have introduced quite a > big number of changes in cinder that will have a great impact

[openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

Hi, As you all probably know, during this cycle we have introduced quite a big number of changes in cinder that will have a great impact in the development of the new functionality as well as changes to existing ones moving forward from an implementation perspective. These changes to the cinder c

Re: [openstack-dev] [Cinder] PTL Candidacy

Thanks for your leadership Sean, I think you've done a terrific job. Gorka. On 11/03, Sean McGinnis wrote: > Hey everyone, > > Wow, how six months flies! I'd like to announce my candidacy to continue on as > Cinder PTL for the Newton release cycle. > > A lot has been accomplished in the Mitaka

[openstack-dev] [Cinder] PTL Candidacy

Hey everyone, Wow, how six months flies! I'd like to announce my candidacy to continue on as Cinder PTL for the Newton release cycle. A lot has been accomplished in the Mitaka cycle. After a lot of work by many folks, over a couple development cycles, we now have what we consider a "tech preview"

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

John, It's a good option. Let's try it! Also, we can try to find/implement something like [13] for ostestr. [13] https://github.com/mahmoudimus/nose-timer Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Mar 7, 2016 at 7:16 PM, John Griffith wrote: > > > On Mon, Mar 7, 2016 at 8:57

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 2016-03-07 23:54:49 +0800 (+0800), Duncan Thomas wrote: > Complexity can be tricky to spot by hand, and expecting reviewers to get it > right all of the time is not a reasonable expectation. > > My ideal would be something that processes the commit and the jenkins logs, > extracts the timing in

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On Mon, Mar 7, 2016 at 8:57 AM, Knight, Clinton wrote: > > > On 3/7/16, 10:45 AM, "Eric Harney" wrote: > > >On 03/06/2016 09:35 PM, John Griffith wrote: > >> On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant > >> >>> wrote: > >> > >>> Ivan, > >>> > >>> I agree that our testing needs improvement. Th

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 3/7/16, 10:45 AM, "Eric Harney" wrote: >On 03/06/2016 09:35 PM, John Griffith wrote: >> On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant wrote: >> >>> Ivan, >>> >>> I agree that our testing needs improvement. Thanks for starting this >>> thread. >>> >>> With regards to adding a hacking c

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 7 March 2016 at 23:45, Eric Harney wrote: > > > I'm not really sure that writing a "hacking" check for this is a > worthwhile investment. (It's not a hacking check really, but something > more like what you're describing, but that's beside the point.) > > We should just be looking for large,

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/06/2016 09:35 PM, John Griffith wrote: > On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant > wrote: > >> Ivan, >> >> I agree that our testing needs improvement. Thanks for starting this >> thread. >> >> With regards to adding a hacking check for tests that run too long ... are >> you thinking t

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant wrote: > Ivan, > > I agree that our testing needs improvement. Thanks for starting this > thread. > > With regards to adding a hacking check for tests that run too long ... are > you thinking that we would have a timer that checks or long running job

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Ivan, I agree that our testing needs improvement. Thanks for starting this thread. With regards to adding a hacking check for tests that run too long ... are you thinking that we would have a timer that checks or long running jobs or something that checks for long sleeps in the testing code

Re: [openstack-dev] [cinder] Nested quota -1 limit race condition

On 03/03, Ryan McNair wrote: > Hey all, > > Nested quotas has officially started fighting back - while writing Tempest > tests for the nested quota support [1], I hit a race-condition related to > the nested quota -1 support that has me stumped. I opened a bug for it [2] > with more details, but b

Re: [openstack-dev] [Cinder] Status of cinder-list bug delay with 1000's of volumes

On 03/03/2016 06:38 PM, Walter A. Boring IV wrote: > Adam, > As the bug shows, it was fixed in the Juno release. The icehouse > release is no longer supported. I would recommend upgrading your > deployment if possible or looking at the patch and see if it can work > against your Icehouse code

Re: [openstack-dev] [Cinder] Status of cinder-list bug delay with 1000's of volumes

Adam, As the bug shows, it was fixed in the Juno release. The icehouse release is no longer supported. I would recommend upgrading your deployment if possible or looking at the patch and see if it can work against your Icehouse codebase. https://review.openstack.org/#/c/96548/ Walt On 0

[openstack-dev] [cinder] Nested quota -1 limit race condition

Hey all, Nested quotas has officially started fighting back - while writing Tempest tests for the nested quota support [1], I hit a race-condition related to the nested quota -1 support that has me stumped. I opened a bug for it [2] with more details, but basically the issue occurs when if you cha

[openstack-dev] [Cinder] Status of cinder-list bug delay with 1000's of volumes

Hey all (hi John), What's the status of this [1]? We're experiencing this behavior in Icehouse - wondering where it was addressed and if so, when. I always get confused when I look at the launchpad/review portals. [1] https://bugs.launchpad.net/cinder/+bug/1317606 *Adam Lawson* AQORN, Inc. 427

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 02/03, Ivan Kolodyazhny wrote: > I'll try to implement such scenario and step-by-step guideline soon. > That would be fantastic!! Thank you very much Looking forward to it. :-) Cheers, Gorka. > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Wed, Mar 2, 2016 at 5:16 PM, Eric

Re: [openstack-dev] [cinder] 3.rd Party CI requirements for compliance

On Wed, Mar 02, 2016 at 06:14:30PM +, Indra Harijono wrote: > Hi, > > I am new in this forum and openstack dev. so please my sincere apology if I > submitted stupid (redundant) questions. > I am writing this to clarify cinder compliance requirements (and 3.rd Party > CI Testing). > We are de

Re: [openstack-dev] [cinder] 3.rd Party CI requirements for compliance

On 18:14 Mar 02, Indra Harijono wrote: > Hi, > > I am new in this forum and openstack dev. so please my sincere apology if I > submitted stupid (redundant) questions. > I am writing this to clarify cinder compliance requirements (and 3.rd Party > CI Testing). > We are developing storage applianc

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

Hi, It's still not clear for me, why we can't just add Rally jobs with scenarios related to specific project. It will work quite fast and it will cover CLI (instantly) with good integration/functional testing. Best regards, Boris Pavlovic On Wed, Mar 2, 2016 at 4:52 AM, Sean Dague wrote: > O

[openstack-dev] [cinder] 3.rd Party CI requirements for compliance

Hi, I am new in this forum and openstack dev. so please my sincere apology if I submitted stupid (redundant) questions. I am writing this to clarify cinder compliance requirements (and 3.rd Party CI Testing). We are developing storage appliance and would like to run cinder on it. We don't direct

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Hi, I will try to be short. - Voting unit test coverage job is ready, and you can just use it as is from rally source code: you need this file https://github.com/openstack/rally/blob/master/tests/ci/cover.sh and this change in tox: https://github.com/openstack/rally/blob/master/tox.ini#L51-

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 04:11 PM, Gorka Eguileor wrote: > On 02/03, Ivan Kolodyazhny wrote: >> Eric, >> >> There are Gorka's patches [10] to remove API Races >> >> >> [10] >> https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified >> > I looked at Rally a long t

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

I'll try to implement such scenario and step-by-step guideline soon. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 5:16 PM, Eric Harney wrote: > On 03/02/2016 10:07 AM, Ivan Kolodyazhny wrote: > > Eric, > > > > For now, we test Cinder API with some concurrency only wi

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 10:07 AM, Ivan Kolodyazhny wrote: > Eric, > > For now, we test Cinder API with some concurrency only with Rally, so, IMO, > it's reasonable get more scenarios for API races fixes. > > It's not a hard task to implement new scenarios, they are pretty simple: > [11] and [12] > Sure,

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 02/03, Ivan Kolodyazhny wrote: > Eric, > > There are Gorka's patches [10] to remove API Races > > > [10] > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > I looked at Rally a long time ago so apologies if I'm totally off base here, bu

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Eric, For now, we test Cinder API with some concurrency only with Rally, so, IMO, it's reasonable get more scenarios for API races fixes. It's not a hard task to implement new scenarios, they are pretty simple: [11] and [12] [11] https://github.com/openstack/rally/blob/master/rally/plugins/opens

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [cinder] Proposal: changes to our current > testing process > > > > Eric, > > > > There are Gorka's patches [10] to remove API Races > >

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [cinder] Proposal: changes to our current testing process Eric, There are Gorka's patches [10] to remove API Races [10] https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 09:36 AM, Ivan Kolodyazhny wrote: > Eric, > > There are Gorka's patches [10] to remove API Races > > > [10] > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > So the

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Eric, There are Gorka's patches [10] to remove API Races [10] https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney wrote: > On 03/02/2016 06:25 AM,

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > Hi Team, > > Here are my thoughts and proposals how to make Cinder testing process > better. I won't cover "3rd party CI's" topic here. I will share my opinion > about current and feature jobs. > > > Unit-tests > >- Long-running tests. I hop

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

t; Scott D'Angelo (scottda) > > From: Ivan Kolodyazhny [e...@e0ne.info] > Sent: Wednesday, March 02, 2016 4:25 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [cinder] Proposal: changes to our current testing > process > > Hi Te

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

ngelo (scottda) From: Ivan Kolodyazhny [e...@e0ne.info] Sent: Wednesday, March 02, 2016 4:25 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [cinder] Proposal: changes to our current testing process Hi Team, Here are my thoughts and proposals h

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

On 03/02/2016 07:34 AM, Ivan Kolodyazhny wrote: > Sean, > > I've mentioned above, that current tempest job runs ~1429 tests and only > about 10 of them uses cinderclient. It tooks a lot of time without any > benefits for cinder, e.g.: tests like tempest.api.network.* verifies > Neutron, not python

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

Sean, I've mentioned above, that current tempest job runs ~1429 tests and only about 10 of them uses cinderclient. It tooks a lot of time without any benefits for cinder, e.g.: tests like tempest.api.network.* verifies Neutron, not python-cinderclient. Regards, Ivan Kolodyazhny, http://blog.e0ne.

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Hi Ivan! On Wed, Mar 2, 2016 at 1:25 PM, Ivan Kolodyazhny wrote: > Hi Team, > > Here are my thoughts and proposals how to make Cinder testing process > better. I won't cover "3rd party CI's" topic here. I will share my opinion > about current and feature jobs. > > > Unit-tests > >- Long-runn

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

On 03/02/2016 06:58 AM, Ivan Kolodyazhny wrote: > Sean, > > In such case, can we configure which tests should be run for > the python-cinderclient src job? No, there really isn't a mechanism for this because getting it right is quite complicated and error prone. What is the motivation here? Mayb

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

Sean, In such case, can we configure which tests should be run for the python-cinderclient src job? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 1:45 PM, Sean Dague wrote: > On 03/02/2016 05:24 AM, Ivan Kolodyazhny wrote: > > Sean, > > > > I do understand why we hav

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

On 03/02/2016 05:24 AM, Ivan Kolodyazhny wrote: > Sean, > > I do understand why we have tempest for python-cinderclient now. > > But my point is: tempest runs more than 200 tests per each cinderclient > change request which takes a lot of time. Why can't we just introduce > few integration test

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

Luigi, >From my point of view, Tempest should verify Cinder for DefCore requirements [1] only. Such integration tests won't be just a re-implementation if a Tempest tests. It will me more extended set of tests for integration between cinderclient and other projects. [1] https://github.com/opens

[openstack-dev] [cinder] Proposal: changes to our current testing process

Hi Team, Here are my thoughts and proposals how to make Cinder testing process better. I won't cover "3rd party CI's" topic here. I will share my opinion about current and feature jobs. Unit-tests - Long-running tests. I hope, everybody will agree that unit-tests must be quite simple and

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

On Wednesday 02 of March 2016 12:24:57 Ivan Kolodyazhny wrote: > Sean, > > I do understand why we have tempest for python-cinderclient now. > > But my point is: tempest runs more than 200 tests per each cinderclient > change request which takes a lot of time. Why can't we just introduce few > int

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

Sean, I do understand why we have tempest for python-cinderclient now. But my point is: tempest runs more than 200 tests per each cinderclient change request which takes a lot of time. Why can't we just introduce few integration tests which will tests nova<=>python-cinderclient API. Also, Nova i

Re: [openstack-dev] [Cinder] [nova] Work flow for detaching a volume

On Fri, Feb 26, 2016 at 12:47 PM, Sean McGinnis wrote: > On Fri, Feb 26, 2016 at 06:11:15PM +, Srinivas Sakhamuri wrote: > > I want to confirm the correct work flow for detaching a volume, Both nova > > and cinder (unpublished, available through cinder.volumes.detach) > provides > > detach vo

Re: [openstack-dev] [Cinder] [nova] Work flow for detaching a volume

On Fri, Feb 26, 2016 at 06:11:15PM +, Srinivas Sakhamuri wrote: > I want to confirm the correct work flow for detaching a volume, Both nova > and cinder (unpublished, available through cinder.volumes.detach) provides > detach volume API. Only nova seems to have correct work flow in terms of > d

[openstack-dev] [Cinder] [nova] Work flow for detaching a volume

I want to confirm the correct work flow for detaching a volume, Both nova and cinder (unpublished, available through cinder.volumes.detach) provides detach volume API. Only nova seems to have correct work flow in terms of detaching a volume i.e. 1) detaches the volume from the VM (libvirt.volum

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/20/2016 12:38 AM, Morgan Fainberg wrote: > AS a point we are also trying to drop "versioned endpoints" as a thing > from the catalog going forward. Please do not add a "cinderv3" or > "volumev3" entry to the catalog. This is something that enourages adding > for every version a new endpoint.

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/22/2016 10:22 PM, Sean McGinnis wrote: > On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote: >> >> I'd vote for the extra round trip and implementation of caching whenever >> possible. Using another endpoint is really annoying, I already have >> specific stuff for cinder to setup

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/20/2016 02:42 PM, Duncan Thomas wrote: On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote: > Not that I'm adding much to this conversation that hasn't been said already, but I am pro v2 API, purely because of how painful and long it's been to get the off

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 2/22/16, 9:33 AM, "Sean McGinnis" wrote: >On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote: >> >> So we can't get users to change endpoints, or write our libraries to >>have >> sensible defaults, but we're somehow going to magically get consumers >>to do >> the much harder job

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote: > > So we can't get users to change endpoints, or write our libraries to have > sensible defaults, but we're somehow going to magically get consumers to do > the much harder job of doing version probes in their code/libraries so that >

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote: > > I'd vote for the extra round trip and implementation of caching whenever > possible. Using another endpoint is really annoying, I already have > specific stuff for cinder to setup both v1 and v2 endpoint, as v2 > doesn't fully imp

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/21/2016 12:59 PM, Duncan Thomas wrote: > On 21 February 2016 at 19:34, Jay S. Bryant > mailto:jsbry...@electronicjungle.net>> > wrote: > > Spent some time talking to Sean about this on Friday afternoon and > bounced back and forth between the two options. At first, /v3 made > th

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 22 February 2016 at 06:40, Thomas Goirand wrote: > > I'd vote for the extra round trip and implementation of caching whenever > possible. Using another endpoint is really annoying, I already have > specific stuff for cinder to setup both v1 and v2 endpoint, as v2 > doesn't fully implements wha

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/18/2016 11:38 PM, D'Angelo, Scott wrote: > Cinder team is proposing to add support for API microversions [1]. It came up > at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on > IRC have raised questions about this [3] > > Please weigh in on the design decision to add

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

: Walter A. Boring IV [mailto:walter.bor...@hpe.com] Sent: Friday, February 19, 2016 4:18 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions >> But, there are no such clients today. And there is no library that &

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 21 February 2016 at 19:34, Jay S. Bryant wrote: > Spent some time talking to Sean about this on Friday afternoon and bounced > back and forth between the two options. At first, /v3 made the most sense > to me ... at least it did at the meetup. With people like Sean Dague and > Morgan Fainber

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/20/2016 04:42 PM, Duncan Thomas wrote: On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote: > Not that I'm adding much to this conversation that hasn't been said already, but I am pro v2 API, purely because of how painful and long it's been to get the o

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 20 Feb 2016 00:21, "Walter A. Boring IV" wrote: > Not that I'm adding much to this conversation that hasn't been said already, but I am pro v2 API, purely because of how painful and long it's been to get the official OpenStack projects to adopt the v2 API from v1. I think there's a slightly d

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

But, there are no such clients today. And there is no library that does this yet. It will be 4 - 6 months (or even more likely 12+) until that's in the ecosystem. Which is why adding the header validation to existing v2 API, and backporting to liberty / kilo, will provide really substantial cove

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 11:24 AM, Sean Dague wrote: On 02/19/2016 11:15 AM, Ben Swartzlander wrote: On 02/19/2016 10:57 AM, Sean Dague wrote: On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: Cinder team is proposing to add support for API microversions [1]. It came up at our mid-cycle that we should add a

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 11:28:09AM -0500, Sean Dague wrote: > On 02/19/2016 11:20 AM, Sean McGinnis wrote: > > On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote: > >> The concern as I understand it is that by extending the v2 API with > >> microversions the following failure scenario exist

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 8:24 AM, Sean Dague wrote: > On 02/19/2016 11:15 AM, Ben Swartzlander wrote: > > On 02/19/2016 10:57 AM, Sean Dague wrote: > >> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: > >>> Cinder team is proposing to add support for API microversions [1]. It > >>> came up at our m

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 11:20 AM, Sean McGinnis wrote: > On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote: >> The concern as I understand it is that by extending the v2 API with >> microversions the following failure scenario exists >> >> If: >> >> 1) a client already is using the /v2 API >> 2) a c

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