On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
On 2/19/16, 10:07 AM, "Matt Riedemann" <mrie...@linux.vnet.ibm.com> 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.
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:
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
This is my preferred choice - keep the functionality exactly the same as the
way it is today. Users (if this is available) can opt-in. Not 100% familiar
with micro-version - but is it possible to opt-out of this micro-version all
together, but have other, later, micro-versions?
Users/clients opt into a microversion by specifying a header with the
version in the request. You can't skip microversions. If your client
support 2.10 and then you wanted to support 2.18, for example, you have
to also build in support for handling 2.11-2.17.
In this case the user has to opt into auto-allocating the network.
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.
I don't like this but I think other people might. Really I would like to see a
config option detailing how the cloud admin wants to handle this behavior.
With the push for more consistent API behavior across public OpenStack
clouds, making the API configurable with config options is not really a
thing we want to do anymore since it's not discoverable. If cloud A
doesn't support this but cloud B does, even though you've specified the
same microversion for both, it's confusing and unreliable. Of course we
already have some of this situation already since not all of the virt
driver backends support 100% of the REST API, but I don't think we want
to add to that if we can help it.
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 don't like this option at all. You are chaning what people must provide on
the bootline and this as far as I can tell is a breaking change.
Yes it's a breaking change, but with a microversion you have to opt into
it, so you have to be aware of it when you make the request. Just FYI.
--
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.
If you or your users have any input on this, please respond in this
thread of the one in the -dev list.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
