cool, then option 2 makes sense. On Thu, Feb 25, 2016 at 9:41 PM, Kevin Benton <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: >> >>> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann >>> <[email protected]> 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" <[email protected]> >>> >>> 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 >>> >>>> [email protected] >>> >>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >>> >> >>> > >>> > -- >>> > >>> > Thanks, >>> > >>> > Matt Riedemann >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-operators mailing list >>> > [email protected] >>> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >> >> _______________________________________________ >> OpenStack-operators mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >>
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
