Hi,
this looks reasonable to me but I would prefer B.
In this case the operator can configure the hard limit.
I don't think we more granularity or expose it using the API.
Belmiro
On Fri, Jun 8, 2018 at 3:46 PM Dan Smith wrote:
> > Some ideas that have been discussed so far include:
>
> FYI,
> I thought we were leaning toward the option where nova itself doesn't
> impose a limit, but lets the virt driver decide.
>
> I would really like NOT to see logic like this in any nova code:
>
>> if kvm|qemu:
>> return 256
>> elif POWER:
>> return 4000
>> elif:
>>
On Mon, Jun 11, 2018 at 10:14:33AM -0500, Eric Fried wrote:
> I thought we were leaning toward the option where nova itself doesn't
> impose a limit, but lets the virt driver decide.
Yeah, I agree with that, if we can't arrive at a sensible limit for
Nova, after testing with all drivers that
I thought we were leaning toward the option where nova itself doesn't
impose a limit, but lets the virt driver decide.
I would really like NOT to see logic like this in any nova code:
> if kvm|qemu:
> return 256
> elif POWER:
> return 4000
> elif:
> ...
On
On Mon, Jun 11, 2018 at 11:55:29AM +0200, Sahid Orentino Ferdjaoui wrote:
> On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote:
> > On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
[...]
> > > The 26 volumes thing is a libvirt driver restriction.
> >
> > The
On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote:
> On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
> > On 6/7/2018 12:56 PM, melanie witt wrote:
> > > Recently, we've received interest about increasing the maximum number of
> > > allowed volumes to attach to a
Dan Smith wrote on 06/08/2018 08:46:01 AM:
> From: Dan Smith
> To: melanie witt
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> ,
openstack-operat...@lists.openstack.org
> Date: 06/08/2018 08:48 AM
> Subject: Re: [openstack-dev] [nova] incr
> Some ideas that have been discussed so far include:
FYI, these are already in my order of preference.
> A) Selecting a new, higher maximum that still yields reasonable
> performance on a single compute host (64 or 128, for example). Pros:
> helps prevent the potential for poor performance on a
On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
> On 6/7/2018 12:56 PM, melanie witt wrote:
> > Recently, we've received interest about increasing the maximum number of
> > allowed volumes to attach to a single instance > 26. The limit of 26 is
> > because of a historical
On Thu, Jun 7, 2018, 4:17 PM Matt Riedemann wrote:
> On 6/7/2018 1:54 PM, Jay Pipes wrote:
> >
> > If Cinder tracks volume attachments as consumable resources, then this
> > would be my preference.
>
> Cinder does:
>
> https://developer.openstack.org/api-ref/block-storage/v3/#attachments
>
>
On 6/7/2018 1:54 PM, Jay Pipes wrote:
If Cinder tracks volume attachments as consumable resources, then this
would be my preference.
Cinder does:
https://developer.openstack.org/api-ref/block-storage/v3/#attachments
However, there is no limit in Cinder on those as far as I know.
--
On 06/07/2018 12:07 PM, Matt Riedemann wrote:
On 6/7/2018 12:56 PM, melanie witt wrote:
C) Create a configurable API limit for maximum number of volumes to attach to
a single instance that is either a quota or similar to a quota. Pros: lets
operators opt-in to a maximum that works in their
On 06/07/2018 01:56 PM, melanie witt wrote:
Hello Stackers,
Recently, we've received interest about increasing the maximum number of
allowed volumes to attach to a single instance > 26. The limit of 26 is
because of a historical limitation in libvirt (if I remember correctly)
and is no
+operators (I forgot)
On 6/7/2018 1:07 PM, Matt Riedemann wrote:
On 6/7/2018 12:56 PM, melanie witt wrote:
Recently, we've received interest about increasing the maximum number
of allowed volumes to attach to a single instance > 26. The limit of
26 is because of a historical limitation in
On 6/7/2018 12:56 PM, melanie witt wrote:
Recently, we've received interest about increasing the maximum number of
allowed volumes to attach to a single instance > 26. The limit of 26 is
because of a historical limitation in libvirt (if I remember correctly)
and is no longer limited at the
Hello Stackers,
Recently, we've received interest about increasing the maximum number of
allowed volumes to attach to a single instance > 26. The limit of 26 is
because of a historical limitation in libvirt (if I remember correctly)
and is no longer limited at the libvirt level in the present
16 matches
Mail list logo
