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