Open Stack

On 12 February 2016 at 09:15, Matt Riedemann <mriedem at 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.

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/


> 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.

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160212/6f24eeac/attachment.html>