[openstack-dev] [all] [tc] "No Open Core" in 2016

Tim Bell Tim.Bell at cern.ch
Wed Feb 10 21:28:27 UTC 2016


On 10/02/16 21:53, "gordon chung" <gord at live.ca> wrote:

>
>
>On 10/02/2016 11:35 AM, Thierry Carrez wrote:
>> Chris Dent wrote:
>>> [...]
>>> Observing this thread and "the trouble with names"[1] one I get
>>> concerned that we're trending in the direction of expecting
>>> projects/servers/APIs to be done and perfect before they will ever
>>> be OpenStack. This, of course, runs entirely contrary to the spirit
>>> of open source where people release a solution to their itch and
>>> people join with them to make it better.
>>>
>>> If we start thinking of projects as needing to have "production-grade"
>>> implementations and APIs as needing to be stable and correct from
>>> the start we're backing ourselves into corners that are very difficult
>>> to get out of, distracting ourselves from the questions we ought to be
>>> asking, and putting barriers in the way of doing new but necessary
>>> stuff and evolving.
>>
>> I certainly didn't intend to mean that projects need to have a final API
>> or perfect implementation before they can join the tent. I meant that
>> projects need to have a reference implementation using open source tools
>> that has a chance of being used in production one day. Imagine a project
>> which uses sqlite in testing but requires Oracle DB to achieve full
>> functionality or scaling beyond one user: the sqlite backend would be a
>> token open backend for testing purposes but real usage would need you to
>> buy into proprietary options. That would certainly be considered "open
>> core": a project that pretends to be open but requires proprietary
>> technology to be "really used".
>
>apologies if this was asked somewhere else in thread, but should we try 
>to define "production" scale or can we even? based on the last survey, 
>the vast majority of deployments are under 100nodes[1]. that said, a few 
>years ago, one company was dreaming 100,000 nodes.
>
>i'd imagine the 50 node solution won't satisfy the 1000 node solution 
>let alone the 10k node. similarly, the opposite direction will probably 
>give an overkill solution. it seems somewhat difficult to define 
>something against 'production' term unless we scope it somehow (e.g # of 
>node ranges)?
>
>[1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf


As always, scale is relative. However, projects have shown major difficulties to scale to 10% of the larger deployments. Scaling beyond that, even with commercial solutions, has required major investments in custom configurations by the deployers.

There are two risks I see

A. Use sqlite and then change to proprietary solution X for scale
B. Works at a small scale but scalability has not been considered as a design criteria or demonstrated

I think it is important that the community is informed on these constraints before feeling that a particular project is the solution for them and that the TC factors these questions into their approval criteria.

Tim


>
>-- 
>gord
>
>__________________________________________________________________________
>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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160210/ab1b36a9/attachment.bin>


More information about the OpenStack-dev mailing list