Open Stack

> On Feb 12, 2016, at 12:03 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> 
> 
> 
> On 2/12/2016 12:45 PM, John Garbutt wrote:
>> On 12 February 2016 at 18:17, Andrew Laski <andrew at 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-request at 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
>> 
>> __________________________________________________________________________
>> 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
>> 
> 
> 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.

I thought one of the original notions behind this was to make ‘nova boot’ as simple as in the nova-net case, which would imply not needing to use —nic at all. I personally like the idea of the flag being for the no network case.

doug


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