On Mon, Aug 29, 2016 at 1:27 PM, gordon chung <g...@live.ca> wrote: > 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.*
One idea I hear fairly often is having a couple of hypervisors in say a single store or some other customer premise, but not wanting to also run an OpenStack control plane there. If we are talking about a hypervisor level, not some other unknown but smaller IoTs...uh thing, does that make more sense from a OpenStack + vCPE context? Or do some think that is out of scope for OpenStack's mission as well? Thanks, Curtis. > > * 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 > 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> > 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> 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 > 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 > 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 > 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 > -- Blog: serverascode.com __________________________________________________________________________ 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