Open Stack

On Mon, Jul 28, 2014 at 9:33 PM, John Griffith <john.griffith at solidfire.com>
wrote:

>
>
>
> On Mon, Jul 28, 2014 at 10:25 AM, Abel Lopez <alopgeek at gmail.com> wrote:
>
>> I think this fills a gap between “enterprisy” storage backends and DIY
>> backends.
>> For example, a robust storage platform like NetApp or the like will have
>> features like snapmirror, etc for replication, also I keep hearing that
>> Ceph is getting/very-close to having cross-site replica sets. So that
>> handles cinder with robust backends, but what about those using plain-old
>> LVM?
>> On the one hand, it sounds like a needed addition, but I’m curious if
>> it’s worth the complication.
>>
>
> ​FWIW, that's exactly what I'm wondering too (ROI for the complication
> introduced).​
>
>>
>> I imaging, in a DR scenario, with storage-based replication, a database
>> dump of cinder would be pretty much all that’s required to bring up a new
>> site.
>>
>
> ​Interesting...  another avenue/use case to think about.​
>
>>
>> On Jul 26, 2014, at 7:28 AM, John Griffith <john.griffith at solidfire.com>
>> wrote:
>>
>> Hey OS-Operators,
>>
>> There are some features that have been kicked around and debated for a
>> while now that I thought it might be great to try and solicit input from
>> folks that are actually deploying and administering OpenStack.  Rather than
>> leaving it up to those of us that may be in a "Vendor Vacuum" or a "Dev
>> Vacuum" I thought it might be worthwhile to get some input.
>>
>> Cinder is getting to a point where people are proposing more advanced
>> features which is great.  The problem is that those advanced features
>> typically mean different things to everyone and they also open up the door
>> to a whole host of implementation options.
>>
>> There are two features being worked on currently that I'd love to get
>> some feedback on:
>>
>> 1. Replication
>> 2. Consistency Groups
>>
>> It's easy for Vendors to come to me and say "we have lots of customers
>> asking for this" but personally I'd love to get feedback directly from the
>> actual customers, that's where you all come in.
>>
>> So, if any of you out there are interested in these topics from a Cinder
>> perspective I'd love to hear from you.  If there's interest we can either
>> start an ML thread to discuss, or perhaps a meeting to catch everybody up
>> and hash things out a bit.  I'd like to discuss the current proposals and
>> go through what you as Operators may feel should be priorities (or better
>> yet things you don't care about).  I make no promises on the outcome of
>> this little experiment but thought it would be interesting to try and get
>> user input up front before we release new features.
>>
>> Let me know your thoughts, I'll avoid a bunch of detail in this posting
>> until I get a feel for who if anybody is interested in helping out.
>>
>> Thanks,
>> John
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
> ​Wow!!  This is great, I really appreciate all of the great feedback.  By
all means feel free to keep providing input to this or another thread or
even to me on IRC if you like.  I think it's great to get feedback from
Operator Community and hopefully use it to deliver something they actually
want/need.

I'm going to spend some more time digesting this but so far the take-aways
I'm gleaning here are:
1. Remote site rep is what's interesting/needed most
2. Cross backend devices is the silver bullet, but not always required (and
only worthwhile if it's "good")
3. Simple is better to start
4. API control isn't mandatory, and in some cases maybe not even ideal (ie
loss of flexibility), but hooks in backend devices is a needed building
block or minimal functionality

Thank you to everyone that responded so far!!

John​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140728/f2b230ed/attachment.html>