Open Stack

Hi Vitaly,

We were thinking about that, and from technical point of view
this role doesn't conflict with any other role, and it could be useful
for some plugin related workarounds not to have any conflicts.

Thanks,

On Mon, Jan 26, 2015 at 7:08 PM, Vitaly Kramskikh <vkramskikh at mirantis.com>
wrote:

> 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.
>
> __________________________________________________________________________
> 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/20150126/5c4ac6f9/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/5c4ac6f9/attachment-0001.png>