Open Stack

>From a public cloud perspective I'm not convinced that an opt-out argument
is the right way to go. A router in our context is a chargeable item,
because it has an external IP address, so automatically creating stuff
without the user specifying it is not an ideal outcome. Personally I'd
rather see an opt-in argument ie. option 1

On 26 February 2016 at 11:05, Robert Starmer <robert at kumul.us> wrote:

> 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
>>>
>>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160226/06c71ff8/attachment-0001.html>