Open Stack

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/20160225/d9d10a3c/attachment.html>