Open Stack

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