Open Stack

On 2/12/2016 12:44 PM, Armando M. wrote:
>
>
> On 12 February 2016 at 09:15, Matt Riedemann <mriedem at linux.vnet.ibm.com
> <mailto: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.

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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 

Thanks,

Matt Riedemann