Re: [openstack-dev] [manila] propose adding gouthamr to manila core

+1000 On Wed, Nov 2, 2016 at 1:09 PM, Tom Barron wrote: > I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the > manila core team. This is a clear case where he's already been doing > the review work, excelling both qualitatively and quantitatively, as >

Re: [openstack-dev] [openstack-operators][cinder] max_concurrent_builds in Cinder

This sounds like a good idea to me. The queue doesn't handle this since we just read everything off immediately anyways. I have seen issues where customers have to write scripts that build 5 volumes, sleep, then build more until they get >100 volumes. Just because a Cinder volume service will

Re: [openstack-dev] [Cinder] Nominating Michał Dulko to Cinder Core

+1 I thought he was already! which is usually a good sign. On Thu, May 5, 2016 at 1:39 PM, Mike Perez wrote: > On 13:16 May 03, Sean McGinnis wrote: > > Hey everyone, > > > > I would like to nominate Michał Dulko to the Cinder core team. Michał's > > contributions with both

Re: [openstack-dev] [api] service type vs. project name for use in headers

I'd like an answer on this specific issue. I agree with Chris and I wonder if our goal is consistency across services or an ideal standard. Nova has 'X-OpenStack-Nova-API-Version' and Manila has 'X-Openstack-Manila-Api-Version'. If we deviate from this, we should suggest that those projects add

Re: [openstack-dev] [Glance] glance core rotation part 1

from glance-core based on > > the simple criterion of inactivity/limited activity for a long period (2 > > cycles or more) of time: > > > > Alex Meade > > Arnaud Legendre > > Mark Washenberger > > Iccha Sethi > > I think these are overdue > > >

Re: [openstack-dev] [nova][manila] latest microversion considered dangerous

I don't know if this is really a big problem. IMO, even with microversions you shouldn't be implementing things that aren't backwards compatible within the major version. I thought the benefit of microversions is to know if a given feature exists within the major version you are using. I would

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

Hi Chen Li, You are correct in that setting up a CI system is not a trivial task. IMO it would make sense to have this eventually tested with infras infrastructure but as Jeremy mentioned, they don't have the bandwidth to do the setup. Below are some links to get started if you all are interested

Re: [openstack-dev] [cinder] Rebranded Volume Drivers

Agreed, I'd also like to mention that rebranded arrays may differ slightly in functionality as well so the CIs would need to run against a physical rebranded device. These differences also justify the need for letting rebranded drivers in. -Alex On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

There is a spec to get this work started. It's currently a Heat spec: https://review.openstack.org/#/c/186436/ That spec is for defining a basic schema to start with. -Alex On Mon, Jun 1, 2015 at 4:48 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/15 16:48 +0100, Gordon Sim wrote: On

[openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

It appears that the release of taskflow 0.10.0 exposed an issue in the NetApp NFS drivers. Something changed that caused the sqlalchemy Volume object to be garbage collected even though it is passed into create_volume() An example error can be found in the c-vol logs here:

Re: [openstack-dev] [cinder] Taskflow 0.10.0 incompatible with NetApp NFS drivers

So it seems that this will break a number of drivers, I see that glusterfs does the same thing. On Thu, May 7, 2015 at 10:29 PM, Alex Meade mr.alex.me...@gmail.com wrote: It appears that the release of taskflow 0.10.0 exposed an issue in the NetApp NFS drivers. Something changed that caused

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

Hey Erlon, The summit etherpad is here: https://etherpad.openstack.org/p/liberty-cinder-async-reporting It links to what we discussed in Paris. I will be filling it out this week. Also note, I have submitted this topic for a cross-project session:

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

I think there is a lot to discuss here and I would love to push for a solution implemented in Liberty. I have a proposed summit session on this topic (Asynchrounous Error Reporting). I also discussed this briefly at the Kilo summit. I will work on formalizing some of these ideas and hopefully we

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

We believe we have satisfied the required criteria [1] to have NetApp’s fibre channel drivers included in the Kilo release. We have submitted a revert patch [2] along with posting an ether pad [3] to provide more detail on our progress. Thanks for your consideration. [1]

Re: [openstack-dev] [Manila] Nominate Clinton Knight for core team

+1 On Thu, Apr 2, 2015 at 10:30 AM, Thomas Bechtold thomasbecht...@jpberlin.de wrote: On 02.04.2015 15:16, Ben Swartzlander wrote: Clinton Knight (cknight on IRC) has been working on OpenStack for the better part of the year, and starting in February, he shifted his focus from Cinder to

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

As an Engineer running the NetApp CI, I thought it would be a good time to chime in here. While I have many opinions around this whole process, I will try my best to avoid any judgement and minimize ratholes. Over the past year, we have implemented a scalable CI system that is now running tests

Re: [openstack-dev] [Glance] Recall for previous iscsi backend BP

Hey Henry/Folks, I think it could make sense for Glance to store the volume UUID, the idea is that no matter where an image is stored it should be *owned* by Glance and not deleted out from under it. But that is more of a single tenant vs multi tenant cinder store. It makes sense for Cinder to

[openstack-dev] [Cinder] Request for J3 FFE - NetApp: storage pools for scheduler

tested against our storage controllers and are not very complex. I would appreciate any consideration for an FFE. Thanks, -Alex Meade [1] https://blueprints.launchpad.net/cinder/+spec/pool-aware-cinder-scheduler-support-in-netapp-drivers [2] https://review.openstack.org/#/c/119436/ [3] https

Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core

+100 it's about time! On Thu, Jun 12, 2014 at 3:26 AM, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks, I'd like to nominate Nikhil Komawar to join glance-core. His code and review contributions over the past years have been very helpful and he's been taking on a very

[openstack-dev] [manila] Access Groups API and DB changes

Hey Folks, The blueprint for Access Groups can be found here: https://blueprints.launchpad.net/manila/+spec/access-groups If you have a chance, please look through the proposal for the API resources and DB schema changes here: https://etherpad.openstack.org/p/manila-access-groups-api-proposal

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

Glance has the concept of 'protected properties' which is really just policies around metadata. property = metadata in glance. https://wiki.openstack.org/wiki/Glance-property-protections -Alex On Tue, May 6, 2014 at 6:50 AM, Duncan Thomas duncan.tho...@gmail.comwrote: 'metadata' is a free

Re: [openstack-dev] [Nova][Cinder] Feature about volume delete protection

Just so everyone is aware. Glance supports 'delayed deletes' where image data will not actually be deleted at the time of the request. Glance also has the concept of 'protected images', which allows for setting an image as protected, preventing it from being deleted until the image is

Re: [openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator

I think I agree with you John. Micromanaging the common library just makes more work. Is there any argument to not syncing everything? And do you mean cherry-picking only some of the changes in a single module?!? if that's the case then future syncing could get weird, really weird. -Alex

[openstack-dev] [glance] Action-Requested: In progress bugs/blueprints/abandoned patches

their abandoned patches and restore any that are still relevant. Use this link to see your abandoned patches, just replace alex-meade with your own launchpad id. https://review.openstack.org/#/q/status:abandoned+project:openstack/glance+owner:alex-meade,n,z Also, if you have any in progress bugs

Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing In Glance

I don't know any actual numbers but I would have the concern that images tend to stick around longer than instances. For example, if someone takes daily snapshots of their server and keeps them around for a long time, the number of exists events would go up and up. Just a thought, could be a

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

another -1 from me for dropping it from hacking. I've been bitten by both lack of explicit usage and review bikeshedding on this exact thing. -Alex -Original Message- From: Sean Dague s...@dague.net Sent: Tuesday, August 6, 2013 7:32am To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] Usage of mox through out the Openstack project.

+1 I prefer mock over mox as well. It's more readable and intuitive. I've had a number of bad mox experiences lately so I'm a tad biased. -Alex -Original Message- From: Jay Pipes jaypi...@gmail.com Sent: Wednesday, July 24, 2013 2:24pm To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] Usage of mox through out the Openstack project.

+1 to everything Russell just said and of course Blueprints for this. One for #3 (changing from mox - Mock) would be good so that anyone who is bored or finds this urgent can collaborate. Also, we need to make sure reviewers are aware (Hopefully they are reading this). -Alex -Original