Open Stack

On Mon, Sep 19, 2016 at 2:54 PM, Duncan Thomas <duncan.thomas at gmail.com>
wrote:

> I think there's some mileage in some further work on adding local LVM,
> since things like striping/mirroring for performace can be done. We can
> prototype it and get the numbers before even thinking about merging though
> - as additions to an already fully featured driver. these seem more
> worthwhile a way forward than limping on with the bdd driver.
>
​I think that's a different discussion, a good one, but a different one.
I'd also like to point out that there's been a mirroring option in the
existing LVM driver for years (Vish added it a long time ago) but there
have been very few people that have showed any interest in it.

Again, rather than change the entire architecture of things, I'd rather see
us do some things around multi-pathing and exploitation of the mirroring
that we already have.  IMHO we either flush out and refine the
features/options we have or start removing them; but I hate to continue
piling little corner case configs into the mix that aren't tested and
typically don't implement the entire API.

​


>
> Moving to change our default target to LIO seems worthwhile - I'd suggest
> being cautious with deprecation rather than aggressive though - aiming to
> change the default in 'O' then planning the rest based on how that goes.
>
> On 19 September 2016 at 21:54, John Griffith <john.griffith8 at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 12:01 PM, Ivan Kolodyazhny <e0ne at e0ne.info>
>> wrote:
>>
>>> + [sahara] because they are primary consumer of the BDD.
>>>
>>> John,
>>> Thanks for the answer. My comments are inline.
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> On Mon, Sep 19, 2016 at 4:41 PM, John Griffith <john.griffith8 at gmail.com
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny <e0ne at e0ne.info>
>>>> wrote:
>>>>
>>>>> Hi team,
>>>>>
>>>>> We did some performance tests [1] for LVM and BDD drivers. All tests
>>>>> were executed on real hardware with OpenStack Mitaka release.
>>>>> Unfortunately, we didn't have enough time to execute all tests and compare
>>>>> results. We used Sahara/Hadoop cluster with TestDFSIO and others
>>>>> tests.
>>>>>
>>>>> All tests were executed on the same hardware and OpenStack release.
>>>>> Only difference were in cinder.conf to enable needed backend and/or target
>>>>> driver.
>>>>>
>>>>> Tests were executed on following configurations:
>>>>>
>>>>>    - LVM +TGT target
>>>>>    - LVM+LocalTarget: PoC based on [2] spec
>>>>>    - LVM+LIO
>>>>>    - Block Device Driver.
>>>>>
>>>>>
>>>>> Feel free to ask question if any about our testing infrastructure,
>>>>> environment, etc.
>>>>>
>>>>>
>>>>> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD
>>>>> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing
>>>>> [2] https://review.openstack.org/#/c/247880/
>>>>>
>>>>> Regards,
>>>>> Ivan Kolodyazhny,
>>>>> http://blog.e0ne.info/
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>> ​Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a
>>>> few things (again):
>>>>
>>>> 1. Deprecate the BDD driver
>>>>  Based on the data here LVM+LIO the delta in performance ​(with the
>>>> exception of the Terravalidate run against 3TB) doesn't seem significant
>>>> enough to warrant maintaining an additional driver that has only a subset
>>>> of features implemented.  It would be good to understand why that
>>>> particular test has such a significant peformance gap.
>>>>
>>> What about Local Target? Does it make sense to implement it instead BDD?
>>>
>> ​Maybe I'm missing something, what would the advantage be?  LVM+LIO and
>> LVM+LOCAL-TARGET seem pretty close.  In the interest of simplicity and
>> maintenance just thinking maybe it would be worth considering just using
>> LVM+LIO across the board.
>> ​
>>
>>
>>>
>>>> 2. Consider getting buy off to move the default implementation to use
>>>> the LIO driver and consider deprecating the TGT driver
>>>>
>>> +1. Let's bring this topic for the next weekly meeting.
>>>
>>>
>>>
>>>>
>>>> I realize this probably isn't a sufficient enough data set to make
>>>> those two decisions but I think it's at least enough to have a more
>>>> informed discussion this time.
>>>>
>>>> Thanks,
>>>> John​
>>>>
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __________________________________________________________________________
> 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/20160919/b7de1fbd/attachment.html>