Open Stack

"as an operator"? That's not related to the iPhone developer use case (user
usability) at all.

For users, they just boot a VM and Nova will call the API and neutron will
setup a network/router/etc on demand and return it so there is nothing the
user has to do.

If you have issues with operator usability, that relates to improvements to
the openstack networking guide, but that's not what this thread is about.


On Jan 13, 2017 10:50, "Clint Byrum" <clint at fewbar.com> wrote:

Excerpts from Joshua Harlow's message of 2017-01-12 22:38:46 -0800:
> Kevin Benton wrote:
> > If you don't want users to specify network details, then use the get me
> > a network extension or just have them boot to a public (or other
> > pre-created) network.
> >
> > In your thought experiment, why is your iPhone app developer not just
> > using a PaaS that handles instance scaling, load balancing and HA? Why
> > would he/she want to spend time managing security updates and log
> > rotation for an operating system running inside another program
> > pretending to be hardware? Different levels of abstraction solve
> > different use cases.
>
> Fair point, probably mr/mrs iPhone app developer should be doing that.
>

I totally disagree. If PaaS was the answer, they'd all be using PaaS.

Maybe some day, but that's no excuse for having an overly complex story
for the base. I totally appreciate that "Get me a network" is an effort
to address this. But after reading docs on it, I actually have no idea
how it works or how to make use of it (I do have a decent understanding
of how to setup a default subnetpool as an operator).

__________________________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170113/d2d96f77/attachment.html>