[openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Curtis serverascode at gmail.com
Mon Aug 29 19:51:42 UTC 2016


On Mon, Aug 29, 2016 at 1:27 PM, gordon chung <gord at 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:jaypipes at gmail.com]
> Sent: Monday, August 29, 2016 3:48 AM
> To: openstack-dev at 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:ed at leafe.com]
> Sent: Saturday, August 27, 2016 10:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at 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 <bh526r at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Blog: serverascode.com



More information about the OpenStack-dev mailing list