Open Stack

On 13 January 2017 at 15:01, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Armando M.'s message of 2017-01-13 11:39:33 -0800:
> > On 13 January 2017 at 10:47, 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).
> > >
> >
> > I'd be happy to improve the docs, but your feedback is not very
> actionable.
> > Any chance you can elaborate on what you're struggling with?
> >
>
> The docs I found are all extremely Neutron-centric. I was told later
> on IRC that once the default subnet pool is setup, Nova would do some
> magic to tell neutron to allocate a subnet from that pool to the user
> when they create an instance.


> Basically, the docs I found were not at all user-centric. They were
> Neutron-centric and they didn't really explain why, as an operator, I'd
> want to allocate a subnet pool. I mean, they do, but because I don't
> really know if I have that problem or what it is, I just wasn't able
> to grasp where this was going. It tells me to go ahead and list default
> subnet pools, and then pass --nic=net-id=$ID from that. Super confusing
> and not really any more friendly than before.
>
>
If you are referring to [1], I wouldn't expect anything less, it's the
OpenStack networking guide after all.


> So what I want is the story from the user's perspective. Something like:
>
> "Without this extension, your users will need to do these steps in order
> to boot servers with networking:..."
>
> and then
>
> "With this extension, your users will not need to perform those steps,
> and the default subnet pools that you setup will be automatically
> allocated to users upon their first server boot."
>

Problem statement from the user's point of view is typically left to the
specs [2,3].
I am sure one can argue that the content there may not be well written or
organized, but it was enough for getting the nova and the neutron team to
have a mutual understanding and agreement on how to design, implement and
test the feature.

>From what I hear, there is a gap in the networking guide in that the
rationale behind the feature is missing. I suppose we can fill that up, and
thus I filed [4].

Thanks.

[1]
http://docs.openstack.org/newton/networking-guide/config-auto-allocation.html
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/mitaka/get-me-a-network.html
[3]
http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html
[4] https://bugs.launchpad.net/openstack-manuals/+bug/1656447


> __________________________________________________________________________
> 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/f2a12b75/attachment-0001.html>