[openstack-dev] [cinder][manila] PLEASE READ: Change of location for dinner ...

Team, The dinner has had to change locations.  Dicke Wirtin didn't get my online reservation and they are full. NEW LOCATION: Joe's Restaurant and Wirsthaus -- Theodor-Heuss-Platz 10, 14052 Berlin The time is still 8 pm. Please pass the word on! Jay

Re: [openstack-dev] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...

Ivan, Yeah, I saw that was the case but it seems like there is not a point in time where there isn't a conflict.  Need to get some food at some point so anyone who wants to join can, and then we can head to the party if people want. Jay On 11/10/2018 8:07 AM, Ivan Kolodyazhny wrote:

[openstack-dev] [cinder] No meeting this week ...

Team, Just a friendly reminder that we will not have our weekly meeting this week due to the OpenStack Summit. Hope to see some of you here.  Otherwise, talk to you next week! Thanks, Jay __ OpenStack Development

Re: [openstack-dev] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...

Thanks for organizing this, Jay, Just in case if you missed it, Matrix Party hosted by Trilio + Red Hat will be on Tuesday too. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Nov 8, 2018 at 12:43 AM Jay S Bryant wrote: > All, > > I am working on scheduling a dinner for the Cinder

[openstack-dev] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...

All, I am working on scheduling a dinner for the Cinder team (and our extended family that work on and around Cinder) during the Summit in Berlin.  I have created an etherpad for people to RSVP for dinner [1]. It seemed like Tuesday night after the Marketplace Mixer was the best time for

Re: [openstack-dev] [cinder] about use nfs driver to backup the volume snapshot

arney"; Date: Fri, Nov 2, 2018 10:00 PM To: "jsbryant"; "OpenStack Developmen"; Subject: Re: [openstack-dev] [cinder] about use nfs driver to backup the volume snapshot On 11/1/18 4:44 PM, Jay Bryant wrote: > On Thu, Nov 1, 2018, 10:44 AM Rambo wrote: > &

Re: [openstack-dev] [cinder] about use nfs driver to backup the volume snapshot

On 11/1/18 4:44 PM, Jay Bryant wrote: On Thu, Nov 1, 2018, 10:44 AM Rambo wrote: Hi,all Recently, I use the nfs driver as the cinder-backup backend, when I use it to backup the volume snapshot, the result is return the NotImplementedError[1].And the nfs.py doesn't has the

Re: [openstack-dev] [cinder] about use nfs driver to backup the volume snapshot

On Thu, Nov 1, 2018, 10:44 AM Rambo wrote: > Hi,all > > Recently, I use the nfs driver as the cinder-backup backend, when I > use it to backup the volume snapshot, the result is return the > NotImplementedError[1].And the nfs.py doesn't has the > create_volume_from_snapshot function. Does

[openstack-dev] [cinder] about use nfs driver to backup the volume snapshot

Hi,all Recently, I use the nfs driver as the cinder-backup backend, when I use it to backup the volume snapshot, the result is return the NotImplementedError[1].And the nfs.py doesn't has the create_volume_from_snapshot function. Does the community plan to achieve it which is as nfs as

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Great, Jon. Thanks for your reply. I am looking forward to your report. Cheers, Boxiang On 10/23/2018 22:01，Jon Bernard wrote： * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Tue, 23 Oct 2018 10:01:42 -0400, Jon Bernard wrote: * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host

[openstack-dev] [cinder][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Cinder team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On 10/23/2018 9:01 AM, Jon Bernard wrote: * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

* melanie witt wrote: > On Fri, 19 Oct 2018 23:21:01 +0800 (GMT+08:00), Boxiang Zhu wrote: > > > > The version of my cinder and nova is Rocky. The scope of the cinder spec[1] > > is only for available volume migration between two pools from the same > > ceph cluster. > > If the volume is in-use

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

* melanie witt wrote: > On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: > > I created a new vm and a new volume with type 'ceph'[So that the volume > > will be created on one of two hosts. I assume that the volume created on > > host dev@rbd-1#ceph this time]. Next step is to

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host dev@rbd-1#ceph this time]. Next step is to attach the volume to the vm. At

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Jay and Melanie, It's my fault to let you misunderstand the problem. I should describe my problem more clearly. My problem is not to migrate volumes between two ceph clusters. I have two clusters, one is openstack cluster(allinone env, hostname is dev) and another is ceph cluster. Omit the

Re: [openstack-dev] [cinder]ceph rbd replication group support

I would reach out to Lisa Li (lixiaoy1) on Cinder to see if this is something they may pick back up.  She has been more active in the community lately and may be able to look at this again or at least have good guidance for you. Thanks! Jay On 10/19/2018 1:14 AM, 王俊 wrote: Hi: I have a

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Boxiang, I have not herd any discussion of extending this functionality for Ceph to work between different Ceph Clusters.  I wasn't aware, however, that the existing spec was limited to one Ceph cluster. So, that is good to know. I would recommend reaching out to Jon Bernard or Eric Harney

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Fri, 19 Oct 2018 23:21:01 +0800 (GMT+08:00), Boxiang Zhu wrote: The version of my cinder and nova is Rocky. The scope of the cinder spec[1] is only for available volume migration between two pools from the same ceph cluster. If the volume is in-use status[2], it will call the generic

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Hi melanie, thanks for your reply. The version of my cinder and nova is Rocky. The scope of the cinder spec[1] is only for available volume migration between two pools from the same ceph cluster. If the volume is in-use status[2], it will call the generic migration function. So that as you

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Fri, 19 Oct 2018 11:33:52 +0800 (GMT+08:00), Boxiang Zhu wrote: When I use the LVM backend to create the volume, then attach it to a vm. I can migrate the volume(in-use) from one host to another. The nova libvirt will call the 'rebase' to finish it. But if using ceph backend, it raises

[openstack-dev] [cinder]ceph rbd replication group support

Hi: I have a question about rbd replication group, I want to know the plan or roadmap about it? Anybody work on it? Blueprint: https://blueprints.launchpad.net/cinder/+spec/ceph-rbd-replication-group-support Thanks 保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！

[openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Hi folks, When I use the LVM backend to create the volume, then attach it to a vm. I can migrate the volume(in-use) from one host to another. The nova libvirt will call the 'rebase' to finish it. But if using ceph backend, it raises exception 'Swap only supports host devices'. So now it

[openstack-dev] [cinder][swift] FOSDEM Call for Participation: Software Defined Storage devroom

CfP for the Software Defined Storage devroom at FOSDEM 2019 (Brussels, Belgium, February 3rd). FOSDEM is a free software event that offers open source communities a place to meet, share ideas and collaborate. It is renown for being highly developer- oriented and brings together 8000+ participants

Re: [openstack-dev] [cinder][qa] Enabling online volume_extend tests by default

Hi Ghanshyam, Though I have concern over running those tests by default(making config > options True by default), because it is not confirmed all cinder backends > implements this functionality and it only works for nova libvirt driver. We > need to keep config options default as False and

Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

On 10/8/2018 8:54 AM, Sean McGinnis wrote: On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote: In Denver, we agree to add a new "re-image" API in cinder to support upport volume-backed server rebuild with a new image. An initial blueprint has been drafted in [3], welcome to review

Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

On 10/9/2018 8:04 AM, Erlon Cruz wrote: If you are planning to re-image an image on a bootable volume then yes you should use a force parameter. I have lost the discussion about this on PTG. What is the main use cases? This seems to me something that could be leveraged with the current

Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

If you are planning to re-image an image on a bootable volume then yes you should use a force parameter. I have lost the discussion about this on PTG. What is the main use cases? This seems to me something that could be leveraged with the current revert-to-snapshot API, which would be even better.

Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote: > In Denver, we agree to add a new "re-image" API in cinder to support upport > volume-backed server rebuild with a new image. > > An initial blueprint has been drafted in [3], welcome to review it, thanks. > : ) > > [snip] > > The

[openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

In Denver, we agree to add a new "re-image" API in cinder to support upport volume-backed server rebuild with a new image. An initial blueprint has been drafted in [3], welcome to review it, thanks. : ) The API is very simple, something like: URL: POST

Re: [openstack-dev] [cinder][qa] Enabling online volume_extend tests by default

On Sat, 06 Oct 2018 01:42:11 +0900 Erlon Cruz wrote > Hey folks, > Following up on the discussions that we had on the Denver PTG, the Cinder > teamis planning to enable online volume_extend tests[1] to be run by > default. Currently,those tests are only run by some CI systems

[openstack-dev] [cinder][qa] Enabling online volume_extend tests by default

Hey folks, Following up on the discussions that we had on the Denver PTG, the Cinder team is planning to enable online volume_extend tests[1] to be run by default. Currently, those tests are only run by some CI systems and infra jobs that explicitly set it to be so. We are also adding a negative

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

On 10/3/2018 9:45 AM, Jay S. Bryant wrote: Team, We had discussed the possibility of adding Gorka to the stable core team during the PTG.  He does review a number of our backport patches and is active in that area. If there are no objections in the next week I will add him to the list.

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

On Wed, Oct 03, 2018 at 09:45:25AM -0500, Jay S. Bryant wrote: > Team, > > We had discussed the possibility of adding Gorka to the stable core team > during the PTG.  He does review a number of our backport patches and is > active in that area. > > If there are no objections in the next week I

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

+1 from me to Gorka! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Oct 3, 2018 at 5:47 PM Jay S. Bryant wrote: > Team, > > We had discussed the possibility of adding Gorka to the stable core team > during the PTG. He does review a number of our backport patches and is > active

[openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

Team, We had discussed the possibility of adding Gorka to the stable core team during the PTG.  He does review a number of our backport patches and is active in that area. If there are no objections in the next week I will add him to the list. Thanks! Jay (jungleboyj)

[openstack-dev] [cinder] Follow-up on core team changes ...

Team, I wanted to follow up on the note I sent a week or so ago about changes to the Core team.  I talked to Winston-D (Huang Zhiteng) and it sounded like he would not be able to take a more active role.  There were no other objections so I am removing him from the Core list. John Griffith

Re: [openstack-dev] [cinder][puppet][kolla][helm][ansible] Change in Cinder backup driver naming

Thanks Sean! I did a quick sanity check on the backup part in the puppet-cinder module and there is no opinionated default value there which needs to be changed. Best regards On 09/27/2018 08:37 PM, Sean McGinnis wrote: This probably applies to all deployment tools, so hopefully this

Re: [openstack-dev] [cinder][puppet][kolla][helm][ansible] Change in Cinder backup driver naming

Thanks for the email Sean. https://review.openstack.org/605846 Fix Cinder backup to use full paths I think this should cover us, please let me know if we did things right. FYI: the docs all still seem to point at the old paths..

[openstack-dev] [cinder][puppet][kolla][helm][ansible] Change in Cinder backup driver naming

This probably applies to all deployment tools, so hopefully this reaches the right folks. In Havana, Cinder deprecated the use of specifying the module for configuring backup drivers. Patch https://review.openstack.org/#/c/595372/ finally removed the backwards compatibility handling for configs

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

For those who may be following along and are not familiar with what we mean by federated auto-provisioning [0]. [0] https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#auto-provisioning On Wed, Sep 26, 2018 at 9:06 AM Morgan Fainberg wrote: > This

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

Hey Colleen, >This sounds like it is based on the customizations done at Oath, which to my recollection did not use the actual federation implementation in keystone due to its reliance on Athenz (I think?) as an identity manager. Something similar can be accomplished in standard keystone with the

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

hi, thanks for sharing this! At TripleO we're looking at implementing in Stein deployment of at least 1 regional DC and N edge zones. More comments below. On 9/25/18 11:21 AM, Ildiko Vancsa wrote: > Hi, > > Hereby I would like to give you a short summary on the discussions that happened at the

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

This discussion was also not about user assigned IDs, but predictable IDs with the auto provisioning. We still want it to be something keystone controls (locally). It might be hash domain ID and value from assertion ( similar.to the LDAP user ID generator). As long as within an environment, the

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

On 09/26/2018 05:10 AM, Colleen Murphy wrote: Thanks for the summary, Ildiko. I have some questions inline. On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote: We agreed to prefer federation for Keystone and came up with two work items to cover missing functionality: * Keystone to

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

Thanks for the summary, Ildiko. I have some questions inline. On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote: > > We agreed to prefer federation for Keystone and came up with two work > items to cover missing functionality: > > * Keystone to trust a token from an ID Provider master

[openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

Hi, Hereby I would like to give you a short summary on the discussions that happened at the PTG in the area of edge. The Edge Computing Group sessions took place on Tuesday where our main activity was to draw an overall architecture diagram to capture the basic setup and requirements of edge

[openstack-dev] [cinder][forum] Need Topics for Berlin Forum ...

Team, Just a reminder that we have an etherpad to plan topics for the Forum in Berlin [1].  We are short on topics right now so please take some time to think about what we should talk about.  I am also planning time for this discussion during our Wednesday meeting this week. Thanks for

[openstack-dev] [cinder] Mid-Cycle Planning ...

Team, As we discussed at the PTG I have started an etherpad to do some planning for a possible Cinder Mid-cycle meeting.  Please check out the etherpad [1] and leave your input. Thanks! Jay [1] https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

On 9/21/2018 12:06 PM, John Griffith wrote: On Fri, Sep 21, 2018 at 11:00 AM Sean McGinnis > wrote: On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote: > All, > > In the last year we have had some changes to Core team

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

On Fri, Sep 21, 2018 at 11:00 AM Sean McGinnis wrote: > On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote: > > All, > > > > In the last year we have had some changes to Core team participation. > This > > was a topic of discussion at the PTG in Denver last week. Based on that > >

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote: > All, > > In the last year we have had some changes to Core team participation.  This > was a topic of discussion at the PTG in Denver last week.  Based on that > discussion I have reached out to John Griffith and Winston D (Huang

[openstack-dev] [cinder] Proposed Changes to the Core Team ...

All, In the last year we have had some changes to Core team participation.  This was a topic of discussion at the PTG in Denver last week.  Based on that discussion I have reached out to John Griffith and Winston D (Huang Zhiteng) and asked if they felt they could continue to be a part of the

Re: [openstack-dev] [cinder] Berlin Forum Proposals

On 19/09, Jay S Bryant wrote: > Gorka, > > Oh man!  Sorry for the duplication.  I will update the link on the Forum > page if you are able to move your content over.  Think it will confused > people less if we use the page I most recently sent out.  Does that make > sense? > Hi Jay, Yup, it makes

Re: [openstack-dev] [cinder] Berlin Forum Proposals

Gorka, Oh man!  Sorry for the duplication.  I will update the link on the Forum page if you are able to move your content over.  Think it will confused people less if we use the page I most recently sent out.  Does that make sense? Thanks for catching this mistake! Jay On 9/19/2018 4:42

Re: [openstack-dev] [cinder] Berlin Forum Proposals

On 18/09, Jay S Bryant wrote: > Team, > > I have created an etherpad for our Forum Topic Planning: > https://etherpad.openstack.org/p/cinder-berlin-forum-proposals > > Please add your ideas to the etherpad.  Thank you! > > Jay > Hi Jay, After our last IRC meeting, a couple of weeks ago, I

[openstack-dev] [cinder] Berlin Forum Proposals

Team, I have created an etherpad for our Forum Topic Planning: https://etherpad.openstack.org/p/cinder-berlin-forum-proposals Please add your ideas to the etherpad.  Thank you! Jay __ OpenStack Development Mailing List

Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

On Mon, Sep 17, 2018, at 8:53 AM, Jay S Bryant wrote: > > > On 9/17/2018 10:46 AM, Sean McGinnis wrote: > >>> Plan > >>> > >>> We would now like to have the driverfixes/ocata branch deleted so there > >>> is no > >>> confusion about where backports should go and we don't accidentally get

Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

On 9/17/2018 10:46 AM, Sean McGinnis wrote: Plan We would now like to have the driverfixes/ocata branch deleted so there is no confusion about where backports should go and we don't accidentally get these out of sync again. Infra team, please delete this branch or let me know if there is

Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

> > > > Plan > > > > We would now like to have the driverfixes/ocata branch deleted so there is > > no > > confusion about where backports should go and we don't accidentally get > > these > > out of sync again. > > > > Infra team, please delete this branch or let me know if there is a

Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

On Mon, Sep 17, 2018, at 8:00 AM, Sean McGinnis wrote: > Hello Cinder and Infra teams. Cinder needs some help from infra or some > pointers on how to proceed. > > tl;dr - The openstack/cinder repo had a driverfixes/ocata branch created for > fixes that no longer met the more restrictive phase II

[openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

Hello Cinder and Infra teams. Cinder needs some help from infra or some pointers on how to proceed. tl;dr - The openstack/cinder repo had a driverfixes/ocata branch created for fixes that no longer met the more restrictive phase II stable policy criteria. Extended maintenance has changed that and

[openstack-dev] [cinder][ptg] Team Photos Posted ...

Team, Wanted to share the team photos from the PTG.  You can get them here: https://www.dropbox.com/sh/2pmvfkstudih2wf/AADynEnPDJiWIOE2nwjzBgtla/Cinder?dl=0_nav_tracking=1 Jay __ OpenStack Development Mailing List (not

Re: [openstack-dev] [cinder][ptg] Topics scheduled for next week ...

On 07/09, Jay S Bryant wrote: > Team, > > I have created an etherpad for each of the days of the PTG and split out the > proposed topics from the planning etherpad into the individual days for > discussion: [1] [2] [3] > > If you want to add an additional topic please add it to Friday or find some

[openstack-dev] [cinder][ptg] Topics scheduled for next week ...

Team, I have created an etherpad for each of the days of the PTG and split out the proposed topics from the planning etherpad into the individual days for discussion: [1] [2] [3] If you want to add an additional topic please add it to Friday or find some time on one of the other days. I

[openstack-dev] [cinder][placement] Room Scheduled for Cinder Placement Discussion ...

All, The results of the Doodle poll suggested that the end of the day Tuesday was the best option for us all to get together. [1] I have scheduled the Big Thompson Room on Tuesday from 15:15 to 17:00. I hope we can all get together there and then to have a good discussion. Thanks! Jay [1]

[openstack-dev] [cinder][nova][placement] Doodle Calendar Created for Placement Discussion

All, We discussed in our weekly meeting yesterday that it might be good to plan an additional meeting at the PTG to continue discussions with regards to Cinder's use of the Placement Service. I have looked at the room schedule [1] and there are quite a few open rooms on Monday.  Fewer rooms

[openstack-dev] cinder 13.0.0.0rc3 (rocky)

Hello everyone, A new release candidate for cinder for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

[openstack-dev] cinder 13.0.0.0rc2 (rocky)

Hello everyone, A new release candidate for cinder for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

[openstack-dev] [cinder][manila] Team Dinner Planning at PTG...

All, We talked in the Cinder team meeting about doing a joint Cinder/Manila team dinner at the PTG in Denver. I have created a Doodle Poll to indicate what night would work best for everyone. [1]  Also, if you are planning to come please add your name in the Cinder Etherpad [2]. Look

Re: [openstack-dev] [Cinder] How to mount NFS volume?

Hi Clay, Unfortunately, local-attach doesn't support NFS-based volumes due to the security reasons. We haven't the good solution now for multi-tenant environments. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Aug 17, 2018 at 12:03 PM, Chang, Clay (HPS OE-Linux TDC) < cl...@hpe.com>

[openstack-dev] [Cinder] How to mount NFS volume?

Hi, I have Cinder configured with NFS backend. On one bare metal node, I can use 'cinder create' to create the volume with specified size - I saw a volume file create on the NFS server, so I suppose the NFS was configured correctly. My question is, how could I mount the NFS volume on the bare

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

Okay, thanks. There's no Sigyn in openstack-oslo so I think we're good. :-) On 08/14/2018 10:37 AM, Jay S Bryant wrote: Ben, Don't fully understand why it was kicking me.  I guess one of the behaviors that is considered suspicious is trying to message a bunch of nicks at once.  I had tried

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

That bot is indeed missing from the channel Amy (spotz) On Mon, Aug 13, 2018 at 5:44 PM, Jeremy Stanley wrote: > On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote: > > I know we did a ping last week in #openstack-ansible for our meeting no > > issue. I wonder if it's a length of names

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

On 8/13/2018 5:44 PM, Jeremy Stanley wrote: On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote: I know we did a ping last week in #openstack-ansible for our meeting no issue. I wonder if it's a length of names thing or a channel setting. [...] Freenode's Sigyn bot may not have been

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

Ben, Don't fully understand why it was kicking me.  I guess one of the behaviors that is considered suspicious is trying to message a bunch of nicks at once.  I had tried reducing the number of people in my ping but it still kicked me and so I decided to not risk it again. Sounds like the

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote: > I know we did a ping last week in #openstack-ansible for our meeting no > issue. I wonder if it's a length of names thing or a channel setting. [...] Freenode's Sigyn bot may not have been invited to #openstack-ansible. We might want to

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

I know we did a ping last week in #openstack-ansible for our meeting no issue. I wonder if it's a length of names thing or a channel setting. Amy (spotz) On Mon, Aug 13, 2018 at 4:25 PM, Eric Fried wrote: > Are you talking about the nastygram from "Sigyn" saying: > > "Your actions in # tripped

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

Are you talking about the nastygram from "Sigyn" saying: "Your actions in # tripped automated anti-spam measures (nicks/hilight spam), but were ignored based on your time in channel; stop now, or automated action will still be taken. If you have any questions, please don't hesitate to contact a

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

On 08/08/2018 12:04 PM, Jay S Bryant wrote: Team, A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 UTC.  I bring this up as I can no longer send the courtesy pings without being kicked from IRC.  So, if you wish to join the meeting please add a reminder to your

[openstack-dev] cinder 13.0.0.0rc1 (rocky)

Hello everyone, A new release candidate for cinder for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

On Wed, Aug 08, 2018 at 05:15:26PM +, Sean McGinnis wrote: > On Tue, Aug 07, 2018 at 05:27:06PM -0500, Monty Taylor wrote: > > On 08/07/2018 05:03 PM, Akihiro Motoki wrote: > > >Hi Cinder and API-SIG folks, > > > > > >During reviewing a horizon bug [0], I noticed the behavior of Cinder API > >

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

On Tue, Aug 07, 2018 at 05:27:06PM -0500, Monty Taylor wrote: > On 08/07/2018 05:03 PM, Akihiro Motoki wrote: > >Hi Cinder and API-SIG folks, > > > >During reviewing a horizon bug [0], I noticed the behavior of Cinder API > >3.0 was changed. > >Cinder introduced more strict schema validation for

[openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

Team, A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 UTC.  I bring this up as I can no longer send the courtesy pings without being kicked from IRC.  So, if you wish to join the meeting please add a reminder to your calendar of choice. Thank you! Jay

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

> > > > > > Previously, Cinder API like 3.0 accepts unused fields in POST requests > > > but after [1] landed unused fields are now rejected even when Cinder API > > > 3.0 is used. > > > In my understanding on the microversioning, the existing behavior for > > > older versions should be

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

On Wed, 08 Aug 2018 07:27:06 +0900 Monty Taylor wrote > On 08/07/2018 05:03 PM, Akihiro Motoki wrote: > > Hi Cinder and API-SIG folks, > > > > During reviewing a horizon bug [0], I noticed the behavior of Cinder API > > 3.0 was changed. > > Cinder introduced more strict

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

On 08/07/2018 05:03 PM, Akihiro Motoki wrote: Hi Cinder and API-SIG folks, During reviewing a horizon bug [0], I noticed the behavior of Cinder API 3.0 was changed. Cinder introduced more strict schema validation for creating/updating volume encryption type during Rocky and a new micro

[openstack-dev] [cinder][api] strict schema validation and microversioning

Hi Cinder and API-SIG folks, During reviewing a horizon bug [0], I noticed the behavior of Cinder API 3.0 was changed. Cinder introduced more strict schema validation for creating/updating volume encryption type during Rocky and a new micro version 3.53 was introduced[1]. Previously, Cinder API

Re: [openstack-dev] [cinder] about block device driver

On Fri, Jul 27, 2018 at 8:44 AM Matt Riedemann wrote: > On 7/16/2018 4:20 AM, Gorka Eguileor wrote: > > If I remember correctly the driver was deprecated because it had no > > maintainer or CI. In Cinder we require our drivers to have both, > > otherwise we can't guarantee that they actually

[openstack-dev] [cinder][nova] - Barbican w/Live Migration in DevStack Multinode

Hi OpenStack Community, I am having some issues with key management in a multinode devstack (from master branch 27th July '18) environment where Barbican is the configured key_manager. I have followed setup instructions from the following pages: *

Re: [openstack-dev] [cinder] about block device driver

On 7/16/2018 4:20 AM, Gorka Eguileor wrote: If I remember correctly the driver was deprecated because it had no maintainer or CI. In Cinder we require our drivers to have both, otherwise we can't guarantee that they actually work or that anyone will fix it if it gets broken. Would this really

Re: [openstack-dev] [cinder] about block device driver

On Tue, Jul 24, 2018 at 06:07:24PM +0800, Rambo wrote: > Hi,all > > > In the Cinder repository, I noticed that the BlockDeviceDriver driver is > being deprecated, and was eventually be removed with the Queens release. > > >

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On 20-07-18 08:10:37, Erlon Cruz wrote: > Nice, good to know. Thanks all for the feedback. We will fix that in our > drivers. FWIW Nova does not and AFAICT never has called os-force_detach. We previously used os-terminate_connection with v2 where the connector was optional. Even then we always

[openstack-dev] [cinder] about block device driver

Hi,all In the Cinder repository, I noticed that the BlockDeviceDriver driver is being deprecated, and was eventually be removed with the Queens release. https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/block_device.py However,I want to use it out of

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

Nice, good to know. Thanks all for the feedback. We will fix that in our drivers. @Walter, so, in this case, if Cinder has the connector, it should not need to call the driver passing a None object right? Erlon Em qua, 18 de jul de 2018 às 12:56, Walter Boring escreveu: > The whole purpose of

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

The whole purpose of this test is to simulate the case where Nova doesn't know where the vm is anymore, or may simply not exist, but we need to clean up the cinder side of things. That being said, with the new attach API, the connector is being saved in the cinder database for each volume

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On 17/07, Sean McGinnis wrote: > On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote: > > Hi Cinder and Nova folks, > > > > Working on some tests for our drivers, I stumbled upon this tempest test > > 'force_detach_volume' > > that is calling Cinder API passing a 'None' connector. At the

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote: > Hi Cinder and Nova folks, > > Working on some tests for our drivers, I stumbled upon this tempest test > 'force_detach_volume' > that is calling Cinder API passing a 'None' connector. At the time this was > added several CIs > went

[openstack-dev] [cinder][nova] Proper behavior for os-force_detach

Hi Cinder and Nova folks, Working on some tests for our drivers, I stumbled upon this tempest test 'force_detach_volume' that is calling Cinder API passing a 'None' connector. At the time this was added several CIs went down, and people started discussing whether this (accepting/sending a None

  1   2   3   4   5   6   7   8   9   10   >