Open Stack

On 12 February 2016 at 11:08, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> 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
>
>
Ok I am with you: the public in the comment is somewhat misleading because
there's nothing 'public' about a shared network and as a matter of fact
RBAC [1] allows for networks to be shared only to a subset of tenants.

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html


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

I think we're understanding the problem space a bit more, for sure.
Hopefully we have all the building blocks in place to execute on this.


>
>
>> 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
>
>
> __________________________________________________________________________
> 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/0883dca4/attachment.html>