>> 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 <[email protected]> wrote: > On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin <[email protected]> wrote: > > Answers inline. > > > > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <[email protected]> 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: > [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > -- > > Andrey Danin > > [email protected] > > skype: gcon.monolake > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
