fuel-dev team mailing list archive

[Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx>]

>
> *The roles-and-nodes screens do list MongoDB as a role that can be
> assigned.  *


this is new to me ;( Feature owner to rescue!

---
Regards,
Dmitriy


On Mon, May 26, 2014 at 12:22 AM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>wrote:

> Thanks, Dmitriy, this is the impression I have as well.  So the
> terminology article that starts with a
> quick definition of MongoDB and a link to its web site should say:
>
> "Mirantis OpenStack 5.0 and later implements MongoDB to use as a backend
> for Ceilometer.  The
> MongoDB role should be activated only if you are running Ceilometer; other
> OpenStack services
> continue to use MySQL."
>
> The roles-and-nodes screens do list MongoDB as a role that can be
> assigned.  This is why I want
> a bit of information about MongoDB -- I'll link to this article from the
> page that discusses that screen.
>
> Do we anticipate using MongoDB more widely in the future?  I see that the
> blueprint is marked for 5.1
> but I'm not sure if this is just for refinements for Ceilometer/MongoDB or
> for a broader implementation.
>
>
> On Sun, May 25, 2014 at 1:03 PM, Dmitriy Novakovskiy <
> dnovakovskiy@xxxxxxxxxxxx> wrote:
>
>> I may be wrong, but it seems like MongoDB is relevant only as a backend
>> for Ceilometer. I'm also not sure if there are any configuration screens
>> related to it.
>>
>> To my current understanding:
>> - In 4.x we used MySQL as backend for Ceilometer, due to know bugs of
>> Ceilometer+MySQL Web GUI part of Ceilometer part didn't work
>> - In 5.x we use MongoDB as backend for Ceilometer - all should be working
>> neatly now :)
>>
>> ---
>> Regards,
>> Dmitriy
>>
>>
>> On Sat, May 24, 2014 at 8:23 AM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>wrote:
>>
>>> Hi, all.  Does anyone have a sentence or two (or more) to add about
>>> MongoDB in OpenStack 5.0?
>>> This is the terminology article I have:
>>>
>>> http://docs.mirantis.com/openstack/fuel/fuel-5.0/terminology.html#mongodb
>>>
>>> It is just a bit weak, I'd say...
>>>
>>> I would like to have at least enough information to tell people what to
>>> do about the MongoDB item
>>> on the Fuel configuration screens:
>>>
>>>
>>> http://docs.mirantis.com/openstack/fuel/fuel-5.0/user-guide.html#assign-a-role-or-roles-to-each-node-server
>>>
>>> I do understand that a lot more MongoDB functionality is coming in 5.1.
>>> I could include a link to the blueprint
>>> in the terminology article if you think it's appropriate, or make a
>>> vague statement about ongoing development
>>> work.
>>>
>>> Thanks much,
>>> meg
>>>
>>>
>>> On Wed, Apr 2, 2014 at 6:59 AM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>wrote:
>>>
>>>> On 04/01/2014 03:58 PM, Vladimir Kuklin wrote:
>>>> > Guys
>>>> >
>>>> > We had a MongoDB integration meeting today and that;s what we
>>>> discussed
>>>> > ordered by priority.
>>>> >
>>>> > Overall list of things to be done:
>>>> >
>>>> > 1) High: Finish work on puppet manifests:
>>>> >              replicaset connection
>>>> >              fix admin user rights
>>>> > 2) High: Check nailgun disk allocation in case of role combination
>>>> > 3) High: Use the following scheme for disk allocation
>>>> >              floor(n-1/2) for combined roles
>>>> >              n-1 for mongo-only node
>>>> > 4) Medium: use striped LVM/mdraid for mongo nodes - (the same for
>>>> ceph)
>>>>
>>>> I believe native sharding[0] should be used instead of hw-level
>>>> "simulations" (striped raids) because sharding handles "entering
>>>> to/recovering from partitioning state"[1] far way better then degraded
>>>> striped raids could do :-)
>>>> Please correct me, if I'm wrong (I'm new with MongoDB and this
>>>> "sharding" stuff)
>>>>
>>>> [0] about sharding in Mongo (RU) http://habrahabr.ru/post/217393/
>>>> [1] some CAP consideraions
>>>>
>>>> http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
>>>>
>>>> > 5) High: UI:
>>>> >              role-setting dependencies -> rebase mongo UI role request
>>>> >              1-disk mongo node should raise caution of non-production
>>>> > scenario
>>>> > 6) Medium: perform I/O tuning for filesystem (the same for ceph?):
>>>> >     a) deadline scheduler
>>>> >     b) common high-performance mount options (noatime, barriers=0,
>>>> > commit=600, journal=writeback)
>>>> > 7) Low: SSD-disks are preferrable
>>>> >
>>>> > These changes are to be reflected in the blueprint
>>>> > <https://blueprints.launchpad.net/fuel/+spec/mongodb-fuel-integration
>>>> >
>>>> > drafted by Max Mazur.
>>>> >
>>>> > Please, provide your input or feedback if you have any.
>>>> >
>>>> >
>>>> > --
>>>> > Yours Faithfully,
>>>> > Vladimir Kuklin,
>>>> > Fuel Library Tech Lead,
>>>> > Mirantis, Inc.
>>>> > +7 (495) 640-49-04
>>>> > +7 (926) 702-39-68
>>>> > Skype kuklinvv
>>>> > 45bk3, Vorontsovskaya Str.
>>>> > Moscow, Russia,
>>>> > www.mirantis.com <http://www.mirantis.ru/>
>>>> > www.mirantis.ru <http://www.mirantis.ru/>
>>>> > vkuklin@xxxxxxxxxxxx <mailto:vkuklin@xxxxxxxxxxxx>
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Bogdan Dobrelya,
>>>> Skype #bogdando_at_yahoo.com
>>>> Irc #bogdando
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>