On 2/12/2016 12:45 PM, John Garbutt wrote:
On 12 February 2016 at 18:17, Andrew Laski <and...@lascii.com> wrote:
On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
Forgive me for thinking out loud, but I'm trying to sort out how nova
would use a microversion in the nova API for the get-me-a-network
feature recently added to neutron [1] and planned to be leveraged in
nova (there isn't a spec yet for nova, I'm trying to sort this out for a
draft).
Originally I was thinking that a network is required for nova boot, so
we'd simply check for a microversion and allow not specifying a network,
easy peasy.
Turns out you can boot an instance in nova (with neutron as the network
backend) without a network. All you get is a measly debug log message in
the compute logs [2]. That's kind of useless though and seems silly.
I haven't tested this out yet to confirm, but I suspect that if you
create a nova instance w/o a network, you can latter try to attach a
network using the os-attach-interfaces API as long as you either provide
a network ID *or* there is a public shared network or the tenant has a
network at that point (nova looks those up if a specific network ID
isn't provided).
The high-level plan for get-me-a-network in nova was simply going to be
if the user tries to boot an instance and doesn't provide a network, and
there isn't a tenant network or public shared network to default to,
then nova would call neutron's new auto-allocated-topology API to get a
network. This, however, is a behavior change.
So I guess the question now is how do we handle that behavior change in
the nova API?
We could add an auto-create-net boolean to the boot server request which
would only be available in a microversion, then we could check that
boolean in the compute API when we're doing network validation.
I think a flag like this is the right approach. If it's currently valid
to boot an instance without a network than there needs to be something
to distinguish a request that wants a network created vs. a request that
doesn't want a network.
This is still hugely useful if all that's required from a user is to
indicate that they would like a network, they still don't need to
understand/provide details of the network.
I was thinking a sort of opposite. Would this work?
We add a new micro-version that does this:
* nothing specified: do the best we can to get a port created
(get-me-a-network, etc,), or fail if not possible
* --no-nics option (or similar) that says "please don't give me any nics"
This means folks that don't want a network, reliably have a way to do
that. For everyone else, we do the same thing when using either
neutron or nova-network VLAN manager.
Thanks,
johnthetubaguy
PS
I think we should focus on the horizon experience, CLI experience, and
API experience separately, for a moment, to make sure each of those
cases actually works out OK.
Today if you don't specify a network and don't have a network available,
then the validation in the API is basically just quota checking that you
can get at least one port in your tenant [3]. With a flag on a
microversion, we could also validate some other things about
auto-creating a network (if we know that's going to be the case once we
hit the compute).
Anyway, this is mostly me getting thoughts out of my head before the
weekend so I don't forget it and am looking for other ideas here or
things I might be missing.
[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
[2]
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
[3]
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think we're basically looking at the same use case. And as Kevin noted
I was thinking an option on the --nic part of the request, like
auto-allocate.
My thinking was with the microversion, that defaults to True and you
have to opt-in to the old behavior (specify auto-allocate=False) of nova
being OK with not providing any network for the instance. The flag that
goes down through the compute API and neutronv2 API code would default
to False for backward compat, we'd just default the option to True in
the REST API if not explicitly provided.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
