>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) < kevin...@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" <mord...@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@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators