On 2/12/2016 12:44 PM, Armando M. wrote:
On 12 February 2016 at 09:15, Matt Riedemann <mrie...@linux.vnet.ibm.com
<mailto:mrie...@linux.vnet.ibm.com>> 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.
Incidentally, I was checking this out with Horizon, and the dashboard
instance boot workflow doesn't let you proceed without specifying a
network (irrespective of the network backend). So if the user has no
networks, he/she is stuck and has to flip to the CLI. <sarcasm>Nice,
uh</sarcasm>?
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).
Just to make sure we're on the same page: if you're referring to 'public
shared network' as the devstack's provisioned network called 'public',
that's technically not shared and it represent your floating IP pool. A
user can explicitly boot VM's on it, but that's not to be confused with
a 'shared' provider network.
I was referring to this code:
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223
That said, I tried the workflow of booting a vm without networks and
trying to attach an interface without specifying anything and I got a
500 [1]. Error aside, I think it's it would be erroneous to expect the
attach command to accept no networks (and still pick one), when the boot
command doesn't.
[1] http://paste.openstack.org/show/486856/
Cool, yeah, I was totally expecting an IndexError because of the code here:
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610
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.
I assume that for you 'public shared network' it's not the public
network as available in DevStack because, because I don't believe that
user can boot VM's on that network automatically.
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.
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.
John and I just finished talking about this a bit more and I think the
the thought process led us to this conclusion:
From Horizon, we could provide a 'get-me-a-network' button on the
Networks wizard for the boot workflow. If the user doesn't see any
Networks available he/she can hit the button, see the network being
pre-populated and choose to proceed, instead of going back to the
Network panel and do the entire workflow.
As for Nova, we could introduce a new micro-version that changes the
behavior of nova boot without networks. In this case, if the tenant has
access to no networks, one will be created for him/her and the VM will
boot off of it.
On the other end, if the user does want a VM without nics, he/she should
be explicit about this and specify 'no-nic' boolean, e.g.
nova boot <instance-name> --flavor <flavor-id> --image <image-id>
--no-nics
John and I think this would be preferable because the output of the
command becomes more predictable: the user doesn't end up having VM's
connected to NICs accidentally if some net-create sneaks underneath.
Yeah, I replied to John's post and I think we're all basically on the
same page, it's just a matter of implementation details, but we're in
agreement that by default (with the microversion), you're going to get a
network allocated if you don't bring one or have one available, unless
you explicitly opt out of that with some flag on the request.
Anyhow, food for thought.
Thanks for starting this thread.
Cheers,
Armando
[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://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
--
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
