In an app ecosystem, the users tend not to interact directly with the low level plumbing, but the app developers do. So likely, its the app developers, not the end users that care about naas in the long run. So I do agree that most users wont directly care about naas. But they will care about the software that is enabled by naas. A fine distinction, but important.
Really, what I expect to see long term in a healthy OpenStack ecosystem is some global AppStore like functionality baked in to horizon. A user goes to it, selects "my awesome scalable web hosting system", hits launch, and is given a link to login via webbrowser to edit their site. Under the hood, the system just stood up a trove database, an elasticsearch cluster in its own network, a web tier, a load balancer etc. The user didnt have to care how hard that use to be, and just gets charged for the resources consumed. Benifiting the cloud deployer and the end user. The easier it is to use/create/consume cloud resources the better it is for the deployer. If a bit steaper learning curve up front is nessisary, that sucks, but will be worth it. This sort of thing is what we need to get to, and is extremely difficult if OpenStack clouds differ wildly in functionality. Thanks, Kevin ________________________________ From: Salvatore Orlando Sent: Friday, April 17, 2015 8:45:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] And since we've circled back I might add that perhaps we want nova-network to deliver that. Simple, reliable networking leveraging well-established off-the-shelf technologies that satisfies the use cases Jeremy is referring to. If regardless of changes in governance pertaining openstack project the consensus is still that nova-network functionalities should be performed by neutron under the same assumptions, then what Kevin is suggesting goes in the right direction, regardless of whether the deployer chooses linux bridge, OVS, or some fancy advanced technology like [1]. However, there's more than that. For instance ask the average user that "just wants connectivity" whether they think creating a router or pointing a floating ip to a port should be part of their workflow. You can figure out the answer by yourself. I had a chat with Sean Dague a few day back on IRC [2]. The point seems that when neutron is deployed as a replacement for nova-network it should provide defaults that provide a replacement for nova-network flatdhcp networking mode. For instance this would be a shared network, a single router, and a single external network (the floating IP pool). If multi-host is required that single router should be distributed (and perhaps one day neutron will distribute SNAT too). Router distribution with linux bridge might be a problem with the current framework, where we're insisting on supporting nova-network scenario using neutron's control plane constructs which have been conceived for multi-tenancy and self service networking. And then there's the API usability perspective. But if we provide default for neutron resources then the problem is probably solved as users will have little to no interaction with the neutron API. Salvatore [1] https://github.com/salv-orlando/hdn [2] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-04-15.log from 2015-04-15T13:26:55 On 17 April 2015 at 17:22, Jeremy Stanley <fu...@yuggoth.org<mailto:fu...@yuggoth.org>> wrote: On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote: > What do you disagree with? I was pointing out that using Linux > bridge will not reduce the complexity of the model of self-service > networking, which is what the quote was complaining about. On the contrary, if you reread the message to which you were previously replying, it's was about the unnecessary complexity of OVS (and Neutron in general) for deployments which explicitly _don't_ need and can never take advantage of self-service networking. The implication being that Neutron needs a "just connect everything to a simple flat network on a bridge I can easily debug" mode which hides or eliminates those complexities instead. -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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
