Open Stack

We had a really good (and unexpected) experiment with something similar during the Swift sessions in Hong Kong. One of the technical sessions was led by a Swift contributor who brought a use case and a set of very practical questions about what using Swift as part of the entire storage system would look like. In this particular case, it was exploring the use of Swift as storage for the LINE messaging app <http://en.wikipedia.org/wiki/Line_(application)>.

When considering any OpenStack project in production system, many factors must be considered. These are the sort of questions that come up every day as part of a sales process (even if that sales process is simply convincing other internal people to use something). Questions like: What's the pain point with the system it's replacing? How does it integrate with existing policies and procedures? Does it functionally meet all current requirements, or is additional development work needed? etc.

In the case of LINE discussion for Swift, we had to consider questions around global distribution, hot content, supporting a billion users (ie auth questions), and other questions related to supporting a massively popular mobile application. One thing I liked about the discussion is that it wasn't a slam-dunk traditional use case. There were areas where Swift was a great fit for the LINE app, and there were areas where new functionality would be required to better support their use case.

These sort of discussions happen every day as vendors are pitching their OpenStack wares to potential new users. The good parts about the discussion in HK was that it was an engineer-to-engineer discussion (with no related product sales pitch), and it exposed the active Swift contributors gathered in HK to the varied use cases that face real-world deployments. It's this kind of feedback that is essential for keeping the code relevant and the vision fresh.

I got lots of positive feedback after the LINE session in HK, and it's something I'll be actively seeking out for Atlanta. It's got to be balanced so it doesn't turn into a vendor honeypot, but I definitely want to have one session during the Swift technical track at the next summit focused on sussing out requirements for a hard real-world use case. I'd encourage other OpenStack projects to do the same.

--John





On Dec 14, 2013, at 11:29 PM, Tristan Goode <tristan at aptira.com> wrote:

> That's a bunch of talks. What I'm trying to establish is a feedback loop.
> 
> 
>> -----Original Message-----
>> From: Jeremy Stanley [mailto:fungi at yuggoth.org]
>> Sent: Sunday, 15 December 2013 10:41 AM
>> To: community at lists.openstack.org
>> Subject: Re: [openstack-community] Bringing focus to the Operators and
> Users at
>> the next summit
>> 
>> On 2013-12-13 18:26:43 +0300 (+0300), Adam Nelson wrote:
>> [...]
>>> a track dedicated to those managing existing clouds or installing them
>>> could really benefit from sharing their experiences in a dedicated
>>> way.
>> 
>> Perhaps I'm misunderstanding, but at the last summit (as at previous
> ones) we had
>> an "Operations" track. It ran pretty much solid for three days
> straight...
>> 
>> http://openstacksummitnovember2013.sched.org/overview/type/operations
>> 
>> It sounds like energy would be best directed into improving and
> redirecting that, if
>> it's not meeting the current needs of deployer/operator attendees?
>> --
>> Jeremy Stanley
>> 
> 
> _______________________________________________
> Community mailing list
> Community at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/community/attachments/20131215/2e21788a/attachment.pgp>