Open Stack

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

> 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
> [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/20160215/c4e5b602/attachment.html>