<div dir="ltr">On our public cloud we do exactly as Robert describes - as part of our customer onboarding process, we automatically create a default network and router to our provider network, so that a tenant can just spin up a VM if they want to. Obviously the customer can then delete this if they wish, but it gets them started. </div><div class="gmail_extra"><br><div class="gmail_quote">On 25 February 2016 at 00:19, Robert Starmer <span dir="ltr"><<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Most service environments I've worked with will deploy (often automatically) a first tenant network and router, allowing for the simple case of "deploy a vm, and it auto attaches to the only network" model.  So in effect, this is anticipated, if not expected, behavior.  If on the other hand, there is no network, does the auto-network process also create a router, and associate that router with an "external" network with floating address/etc.?  If not, then isn't the --nic=auto case effectively equivalent to the no network case anyway? there's still neutron work to be done, and the VM will likely need to have a DHCP lease re-established if a router is also attached so that the network has anything other than local meaning.<div><br></div><div>I.e., what was the original use case of this auto-created network (which sounds like it's here to stay regardless).  Does someone have a pointer to the spec that defines the use case of this.</div><div><br></div><div>But even so, I'd say I prefer model 2 over the others, but perhaps a warning needs to be generated, especially if the network isn't router connected automatically, otherwise, the end user is going to be confused as to why internet connectivity isn't available ("I see a network attached, but I can't get to the internet").</div><div><br></div><div>Just my $0.02</div><span class="HOEnZb"><font color="#888888"><div>Robert</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann<br>
<div><div><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
><br>
><br>
> On 2/20/2016 5:29 PM, Matt Riedemann wrote:<br>
>><br>
>><br>
>><br>
>> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:<br>
>>><br>
>>><br>
>>><br>
>>> ___________________________________________________________________<br>
>>> Kris Lindgren<br>
>>> Senior Linux Systems Engineer<br>
>>> GoDaddy<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On 2/19/16, 10:07 AM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> There is a long contentious dev thread going on here [1] about how Nova<br>
>>>> should handle the Neutron auto-allocate-topology API (referred to as the<br>
>>>> 'get-me-a-network' effort).<br>
>>>><br>
>>>> The point is to reduce the complexity for users to simply boot an<br>
>>>> instance and be able to ssh into it without having to first setup<br>
>>>> networks/subnets/routers in neutron and then specify a nic when booting<br>
>>>> the instance. If the planets are aligned, and no nic is provided (or<br>
>>>> available to the project), then nova would call the new neutron API to<br>
>>>> auto-allocate the network and use that to create a port to associate<br>
>>>> with the instance.<br>
>>>><br>
>>>> There is existing behavior in Nova where you can boot an instance and<br>
>>>> get no networking with neutron as the backend. You can later add<br>
>>>> networking by attaching an interface. The nova dev team has no idea how<br>
>>>> common this use case is though.<br>
>>>><br>
>>>> There will be a microversion to the nova API with the get-me-a-network<br>
>>>> support. The debate is what the default behavior should be when using<br>
>>>> that microversion. The options are basically:<br>
>>>><br>
>>>> 1. If no nic is provided at boot and none are available, don't provide a<br>
>>>> network (existing behavior). If the user wants a network auto-allocated,<br>
>>>> they specify something like: --nic=auto<br>
>>><br>
>>><br>
>>> This is my preferred choice - keep the functionality exactly the same<br>
>>> as the way it is today.  Users (if this is available) can opt-in.  Not<br>
>>> 100% familiar with micro-version - but is it possible to opt-out of<br>
>>> this micro-version all together, but have other, later, micro-versions?<br>
>><br>
>><br>
>> Users/clients opt into a microversion by specifying a header with the<br>
>> version in the request. You can't skip microversions. If your client<br>
>> support 2.10 and then you wanted to support 2.18, for example, you have<br>
>> to also build in support for handling 2.11-2.17.<br>
>><br>
>>><br>
>>><br>
>>>><br>
>>>> In this case the user has to opt into auto-allocating the network.<br>
>>>><br>
>>>> 2. If no nic is provided at boot and none are available, nova will<br>
>>>> attempt to auto-allocate the network from neutron. If the user<br>
>>>> specifically doesn't want networking on instance create (for whatever<br>
>>>> reason), they have to opt into that behavior with something like:<br>
>>>> --nic=none<br>
>>>><br>
>>>> This is closer in behavior to how booting an instance works with<br>
>>>> nova-network, but it is a change in the default behavior for the neutron<br>
>>>> case, and that is a cause for concern for any users that have written<br>
>>>> tools to expect that default behavior.<br>
>>><br>
>>><br>
>>><br>
>>> I don't like this but I think other people might.  Really I would like<br>
>>> to see a config option detailing how the cloud admin wants to handle<br>
>>> this behavior.<br>
>><br>
>><br>
>> With the push for more consistent API behavior across public OpenStack<br>
>> clouds, making the API configurable with config options is not really a<br>
>> thing we want to do anymore since it's not discoverable. If cloud A<br>
>> doesn't support this but cloud B does, even though you've specified the<br>
>> same microversion for both, it's confusing and unreliable. Of course we<br>
>> already have some of this situation already since not all of the virt<br>
>> driver backends support 100% of the REST API, but I don't think we want<br>
>> to add to that if we can help it.<br>
><br>
><br>
> Thinking about this again today, nova is going to be checking that the<br>
> auto-allocate-topolocy extension is enabled in neutron. So if you just don't<br>
> enable that extension, you've effectively disabled the nic=auto option in<br>
> nova. Basically like a config option.<br>
<br>
</div></div>Only you kinda can't:<br>
<a href="https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41</a><br>
<br>
get-me-a-network is enabled by default, so if you're running a recent<br>
enough Neutron you're just going to get that extension enabled.<br>
<div><div><br>
><br>
><br>
>><br>
>>><br>
>>>><br>
>>>> 3. If no nic is provided at boot and none are available, fail the<br>
>>>> request and force the request to be explicit, i.e. provide a specific<br>
>>>> nic, or auto, or none. This is a fail-fast scenario to force users to<br>
>>>> really state what they want.<br>
>>><br>
>>><br>
>>> I don't like this option at all.  You are chaning what people must<br>
>>> provide on the bootline and this as far as I can tell is a breaking<br>
>>> change.<br>
>><br>
>><br>
>> Yes it's a breaking change, but with a microversion you have to opt into<br>
>> it, so you have to be aware of it when you make the request. Just FYI.<br>
>><br>
>>><br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> As with any microversion change, we hope that users are reading the docs<br>
>>>> and aware of the changes in each microversion, but we can't guarantee<br>
>>>> that, so changing default behavior (case 2) requires discussion and<br>
>>>> input, especially from outside the dev team.<br>
>>>><br>
>>>> If you or your users have any input on this, please respond in this<br>
>>>> thread of the one in the -dev list.<br>
>>>><br>
>>>> [1]<br>
>>>><br>
>>>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html</a><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> Matt Riedemann<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-operators mailing list<br>
>>>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>><br>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>

<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span>