[openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

Andrew Laski andrew at lascii.com
Mon Feb 22 19:50:22 UTC 2016



On Mon, Feb 22, 2016, at 02:42 PM, Matt Riedemann wrote:
> 
> 
> On 2/22/2016 5:56 AM, Sean Dague wrote:
> > On 02/19/2016 12:49 PM, John Garbutt wrote:
> > <snip>
> >>
> >> Consider a user that uses these four clouds:
> >> * nova-network flat DHCP
> >> * nova-network VLAN manager
> >> * neutron with a single provider network setup
> >> * neutron where user needs to create their own network
> >>
> >> For the first three, the user specifies no network, and they just get
> >> a single NIC with some semi-sensible IP address, likely with a gateway
> >> to the internet.
> >>
> >> For the last one, the user ends up with a network with zero NICs. If
> >> they then go and configure a network in neutron (and they can now use
> >> the new easy one shot give-me-a-network CLI), they start to get VMs
> >> just like they would have with nova-network VLAN manager.
> >>
> >> We all agree the status quo is broken. For me, this is a bug in the
> >> API where we need to fix the consistency. Because its a change in the
> >> behaviour, it needs to be gated by a micro version.
> >>
> >> Now, if we step back and created this again, I would agree that
> >> --nic=auto is a good idea, so its explicit. However, all our users are
> >> used to automatic being the default, all be it a very patchy default.
> >> So I think the best evolution here is to fix the inconsistency by
> >> making a VM with no network being the explicit option (--no-nic or
> >> something?), and failing the build if we are unable to get a nic using
> >> an "automatic guess" route. So now the default is more consistent, and
> >> those that what a VM with no NIC have a way to get their special case
> >> sorted.
> >>
> >> I think this means I like "option 2" in the summary mail on the ops list.
> >
> > Thinking through this over the weekend.
> >
> >  From the API I think I agree with Laski now. An API shouldn't doesn't
> > typically need default behavior, it's ok to make folks be explicit. So
> > making nic a required parameter is fine.
> >
> > "nic": "auto"
> > "nic": "none"
> > "nic": "$name"
> >
> > nic is now jsonschema enforced, 400 if not provided.
> >
> > that being said... I think the behavior of CLI tools should default to
> > nic auto being implied. The user experience there is different. You use
> > cli tools for one off boots of things, so should be as easy as possible.
> >
> > I think this is one of the places where the UX needs of the API and the
> > CLI are definitely different.
> >
> > 	-Sean
> >
> 
> Is nic only required when using neutron? Or as part of the microversion 
> are we also going to enforce this for nova-network, because if so, that 
> seems like a step backward. But if we don't enforce that check for both 
> neutron and nova-network, then we have differences in the API again.

I think it makes sense to require it in both cases and keep users
blissfully unaware of which networking service is in use.

> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list