Open Stack

cool, then option 2 makes sense.

On Thu, Feb 25, 2016 at 9:41 PM, Kevin Benton <kevin at benton.pub> wrote:

> The router is automatically created as well and is attached to the tenants
> network and an external network with the flag 'is_default' set to true.
> On Feb 24, 2016 6:25 PM, "Robert Starmer" <robert at kumul.us> wrote:
>
>> Most service environments I've worked with will deploy (often
>> automatically) a first tenant network and router, allowing for the simple
>> case of "deploy a vm, and it auto attaches to the only network" model.  So
>> in effect, this is anticipated, if not expected, behavior.  If on the other
>> hand, there is no network, does the auto-network process also create a
>> router, and associate that router with an "external" network with floating
>> address/etc.?  If not, then isn't the --nic=auto case effectively
>> equivalent to the no network case anyway? there's still neutron work to be
>> done, and the VM will likely need to have a DHCP lease re-established if a
>> router is also attached so that the network has anything other than local
>> meaning.
>>
>> I.e., what was the original use case of this auto-created network (which
>> sounds like it's here to stay regardless).  Does someone have a pointer to
>> the spec that defines the use case of this.
>>
>> But even so, I'd say I prefer model 2 over the others, but perhaps a
>> warning needs to be generated, especially if the network isn't router
>> connected automatically, otherwise, the end user is going to be confused as
>> to why internet connectivity isn't available ("I see a network attached,
>> but I can't get to the internet").
>>
>> Just my $0.02
>> Robert
>>
>> On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller <amuller at redhat.com> wrote:
>>
>>> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
>>> <mriedem at linux.vnet.ibm.com> wrote:
>>> >
>>> >
>>> > On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>>> >>
>>> >>
>>> >>
>>> >> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> ___________________________________________________________________
>>> >>> Kris Lindgren
>>> >>> Senior Linux Systems Engineer
>>> >>> GoDaddy
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 2/19/16, 10:07 AM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com>
>>> >>> wrote:
>>> >>>
>>> >>>> There is a long contentious dev thread going on here [1] about how
>>> Nova
>>> >>>> should handle the Neutron auto-allocate-topology API (referred to
>>> as the
>>> >>>> 'get-me-a-network' effort).
>>> >>>>
>>> >>>> The point is to reduce the complexity for users to simply boot an
>>> >>>> instance and be able to ssh into it without having to first setup
>>> >>>> networks/subnets/routers in neutron and then specify a nic when
>>> booting
>>> >>>> the instance. If the planets are aligned, and no nic is provided (or
>>> >>>> available to the project), then nova would call the new neutron API
>>> to
>>> >>>> auto-allocate the network and use that to create a port to associate
>>> >>>> with the instance.
>>> >>>>
>>> >>>> There is existing behavior in Nova where you can boot an instance
>>> and
>>> >>>> get no networking with neutron as the backend. You can later add
>>> >>>> networking by attaching an interface. The nova dev team has no idea
>>> how
>>> >>>> common this use case is though.
>>> >>>>
>>> >>>> There will be a microversion to the nova API with the
>>> get-me-a-network
>>> >>>> support. The debate is what the default behavior should be when
>>> using
>>> >>>> that microversion. The options are basically:
>>> >>>>
>>> >>>> 1. If no nic is provided at boot and none are available, don't
>>> provide a
>>> >>>> network (existing behavior). If the user wants a network
>>> auto-allocated,
>>> >>>> they specify something like: --nic=auto
>>> >>>
>>> >>>
>>> >>> This is my preferred choice - keep the functionality exactly the same
>>> >>> as the way it is today.  Users (if this is available) can opt-in.
>>> Not
>>> >>> 100% familiar with micro-version - but is it possible to opt-out of
>>> >>> this micro-version all together, but have other, later,
>>> micro-versions?
>>> >>
>>> >>
>>> >> Users/clients opt into a microversion by specifying a header with the
>>> >> version in the request. You can't skip microversions. If your client
>>> >> support 2.10 and then you wanted to support 2.18, for example, you
>>> have
>>> >> to also build in support for handling 2.11-2.17.
>>> >>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>> In this case the user has to opt into auto-allocating the network.
>>> >>>>
>>> >>>> 2. If no nic is provided at boot and none are available, nova will
>>> >>>> attempt to auto-allocate the network from neutron. If the user
>>> >>>> specifically doesn't want networking on instance create (for
>>> whatever
>>> >>>> reason), they have to opt into that behavior with something like:
>>> >>>> --nic=none
>>> >>>>
>>> >>>> This is closer in behavior to how booting an instance works with
>>> >>>> nova-network, but it is a change in the default behavior for the
>>> neutron
>>> >>>> case, and that is a cause for concern for any users that have
>>> written
>>> >>>> tools to expect that default behavior.
>>> >>>
>>> >>>
>>> >>>
>>> >>> I don't like this but I think other people might.  Really I would
>>> like
>>> >>> to see a config option detailing how the cloud admin wants to handle
>>> >>> this behavior.
>>> >>
>>> >>
>>> >> With the push for more consistent API behavior across public OpenStack
>>> >> clouds, making the API configurable with config options is not really
>>> a
>>> >> thing we want to do anymore since it's not discoverable. If cloud A
>>> >> doesn't support this but cloud B does, even though you've specified
>>> the
>>> >> same microversion for both, it's confusing and unreliable. Of course
>>> we
>>> >> already have some of this situation already since not all of the virt
>>> >> driver backends support 100% of the REST API, but I don't think we
>>> want
>>> >> to add to that if we can help it.
>>> >
>>> >
>>> > Thinking about this again today, nova is going to be checking that the
>>> > auto-allocate-topolocy extension is enabled in neutron. So if you just
>>> don't
>>> > enable that extension, you've effectively disabled the nic=auto option
>>> in
>>> > nova. Basically like a config option.
>>>
>>> Only you kinda can't:
>>>
>>> https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41
>>>
>>> get-me-a-network is enabled by default, so if you're running a recent
>>> enough Neutron you're just going to get that extension enabled.
>>>
>>> >
>>> >
>>> >>
>>> >>>
>>> >>>>
>>> >>>> 3. If no nic is provided at boot and none are available, fail the
>>> >>>> request and force the request to be explicit, i.e. provide a
>>> specific
>>> >>>> nic, or auto, or none. This is a fail-fast scenario to force users
>>> to
>>> >>>> really state what they want.
>>> >>>
>>> >>>
>>> >>> I don't like this option at all.  You are chaning what people must
>>> >>> provide on the bootline and this as far as I can tell is a breaking
>>> >>> change.
>>> >>
>>> >>
>>> >> Yes it's a breaking change, but with a microversion you have to opt
>>> into
>>> >> it, so you have to be aware of it when you make the request. Just FYI.
>>> >>
>>> >>>
>>> >>>>
>>> >>>> --
>>> >>>>
>>> >>>> As with any microversion change, we hope that users are reading the
>>> docs
>>> >>>> and aware of the changes in each microversion, but we can't
>>> guarantee
>>> >>>> that, so changing default behavior (case 2) requires discussion and
>>> >>>> input, especially from outside the dev team.
>>> >>>>
>>> >>>> If you or your users have any input on this, please respond in this
>>> >>>> thread of the one in the -dev list.
>>> >>>>
>>> >>>> [1]
>>> >>>>
>>> >>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Matt Riedemann
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> OpenStack-operators mailing list
>>> >>>> OpenStack-operators at lists.openstack.org
>>> >>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >>
>>> >>
>>> >
>>> > --
>>> >
>>> > Thanks,
>>> >
>>> > Matt Riedemann
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-operators mailing list
>>> > OpenStack-operators at lists.openstack.org
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160226/d0b39c62/attachment.html>