misunderstood the proposal further up the thread when I replied
before. This sounds eminently sensible. There's certainly no hard at all in
recognising large contributions other than reviews, and bug triage is
almost becoming as large a job at various points in the cycle.
--
Duncan Thomas
On 31 March 2015 at 01:35, John Griffith john.griffi...@gmail.com wrote:
On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley
doug...@parksidesoftware.com wrote:
- Test relies on some “optional” feature, like overlapping IP subnets that
the backend doesn’t support. I’d argue it’s another
__
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
...@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
on this, and to all of the various
people in both cinder and infra who've been very active in helping people
get their CI running, sometimes in very trying circumstances.
--
Duncan Thomas
__
OpenStack Development Mailing List
/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
to
answer these questions yet, and I agree we need to get that on the road
map. Some of the above questions should ideally only have one question, but
there are limitations on various drivers that we've not yet fixed.
--
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
--
Duncan Thomas
On 13 March 2015 at 17:36, Doug Hellmann d...@doughellmann.com wrote:
I wish we, as a community, were less obsessed with creating so many
hacking rules. These are really minor changes and it's going to be a
relatively short-lived issue that could just be fixed once. If there's a
regression,
On 13 March 2015 at 02:37, Nikhil Manchanda nik...@manchanda.me wrote:
- We wanted to ensure that we had a corresponding hacking rule in
place to prevent future patch-sets from using the deprecated module
names.
There's one in cinder that Jay wrote, please do feel free to copy (and
point
On 12 March 2015 at 18:48, Doug Hellmann d...@doughellmann.com wrote:
On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
Yay, the system is working as designed!
Good to hear
What are normal, none developer users supposed to do with such warnings,
other than:
a) panic or b
:
On Thursday 12 March 2015 12:24:57 Duncan Thomas wrote:
ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
/usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19:
DeprecationWarning: The oslo namespace package is deprecated. Please use
oslo_i18n instead.
from oslo import i18n
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
__
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
/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
that currently get incorrectly hit by auto-abandon.
--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
I'm assuming your mean the following lines in nova policy.js:
compute_extension:os-assisted-volume-snapshots:create:rule:admin_api,
compute_extension:os-assisted-volume-snapshots:delete:rule:admin_api
These 2 calls are not intended to be made directly via an end user, but via
cinder, as a
volume migration then it would be good for new folks in cinder.
Regards
Nikesh
On Sun, Mar 1, 2015 at 10:12 PM, Duncan Thomas duncan.tho...@gmail.com
wrote:
Migrate - move between backends of the same volume type
Retype - move between types. Will migrate the volume for you if necessary
.
__
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
?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
__
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
Thanks for that, Joe. I'd say the cons miss 'It looks ugly in places'.
On 25 February 2015 at 20:54, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas duncan.tho...@gmail.com
wrote:
Hi
So a review [1] was recently submitted to cinder to fix up all
readable,
Is there anybody who'd like to step forward in defence of this rule and
explain why it is an improvement? I don't discount for a moment the
possibility I'm missing something, and welcome the education in that case
Thanks
[1] https://review.openstack.org/#/c/145780/
--
Duncan Thomas
/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
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
__
OpenStack
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
.
__
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
--
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
As far as I know, this has not been looked at - you need to use whatever
management tools your backend provides to do this.
There was somebody from Intel IIRC in Paris with some interest in maybe
starting something about this, but I don't know that it came to much.
Duncan Thomas
On Feb 11, 2015
/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 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
, be are trying to choose a subset that can be:
- Implemented on as many different backends as possible
- Don't limit backend architectures from doing novel new things
- Allow a rich tenant experience
- Guide a tenant away from operating in a high-risk manner
--
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
--
Duncan Thomas
...@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
__
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
?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
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
.
[1] -
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html
___
Product-wg mailing list
product...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
--
Duncan Thomas
+1
Very excited to see this in and usable
Duncan Thomas
On Jan 30, 2015 2:56 AM, Philipp Marek philipp.ma...@linbit.com wrote:
Hi all,
in Paris (and later on, on IRC and the mailing list) I began to ask
around
about providing a DRBD storage driver for Nova.
This is an alternative
(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
-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
-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to the way some
people already
use the ‘host’ option?
Thanks!
Arne
On 08 Jan 2015, at 15:11, Duncan Thomas duncan.tho...@gmail.com wrote:
The problem is that the scheduler doesn't currently have enough info to
know which backends are 'equivalent' and which aren't. e.g. If you have 2
ceph
but IMO it is more important that these are
made consistent.
I like option 2 better.
--
Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan
No, I mean that if drivers are going to access database, then they should
do it via a defined interface that limits what they can do to a sane set of
operations. I'd still prefer that they didn't need extra access beyond the
model update, but I don't know if that is possible.
Duncan Thomas
On Dec
by the model update (generally provider location and provider auth) then
writing some helper methods that wrap the context bump and db call would be
better than accessing it directly from the driver.
Duncan Thomas
On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote:
Hi Stackers,
I have
, or
that driver is at risk of being removed from the tree.
Please join #openstack-cinder to discuss CI requirements.
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
There are some significant limitations to the pure taskflow approach,
however some combination of atomic micro-state management and taskflow
persistence is being looked at
Duncan Thomas
On Dec 9, 2014 6:24 PM, Dulko, Michal michal.du...@intel.com wrote:
And what about no recovery in case
calls.
Curious to see if any other folks have input here?
John
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
Duncan Thomas
On Nov 27, 2014 10:32 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
We were thinking each service API would expose their schema via a new
/schema resource (or something). Nova would expose its schema. Glance its
own. etc. This would also work well for installations still using
The internal URL is used for more than just admin actions, and admin is no
longer a global flag, so this restriction is not suitable.
Duncan Thomas
On Nov 29, 2014 6:08 AM, joehuang joehu...@huawei.com wrote:
Hello,
if an ordinary user sent a get-token request to KeyStone, internalURL
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://review.openstack.org/#/c/136980/
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
...@gmail.com
wrote:
On Mon, Nov 24, 2014 at 10:53 AM, Monty Taylor mord...@inaugust.com
wrote:
On 11/24/2014 10:14 AM, Drew Fisher wrote:
On 11/17/14 10:27 PM, Duncan Thomas wrote:
Is the new driver drop-in compatible with the old one? IF not, can
existing systems be upgraded to the new
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
are posted?
Thanks,
Liu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing
-cinder on irc.freenode.net is the easiest
way to chat to cinder developers realtime, please feel free to join us
there.
Welcome to the cinder community.
--
Duncan Thomas
On 30 October 2014 11:50, Eduard Matei eduard.ma...@cloudfounders.com wrote:
Hi Darshan,
Having just finished writing
take too much space.
Duncan, could you please elaborate on the pain a single volume group is
likely to cause for Cinder? Is it a show stopper?
Thank you,
Dan
1. https://wiki.archlinux.org/index.php/LVM#LVM_Building_Blocks
On 10/21/2014 03:10 PM, Duncan Thomas wrote:
Sharing the vg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 28 October 2014 18:01, Dan Genin daniel.ge...@jhuapl.edu wrote:
Changing Nova disk names is a lng shot. It's likely I will be doing
something else by the time that gets merged:) So we are left with the two
options of 1) using a shared volume group and, thus, complicating life for
On 23 October 2014 08:30, Preston L. Bannister pres...@bannister.us wrote:
John,
As a (new) OpenStack developer, I just discovered the CINDER_SECURE_DELETE
option.
As an *implicit* default, I entirely approve. Production OpenStack
installations should *absolutely* insure there is no
-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev
Sharing the vg with cinder is likely to cause some pain testing proposed
features cinder reconciling backend with the cinder db. Creating a second
vg sharing the same backend pv is easy and avoids all such problems.
Duncan Thomas
On Oct 21, 2014 4:07 PM, Dan Genin daniel.ge...@jhuapl.edu wrote
On 8 October 2014 10:32, joehuang joehu...@huawei.com wrote:
maybe we should just slap a REST api on it. The challenge of Node-pool REST
API is What it will look like for these API, totally new API? current OS-API
?. From cloud operators' feed back, OS-API is preferred. If we developed
On 9 October 2014 07:49, henry hly henry4...@gmail.com wrote:
Hi Joshua,
...in fact hierarchical scale
depends on square of single child scale. If a single child can deal
with 00's to 000's, cascading on it would then deal with 00,000's.
That is faulty logic - maybe the cascading solution
On 8 October 2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:
On 08/10/14 09:30, Christian Berendt wrote:
After proposing a change to Horizon to remove the @author tags from
the header of Python files
(https://review.openstack.org/#/c/126656/) Matthias Runge proposed
to discuss this
/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
On 7 October 2014 16:30, Monty Taylor mord...@inaugust.com wrote:
Second BTW - you're certainly right about the first two in the global
list - we keep track of quota and usage ourselves inside of nodepool.
Actually - since nodepool already does a bunch of these things - maybe
we should just
of an existing project that has had any substantial
amount of work done on it. Not impossible, but flicking through a pile
of old final year projects that got good marks shows that stand-alone
start-to-finish projects tend to get better marks. (I've looked into
this quite a bit)
--
Duncan Thomas
] https://wiki.openstack.org/wiki/Blazar
[3] https://review.openstack.org/#/q/project:stackforge/blazar,n,z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and dedicate resources to it. Putting
the work on people not interested is just the same as killing them
off, except slower, messier and creating more anger and otehr
community fallout along the way.
--
Duncan Thomas
___
OpenStack-dev mailing list
On 2 October 2014 14:30, joehuang joehu...@huawei.com wrote:
In our PoC design principle, the cascaded OpenStack should work passively,
and has no kowledge whether it is running under cascading senario or not to
and whether there is sibling OpenStack or not, to reduce interconnect
between
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev
On Oct 1, 2014 12:37 AM, Adam Young ayo...@redhat.com wrote:
On 09/30/2014 12:21 PM, Sean Dague wrote:
On 09/30/2014 11:58 AM, Jay Pipes wrote:
On 09/30/2014 11:37 AM, Adam Young wrote:
On 09/30/2014 11:06 AM, Louis Taylor wrote:
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young
of work once the end of the blockage is removed, neither of
which is desirable.
I'd rather not have convenience labels on the backend array than
increase the risks of this sort of failure mode.
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev
significant dividends in that area - state machine, cinder
agent, decoupling of drivers and connector types.
I have always encouraged anybody to reach out to me with questions and
concerns, and continue to do so. I look forward to continuing the
great work we've been doing.
Regards
--
Duncan Thomas
On 22 September 2014 23:14, Robert Collins robe...@robertcollins.net wrote:
I am not at all sure we've prevented other flowers blooming -
and I hate the idea that we have done that.
I've certainly sat around at discussions which shut down hard with
somebody making the statement that 'that is
pleasure and honor
for me.
It's been a pleasure to work with you this far, and I hope to continue
doing so. You've seen Cinder through its birthing pains and into a
mature project, and done a great job doing so.
Cheers for all the hard work.
--
Duncan Thomas
On 16 September 2014 01:28, Nathan Kinder nkin...@redhat.com wrote:
The idea would be to leave normal tokens with a smaller validity period
(like the current default of an hour), but also allow one-time use
tokens to be requested.
Cinder backup makes many requests to swift during a backup, one
(failures=26)
Regrads
Nikesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
___
OpenStack-dev mailing
On 12 September 2014 09:54, Thierry Carrez thie...@openstack.org wrote:
At this point, unless it's critical to the success of the release (like,
it completes a feature that is 99% there, or it increases consistency by
plugging a feature gap, or it fixes a potential security vulnerability),
I
On 11 September 2014 12:36, Sean Dague s...@dague.net wrote:
I continue to not understand how N non overlapping teams makes this any
better. You have to pay the integration cost somewhere. Right now we're
trying to pay it 1 patch at a time. This model means the integration
units get much
On 11 September 2014 03:17, Angus Lees g...@inodes.org wrote:
(As inspired by eg kerberos)
2. Ensure at some environmental/top layer that the advertised token lifetime
exceeds the timeout set on the request, before making the request. This
implies (since there's no special handling in place)
On 11 September 2014 15:35, James Bottomley
james.bottom...@hansenpartnership.com wrote:
OK, so look at a concrete example: in 2002, the Linux kernel went with
bitkeeper precisely because we'd reached the scaling limit of a single
integration point, so we took the kernel from a single
with this after cert results are provided.
[1] - https://review.openstack.org/#/c/110236/
--
Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
you in advance.
--
Best regards,
Mykola Grygoriev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Duncan Thomas
On 4 September 2014 16:00, Solly Ross sr...@redhat.com wrote:
My only question is about the need to separate out each virt driver into a
separate project, wouldn't you
accomplish a lot of the benefit by creating a single virt project that
includes all of the drivers?
I don't think there's
/cinder-meetup-summer-2014
[3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
--
Duncan Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 3 September 2014 01:20, Emma Lin l...@vmware.com wrote:
Thank you all for the prompt response. And I’m glad to see the progress on
this topic.
Basically, what I’m thinking is the local storage support for big data and
large scale computing is specially useful.
I’ll monitor the meeting
Emma
I encourage you to join the cinder RIC channel, #openstack-cinder, on
the freenode irc network (irc.freenode.net) to ask questions, you'll
get much more interactive feedback there.
Regards
--
Duncan
___
OpenStack-dev mailing list
On 2 September 2014 04:56, Emma Lin l...@vmware.com wrote:
Hi Gurus,
I saw the wiki page for Cinder Brick proposal for Havana, but I didn’t see
any follow up on that idea. Is there any real progress on that idea?
As this proposal is to address the local storage issue, I’d like to know the
On 11 August 2014 19:26, Jay Pipes jaypi...@gmail.com wrote:
The above does not really make sense for MySQL Galera/PXC clusters *if only
Galera nodes are used in the cluster*. Since Galera is synchronously
replicated, there's no real point in segregating writers from readers, IMO.
Better to
201 - 300 of 413 matches
Mail list logo
