Open Stack

On 2/15/2016 1:41 AM, Gary Kotton wrote:
> Yes, you could consider Neutron as a proxy for this. It creates the
> network, subnet, router… To be honest I think that we should maybe
> consider ofering a template that can be created by Neutron and then the
> template ID passed from Nova or wherever. This will enable an admin to
> pre cook a number of different templates for different use cases. But
> maybe that I too far down the line.
>
>
> From: Alex Xu <soulxu at gmail.com <mailto:soulxu at gmail.com>>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Monday, February 15, 2016 at 7:06 AM
> To: OpenStack List <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [nova][neutron] How would nova microversion
> get-me-a-network in the API?
>
> May I ask can we put those thing in to the CLI? I guess there should
> have similar discussion and I missed. As we didn't want to provide more
> neutron API proxy, this works sounds like adding more proxy. And API is
> more simple and more flexible, this make the API have more complex
> behaviour. Just like evacuate API, it just does one thing, for evacuate
> the all the instances on the host, that should be CLI thing.
>
> Thanks
> Alex
>
> 2016-02-13 1:15 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>>:
>
>     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.
>
>     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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L594-2DL595&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs&s=t42iKObPq-keVfC3EZd9X7WyehiSgwzxw501xt7wqyM&e=>
>     [3]
>     https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L1107&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs&s=ddAFuD4WtYtA_FxgOglckfO17USVYIlVzihIiZWvsrA&e=>
>
>     --
>
>     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
>

These are fair questions, and yes, this is definitely adding more proxy 
code in nova, which we've stated that we don't want to do anymore. This 
would be akin to boot from volume where you're not bringing your own 
volume to attach, and that has it's own issues (mostly around timing 
issues and cleanup when things fail).

So this does add more orchestration to the API, which is unfortunate, 
but it is also an attempt to get the API to behave closer to how it 
works with nova-network, and simplify the API. So I think this is an 
exceptional case and honestly if it were a major deal breaker, I'd have 
expected the interested parties to have brought it up and squashed it up 
long ago (like the YVR summit).

-- 

Thanks,

Matt Riedemann