Re: [openstack-dev] [openstack-community] Give cinder-backup more CPU resources

You can run many c-bak processes on one node, which will get fed round robin, so you should see fairly linear speedup in the many backups case until you run out of CPUs. Parallelising a single backup was something I attempted, but python makes it extremely difficult so there's no useful implementa

Re: [openstack-dev] Create a Volume type using OpenStack

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

Re: [openstack-dev] [cinder][nova] about re-image the volume

th OS-Brick using returned connection > information. > > So I agree, it's not a blockRebase operation, just a change in the > volume that is used. > > Regards, > Gorka. > > __ > OpenStack Deve

Re: [openstack-dev] [nova] New image backend: StorPool

n? Cinder supports a range of connectors, and there has never been any opposition in principle to supporting more. I suggest looking at the RDB support in cinder as an example of a strongly supported native attachment method. -- Duncan Thomas _

Re: [openstack-dev] Pros and Cons of face-to-face meetings

tc. It always feels like a very second-class position to me. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

Met with Jay, looking at alternatives On 2 Mar 2018 6:26 pm, "Duncan Thomas" wrote: > I'm in the pub now, and they are closing down > > On 2 Mar 2018 5:48 pm, "Jay S. Bryant" wrote: > >> Ivan, >> >> I sent another note but will also respon

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

I'm in the pub now, and they are closing down On 2 Mar 2018 5:48 pm, "Jay S. Bryant" wrote: > Ivan, > > I sent another note but will also respond in this thread. > > Yes, they will serve us tonight. It is a somewhat limited menu but I > stopped to look at it and it still looked good. > > Sidewa

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

So I guess my question here is why is being RESTful good? Sure it's (very, very loosely) a standard, but what are the actual advantages? Standards come and go, what we want most of all is a good quality, easy to use API. I'm not saying that going RESTful is wrong, but I don't see much discussion a

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

;> work in devops. If ceilometer >>> pollester can handle it. I think may be we should remove it? >>> >>> >>> >>> >>> >>> -- >>> 谦谦君子 >>> >>> __ >>> OpenSt

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

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

Re: [openstack-dev] [security] [api] Script injection issue

But the filtering requirements are going to be different for different front ends, and we can't hope to catch them all. Trying to do any filtering at the cinder/nova API level just provides a false sense of security - horizon and other UI *have* to get their escaping right. If you put incomplete fi

Re: [openstack-dev] [glance] Does glance_store swift driver support range requests ?

On 15 November 2017 at 11:15, Matt Keenan wrote: > On 13/11/17 22:51, Nikhil Komawar wrote: > > I think it will a rather hard problem to solve. As swift store can be > configured to store objects in different configurations. I guess the next > question would be, what is your underlying problem --

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

I'm not sure there's a general agreement about removing the fixed key manager code in future. It serves several purposes, testing being the most significant one, though it also covers some people's usecase from a security PoV too where something better might not be worth the complexity trade off. I

Re: [openstack-dev] [Cinder] Requirements for re-adding Gluster support

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

Re: [openstack-dev] [Cinder] Requirements for re-adding Gluster support

://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > 4. https://build.gluster.org/ > 5. https://ci.centos.org/view/Gluster/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: ope

