Open Stack

>> The whole-disk allocator we use for ceph-osd should be proper to work
around this problem in a way.

Our current constraint for Ubuntu is it cannot be allocated on several
disks,
as far as I remember for ceph-osd Fuel allocates from 1 to N disks, and it
doesn't
allocate any other volumes on the same disk with Ceph's volumes. So I don't
see
how it can help here.

On Thu, Jan 15, 2015 at 11:47 PM, Andrew Woodward <xarses at gmail.com> wrote:

> On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin <adanin at mirantis.com> wrote:
> > Answers inline.
> >
> > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <eli at mirantis.com> wrote:
> >>
> >> Hi,
> >>
> >> Empty role is ready [1], thanks to granular deployment feature
> >> I didn't have to hardcode some hacks in Astute again.
> >>
> >> But there are several things which I want to mention/discuss:
> >>
> >> 1. in the patch you can see the name of the role and its description
> >>     I would like to ask you to verify it and provide some other options
> if
> >> you
> >>     have any
> >> 2. we have a minor problem with the progress bar, we will figure out how
> >>     to fix it in Astute with Vladimir S.
> >> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
> >> and it
> >>     doesn't allow us to make efficient partitioning schema, e.g. it
> means
> >> that we
> >>     cannot allocate root partition for all of the disks (provisioning
> will
> >> fail), the
> >>     current workaround is to allocate root partition with minimal size
> >>     (about 15G) and leave the rest of the space as is (unallocated). As
> >>     far as I can see from the bug it's not so easy to fix the problem,
> >> actually
> >>     image based provisioning fixes the problem, but it's not an option
> for
> >> the
> >>     current release. Maybe you have some other ideas how to fix this
> >> problem?
> >>
> > I would leave it as is - 15 GB. A user or plugin can adjust it for its
> > needs.
>
> Seriously? NO the 15G Min / Max 50G "min" for the OS allocation is too
> small for a default value and not using the rest of the disk. While
> the user may easily change this (by the way, most users don't they
> expect better allocations), how do you expect the plugin-dev to deal
> with this? The way this seams to push the plugin-dev is to do it
> pre-deployment via code. We know already working with the disk
> allocation is very painful, why are we pushing them to 'duplicate'
> code. We need proper support of dynamically adding roles so they can
> re-use our code
>
> Is [2] the correct bug for the ubuntu OS volume issue? It's clearly
> talking about small root disk values being wrong for all real
> deployments.
>
> I'll try to look for the proper bug w/regards to ubuntu OS, but the
> gist is the limitation is that the OS volume can not span multiple
> disks. The whole-disk allocator we use for ceph-osd should be proper
> to work around this problem in a way.
>
> >>
> >> Thanks,
> >>
> >> [1] https://review.openstack.org/#/c/147230/
> >> [2] https://bugs.launchpad.net/fuel/+bug/1278964
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Andrey Danin
> > adanin at mirantis.com
> > skype: gcon.monolake
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/1242d984/attachment.html>