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

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

nection > information. > > So I agree, it's not a blockRebase operation, just a change in the > volume that is used. > > Regards, > Gorka. > > __ > OpenStack Development Mailing List (not for usage

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

ports 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

le, etc. 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 ht

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" <duncan.tho...@gmail.com> wrote: > I'm in the pub now, and they are closing down > > On 2 Mar 2018 5:48 pm, "Jay S. Bryant" <jungleb...@gmail.com> wrote: > >> Iva

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

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

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

-12-04 19:36 GMT+08:00 Duncan Thomas <duncan.tho...@gmail.com>: >> Why remove something that works and people are using? > > Yes, removing it will make noise. > >> >> If polster can be set up to do the job, then great, but there's no >> rush to remove the

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

tack-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 usage questions) Unsubscribe:

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

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

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.

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

ubject: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

bscribe: 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 usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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" <lyarw...@redhat.com> wrote: On 25-05-17 11:38:44, Duncan Thomas wrote: > On 25 May 2017 at 11:00, Lee Yarwood <lyarw...@redhat.com> wrote: > > This has also reminded me that the plain (dm-crypt) format really needs > >

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

o last > minute objections I'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 remove i

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

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

, maybe 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

rd 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

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

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

penstack.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...

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

end might be one way to solve 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 <duncan.tho...@gmail.com&

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

volumes, so it only > 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 <mriede...@gmail.com>: >> >> On 3/27/2017 9:59 AM, Duncan Thomas wrote: &

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

tions) > 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

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

cepts 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

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

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

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?

______ > 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

It'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.openstac

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

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

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

tely 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) Unsubscribe:

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

a firm conclusion. -- 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] [cinder] drbdmanage is no more GPL2

g?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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

B schema to look a particular 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 _

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

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 Maili

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

going to discuss 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 in

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

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

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

cussion this time. >>> >>> Thanks, >>> John​ >>> >>> >>> ________ >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsub

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

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

On 13 September 2016 at 06:44, Ben Swartzlander <b...@swartzlander.org> 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 distribut

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

On 9 September 2016 at 17:22, Ben Swartzlander <b...@swartzlander.org> 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

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

freely distribute them. 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

gt; >> __ >> 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/lis

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

solution > 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

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

On 31 August 2016 at 18:54, Joshua Harlow <harlo...@fastmail.com> wrote: > Duncan Thomas wrote: > >> On 31 August 2016 at 11:57, Bogdan Dobrelya <bdobre...@mirantis.com >> <mailto:bdobre...@mirantis.com>> wrote: >> >> I agree that RPC desi

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 >

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

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

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

On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote: > > Duncan Thomas wrote: > > > >> On 8 August 2016 at 21:12, Matthew Treinish > >> wrote: > >> Ignoring all that, this is also contrary to how we perform testing in > >> OpenStack. > >>

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

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

parent project (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 given a singl

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

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" <s...@dague.net> wrote: > On 08/12/2016 08:40 AM, Duncan Thomas wrote: > > On 12 Aug 2016 15:28, "Thierry Carrez" <thie...@openstack

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" >

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

On 12 Aug 2016 15:28, "Thierry Carrez" <thie...@openstack.org> 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 ha

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

ly sucks that yes, a release could come out and that driver no longer > exists, and that's no good. > > > BUT on the other hand, it's not much worse to find that the code has been > all but abandoned and no longer works anyway. I don't think either > scenario is a good one. It highlig

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

unctional tests would > be > *entirely* 3rd party. > > Yours Tony. > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.o

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

> But is it more 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 saying it's a di

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

3+ cycles), what positive suggestions can people make? -- 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] [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

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

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

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

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

ent 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 __ 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] 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 <shane.w...@intel.com> wrote: > Hi, OpenStackers, > &

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

aplane implementations (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 Maili

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

any open bugs that disagree), is it time to dump the LVM-thick support completely? -- 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] [nova] I'm going to expire open bug reports older than 18 months.

> -- > Regards, Markus Zoeller (markus_z) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http:

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

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

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

spel and expect to be reworked if it proves necessary. -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstac

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

ailing 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 __ Op

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

ou use the same > volume (at least the disk UUID will be the same). > > On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas <duncan.tho...@gmail.com> > wrote: > >> You can't just change the contents of a volume under the instance though >> - at the very least you nee

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

to know whether the topic have been discussed or have other >>> recommendations to us? >>> >>> >>> >>>Thanks >>> >>> >>> >>> __ >>> OpenStack

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

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

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

t; 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_status set [3]. > >> > >> So

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

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

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

Advanced users who want anonymous volumes can always hit the API > directly with curl or whatever SDK. > > On Sun, Mar 27, 2016 at 4:44 PM, Duncan Thomas <duncan.tho...@gmail.com> > wrote: > >> I think it is worth fixing the client to actually match the API, yes. The >

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

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 u

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

- I wouldn't suggest 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 (no

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

indicating 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 Development Mailin

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

ind 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 that this proposal wi

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

ng missing to be a serious bug -- 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] [cinder] adding a new /v3 endpoint for api-microversions

there? There's no way that's a sensible API design. -- 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] [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

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

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

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

so live backup (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

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

nder. 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 Devel

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

d over the old json, 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-

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

JSON file (it'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 ke

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

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

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

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

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

nnection(). >> >> > 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 implementi

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

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

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

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

;> [] >>>> >>>> >>> volumes[0].id >>>> >>>> u'e8be1df5-64fb-43fa-aacd-9bebba17fba5' >>>> >>>> >>> volumes[0].volume_type >>>> >>>> u'iscsi_1' >>>> >>>> >>>> >>>

  1   2   3   4   5   >