Re: [openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

On 25 May 2017 12:33 pm, "Lee Yarwood" wrote: On 25-05-17 11:38:44, Duncan Thomas wrote: > On 25 May 2017 at 11:00, Lee Yarwood wrote: > > This has also reminded me that the plain (dm-crypt) format really needs > > to be deprecated this cycle. I posted to the dev and

Re: [openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

7;m going to move forward with deprecating this format > in os-brick this cycle. What is the reasoning for this? There are plenty of people using it, and you're going to break them going forward if you remo

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On 23 May 2017 4:51 am, "Matt Riedemann" wrote: Is this really something we are going to have to deny at least once per release? My God how is it that this is the #1 thing everyone for all time has always wanted Nova to do for them? Is it entirely unreasonable to turn the question around and

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

the answer is to put that logic in a new service, that talks to those four, and provides a nice simple API, while allowing the cinder, nova etc APIs to remove things like internal retries? -- Duncan Thomas __ OpenStack D

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

dard definitions is that your standards rarely match the next guy's standards, and since some of these are entirely irrelevant to many storage topologies, you're likely going to need an API to discover what is relevant to a specific system anyway. -- Duncan Thomas __

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On 5 May 2017 at 23:45, Chris Friesen wrote: > On 05/05/2017 02:04 PM, John Griffith wrote: >> I'd love some detail on this. What falls over? > It's been a while since I looked at it, but the main issue was that with LIO > as the iSCSI server there is no automatic traffic shaping/QoS between > g

Re: [openstack-dev] [cinder] Is Cinder still maintained?

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

Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

the problem. > > By the way, How about another way that we could import volume > size with float value? such as: 2.5G, 3.4G? > > Did community consider about it in the begin? > > > 2017-04-07 20:16 GMT+08:00 Duncan Thomas : >> >> Cinder will store the volume as 1G in

Re: [openstack-dev] [Cinder] Tags for volumes

> support the 1 and 2. > > Is there any suggestion that how Cinder can support them? > > > Thanks > Wangxiyuan > > 2017-04-08 8:49 GMT+08:00 Matt Riedemann : >> >> On 3/27/2017 9:59 AM, Duncan Thomas wrote: >>> >>> On 27 March 2017 at 14:20

Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

r usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas __ OpenStack Development Mailing

Re: [openstack-dev] [OpenStack-Dev][Cinder][Driver][Nimble] - Need Point of contact

epts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?

Re: [openstack-dev] [Cinder] Tags for volumes

;> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

On 9 Mar 2017 18:22, "Jay Pipes" wrote: > > On 03/09/2017 01:06 PM, Dmitry Tantsur wrote: >> >> On 03/09/2017 06:57 PM, Clint Byrum wrote: >>> >>> Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500: >> >> >>> >>> >>> Combine that with the lower cost and subsidized travel suppor

Re: [openstack-dev] [cinder] [nova] confusion on where nova_catalog_admin_info is used in cinder

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

Re: [openstack-dev] [cinder] Can I use lvm thin provisioning in mitaka?

t; in the cinder.conf file. > > Be aware that LVM thin provisioning will see a performance penalty the > first time you write to a given disk block in a volume, because it needs to > allocate a new block, zero it out, then write the new data to it. > > Chris > > > _____

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

's a pretty terrible secrets-as-a-service product at the moment. Fixing it is not trivial. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openst

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

To give a totally different prospective on why somebody might dislike Barbican (I'm one of those people). Note that I'm working from pretty hazy memories so I don't guarantee I've got everything spot on, and I am without a doubt giving a very one sided view. But hey, that's the side I happen to sit

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

On 12 December 2016 at 16:35, Ash wrote: > I tend to agree with you, Sean. Also, if there's a concern that some > project has changed its license, then just create a fork. In the case of > this previously GPL code, it will at least be re-distributable. In the end, > I just don't think this is a h

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

ft dependencies are absolutely a obstacle, and in some cases (like customers who want a fully offline/airgapped install) an insurmountable one. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubs

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

s personally bothered by the the parts that can't be freely redistributed, rather than free software per se, but that still leaves a large number of problem cases. Few people were willing to seriously consider pulling 1/3 of the cinder drivers out, and there was not AFAICT a firm conclusion.

Re: [openstack-dev] [cinder] drbdmanage is no more GPL2

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

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

rticular way for a specific version > of the Glance service software. > Cinder services can run N+-1 versions in a mixed manner, all talking to the same database, no conductor required. -- Duncan Thomas __ OpenStack Develo

Re: [openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -- Duncan Thomas __ OpenStack Devel

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

cuss it, how can we be there to influence that discussion? I've got to agree entirely here. I am mostly interested in cinder stuff, but I've interest and a stake in specific nova and glance topics... getting involved in those is going to be impossible without some sort of schedule

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

On 22 September 2016 at 00:23, John Griffith wrote: > > Yes, that is a sizeable chunk of the solution. The remaining components > are how to coordinate with Nova (compute nodes) and figuring out if we just > use c-vol as is, or if we come up with some form of a paired down agent. > Just using c-

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

On 20 September 2016 at 16:24, Nikita Konovalov wrote: > Hi, > > From Sahara (and Hadoop workload in general) use-case the reason we used > BDD was a complete absence of any overhead on compute resources > utilization. > > The results show that the LVM+Local target perform pretty close to BDD in

Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers performance tests results

gt;>> John​ >>> >>> >>> ____ >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack

Re: [openstack-dev] [cinder]tempest test case for force detach volume

Writing a sensible test for this api is rather tricky, since it is intended to clean up one very specific error condition, and has few guarantees about the state it leaves the system in. It is provided as a tool to allow the system administrator to clean up certain faults and situations without nee

Re: [openstack-dev] [cinder] moving driver to open source

On 13 September 2016 at 06:44, Ben Swartzlander wrote: > On 09/09/2016 11:12 AM, Duncan Thomas wrote: > >> I don't care so much whether your CLI or API proxy in open or closed >> source, but I really do care if I can create a distribution, even a >> novel one, with

Re: [openstack-dev] [cinder] moving driver to open source

On 9 September 2016 at 17:22, Ben Swartzlander wrote: On 09/08/2016 04:41 PM, Duncan Thomas wrote: > > Despite the fact I've appeared to be slightly disagreeing with John in >> the IRC discussion on this subject, you've summarised my concern very >> well. I'm

Re: [openstack-dev] [cinder] moving driver to open source

m. I'm not aware of any tools currently required by cinder where this is not the case, but a few of us are in the process of auditing this to make sure we understand the situation before we clarify our rules. -- Duncan Thomas _

Re: [openstack-dev] [cinder] [nova] API interaction changes overview

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

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

> also understood it? > > Thank you for the explanation. Some times it is best to state the apparently obvious just so that everybody is on the same page. There are some pieces in cinder that attempt to work around some of these limitations already, added with the recent H/A cinder-volume

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31 August 2016 at 18:54, Joshua Harlow wrote: > Duncan Thomas wrote: > >> On 31 August 2016 at 11:57, Bogdan Dobrelya > <mailto:bdobre...@mirantis.com>> wrote: >> >> I agree that RPC design pattern, as it is implemented now, is a major >> blo

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 31 August 2016 at 11:57, Bogdan Dobrelya wrote: > I agree that RPC design pattern, as it is implemented now, is a major > blocker for OpenStack in general. It requires a major redesign, > including handling of corner cases, on both sides, *especially* RPC call > clients. Or may be it just hav

Re: [openstack-dev] [tricircle]How to address TCs concerns in Tricircle big-tent application

meeting, please > reply the mail. > > > > Best Regards > > Chaoyi Huang ( joehuang ) > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.open

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

nal Message- > From: Walter A. Boring IV [mailto:walter.bor...@hpe.com] > Sent: Tuesday, August 09, 2016 12:34 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable > policy for drivers > > On 08/08/2016 02:28 PM, Ih

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

There's so much misinformation in that email I barely know where to start. There is nothing stopping out of tree drivers for cinder, and a few have existed, though they don't seem to stick around. The driver is just a python class referenced in the config file. Turning a removed driver into an ou

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

(e.g. a pip release), then finally you can merge the cinder change. To turn the question around, what is the downside of loosing the tag? Are people going to suddenly stop deploying cinder? That seems rather unlikely. Nobody has yet give

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

gh problems on that front already. As far as I can tell, we (the cinder team) are better off shrugging about the tags and carrying on as we are. On 12 Aug 2016 15:54, "Sean Dague" wrote: > On 08/12/2016 08:40 AM, Duncan Thomas wrote: > > On 12 Aug 2016 15:28, "Thierry Carre

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Is there some docs for it somewhere? Or some quick way of telling that we've done it and gotten it right? On 12 Aug 2016 08:17, "Andreas Jaeger" wrote: > On 08/12/2016 04:25 AM, Robert Collins wrote: > > On 11 Aug 2016 3:13 PM, "Ben Swartzlander" > > wrote: > >> >

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On 12 Aug 2016 15:28, "Thierry Carrez" wrote: > > Duncan Thomas wrote: > I agree that leaving broken drivers in tree is not significantly better > from an operational perspective. But I think the best operational > experience would be to have an idea of how much risk y

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

removed. > ​ > That is a great point, it was mentioned at one point but we sort of > conveniently swept it under the rug a bit. I certainly understand the > problem, I do think there's two sides to it. Frankly I also think it > points out that drivers really are *different* like it or not.​ So

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

'mitaka-drivers' branch of cinder > the > gate CI would rapidly degernate to a noop any unit/functional tests would > be > *entirely* 3rd party. > > Yours Tony. > > __ > Open

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

re of a disaster (for the consumers) than zero testing, zero review, scattered around the internet if-you're-lucky-with-a-good-wind you'll maybe get the right patch set? Because that's where we are right now, and vendors, distributors and the cinder core team are all sayi

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

place to analyse e.g. how a certain driver call is implemented across all the drivers, when reasoning or making changes to core code. Given we've identified a clear need, and have repeated rejected one solution (take drivers out of tree - it has been discussed at every summit and mid

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

+1 from me Sound like the best solution to at least part of the problem that was causing people to want to pull the drivers out of tree On 6 Aug 2016 18:49, "Philipp Marek" wrote: > > I want to propose > > we officially make a change to our stable policy to call out that > > drivers bugfixes (N

Re: [openstack-dev] [tc] persistently single-vendor projects

On 1 August 2016 at 18:14, Adrian Otto wrote: > I am struggling to understand why we would want to remove projects from > our big tent at all, as long as they are being actively developed under the > principles of "four opens". It seems to me that working to disqualify such > projects sends an al

Re: [openstack-dev] [Openstack] Listing of volume fails while using openstack client

Looks like either you've got an intermittent network problem or the cinder api service is restarting. Anything enlightening in the cinder-api log? On 28 Jul 2016 16:41, "varun bhatnagar" wrote: Hello Steve, Thanks a lot for such a quick response. Yes the IP is reachable. ping 10.33.237.104 PI

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On 20 July 2016 at 19:57, James Bottomley < james.bottom...@hansenpartnership.com> wrote: > > OK, I accept your analogy, even though I would view currency as the > will to create and push patches. > > The problem you describe: getting the recipients to listen and accept > your patches, is also a c

Re: [openstack-dev] [cinder]The backend-group concept in Cinder

bility = XYZ)) to distinguish > between the backend capability and the backend-group capability. > > 3.he/she can create volumes of a specific type(test_type) > > > __ > OpenStack Development Mailing List (not for usa

Re: [openstack-dev] Invitation to join Hangzhou Bug Smash

Hi I would, once again, love to attend. If you find that other cores apply and you'd rather have a new face, I would be very understanding of the situation. Regards -- Duncan Thomas On 13 June 2016 at 11:06, Wang, Shane wrote: > Hi, OpenStackers, > > As you know, Huawei,

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

ementations (i.e. the go one, maybe something ceph based, etc) to sit outside of the openstack umbrella. This is the model nearly every other openstack service has. -- Duncan Thomas __ OpenStack Development Mailin

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

load that means it is easier to get DB timeouts and other issues. As for delete being resource heavy, our reference driver provides a pathological example with the secure delete code. Now that we've got a high degree of confidence in the LVM thin code (specifically, I'm not aw

Re: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

oard.html#tabExpired > > -- > Regards, Markus Zoeller (markus_z) > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr

Re: [openstack-dev] More on the topic of DELIMITER, the Quota Management Library proposal

On 23 Apr 2016 14:26, "Jay Pipes" wrote: > On 04/23/2016 03:18 PM, Mike Perez wrote: >> How about extending a volume? A volume is a resource and can be extended in >> Cinder today. > > > Yep, understood :) I recognize some resource amounts can be modified for some resource classes. How about *sh

Re: [openstack-dev] [Cinder] API features discoverability

On 19 April 2016 at 23:42, Michał Dulko wrote: > On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > > Hi Michal, > > > > This seemed like a good idea when I first read it. What more, the server > code for extension listing [1] does not do any authorization, so it can be > used for any logged in

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

trivial users then I wouldn't have hesitated. Cross project specs are not getting massive amounts of detailed attention from project teams, end even they were it is not possible to foresee all subtle problems at review time - they should be taken as guidance not gospel and expect to be reworked i

Re: [openstack-dev] [Cinder] Newton Midcycle Planning

st (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -- Duncan Thomas __ OpenStack Devel

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

e > volume (at least the disk UUID will be the same). > > On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas > wrote: > >> You can't just change the contents of a volume under the instance though >> - at the very least you need to do an unmount in the instance, and a

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

o us? >>> >>> >>> >>>Thanks >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscri

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

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

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

r >> dtro...@gmail.com >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bi

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

he swap-volume functionality was added to > >> nova here [1]. The cinder use of it for volume migration was added here > >> [2]. > >> > >> Looking at the cinder volume API for migrate_volume_completion, it > >> expects the source (old) volume to have migration

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

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

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

ous volumes can always hit the API > directly with curl or whatever SDK. > > On Sun, Mar 27, 2016 at 4:44 PM, 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 actu

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

gt; Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -- Duncan Thomas __ OpenStack Development Mailing List (not for us

Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

t taking it as anything other than a PoC to be honest. Certainly it should not be cargo-culted into another project in its present state. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) U

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

ing that these tests should get closer scrutiny. This does not remove reviewer judgement from the equation, just provides a helpful prod that there's something to be considered. -- Duncan Thomas __ OpenStack Developm

Re: [openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

ssentially this is now in your combined hands to prioritise for > > mitaka as you deem appropriate. > > > > - Gus > > > > It seems too me that risks are higher than advantages. Moreover final > release for libraries like os.brick should happen in just 2 days and I > don't

Re: [openstack-dev] [all] A proposal to separate the design summit

es - the kind of thinking and communication needed often doesn't fit into slots and sessions, and really needs the bandwidth of face to face time. I now think the cinder mid-cycle is more valuable for many devs, and much cheaper, than the foundation events. I don't see t

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

n't fully implements what's in v1. BTW, where are we with this? Can > I fully get rid of the v1 endpoint, or will I still experience some > Tempest failures? > Can you detail what isn't in V2 that is in V1 please? I'm not aware of anything, and I'd consider a

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

icroversions - so we're changing a known working pattern, to try to avoid the problem of a user having to get their settings right if they want new functionality, and hoping this doesn't introduce entirely predictable and foreseeable bugs in the future that can't actually be

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] Announcing Ekko -- Scalable block-based backup for OpenStack

Actually, keeping track of changed blocks on cinder volumes would make the cinder incremental backup substantially more efficient... Something could push them into cinder at detach time, and an api call for cinder to pull them at live backup time, and cinder backup can do the rest... Not sure of th

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 now. How do you do

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

x27;s a dead simple format) and perhaps an import for the same. That would allow cinder backup and Ekko to exchange data where desired. I'm not sure if this is possible, but I'd certainly suggest looking at it. Thanks for keeping the dialog open, it has definitely been useful. -- D

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

or create a new one. Either way, the bulk data does not need to be touched. -- -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

. This isn't the > initial priority for Ekko though, but it is good information to have. Thank > you for your comments! > Always interested in better ways to solve backup. -- Duncan Thomas __ OpenStack Develo

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

kup (internally via a snapshot) merged last cycle. I can see a place for other backup solutions, I just want to make the existing ones clear. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) U

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 > exception from volume.rpcapi w

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 regularly on IRC helping answer

Re: [openstack-dev] [Nova][Cinder] Cleanly detaching volumes from failed nodes

That would be ideal but I don't know if cinder is storing this information > in the database like nova is in the nova > block_device_mappings.connection_info column. > This is being discussed for cinder, since it is useful for implementin

Re: [openstack-dev] [glance][ironic][cinder][nova] 'tar' as an image disk_format

I guess my wisdom would be 'why'? What does this enable you to do that you couldn't do with similar ease with the formats we have and are people trying to do that frequently. We've seen in cinder that image formats have a definite security surface to them, and with glance adding arbitrary conversi

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’, …}, > ‘mitaka’: {‘volume’: ‘1.8’,

  1   2   3   4   5   >