On 10/02/16 21:53, "gordon chung" <g...@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-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
