Open Stack

>From a purely benchmarking aspect it makes sense.  It's like a burn in test
case use.  That only makes it make sense.

On Fri, Feb 19, 2016 at 5:09 PM, Kevin Bringard (kevinbri) <
kevinbri at cisco.com> wrote:

> Sorry for top posting.
>
> Just wanted to say I agree with Monty (and didn't want you to have to
> scroll way down to read it). When we switched to neutron the thing people
> said was "Why do I have to do all this other stuff now?". So long as the
> tools exist for folks to do more powerful things if they want to, I'm all
> for making the simplest use case just that: simple. I think if there's any
> issue with this approach it'll be with the people who are unlearning their
> behavior.
>
> -- Kevin
>
>
>
>
> On 2/19/16, 1:21 PM, "Monty Taylor" <mordred at inaugust.com> wrote:
>
> >On 02/19/2016 11:07 AM, Matt Riedemann wrote:
> >> There is a long contentious dev thread going on here [1] about how Nova
> >> should handle the Neutron auto-allocate-topology API (referred to as the
> >> 'get-me-a-network' effort).
> >>
> >> The point is to reduce the complexity for users to simply boot an
> >> instance and be able to ssh into it without having to first setup
> >> networks/subnets/routers in neutron and then specify a nic when booting
> >> the instance. If the planets are aligned, and no nic is provided (or
> >> available to the project), then nova would call the new neutron API to
> >> auto-allocate the network and use that to create a port to associate
> >> with the instance.
> >>
> >> There is existing behavior in Nova where you can boot an instance and
> >> get no networking with neutron as the backend. You can later add
> >> networking by attaching an interface. The nova dev team has no idea how
> >> common this use case is though.
> >
> >Fascinating. I have never wanted to do this. I cannot imagine wanting to
> >do this. I also have never heard anyone express a desire to do this.
> >
> >> There will be a microversion to the nova API with the get-me-a-network
> >> support. The debate is what the default behavior should be when using
> >> that microversion. The options are basically:
> >
> >The command line tool always uses the latest microversion, right?
> >
> >> 1. If no nic is provided at boot and none are available, don't provide a
> >> network (existing behavior). If the user wants a network auto-allocated,
> >> they specify something like: --nic=auto
> >>
> >> In this case the user has to opt into auto-allocating the network.
> >
> >This would not be horrible, but still requires a user to take an action
> >that they would not expect to need to do just to do the simple thing
> >(boot a vm) So it's my least favorite.
> >
> >> 2. If no nic is provided at boot and none are available, nova will
> >> attempt to auto-allocate the network from neutron. If the user
> >> specifically doesn't want networking on instance create (for whatever
> >> reason), they have to opt into that behavior with something like:
> >> --nic=none
> >>
> >> This is closer in behavior to how booting an instance works with
> >> nova-network, but it is a change in the default behavior for the neutron
> >> case, and that is a cause for concern for any users that have written
> >> tools to expect that default behavior.
> >
> >This is my most favorite - because it accomplishes the simplest case
> >"boot me a vm without me requesting anything out of the ordinary about
> >it" in the simplest way "nova boot"
> >
> >> 3. If no nic is provided at boot and none are available, fail the
> >> request and force the request to be explicit, i.e. provide a specific
> >> nic, or auto, or none. This is a fail-fast scenario to force users to
> >> really state what they want.
> >
> >I like this better than 1 but less than 2. The nice part is that the
> >error message can at least communicate to the user that they need to say
> >"--nic=$something" - which is at least active communication on our part.
> >But if there is no network available, then the _only_ valid choices are
> >none and auto, (specific nic wouldn't be a result here because in that
> >case the user currently gets the "I can't figure out which network to
> >use" errror - and again the "no" nic is a strange case that is the least
> >likely thing a user wants to do.
> >
> >> --
> >>
> >> As with any microversion change, we hope that users are reading the docs
> >> and aware of the changes in each microversion, but we can't guarantee
> >> that, so changing default behavior (case 2) requires discussion and
> >> input, especially from outside the dev team.
> >
> >That is totally fair and I think you're right about that. It is a change
> >- but in this particular case I think we can extrapolate pretty well
> >about what people do and how they use clouds.
> >
> >Getting an IP address in an OpenStack Cloud is hard already - AND it's
> >very common for clouds to restrict API calls for port/fixed-ip
> >manipulation, so I doubt VERY seriously that anyone is deliberately
> >going through additional needless steps to get a working IP.
> >
> >> If you or your users have any input on this, please respond in this
> >> thread of the one in the -dev list.
> >
> >I earnestly suggest #2. I believe it is the behavior users are more
> >likely to expect than anything else.
> >
> >
> >_______________________________________________
> >OpenStack-operators mailing list
> >OpenStack-operators at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160219/7d1033e2/attachment.html>