Open Stack

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

2015-01-26 15:24 GMT+03:00 Evgeniy L <eli at mirantis.com>:

> Hi,
>
> The feature was merged, currently QA team is working on test coverage and
> Technical writer team is working on documentation.
>
> The name of the role is "Operating System" and it has the next description:
> "Install base Operating System without additional packages and
> configuration."
>
> Here is screenshot what the role looks like on UI.
>
>
> Thanks,
> ​
>
> On Fri, Jan 16, 2015 at 3:39 PM, Evgeniy L <eli at mirantis.com> wrote:
>
>> >> 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
>>>
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150126/4808a454/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed.png
Type: image/png
Size: 256577 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150126/4808a454/attachment-0001.png>