Open Stack

On 2/14/16, 3:59 PM, "Ken'ichi Ohmichi" <ken1ohmichi at gmail.com> wrote:

>2016-02-12 11:19 GMT-08:00 Andrew Laski <andrew at lascii.com>:
>> On Fri, Feb 12, 2016, at 01: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.
>>
>> I think this pushes our microversions meaning a bit further than
>> intended. I don't think the API should flip behaviors simply based on a
>> microversion.
>>
>> What about requiring nic information with the microversion? Make users
>> indicate explicitly if they want a network or not and avoid changing a
>> default behavior.
>
>I agree with alaski's point here.
>The default behavior changes can hurt API users easily even if bumping
>a microversion because it is difficult to pay attentions for all
>microversions' changes(we have already 22 microversions now) from
>users' viewpoints.

Were there any cross project discussions about this feature or are we
discussing this after the fact?
I do not think that we should be changing the default behavior.

>
>Thanks
>Ken Ohmichi
>
>__________________________________________________________________________
>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