<div dir="ltr">Hi Vitaly,<div><br></div><div>We were thinking about that, and from technical point of view</div><div>this role doesn't conflict with any other role, and it could be useful</div><div>for some plugin related workarounds not to have any conflicts.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 26, 2015 at 7:08 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Shouldn't it be made conflicting with all existing roles? So it won't be possible to assign, for example, empty role + controller on the same node<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2015-01-26 15:24 GMT+03:00 Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>The feature was merged, currently QA team is working on test coverage and</div><div>Technical writer team is working on documentation.</div><div><br></div><div>The name of the role is "Operating System" and it has the next description:</div><div>"Install base Operating System without additional packages and configuration."</div><div><br></div><div>Here is screenshot what the role looks like on UI.</div><div><br></div><img src="cid:ii_i5dtlh9r0_14b262cae881fabc" height="470" width="472"><div><br></div><div>Thanks,<br>​<br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 3:39 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>>> <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></span><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><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>On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin <<a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a>> wrote:<br>
</span><div><div>> Answers inline.<br>
><br>
> On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">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><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" target="_blank">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><div><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>
</div></div></blockquote></div><br></div>
</div></div><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></blockquote></div><br><br clear="all"><br>-- <br></div></div><span class="HOEnZb"><font color="#888888"><div><div dir="ltr"><div><div dir="ltr">Vitaly Kramskikh,<br>Fuel UI Tech Lead,<br>Mirantis, Inc.</div></div></div></div>
</font></span></div>
<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></blockquote></div><br></div>