just to clarify, what 'innovation' do you believe is required to enable you to build on top of OpenStack. what are the feature gaps you are proposing? let's avoid defining "the cloud" since that will give you 1000 different answers if you ask 1000 different people.*
* actually you'll get 100 answers and the rest will say: "i don't know." On 29/08/16 12:23 PM, HU, BIN wrote: Please see inline [BH526R]. -----Original Message----- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Monday, August 29, 2016 3:48 AM To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs On 08/27/2016 11:16 AM, HU, BIN wrote: The challenge in OpenStack is how to enable the innovation built on top of OpenStack. No, that's not the challenge for OpenStack. That's like saying the challenge for gasoline is how to enable the innovation of a jet engine. [BH526R] True. 87 gas or diesel certainly cannot be used in any jet engine. While Jet A-1 and Jet B fuel are widely used for jet engine today, innovation of a new generation of jet engine may require an innovation of new type of aviation fuel. So telco use cases is not only the innovation built on top of OpenStack. Instead, telco use cases, e.g. Gluon (NFV networking), vCPE Cloud, Mobile Cloud, Mobile Edge Cloud, brings the needed requirement for innovation in OpenStack itself. If OpenStack don't address those basic requirements, That's the thing, Bin, those are *not* "basic" requirements. The Telco vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases are asking for fundamental architectural and design changes to the foundational components of OpenStack. Instead of Nova being designed to manage a bunch of hardware in a relatively close location (i.e. a datacenter or multiple datacenters), vCPE is asking for Nova to transform itself into a micro-agent that can be run on an Apple Watch and do things in resource-constrained environments that it was never built to do. [BH526R] So we have 2 choices here - either to explicitly exclude telco requirement from OpenStack, and clearly indicate that telco needs to work on its own "telco stack"; or to allow telco to innovate within OpenStack through perhaps a new type of "telco nova" and/or "telco Neutron". Which way do you suggest? And, honestly, I have no idea what Gluon is trying to do. Ian sent me some information a while ago on it. I read it. I still have no idea what Gluon is trying to accomplish other than essentially bypassing Neutron entirely. That's not "innovation". That's subterfuge. [BH526R] Thank you for recognizing you don't know Gluon. Certainly the perception of "bypassing Neutron entirely" is incorrect. You are very welcome to join our project and meeting so that you can understand more of what Gluon is. We are also happy to set up specific meetings with you to discuss it too. Just let me know which way prefer. We are looking for you to participate in Gluon project and meeting. [BH526R] On the other hand, I also try to understand why "bypassing Neutron entirely" is not an innovation. Neutron is not perfect. (I don't mean Gluon here, but) if there is an innovation that can replace Neutron entirely, everyone should be happy. Just like automobile bypassed carriage wagon entirely. the innovation will never happen on top of OpenStack. Sure it will. AT&T and BT and other Telcos just need to write their own software that runs their proprietary vCPE software distribution mechanism, that's all. The OpenStack community shouldn't be relied upon to create software that isn't applicable to general cloud computing and cloud management platforms. [BH526R] If I understand correctly, this suggestion excludes telco from OpenStack entirely. That's fine. An example is - self-driving car is built on top of many technologies, such as sensor/camera, AI, maps, middleware etc. All innovations in each technology (sensor/camera, AI, map, etc.) bring together the innovation of self-driving car. Yes, indeed, but the people who created the self-driving car software didn't ask the people who created the cameras to write the software for them that does the self-driving. [BH526R] It's actually the other way around. Furthermore, camera/sensor industry does see the need, and VC's funding has been dramatically increased to invest in camera/sensor, map, AI areas. And the startups in those areas are the fastest growing areas. Those investments and innovations accelerate the maturity of self-driving cars. WE NEED INNOVATION IN OPENSTACK in order to enable the innovation built on top of OpenStack. You are defining "innovation" in an odd way, IMHO. "Innovation" for the vCPE use case sounds a whole lot like "rearchitect your entire software stack so that we don't have to write much code that runs on set-top boxes." [BH526R] Certainly it is misunderstanding. "Rearcihtect" may be needed. However, if the "telco Nova" and "telco Neutron" concept and components can be allowed for us telco to innovate within OpenStack, we will write the code and do the rest of work. (But prior suggestion excludes us telco entirely, if I understand correctly.) Just being honest, -jay Thanks Bin -----Original Message----- From: Edward Leafe [mailto:e...@leafe.com] Sent: Saturday, August 27, 2016 10:49 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs On Aug 27, 2016, at 12:18 PM, HU, BIN <bh5...@att.com><mailto:bh5...@att.com> wrote: >From telco perspective, those are the areas that allow innovation, and provide >telco customers with new types of services. We need innovation, starting from not limiting ourselves from bringing new idea and new use cases, and bringing those impossibility to reality. There is innovation in OpenStack, and there is innovation in things built on top of OpenStack. We are simply trying to keep the two layers from getting confused. -- Ed Leafe ______________________________________________________________________ ____ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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
