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

[Matt Riedemann]

On 2/22/2016 2:27 PM, Sean Dague wrote:

On 02/22/2016 02:50 PM, Andrew Laski wrote:



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:



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.


+1

This should make the experience between both far more consistent. It
means making n-net API applications do a bit more work then now, but
it's explicit.

It also means the CLI experience should continue to be the same, because
--nic=auto is implied.

-Sean



OK, here is the spec so we can move discussion there now:

https://review.openstack.org/#/c/283206/

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

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:
> > 
> >>
> >> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 2/22/2016 5:56 AM, Sean Dague wrote:

On 02/19/2016 12:49 PM, John Garbutt wrote:



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.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Garbutt]

On 22 February 2016 at 15:14, John Garbutt  wrote:
> On 22 February 2016 at 12:01, Jay Pipes  wrote:
>> On 02/22/2016 06:56 AM, Sean Dague wrote:
>>> On 02/19/2016 12:49 PM, John Garbutt wrote:
>>> 
 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.
>>
>> I'd be cool with this, too.
>
> +1 I am OK with this.
>
> Its an explicit API, its can be the same for nova-network and neutron,
> and supports the CLI behaviour folks want.
>
> Just to clarify with nic=auto, if there is no way to create a nic
> automatically (not allowed to do give-me-a-network, and no networks
> available, or the user has more than one network available, etc), we
> should fail the build of the server. Today I think we (sometimes?) end
> up falling back to nic=none, which seems totally counter to the
> explicit nature of the API. Its possible we could fail before the API
> returns, as least of the most likely reasons for failure (might need
> more neutron APIs - policy discovery - to do a more complete job of
> that).

Oh, I forgot to mention Horizon...

Talking with folks, since they require a network to be selected in the
create server flow, its likely they will use the new neutron API to
help populate their network drop down, rather than use these changes
in the Nova API. Although, I guess they might want to expose the new
nic=none option, thats not related to the key "first boot in a new
tenant" that we are trying to improve.

I think that means restricting our thoughts to just the Nova CLI and
direct API users, is OK. Although I am curious if that fits with
everyone's thinking about this topic?

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Garbutt]

On 22 February 2016 at 12:01, Jay Pipes  wrote:
> On 02/22/2016 06:56 AM, Sean Dague wrote:
>> On 02/19/2016 12:49 PM, John Garbutt wrote:
>> 
>>> 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.
>
> I'd be cool with this, too.

+1 I am OK with this.

Its an explicit API, its can be the same for nova-network and neutron,
and supports the CLI behaviour folks want.

Just to clarify with nic=auto, if there is no way to create a nic
automatically (not allowed to do give-me-a-network, and no networks
available, or the user has more than one network available, etc), we
should fail the build of the server. Today I think we (sometimes?) end
up falling back to nic=none, which seems totally counter to the
explicit nature of the API. Its possible we could fail before the API
returns, as least of the most likely reasons for failure (might need
more neutron APIs - policy discovery - to do a more complete job of
that).

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Mon, Feb 22, 2016, at 07:07 AM, Chris Dent wrote:
> On Mon, 22 Feb 2016, Sean Dague wrote:
> 
> > 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.
> 
> Thanks Sean, throughout this entire conversation I've been confused
> by the apparent overlap or conflation of the API's interface and the
> command line client's interface.
> 
> I agree that the API should be explicit and that the command line
> should have sane defaults that don't violate the principle of least
> surprise.
> 
> +1

I completely agree with this.

> 
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

On Mon, 22 Feb 2016, Sean Dague wrote:


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.


Thanks Sean, throughout this entire conversation I've been confused
by the apparent overlap or conflation of the API's interface and the
command line client's interface.

I agree that the API should be explicit and that the command line
should have sane defaults that don't violate the principle of least
surprise.

+1

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 02/22/2016 06:56 AM, Sean Dague wrote:

On 02/19/2016 12:49 PM, John Garbutt wrote:



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.


I'd be cool with this, too.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 02/19/2016 12:49 PM, John Garbutt wrote:

> 
> 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

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Akihiro Motoki]

Sorry for chiming in late.

It sounds natural to me that when no --nic option is specified and no
neutron network exists 'get-me-a-network' feature is used.
After a network for a project is created by a get-me-a-network or when
a project already has one network,
a user do not need to specify --nic option to launch an instance. I
think it is a consistent user experience.

"--nic auto" makes sense to some extent but it forces users to use
"--nic auto" option always (for a consistent behavior).

As already discussed, it will change the current behavior in a case
where there is no network,
but users have knowledge that they need to create a network first and
it is rare that a user wants to boot an instance without a network.


Regarding Horizon, I think we can support more user-friendly interaction.
The current launch instance form selects a network as default when
only one network exists.
We can do similar for 'get-me-a-network' case.
Horizon checks if there is a network for a project and if a network
does not exis
 and get-me-a-network is supported by both nova and neutron,
we can show 'auto-allocate' network as a default selection.
A user can continue to launch an instance with get-me-a-network,
or cancel launching an instance and create a network as he wants.

Thanks,
Akihiro


2016-02-20 12:06 GMT+09:00 Armando M. :
>
>
> On 19 February 2016 at 09:49, John Garbutt  wrote:
>>
>> On 19 February 2016 at 16:28, Andrew Laski  wrote:
>> > On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:
>> >> On 02/19/2016 09:30 AM, Andrew Laski wrote:
>> >> >
>> >> >
>> >> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
>> >> >> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
>> >> >>
>> >> >>> This would be my preference as well, even though it's technically a
>> >> >>> backwards-incompatible API change.
>> >> >>>
>> >> >>> The idea behind get-me-a-network was specifically to remove the
>> >> >>> current required complexity of the nova boot command with regards to
>> >> >>> networking options and allow a return to the nova-net model where an 
>> >> >>> admin
>> >> >>> could auto-create a bunch of unassigned networks and the first time a 
>> >> >>> user
>> >> >>> booted an instance and did not specify any network configuration (the
>> >> >>> default, sane behaviour in nova-net), one of those unassigned 
>> >> >>> networks would
>> >> >>> be grabbed for the troject, I mean prenant, sorry.
>> >> >>>
>> >> >>> So yeah, the "opt-in to having no networking at all with a
>> >> >>> --no-networking or --no-nics option" would be my preference.
>> >> >>
>> >> >> +1 to this, especially opting in to have no network at all. It seems
>> >> >> most
>> >> >> friendly to me to have the network allocation automatically happen
>> >> >> if
>> >> >> nothing special is specified.
>> >> >>
>> >> >> This is something where it seems like we need a "reset" to a default
>> >> >> behavior that is user-friendly. And microversions is the way we have
>> >> >> to
>> >> >> "fix" an undesirable current default behavior.
>> >> >
>> >> > The question I would still like to see addressed is why do we need to
>> >> > have a default behavior here? The get-me-a-network effort is
>> >> > motivated
>> >> > by the current complexity of setting up a network for an instance
>> >> > between Nova and Neutron and wants to get back to a simpler time of
>> >> > being able to just boot an instance and get a network. But it still
>> >> > isn't clear to me why requiring something like "--nic auto" wouldn't
>> >> > work here, and eliminate the confusion of changing a default
>> >> > behavior.
>> >>
>> >> The point was the default behavior was a major concern to people. It's
>> >> not like this was always the behavior. If you were (or are) on nova
>> >> net,
>> >> you don't need that option at all.
>> >
>> > Which is why I would prefer to shy away from default behaviors.
>> >
>> >>
>> >> The major reason we implemented API microversions was so that we could
>> >> make the base API experience better for people, some day. One day,
>> >> we'll
>> >> have an API we love, hopefully. Doing so means that we do need to make
>> >> changes to defaults. Deprecate some weird and unmaintained bits.
>> >>
>> >> The principle of least surprise to me is that you don't need that
>> >> attribute at all. Do the right thing with the least amount of work.
>> >> Instead of making the majority of clients and users do extra work
>> >> because once upon a time when we brought in neutron a thing happen.
>> >
>> > The principal of least surprise to me is that a user explicitly asks for
>> > something rather than relying on a default that changes based on network
>> > service and/or microversion. This is the only area in the API where
>> > something did, and would, happen without explicitly being requested by a
>> > user. I just don't understand why it's special compared to
>> > flavor/image/volume which we require to 

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

[Jeremy Stanley]

On 2016-02-19 19:06:17 -0800 (-0800), Armando M. wrote:
[...]
> In fact, if we continue to keep --nic an optional parameter, we
> can reconcile the behavior between nova-net and neutron (which is
> really the win here - make different clouds behave alike).
[...]

Restated, Nova network feature parity was promised by Qua^WNeutron
from the start, and this can be seen simply as filling one of the
remaining, long-standing parity gaps. Even though some "early"
adopters of Neutron might now have grown attached to an unfortunate
and temporary inconsistency between these implementations, this
important work on feature parity should still be driven to
completion.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Armando M.]

On 19 February 2016 at 09:49, John Garbutt  wrote:

> On 19 February 2016 at 16:28, Andrew Laski  wrote:
> > On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:
> >> On 02/19/2016 09:30 AM, Andrew Laski wrote:
> >> >
> >> >
> >> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
> >> >> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
> >> >>
> >> >>> This would be my preference as well, even though it's technically a
> backwards-incompatible API change.
> >> >>>
> >> >>> The idea behind get-me-a-network was specifically to remove the
> current required complexity of the nova boot command with regards to
> networking options and allow a return to the nova-net model where an admin
> could auto-create a bunch of unassigned networks and the first time a user
> booted an instance and did not specify any network configuration (the
> default, sane behaviour in nova-net), one of those unassigned networks
> would be grabbed for the troject, I mean prenant, sorry.
> >> >>>
> >> >>> So yeah, the "opt-in to having no networking at all with a
> --no-networking or --no-nics option" would be my preference.
> >> >>
> >> >> +1 to this, especially opting in to have no network at all. It seems
> most
> >> >> friendly to me to have the network allocation automatically happen if
> >> >> nothing special is specified.
> >> >>
> >> >> This is something where it seems like we need a "reset" to a default
> >> >> behavior that is user-friendly. And microversions is the way we have
> to
> >> >> "fix" an undesirable current default behavior.
> >> >
> >> > The question I would still like to see addressed is why do we need to
> >> > have a default behavior here? The get-me-a-network effort is motivated
> >> > by the current complexity of setting up a network for an instance
> >> > between Nova and Neutron and wants to get back to a simpler time of
> >> > being able to just boot an instance and get a network. But it still
> >> > isn't clear to me why requiring something like "--nic auto" wouldn't
> >> > work here, and eliminate the confusion of changing a default behavior.
> >>
> >> The point was the default behavior was a major concern to people. It's
> >> not like this was always the behavior. If you were (or are) on nova net,
> >> you don't need that option at all.
> >
> > Which is why I would prefer to shy away from default behaviors.
> >
> >>
> >> The major reason we implemented API microversions was so that we could
> >> make the base API experience better for people, some day. One day, we'll
> >> have an API we love, hopefully. Doing so means that we do need to make
> >> changes to defaults. Deprecate some weird and unmaintained bits.
> >>
> >> The principle of least surprise to me is that you don't need that
> >> attribute at all. Do the right thing with the least amount of work.
> >> Instead of making the majority of clients and users do extra work
> >> because once upon a time when we brought in neutron a thing happen.
> >
> > The principal of least surprise to me is that a user explicitly asks for
> > something rather than relying on a default that changes based on network
> > service and/or microversion. This is the only area in the API where
> > something did, and would, happen without explicitly being requested by a
> > user. I just don't understand why it's special compared to
> > flavor/image/volume which we require to be explicit. But I think we just
> > need to agree to disagree here.
>
> 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.
>

As much as I can see why a '--nic auto' option makes sense to some, 

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

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/2016 11:49 AM, John Garbutt wrote:

> 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.

If we expect Nova to be in use for years to come, it makes sense to
accept a little short-term discomfort for a much better long-term
experience. Given that there is no magic solution that will make
everyone happy in all cases, we should favor the one that over the
long haul creates the most number of happy users. The microversion
bump to auto-create a network, IMO, is the least disruptive to
existing use cases and the best choice for the future. We can't wring
our hands forever because we can't make everyone happy.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWx2GtAAoJEKMgtcocwZqL61wQALYd9VMWXtNiG31Y2G8p4sPE
Ya9jb4baoGIbWPE9YBnojZQiFcpaFJt6Z0puWS6ohQq/CLXMqRsrzZuG7WgX5Juw
RL+LJAwdZKYVaO7RO0qU91Xf8oYWMojebWx8lJybEgrdnlMtWcP43cGNdA+0qvQt
EQZEcRDm2MO5qLRKJSn3f1QYDNjRK4OnmJUK9HwMK83J3A18qS6YFzH65PLUshjP
UAYd4co0A6tBiHQ3XWr/xvCYcNvcSAw+k6qm3gN2IjMaA/L1kNir4ZdxTdv83P44
G0EWdS1SM1fWkv98caCq8swsN3OtyqbouVlFusaifysUzJYJIWdqNqk3gyKCkE34
mCWGq51rM5C3wXBJ4F5AfI9NnnL6jel5CXw7GNxlld9HKB0NQX3bxANzctH+yBDf
/BROU2lUvLtwUsTOnYMFcRUQJilnyF+MZMWY2bo7Bc/HrylMU3RgHoCBNo31sTuK
PnwdTNf8rBQzM6ieBJMYtcYsSUhkfxXfJGIlLeaYHVSQz38rZAdII3GRQHyvKqaL
0WTvpgb1yWoz6LHjdDOWhAY4fG2FAzcCOAfIJg7mryCBmL7kiA9D3gjDXBMaKRzV
eQ7XHotBIQ/A759/8f0/8hbkyB+iBjW5FW+NmeK3uKFUS1p0Q98dnyJC7oqPDkHf
i/EDeUEJrrNwO/tnYgXO
=hJLe
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Garbutt]

On 19 February 2016 at 16:28, Andrew Laski  wrote:
> On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:
>> On 02/19/2016 09:30 AM, Andrew Laski wrote:
>> >
>> >
>> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
>> >> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
>> >>
>> >>> This would be my preference as well, even though it's technically a 
>> >>> backwards-incompatible API change.
>> >>>
>> >>> The idea behind get-me-a-network was specifically to remove the current 
>> >>> required complexity of the nova boot command with regards to networking 
>> >>> options and allow a return to the nova-net model where an admin could 
>> >>> auto-create a bunch of unassigned networks and the first time a user 
>> >>> booted an instance and did not specify any network configuration (the 
>> >>> default, sane behaviour in nova-net), one of those unassigned networks 
>> >>> would be grabbed for the troject, I mean prenant, sorry.
>> >>>
>> >>> So yeah, the "opt-in to having no networking at all with a 
>> >>> --no-networking or --no-nics option" would be my preference.
>> >>
>> >> +1 to this, especially opting in to have no network at all. It seems most
>> >> friendly to me to have the network allocation automatically happen if
>> >> nothing special is specified.
>> >>
>> >> This is something where it seems like we need a "reset" to a default
>> >> behavior that is user-friendly. And microversions is the way we have to
>> >> "fix" an undesirable current default behavior.
>> >
>> > The question I would still like to see addressed is why do we need to
>> > have a default behavior here? The get-me-a-network effort is motivated
>> > by the current complexity of setting up a network for an instance
>> > between Nova and Neutron and wants to get back to a simpler time of
>> > being able to just boot an instance and get a network. But it still
>> > isn't clear to me why requiring something like "--nic auto" wouldn't
>> > work here, and eliminate the confusion of changing a default behavior.
>>
>> The point was the default behavior was a major concern to people. It's
>> not like this was always the behavior. If you were (or are) on nova net,
>> you don't need that option at all.
>
> Which is why I would prefer to shy away from default behaviors.
>
>>
>> The major reason we implemented API microversions was so that we could
>> make the base API experience better for people, some day. One day, we'll
>> have an API we love, hopefully. Doing so means that we do need to make
>> changes to defaults. Deprecate some weird and unmaintained bits.
>>
>> The principle of least surprise to me is that you don't need that
>> attribute at all. Do the right thing with the least amount of work.
>> Instead of making the majority of clients and users do extra work
>> because once upon a time when we brought in neutron a thing happen.
>
> The principal of least surprise to me is that a user explicitly asks for
> something rather than relying on a default that changes based on network
> service and/or microversion. This is the only area in the API where
> something did, and would, happen without explicitly being requested by a
> user. I just don't understand why it's special compared to
> flavor/image/volume which we require to be explicit. But I think we just
> need to agree to disagree here.

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.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

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

[Andrew Laski]

On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:
> On 02/19/2016 09:30 AM, Andrew Laski wrote:
> > 
> > 
> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
> >> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
> >>
> >>> This would be my preference as well, even though it's technically a 
> >>> backwards-incompatible API change.
> >>>
> >>> The idea behind get-me-a-network was specifically to remove the current 
> >>> required complexity of the nova boot command with regards to networking 
> >>> options and allow a return to the nova-net model where an admin could 
> >>> auto-create a bunch of unassigned networks and the first time a user 
> >>> booted an instance and did not specify any network configuration (the 
> >>> default, sane behaviour in nova-net), one of those unassigned networks 
> >>> would be grabbed for the troject, I mean prenant, sorry.
> >>>
> >>> So yeah, the "opt-in to having no networking at all with a 
> >>> --no-networking or --no-nics option" would be my preference.
> >>
> >> +1 to this, especially opting in to have no network at all. It seems most
> >> friendly to me to have the network allocation automatically happen if
> >> nothing special is specified.
> >>
> >> This is something where it seems like we need a "reset" to a default
> >> behavior that is user-friendly. And microversions is the way we have to
> >> "fix" an undesirable current default behavior.
> > 
> > The question I would still like to see addressed is why do we need to
> > have a default behavior here? The get-me-a-network effort is motivated
> > by the current complexity of setting up a network for an instance
> > between Nova and Neutron and wants to get back to a simpler time of
> > being able to just boot an instance and get a network. But it still
> > isn't clear to me why requiring something like "--nic auto" wouldn't
> > work here, and eliminate the confusion of changing a default behavior.
> 
> The point was the default behavior was a major concern to people. It's
> not like this was always the behavior. If you were (or are) on nova net,
> you don't need that option at all.

Which is why I would prefer to shy away from default behaviors.

> 
> The major reason we implemented API microversions was so that we could
> make the base API experience better for people, some day. One day, we'll
> have an API we love, hopefully. Doing so means that we do need to make
> changes to defaults. Deprecate some weird and unmaintained bits.
> 
> The principle of least surprise to me is that you don't need that
> attribute at all. Do the right thing with the least amount of work.
> Instead of making the majority of clients and users do extra work
> because once upon a time when we brought in neutron a thing happen.

The principal of least surprise to me is that a user explicitly asks for
something rather than relying on a default that changes based on network
service and/or microversion. This is the only area in the API where
something did, and would, happen without explicitly being requested by a
user. I just don't understand why it's special compared to
flavor/image/volume which we require to be explicit. But I think we just
need to agree to disagree here.

> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 02/19/2016 09:30 AM, Andrew Laski wrote:
> 
> 
> On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
>> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
>>
>>> This would be my preference as well, even though it's technically a 
>>> backwards-incompatible API change.
>>>
>>> The idea behind get-me-a-network was specifically to remove the current 
>>> required complexity of the nova boot command with regards to networking 
>>> options and allow a return to the nova-net model where an admin could 
>>> auto-create a bunch of unassigned networks and the first time a user booted 
>>> an instance and did not specify any network configuration (the default, 
>>> sane behaviour in nova-net), one of those unassigned networks would be 
>>> grabbed for the troject, I mean prenant, sorry.
>>>
>>> So yeah, the "opt-in to having no networking at all with a --no-networking 
>>> or --no-nics option" would be my preference.
>>
>> +1 to this, especially opting in to have no network at all. It seems most
>> friendly to me to have the network allocation automatically happen if
>> nothing special is specified.
>>
>> This is something where it seems like we need a "reset" to a default
>> behavior that is user-friendly. And microversions is the way we have to
>> "fix" an undesirable current default behavior.
> 
> The question I would still like to see addressed is why do we need to
> have a default behavior here? The get-me-a-network effort is motivated
> by the current complexity of setting up a network for an instance
> between Nova and Neutron and wants to get back to a simpler time of
> being able to just boot an instance and get a network. But it still
> isn't clear to me why requiring something like "--nic auto" wouldn't
> work here, and eliminate the confusion of changing a default behavior.

The point was the default behavior was a major concern to people. It's
not like this was always the behavior. If you were (or are) on nova net,
you don't need that option at all.

The major reason we implemented API microversions was so that we could
make the base API experience better for people, some day. One day, we'll
have an API we love, hopefully. Doing so means that we do need to make
changes to defaults. Deprecate some weird and unmaintained bits.

The principle of least surprise to me is that you don't need that
attribute at all. Do the right thing with the least amount of work.
Instead of making the majority of clients and users do extra work
because once upon a time when we brought in neutron a thing happen.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
> 
> > This would be my preference as well, even though it's technically a 
> > backwards-incompatible API change.
> > 
> > The idea behind get-me-a-network was specifically to remove the current 
> > required complexity of the nova boot command with regards to networking 
> > options and allow a return to the nova-net model where an admin could 
> > auto-create a bunch of unassigned networks and the first time a user booted 
> > an instance and did not specify any network configuration (the default, 
> > sane behaviour in nova-net), one of those unassigned networks would be 
> > grabbed for the troject, I mean prenant, sorry.
> > 
> > So yeah, the "opt-in to having no networking at all with a --no-networking 
> > or --no-nics option" would be my preference.
> 
> +1 to this, especially opting in to have no network at all. It seems most
> friendly to me to have the network allocation automatically happen if
> nothing special is specified.
> 
> This is something where it seems like we need a "reset" to a default
> behavior that is user-friendly. And microversions is the way we have to
> "fix" an undesirable current default behavior.

The question I would still like to see addressed is why do we need to
have a default behavior here? The get-me-a-network effort is motivated
by the current complexity of setting up a network for an instance
between Nova and Neutron and wants to get back to a simpler time of
being able to just boot an instance and get a network. But it still
isn't clear to me why requiring something like "--nic auto" wouldn't
work here, and eliminate the confusion of changing a default behavior.



> 
> While I get that a backward-incompatible change may appear to "sneak in"
> for a user specifying a later microversion to get an unrelated feature,
> it seems reasonable to me that a user specifying a microversion would
> consult the documentation for the version delta to get a clear picture of
> what to expect once they specify the new version. This of course hinges
> on users knowing how microversions work and being familiar with
> consulting documentation when changing versions. I hope that is the case
> and I hope this change will come with a very clear and concise release
> note with a link to [1].

I do hope that users read the documentation and aren't caught unaware if
we make a change like this. But we can make it even easier for them to
know that something has changed if instead of changing default behavior
we make that behavior explicit.


> 
> -melanie
> 
> [1]
> http://docs.openstack.org/developer/nova/api_microversion_history.html
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[melanie witt]

On Feb 12, 2016, at 14:49, Jay Pipes  wrote:

> This would be my preference as well, even though it's technically a 
> backwards-incompatible API change.
> 
> The idea behind get-me-a-network was specifically to remove the current 
> required complexity of the nova boot command with regards to networking 
> options and allow a return to the nova-net model where an admin could 
> auto-create a bunch of unassigned networks and the first time a user booted 
> an instance and did not specify any network configuration (the default, sane 
> behaviour in nova-net), one of those unassigned networks would be grabbed for 
> the troject, I mean prenant, sorry.
> 
> So yeah, the "opt-in to having no networking at all with a --no-networking or 
> --no-nics option" would be my preference.

+1 to this, especially opting in to have no network at all. It seems most 
friendly to me to have the network allocation automatically happen if nothing 
special is specified.

This is something where it seems like we need a "reset" to a default behavior 
that is user-friendly. And microversions is the way we have to "fix" an 
undesirable current default behavior.

While I get that a backward-incompatible change may appear to "sneak in" for a 
user specifying a later microversion to get an unrelated feature, it seems 
reasonable to me that a user specifying a microversion would consult the 
documentation for the version delta to get a clear picture of what to expect 
once they specify the new version. This of course hinges on users knowing how 
microversions work and being familiar with consulting documentation when 
changing versions. I hope that is the case and I hope this change will come 
with a very clear and concise release note with a link to [1].

-melanie

[1] http://docs.openstack.org/developer/nova/api_microversion_history.html



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 2/15/2016 1:41 AM, Gary Kotton wrote:

Yes, you could consider Neutron as a proxy for this. It creates the
network, subnet, router… To be honest I think that we should maybe
consider ofering a template that can be created by Neutron and then the
template ID passed from Nova or wherever. This will enable an admin to
pre cook a number of different templates for different use cases. But
maybe that I too far down the line.


From: Alex Xu <sou...@gmail.com <mailto:sou...@gmail.com>>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, February 15, 2016 at 7:06 AM
To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova][neutron] How would nova microversion
get-me-a-network in the API?

May I ask can we put those thing in to the CLI? I guess there should
have similar discussion and I missed. As we didn't want to provide more
neutron API proxy, this works sounds like adding more proxy. And API is
more simple and more flexible, this make the API have more complex
behaviour. Just like evacuate API, it just does one thing, for evacuate
the all the instances on the host, that should be CLI thing.

Thanks
Alex

2016-02-13 1:15 GMT+08:00 Matt Riedemann <mrie...@linux.vnet.ibm.com
<mailto:mrie...@linux.vnet.ibm.com>>:

Forgive me for thinking out loud, but I'm trying to sort out how
nova would use a microversion in the nova API for the
get-me-a-network feature recently added to neutron [1] and planned
to be leveraged in nova (there isn't a spec yet for nova, I'm trying
to sort this out for a draft).

Originally I was thinking that a network is required for nova boot,
so we'd simply check for a microversion and allow not specifying a
network, easy peasy.

Turns out you can boot an instance in nova (with neutron as the
network backend) without a network. All you get is a measly debug
log message in the compute logs [2]. That's kind of useless though
and seems silly.

I haven't tested this out yet to confirm, but I suspect that if you
create a nova instance w/o a network, you can latter try to attach a
network using the os-attach-interfaces API as long as you either
provide a network ID *or* there is a public shared network or the
tenant has a network at that point (nova looks those up if a
specific network ID isn't provided).

The high-level plan for get-me-a-network in nova was simply going to
be if the user tries to boot an instance and doesn't provide a
network, and there isn't a tenant network or public shared network
to default to, then nova would call neutron's new
auto-allocated-topology API to get a network. This, however, is a
behavior change.

So I guess the question now is how do we handle that behavior change
in the nova API?

We could add an auto-create-net boolean to the boot server request
which would only be available in a microversion, then we could check
that boolean in the compute API when we're doing network validation.

Today if you don't specify a network and don't have a network
available, then the validation in the API is basically just quota
checking that you can get at least one port in your tenant [3]. With
a flag on a microversion, we could also validate some other things
about auto-creating a network (if we know that's going to be the
case once we hit the compute).

Anyway, this is mostly me getting thoughts out of my head before the
weekend so I don't forget it and am looking for other ideas here or
things I might be missing.

[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
[2]

https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595

<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L594-2DL595=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs=t42iKObPq-keVfC3EZd9X7WyehiSgwzxw501xt7wqyM=>
[3]

https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107

<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L1107=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs=ddAFuD4WtYtA_FxgOglckfO17USVYIlVzihIiZWvsrA=>

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not 

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

[Chris Dent]

On Fri, 12 Feb 2016, Doug Wiegley wrote:


It hurts discoverability, and “expectedness”. If I’m new to
openstack, having it default boot unusable just means the first time I
use ’nova boot’, I’ll end up with a useless VM. People don’t
read docs first, it should “just work” as far as that’s sane.
And OpenStack has a LOT of these little annoyances for the sake of
strict correctness while optimizing for an unusual or rare case.


Sorry for being a bit late to the game and jumping into the thread
in the middle, but: I wanted to highlight above paragraph. Yes,
there are many of these little annoyances in OpenStack where the
principle of least surprise is completely violated.

In the present day, with the many structures we have in place to manage
versions, backwards compatibility, rolling upgrades, etc it is
increasingly difficult to fix these problems. That rather sucks. If
something is wrong and bad for users _now_ (especially the ones that
don't exist yet) and fixing it costs users only a bit of effort, we may
as well do it.

Microversions, as an example, are designed to make backwards
incompatible changes possible: unless a client requests 'latest' it
is fixed in time. The client users and authors have to make an
explicit choice to move forward. Let's use them and quit
constructing obstacles in the way of making things better.

We can argue that some deployer might move the microversion bar without
notifying users and gosh, we better protect against that. No, we
shouldn't. That's an issue between the deployers and the users.
OpenStack has built in the protections, if people just to use them
poorly, their problem.


The original stated goal of this simpler neutron api was to get back
to the simpler nova boot. I’d like to see that happen.


+1

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Gary Kotton]

Yes, you could consider Neutron as a proxy for this. It creates the network, 
subnet, router… To be honest I think that we should maybe consider ofering a 
template that can be created by Neutron and then the template ID passed from 
Nova or wherever. This will enable an admin to pre cook a number of different 
templates for different use cases. But maybe that I too far down the line.


From: Alex Xu <sou...@gmail.com<mailto:sou...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, February 15, 2016 at 7:06 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova][neutron] How would nova microversion 
get-me-a-network in the API?

May I ask can we put those thing in to the CLI? I guess there should have 
similar discussion and I missed. As we didn't want to provide more neutron API 
proxy, this works sounds like adding more proxy. And API is more simple and 
more flexible, this make the API have more complex behaviour. Just like 
evacuate API, it just does one thing, for evacuate the all the instances on the 
host, that should be CLI thing.

Thanks
Alex

2016-02-13 1:15 GMT+08:00 Matt Riedemann 
<mrie...@linux.vnet.ibm.com<mailto:mrie...@linux.vnet.ibm.com>>:
Forgive me for thinking out loud, but I'm trying to sort out how nova would use 
a microversion in the nova API for the get-me-a-network feature recently added 
to neutron [1] and planned to be leveraged in nova (there isn't a spec yet for 
nova, I'm trying to sort this out for a draft).

Originally I was thinking that a network is required for nova boot, so we'd 
simply check for a microversion and allow not specifying a network, easy peasy.

Turns out you can boot an instance in nova (with neutron as the network 
backend) without a network. All you get is a measly debug log message in the 
compute logs [2]. That's kind of useless though and seems silly.

I haven't tested this out yet to confirm, but I suspect that if you create a 
nova instance w/o a network, you can latter try to attach a network using the 
os-attach-interfaces API as long as you either provide a network ID *or* there 
is a public shared network or the tenant has a network at that point (nova 
looks those up if a specific network ID isn't provided).

The high-level plan for get-me-a-network in nova was simply going to be if the 
user tries to boot an instance and doesn't provide a network, and there isn't a 
tenant network or public shared network to default to, then nova would call 
neutron's new auto-allocated-topology API to get a network. This, however, is a 
behavior change.

So I guess the question now is how do we handle that behavior change in the 
nova API?

We could add an auto-create-net boolean to the boot server request which would 
only be available in a microversion, then we could check that boolean in the 
compute API when we're doing network validation.

Today if you don't specify a network and don't have a network available, then 
the validation in the API is basically just quota checking that you can get at 
least one port in your tenant [3]. With a flag on a microversion, we could also 
validate some other things about auto-creating a network (if we know that's 
going to be the case once we hit the compute).

Anyway, this is mostly me getting thoughts out of my head before the weekend so 
I don't forget it and am looking for other ideas here or things I might be 
missing.

[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
[2] 
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L594-2DL595=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs=t42iKObPq-keVfC3EZd9X7WyehiSgwzxw501xt7wqyM=>
[3] 
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84_nova_network_neutronv2_api.py-23L1107=BQMFaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc=IM9_TPE0bx2WSeqiD3HeyvJhxrdG3sr7rLUEbhAcWMs=ddAFuD4WtYtA_FxgOglckfO17USVYIlVzihIiZWvsrA=>

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

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

[Alex Xu]

2016-02-13 19:05 GMT+08:00 Andrew Laski :

>
>
> On Fri, Feb 12, 2016, at 03:51 PM, Ed Leafe wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 02/12/2016 02:41 PM, Andrew Laski wrote:
> >
> > >> I think if the point of the experience for this API is to be
> > >> working out
> > >>> of the box. So I very much like the idea of a defaults change
> > >>> here to the thing we want to be easy. And an explicit option to
> > >>> disable it if you want to do something more complicated.
> >
> > > I think this creates a potential for confusing behavior for users.
> > > They're happily booting instances with no network on 2.1, as silly
> > > as that might be, and then decide "ooh I'd like to use fancy new
> > > flag foo which is available in 2.35". So they add the flag to their
> > > request and set the version to 2.35 and suddenly multiple things
> > > change about their boot process because they missed that 2.24(or
> > > whatever) changed a default behavior. If this fits within the scope
> > > of microversions then users will need to expect that, but it's
> > > something that would be likely to trip me up as a user of the API.
> >
> > I agree - that's always been the trade-off with microversions. You
> > never get surprises, but you can't move to a new feature in 2.X
> > without also having to get everything that was also introduced in
> > 2.X-1 and before. The benefit, of course, is that the user will have
> > changed something explicitly before getting the new behavior, and at
> > least has a chance of figuring it out.
>
> I completely agree with the idea that the form of a request/response
> could change in any number of backwards incompatible ways due to a
> microversion. That's easily discoverable through a published schema.
> What I'm struggling with is the idea that we would be comfortable
> changing the meaning of something, or a default behavior, with a
> microversion. There's no discoverability for that sort of change except
> to try it and see what happens or read the docs. But the potential for
> surprise is high and there's no immediate feedback on misusing the new
> API like there is if the form changes and JSONSchema validation kicks it
> back.
>
>
If our goal is the client can auto-generated through all the discovery
mechanism, then I agree with you. At least for now, we can implement that.
Thinking of why we have to face behaviour changes, it due to too complex
behaviour in a simple API I guess...


> >
> > - --
> >
> > - -- Ed Leafe
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> > Comment: GPGTools - https://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> > U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> > iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> > ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> > Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> > +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> > VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> > tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> > 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> > B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> > uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> > GcPgzIoclwLrVooRqOSf
> > =Dqga
> > -END PGP SIGNATURE-
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alex Xu]

May I ask can we put those thing in to the CLI? I guess there should have
similar discussion and I missed. As we didn't want to provide more neutron
API proxy, this works sounds like adding more proxy. And API is more simple
and more flexible, this make the API have more complex behaviour. Just like
evacuate API, it just does one thing, for evacuate the all the instances on
the host, that should be CLI thing.

Thanks
Alex

2016-02-13 1:15 GMT+08:00 Matt Riedemann :

> Forgive me for thinking out loud, but I'm trying to sort out how nova
> would use a microversion in the nova API for the get-me-a-network feature
> recently added to neutron [1] and planned to be leveraged in nova (there
> isn't a spec yet for nova, I'm trying to sort this out for a draft).
>
> Originally I was thinking that a network is required for nova boot, so
> we'd simply check for a microversion and allow not specifying a network,
> easy peasy.
>
> Turns out you can boot an instance in nova (with neutron as the network
> backend) without a network. All you get is a measly debug log message in
> the compute logs [2]. That's kind of useless though and seems silly.
>
> I haven't tested this out yet to confirm, but I suspect that if you create
> a nova instance w/o a network, you can latter try to attach a network using
> the os-attach-interfaces API as long as you either provide a network ID
> *or* there is a public shared network or the tenant has a network at that
> point (nova looks those up if a specific network ID isn't provided).
>
> The high-level plan for get-me-a-network in nova was simply going to be if
> the user tries to boot an instance and doesn't provide a network, and there
> isn't a tenant network or public shared network to default to, then nova
> would call neutron's new auto-allocated-topology API to get a network.
> This, however, is a behavior change.
>
> So I guess the question now is how do we handle that behavior change in
> the nova API?
>
> We could add an auto-create-net boolean to the boot server request which
> would only be available in a microversion, then we could check that boolean
> in the compute API when we're doing network validation.
>
> Today if you don't specify a network and don't have a network available,
> then the validation in the API is basically just quota checking that you
> can get at least one port in your tenant [3]. With a flag on a
> microversion, we could also validate some other things about auto-creating
> a network (if we know that's going to be the case once we hit the compute).
>
> Anyway, this is mostly me getting thoughts out of my head before the
> weekend so I don't forget it and am looking for other ideas here or things
> I might be missing.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> [2]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> [3]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Gary Kotton]

On 2/14/16, 3:59 PM, "Ken'ichi Ohmichi"  wrote:

>2016-02-12 11:19 GMT-08:00 Andrew Laski :
>> On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote:
>>> On 12 February 2016 at 18:17, Andrew Laski  wrote:
>>> >
>>> >
>>> > On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
>>> >> Forgive me for thinking out loud, but I'm trying to sort out how
>>>nova
>>> >> would use a microversion in the nova API for the get-me-a-network
>>> >> feature recently added to neutron [1] and planned to be leveraged in
>>> >> nova (there isn't a spec yet for nova, I'm trying to sort this out
>>>for a
>>> >> draft).
>>> >>
>>> >> Originally I was thinking that a network is required for nova boot,
>>>so
>>> >> we'd simply check for a microversion and allow not specifying a
>>>network,
>>> >> easy peasy.
>>> >>
>>> >> Turns out you can boot an instance in nova (with neutron as the
>>>network
>>> >> backend) without a network. All you get is a measly debug log
>>>message in
>>> >> the compute logs [2]. That's kind of useless though and seems silly.
>>> >>
>>> >> I haven't tested this out yet to confirm, but I suspect that if you
>>> >> create a nova instance w/o a network, you can latter try to attach a
>>> >> network using the os-attach-interfaces API as long as you either
>>>provide
>>> >> a network ID *or* there is a public shared network or the tenant
>>>has a
>>> >> network at that point (nova looks those up if a specific network ID
>>> >> isn't provided).
>>> >>
>>> >> The high-level plan for get-me-a-network in nova was simply going
>>>to be
>>> >> if the user tries to boot an instance and doesn't provide a
>>>network, and
>>> >> there isn't a tenant network or public shared network to default to,
>>> >> then nova would call neutron's new auto-allocated-topology API to
>>>get a
>>> >> network. This, however, is a behavior change.
>>> >>
>>> >> So I guess the question now is how do we handle that behavior
>>>change in
>>> >> the nova API?
>>> >>
>>> >> We could add an auto-create-net boolean to the boot server request
>>>which
>>> >> would only be available in a microversion, then we could check that
>>> >> boolean in the compute API when we're doing network validation.
>>> >>
>>> >
>>> > I think a flag like this is the right approach. If it's currently
>>>valid
>>> > to boot an instance without a network than there needs to be
>>>something
>>> > to distinguish a request that wants a network created vs. a request
>>>that
>>> > doesn't want a network.
>>> >
>>> > This is still hugely useful if all that's required from a user is to
>>> > indicate that they would like a network, they still don't need to
>>> > understand/provide details of the network.
>>>
>>> I was thinking a sort of opposite. Would this work?
>>>
>>> We add a new micro-version that does this:
>>> * nothing specified: do the best we can to get a port created
>>> (get-me-a-network, etc,), or fail if not possible
>>> * --no-nics option (or similar) that says "please don't give me any
>>>nics"
>>>
>>> This means folks that don't want a network, reliably have a way to do
>>> that. For everyone else, we do the same thing when using either
>>> neutron or nova-network VLAN manager.
>>
>> I think this pushes our microversions meaning a bit further than
>> intended. I don't think the API should flip behaviors simply based on a
>> microversion.
>>
>> What about requiring nic information with the microversion? Make users
>> indicate explicitly if they want a network or not and avoid changing a
>> default behavior.
>
>I agree with alaski's point here.
>The default behavior changes can hurt API users easily even if bumping
>a microversion because it is difficult to pay attentions for all
>microversions' changes(we have already 22 microversions now) from
>users' viewpoints.

Were there any cross project discussions about this feature or are we
discussing this after the fact?
I do not think that we should be changing the default behavior.

>
>Thanks
>Ken Ohmichi
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 03:51 PM, Ed Leafe wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> 
> >> I think if the point of the experience for this API is to be
> >> working out
> >>> of the box. So I very much like the idea of a defaults change
> >>> here to the thing we want to be easy. And an explicit option to
> >>> disable it if you want to do something more complicated.
> 
> > I think this creates a potential for confusing behavior for users. 
> > They're happily booting instances with no network on 2.1, as silly
> > as that might be, and then decide "ooh I'd like to use fancy new
> > flag foo which is available in 2.35". So they add the flag to their
> > request and set the version to 2.35 and suddenly multiple things
> > change about their boot process because they missed that 2.24(or
> > whatever) changed a default behavior. If this fits within the scope
> > of microversions then users will need to expect that, but it's
> > something that would be likely to trip me up as a user of the API.
> 
> I agree - that's always been the trade-off with microversions. You
> never get surprises, but you can't move to a new feature in 2.X
> without also having to get everything that was also introduced in
> 2.X-1 and before. The benefit, of course, is that the user will have
> changed something explicitly before getting the new behavior, and at
> least has a chance of figuring it out.

I completely agree with the idea that the form of a request/response
could change in any number of backwards incompatible ways due to a
microversion. That's easily discoverable through a published schema.
What I'm struggling with is the idea that we would be comfortable
changing the meaning of something, or a default behavior, with a
microversion. There's no discoverability for that sort of change except
to try it and see what happens or read the docs. But the potential for
surprise is high and there's no immediate feedback on misusing the new
API like there is if the form changes and JSONSchema validation kicks it
back.

> 
> - -- 
> 
> - -- Ed Leafe
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> GcPgzIoclwLrVooRqOSf
> =Dqga
> -END PGP SIGNATURE-
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

Forgive me for thinking out loud, but I'm trying to sort out how nova 
would use a microversion in the nova API for the get-me-a-network 
feature recently added to neutron [1] and planned to be leveraged in 
nova (there isn't a spec yet for nova, I'm trying to sort this out for a 
draft).


Originally I was thinking that a network is required for nova boot, so 
we'd simply check for a microversion and allow not specifying a network, 
easy peasy.


Turns out you can boot an instance in nova (with neutron as the network 
backend) without a network. All you get is a measly debug log message in 
the compute logs [2]. That's kind of useless though and seems silly.


I haven't tested this out yet to confirm, but I suspect that if you 
create a nova instance w/o a network, you can latter try to attach a 
network using the os-attach-interfaces API as long as you either provide 
a network ID *or* there is a public shared network or the tenant has a 
network at that point (nova looks those up if a specific network ID 
isn't provided).


The high-level plan for get-me-a-network in nova was simply going to be 
if the user tries to boot an instance and doesn't provide a network, and 
there isn't a tenant network or public shared network to default to, 
then nova would call neutron's new auto-allocated-topology API to get a 
network. This, however, is a behavior change.


So I guess the question now is how do we handle that behavior change in 
the nova API?


We could add an auto-create-net boolean to the boot server request which 
would only be available in a microversion, then we could check that 
boolean in the compute API when we're doing network validation.


Today if you don't specify a network and don't have a network available, 
then the validation in the API is basically just quota checking that you 
can get at least one port in your tenant [3]. With a flag on a 
microversion, we could also validate some other things about 
auto-creating a network (if we know that's going to be the case once we 
hit the compute).


Anyway, this is mostly me getting thoughts out of my head before the 
weekend so I don't forget it and am looking for other ideas here or 
things I might be missing.


[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
[2] 
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
[3] 
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Garbutt]

On 12 February 2016 at 18:17, Andrew Laski  wrote:
>
>
> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
>> Forgive me for thinking out loud, but I'm trying to sort out how nova
>> would use a microversion in the nova API for the get-me-a-network
>> feature recently added to neutron [1] and planned to be leveraged in
>> nova (there isn't a spec yet for nova, I'm trying to sort this out for a
>> draft).
>>
>> Originally I was thinking that a network is required for nova boot, so
>> we'd simply check for a microversion and allow not specifying a network,
>> easy peasy.
>>
>> Turns out you can boot an instance in nova (with neutron as the network
>> backend) without a network. All you get is a measly debug log message in
>> the compute logs [2]. That's kind of useless though and seems silly.
>>
>> I haven't tested this out yet to confirm, but I suspect that if you
>> create a nova instance w/o a network, you can latter try to attach a
>> network using the os-attach-interfaces API as long as you either provide
>> a network ID *or* there is a public shared network or the tenant has a
>> network at that point (nova looks those up if a specific network ID
>> isn't provided).
>>
>> The high-level plan for get-me-a-network in nova was simply going to be
>> if the user tries to boot an instance and doesn't provide a network, and
>> there isn't a tenant network or public shared network to default to,
>> then nova would call neutron's new auto-allocated-topology API to get a
>> network. This, however, is a behavior change.
>>
>> So I guess the question now is how do we handle that behavior change in
>> the nova API?
>>
>> We could add an auto-create-net boolean to the boot server request which
>> would only be available in a microversion, then we could check that
>> boolean in the compute API when we're doing network validation.
>>
>
> I think a flag like this is the right approach. If it's currently valid
> to boot an instance without a network than there needs to be something
> to distinguish a request that wants a network created vs. a request that
> doesn't want a network.
>
> This is still hugely useful if all that's required from a user is to
> indicate that they would like a network, they still don't need to
> understand/provide details of the network.

I was thinking a sort of opposite. Would this work?

We add a new micro-version that does this:
* nothing specified: do the best we can to get a port created
(get-me-a-network, etc,), or fail if not possible
* --no-nics option (or similar) that says "please don't give me any nics"

This means folks that don't want a network, reliably have a way to do
that. For everyone else, we do the same thing when using either
neutron or nova-network VLAN manager.

Thanks,
johnthetubaguy

PS
I think we should focus on the horizon experience, CLI experience, and
API experience separately, for a moment, to make sure each of those
cases actually works out OK.

>> Today if you don't specify a network and don't have a network available,
>> then the validation in the API is basically just quota checking that you
>> can get at least one port in your tenant [3]. With a flag on a
>> microversion, we could also validate some other things about
>> auto-creating a network (if we know that's going to be the case once we
>> hit the compute).
>>
>> Anyway, this is mostly me getting thoughts out of my head before the
>> weekend so I don't forget it and am looking for other ideas here or
>> things I might be missing.
>>
>> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
>> [2]
>> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
>> [3]
>> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Kevin Benton]

Perhaps another option for '--nic'? nova boot --nic auto-allocate

On Fri, Feb 12, 2016 at 10:17 AM, Andrew Laski  wrote:

>
>
> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
> > Forgive me for thinking out loud, but I'm trying to sort out how nova
> > would use a microversion in the nova API for the get-me-a-network
> > feature recently added to neutron [1] and planned to be leveraged in
> > nova (there isn't a spec yet for nova, I'm trying to sort this out for a
> > draft).
> >
> > Originally I was thinking that a network is required for nova boot, so
> > we'd simply check for a microversion and allow not specifying a network,
> > easy peasy.
> >
> > Turns out you can boot an instance in nova (with neutron as the network
> > backend) without a network. All you get is a measly debug log message in
> > the compute logs [2]. That's kind of useless though and seems silly.
> >
> > I haven't tested this out yet to confirm, but I suspect that if you
> > create a nova instance w/o a network, you can latter try to attach a
> > network using the os-attach-interfaces API as long as you either provide
> > a network ID *or* there is a public shared network or the tenant has a
> > network at that point (nova looks those up if a specific network ID
> > isn't provided).
> >
> > The high-level plan for get-me-a-network in nova was simply going to be
> > if the user tries to boot an instance and doesn't provide a network, and
> > there isn't a tenant network or public shared network to default to,
> > then nova would call neutron's new auto-allocated-topology API to get a
> > network. This, however, is a behavior change.
> >
> > So I guess the question now is how do we handle that behavior change in
> > the nova API?
> >
> > We could add an auto-create-net boolean to the boot server request which
> > would only be available in a microversion, then we could check that
> > boolean in the compute API when we're doing network validation.
> >
>
> I think a flag like this is the right approach. If it's currently valid
> to boot an instance without a network than there needs to be something
> to distinguish a request that wants a network created vs. a request that
> doesn't want a network.
>
> This is still hugely useful if all that's required from a user is to
> indicate that they would like a network, they still don't need to
> understand/provide details of the network.
>
>
>
> > Today if you don't specify a network and don't have a network available,
> > then the validation in the API is basically just quota checking that you
> > can get at least one port in your tenant [3]. With a flag on a
> > microversion, we could also validate some other things about
> > auto-creating a network (if we know that's going to be the case once we
> > hit the compute).
> >
> > Anyway, this is mostly me getting thoughts out of my head before the
> > weekend so I don't forget it and am looking for other ideas here or
> > things I might be missing.
> >
> > [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> > [2]
> >
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> > [3]
> >
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

On 2/12/2016 12:45 PM, John Garbutt wrote:

On 12 February 2016 at 18:17, Andrew Laski  wrote:



On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:

Forgive me for thinking out loud, but I'm trying to sort out how nova
would use a microversion in the nova API for the get-me-a-network
feature recently added to neutron [1] and planned to be leveraged in
nova (there isn't a spec yet for nova, I'm trying to sort this out for a
draft).

Originally I was thinking that a network is required for nova boot, so
we'd simply check for a microversion and allow not specifying a network,
easy peasy.

Turns out you can boot an instance in nova (with neutron as the network
backend) without a network. All you get is a measly debug log message in
the compute logs [2]. That's kind of useless though and seems silly.

I haven't tested this out yet to confirm, but I suspect that if you
create a nova instance w/o a network, you can latter try to attach a
network using the os-attach-interfaces API as long as you either provide
a network ID *or* there is a public shared network or the tenant has a
network at that point (nova looks those up if a specific network ID
isn't provided).

The high-level plan for get-me-a-network in nova was simply going to be
if the user tries to boot an instance and doesn't provide a network, and
there isn't a tenant network or public shared network to default to,
then nova would call neutron's new auto-allocated-topology API to get a
network. This, however, is a behavior change.

So I guess the question now is how do we handle that behavior change in
the nova API?

We could add an auto-create-net boolean to the boot server request which
would only be available in a microversion, then we could check that
boolean in the compute API when we're doing network validation.



I think a flag like this is the right approach. If it's currently valid
to boot an instance without a network than there needs to be something
to distinguish a request that wants a network created vs. a request that
doesn't want a network.

This is still hugely useful if all that's required from a user is to
indicate that they would like a network, they still don't need to
understand/provide details of the network.


I was thinking a sort of opposite. Would this work?

We add a new micro-version that does this:
* nothing specified: do the best we can to get a port created
(get-me-a-network, etc,), or fail if not possible
* --no-nics option (or similar) that says "please don't give me any nics"

This means folks that don't want a network, reliably have a way to do
that. For everyone else, we do the same thing when using either
neutron or nova-network VLAN manager.

Thanks,
johnthetubaguy

PS
I think we should focus on the horizon experience, CLI experience, and
API experience separately, for a moment, to make sure each of those
cases actually works out OK.


Today if you don't specify a network and don't have a network available,
then the validation in the API is basically just quota checking that you
can get at least one port in your tenant [3]. With a flag on a
microversion, we could also validate some other things about
auto-creating a network (if we know that's going to be the case once we
hit the compute).

Anyway, this is mostly me getting thoughts out of my head before the
weekend so I don't forget it and am looking for other ideas here or
things I might be missing.

[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
[2]
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
[3]
https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I think we're basically looking at the same use case. And as Kevin noted 
I was thinking an option on the --nic part of the request, like 
auto-allocate.


My thinking was with the microversion, that defaults to True and you 
have to opt-in to the old behavior (specify auto-allocate=False) of nova 
being OK with not providing any network for the instance. The flag that 
goes down 

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote:
> On 12 February 2016 at 18:17, Andrew Laski  wrote:
> >
> >
> > On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
> >> Forgive me for thinking out loud, but I'm trying to sort out how nova
> >> would use a microversion in the nova API for the get-me-a-network
> >> feature recently added to neutron [1] and planned to be leveraged in
> >> nova (there isn't a spec yet for nova, I'm trying to sort this out for a
> >> draft).
> >>
> >> Originally I was thinking that a network is required for nova boot, so
> >> we'd simply check for a microversion and allow not specifying a network,
> >> easy peasy.
> >>
> >> Turns out you can boot an instance in nova (with neutron as the network
> >> backend) without a network. All you get is a measly debug log message in
> >> the compute logs [2]. That's kind of useless though and seems silly.
> >>
> >> I haven't tested this out yet to confirm, but I suspect that if you
> >> create a nova instance w/o a network, you can latter try to attach a
> >> network using the os-attach-interfaces API as long as you either provide
> >> a network ID *or* there is a public shared network or the tenant has a
> >> network at that point (nova looks those up if a specific network ID
> >> isn't provided).
> >>
> >> The high-level plan for get-me-a-network in nova was simply going to be
> >> if the user tries to boot an instance and doesn't provide a network, and
> >> there isn't a tenant network or public shared network to default to,
> >> then nova would call neutron's new auto-allocated-topology API to get a
> >> network. This, however, is a behavior change.
> >>
> >> So I guess the question now is how do we handle that behavior change in
> >> the nova API?
> >>
> >> We could add an auto-create-net boolean to the boot server request which
> >> would only be available in a microversion, then we could check that
> >> boolean in the compute API when we're doing network validation.
> >>
> >
> > I think a flag like this is the right approach. If it's currently valid
> > to boot an instance without a network than there needs to be something
> > to distinguish a request that wants a network created vs. a request that
> > doesn't want a network.
> >
> > This is still hugely useful if all that's required from a user is to
> > indicate that they would like a network, they still don't need to
> > understand/provide details of the network.
> 
> I was thinking a sort of opposite. Would this work?
> 
> We add a new micro-version that does this:
> * nothing specified: do the best we can to get a port created
> (get-me-a-network, etc,), or fail if not possible
> * --no-nics option (or similar) that says "please don't give me any nics"
> 
> This means folks that don't want a network, reliably have a way to do
> that. For everyone else, we do the same thing when using either
> neutron or nova-network VLAN manager.

I think this pushes our microversions meaning a bit further than
intended. I don't think the API should flip behaviors simply based on a
microversion.

What about requiring nic information with the microversion? Make users
indicate explicitly if they want a network or not and avoid changing a
default behavior.


> 
> Thanks,
> johnthetubaguy
> 
> PS
> I think we should focus on the horizon experience, CLI experience, and
> API experience separately, for a moment, to make sure each of those
> cases actually works out OK.
> 
> >> Today if you don't specify a network and don't have a network available,
> >> then the validation in the API is basically just quota checking that you
> >> can get at least one port in your tenant [3]. With a flag on a
> >> microversion, we could also validate some other things about
> >> auto-creating a network (if we know that's going to be the case once we
> >> hit the compute).
> >>
> >> Anyway, this is mostly me getting thoughts out of my head before the
> >> weekend so I don't forget it and am looking for other ideas here or
> >> things I might be missing.
> >>
> >> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> >> [2]
> >> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> >> [3]
> >> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt Riedemann
> >>
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 

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

[Doug Wiegley]

> On Feb 12, 2016, at 12:03 PM, Matt Riedemann  
> wrote:
> 
> 
> 
> On 2/12/2016 12:45 PM, John Garbutt wrote:
>> On 12 February 2016 at 18:17, Andrew Laski  wrote:
>>> 
>>> 
>>> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
 Forgive me for thinking out loud, but I'm trying to sort out how nova
 would use a microversion in the nova API for the get-me-a-network
 feature recently added to neutron [1] and planned to be leveraged in
 nova (there isn't a spec yet for nova, I'm trying to sort this out for a
 draft).
 
 Originally I was thinking that a network is required for nova boot, so
 we'd simply check for a microversion and allow not specifying a network,
 easy peasy.
 
 Turns out you can boot an instance in nova (with neutron as the network
 backend) without a network. All you get is a measly debug log message in
 the compute logs [2]. That's kind of useless though and seems silly.
 
 I haven't tested this out yet to confirm, but I suspect that if you
 create a nova instance w/o a network, you can latter try to attach a
 network using the os-attach-interfaces API as long as you either provide
 a network ID *or* there is a public shared network or the tenant has a
 network at that point (nova looks those up if a specific network ID
 isn't provided).
 
 The high-level plan for get-me-a-network in nova was simply going to be
 if the user tries to boot an instance and doesn't provide a network, and
 there isn't a tenant network or public shared network to default to,
 then nova would call neutron's new auto-allocated-topology API to get a
 network. This, however, is a behavior change.
 
 So I guess the question now is how do we handle that behavior change in
 the nova API?
 
 We could add an auto-create-net boolean to the boot server request which
 would only be available in a microversion, then we could check that
 boolean in the compute API when we're doing network validation.
 
>>> 
>>> I think a flag like this is the right approach. If it's currently valid
>>> to boot an instance without a network than there needs to be something
>>> to distinguish a request that wants a network created vs. a request that
>>> doesn't want a network.
>>> 
>>> This is still hugely useful if all that's required from a user is to
>>> indicate that they would like a network, they still don't need to
>>> understand/provide details of the network.
>> 
>> I was thinking a sort of opposite. Would this work?
>> 
>> We add a new micro-version that does this:
>> * nothing specified: do the best we can to get a port created
>> (get-me-a-network, etc,), or fail if not possible
>> * --no-nics option (or similar) that says "please don't give me any nics"
>> 
>> This means folks that don't want a network, reliably have a way to do
>> that. For everyone else, we do the same thing when using either
>> neutron or nova-network VLAN manager.
>> 
>> Thanks,
>> johnthetubaguy
>> 
>> PS
>> I think we should focus on the horizon experience, CLI experience, and
>> API experience separately, for a moment, to make sure each of those
>> cases actually works out OK.
>> 
 Today if you don't specify a network and don't have a network available,
 then the validation in the API is basically just quota checking that you
 can get at least one port in your tenant [3]. With a flag on a
 microversion, we could also validate some other things about
 auto-creating a network (if we know that's going to be the case once we
 hit the compute).
 
 Anyway, this is mostly me getting thoughts out of my head before the
 weekend so I don't forget it and am looking for other ideas here or
 things I might be missing.
 
 [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
 [2]
 https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
 [3]
 https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
 
 --
 
 Thanks,
 
 Matt Riedemann
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __
>> OpenStack Development Mailing List (not for 

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

[Armando M.]

On 12 February 2016 at 09:15, Matt Riedemann 
wrote:

> Forgive me for thinking out loud, but I'm trying to sort out how nova
> would use a microversion in the nova API for the get-me-a-network feature
> recently added to neutron [1] and planned to be leveraged in nova (there
> isn't a spec yet for nova, I'm trying to sort this out for a draft).
>
> Originally I was thinking that a network is required for nova boot, so
> we'd simply check for a microversion and allow not specifying a network,
> easy peasy.
>
> Turns out you can boot an instance in nova (with neutron as the network
> backend) without a network. All you get is a measly debug log message in
> the compute logs [2]. That's kind of useless though and seems silly.
>

Incidentally, I was checking this out with Horizon, and the dashboard
instance boot workflow doesn't let you proceed without specifying a network
(irrespective of the network backend). So if the user has no networks,
he/she is stuck and has to flip to the CLI. Nice, uh?


>
> I haven't tested this out yet to confirm, but I suspect that if you create
> a nova instance w/o a network, you can latter try to attach a network using
> the os-attach-interfaces API as long as you either provide a network ID
> *or* there is a public shared network or the tenant has a network at that
> point (nova looks those up if a specific network ID isn't provided).
>

Just to make sure we're on the same page: if you're referring to 'public
shared network' as the devstack's provisioned network called 'public',
that's technically not shared and it represent your floating IP pool. A
user can explicitly boot VM's on it, but that's not to be confused with a
'shared' provider network.

That said, I tried the workflow of booting a vm without networks and trying
to attach an interface without specifying anything and I got a 500 [1].
Error aside, I think it's it would be erroneous to expect the attach
command to accept no networks (and still pick one), when the boot command
doesn't.

[1] http://paste.openstack.org/show/486856/


> The high-level plan for get-me-a-network in nova was simply going to be if
> the user tries to boot an instance and doesn't provide a network, and there
> isn't a tenant network or public shared network

to default to, then nova would call neutron's new auto-allocated-topology
> API to get a network. This, however, is a behavior change.
>

I assume that for you 'public shared network' it's not the public network
as available in DevStack because, because I don't believe that user can
boot VM's on that network automatically.


> So I guess the question now is how do we handle that behavior change in
> the nova API?
>
> We could add an auto-create-net boolean to the boot server request which
> would only be available in a microversion, then we could check that boolean
> in the compute API when we're doing network validation.
>
> Today if you don't specify a network and don't have a network available,
> then the validation in the API is basically just quota checking that you
> can get at least one port in your tenant [3]. With a flag on a
> microversion, we could also validate some other things about auto-creating
> a network (if we know that's going to be the case once we hit the compute).
>
> Anyway, this is mostly me getting thoughts out of my head before the
> weekend so I don't forget it and am looking for other ideas here or things
> I might be missing.
>

John and I just finished talking about this a bit more and I think the the
thought process led us to this conclusion:

>From Horizon, we could provide a 'get-me-a-network' button on the Networks
wizard for the boot workflow. If the user doesn't see any Networks
available he/she can hit the button, see the network being pre-populated
and choose to proceed, instead of going back to the Network panel and do
the entire workflow.

As for Nova, we could introduce a new micro-version that changes the
behavior of nova boot without networks. In this case, if the tenant has
access to no networks, one will be created for him/her and the VM will boot
off of it.

On the other end, if the user does want a VM without nics, he/she should be
explicit about this and specify 'no-nic' boolean, e.g.

  nova boot  --flavor  --image 
--no-nics

John and I think this would be preferable because the output of the command
becomes more predictable: the user doesn't end up having VM's connected to
NICs accidentally if some net-create sneaks underneath.

Anyhow, food for thought.

Thanks for starting this thread.

Cheers,
Armando


> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> [2]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> [3]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> 

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

[Matt Riedemann]

On 2/12/2016 12:44 PM, Armando M. wrote:



On 12 February 2016 at 09:15, Matt Riedemann > wrote:

Forgive me for thinking out loud, but I'm trying to sort out how
nova would use a microversion in the nova API for the
get-me-a-network feature recently added to neutron [1] and planned
to be leveraged in nova (there isn't a spec yet for nova, I'm trying
to sort this out for a draft).

Originally I was thinking that a network is required for nova boot,
so we'd simply check for a microversion and allow not specifying a
network, easy peasy.

Turns out you can boot an instance in nova (with neutron as the
network backend) without a network. All you get is a measly debug
log message in the compute logs [2]. That's kind of useless though
and seems silly.


Incidentally, I was checking this out with Horizon, and the dashboard
instance boot workflow doesn't let you proceed without specifying a
network (irrespective of the network backend). So if the user has no
networks, he/she is stuck and has to flip to the CLI. Nice,
uh?


I haven't tested this out yet to confirm, but I suspect that if you
create a nova instance w/o a network, you can latter try to attach a
network using the os-attach-interfaces API as long as you either
provide a network ID *or* there is a public shared network or the
tenant has a network at that point (nova looks those up if a
specific network ID isn't provided).


Just to make sure we're on the same page: if you're referring to 'public
shared network' as the devstack's provisioned network called 'public',
that's technically not shared and it represent your floating IP pool. A
user can explicitly boot VM's on it, but that's not to be confused with
a 'shared' provider network.


I was referring to this code:

https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223



That said, I tried the workflow of booting a vm without networks and
trying to attach an interface without specifying anything and I got a
500 [1]. Error aside, I think it's it would be erroneous to expect the
attach command to accept no networks (and still pick one), when the boot
command doesn't.

[1] http://paste.openstack.org/show/486856/


Cool, yeah, I was totally expecting an IndexError because of the code here:

https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610




The high-level plan for get-me-a-network in nova was simply going to
be if the user tries to boot an instance and doesn't provide a
network, and there isn't a tenant network or public shared network

to default to, then nova would call neutron's new
auto-allocated-topology API to get a network. This, however, is a
behavior change.


I assume that for you 'public shared network' it's not the public
network as available in DevStack because, because I don't believe that
user can boot VM's on that network automatically.


So I guess the question now is how do we handle that behavior change
in the nova API?

We could add an auto-create-net boolean to the boot server request
which would only be available in a microversion, then we could check
that boolean in the compute API when we're doing network validation.

Today if you don't specify a network and don't have a network
available, then the validation in the API is basically just quota
checking that you can get at least one port in your tenant [3]. With
a flag on a microversion, we could also validate some other things
about auto-creating a network (if we know that's going to be the
case once we hit the compute).

Anyway, this is mostly me getting thoughts out of my head before the
weekend so I don't forget it and am looking for other ideas here or
things I might be missing.


John and I just finished talking about this a bit more and I think the
the thought process led us to this conclusion:

 From Horizon, we could provide a 'get-me-a-network' button on the
Networks wizard for the boot workflow. If the user doesn't see any
Networks available he/she can hit the button, see the network being
pre-populated and choose to proceed, instead of going back to the
Network panel and do the entire workflow.

As for Nova, we could introduce a new micro-version that changes the
behavior of nova boot without networks. In this case, if the tenant has
access to no networks, one will be created for him/her and the VM will
boot off of it.

On the other end, if the user does want a VM without nics, he/she should
be explicit about this and specify 'no-nic' boolean, e.g.

   nova boot  --flavor  --image 
--no-nics

John and I think this would be preferable because the output of the
command becomes more predictable: the user doesn't end up having VM's
connected to NICs accidentally if some 

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

[Armando M.]

On 12 February 2016 at 11:08, Matt Riedemann 
wrote:

>
>
> On 2/12/2016 12:44 PM, Armando M. wrote:
>
>>
>>
>> On 12 February 2016 at 09:15, Matt Riedemann > > wrote:
>>
>> Forgive me for thinking out loud, but I'm trying to sort out how
>> nova would use a microversion in the nova API for the
>> get-me-a-network feature recently added to neutron [1] and planned
>> to be leveraged in nova (there isn't a spec yet for nova, I'm trying
>> to sort this out for a draft).
>>
>> Originally I was thinking that a network is required for nova boot,
>> so we'd simply check for a microversion and allow not specifying a
>> network, easy peasy.
>>
>> Turns out you can boot an instance in nova (with neutron as the
>> network backend) without a network. All you get is a measly debug
>> log message in the compute logs [2]. That's kind of useless though
>> and seems silly.
>>
>>
>> Incidentally, I was checking this out with Horizon, and the dashboard
>> instance boot workflow doesn't let you proceed without specifying a
>> network (irrespective of the network backend). So if the user has no
>> networks, he/she is stuck and has to flip to the CLI. Nice,
>> uh?
>>
>>
>> I haven't tested this out yet to confirm, but I suspect that if you
>> create a nova instance w/o a network, you can latter try to attach a
>> network using the os-attach-interfaces API as long as you either
>> provide a network ID *or* there is a public shared network or the
>> tenant has a network at that point (nova looks those up if a
>> specific network ID isn't provided).
>>
>>
>> Just to make sure we're on the same page: if you're referring to 'public
>> shared network' as the devstack's provisioned network called 'public',
>> that's technically not shared and it represent your floating IP pool. A
>> user can explicitly boot VM's on it, but that's not to be confused with
>> a 'shared' provider network.
>>
>
> I was referring to this code:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223
>
>
Ok I am with you: the public in the comment is somewhat misleading because
there's nothing 'public' about a shared network and as a matter of fact
RBAC [1] allows for networks to be shared only to a subset of tenants.

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html


>
>> That said, I tried the workflow of booting a vm without networks and
>> trying to attach an interface without specifying anything and I got a
>> 500 [1]. Error aside, I think it's it would be erroneous to expect the
>> attach command to accept no networks (and still pick one), when the boot
>> command doesn't.
>>
>> [1] http://paste.openstack.org/show/486856/
>>
>
> Cool, yeah, I was totally expecting an IndexError because of the code here:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610
>
>
>
>>
>> The high-level plan for get-me-a-network in nova was simply going to
>> be if the user tries to boot an instance and doesn't provide a
>> network, and there isn't a tenant network or public shared network
>>
>> to default to, then nova would call neutron's new
>> auto-allocated-topology API to get a network. This, however, is a
>> behavior change.
>>
>>
>> I assume that for you 'public shared network' it's not the public
>> network as available in DevStack because, because I don't believe that
>> user can boot VM's on that network automatically.
>>
>>
>> So I guess the question now is how do we handle that behavior change
>> in the nova API?
>>
>> We could add an auto-create-net boolean to the boot server request
>> which would only be available in a microversion, then we could check
>> that boolean in the compute API when we're doing network validation.
>>
>> Today if you don't specify a network and don't have a network
>> available, then the validation in the API is basically just quota
>> checking that you can get at least one port in your tenant [3]. With
>> a flag on a microversion, we could also validate some other things
>> about auto-creating a network (if we know that's going to be the
>> case once we hit the compute).
>>
>> Anyway, this is mostly me getting thoughts out of my head before the
>> weekend so I don't forget it and am looking for other ideas here or
>> things I might be missing.
>>
>>
>> John and I just finished talking about this a bit more and I think the
>> the thought process led us to this conclusion:
>>
>>  From Horizon, we could provide a 'get-me-a-network' button on the
>> Networks wizard for the boot workflow. If the user doesn't see any
>> Networks available he/she can hit the button, see the network being
>> pre-populated and choose to 

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

[Sean Dague]

On 02/12/2016 02:19 PM, Andrew Laski wrote:
> 
> 
> On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote:
>> On 12 February 2016 at 18:17, Andrew Laski  wrote:
>>>
>>>
>>> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
 Forgive me for thinking out loud, but I'm trying to sort out how nova
 would use a microversion in the nova API for the get-me-a-network
 feature recently added to neutron [1] and planned to be leveraged in
 nova (there isn't a spec yet for nova, I'm trying to sort this out for a
 draft).

 Originally I was thinking that a network is required for nova boot, so
 we'd simply check for a microversion and allow not specifying a network,
 easy peasy.

 Turns out you can boot an instance in nova (with neutron as the network
 backend) without a network. All you get is a measly debug log message in
 the compute logs [2]. That's kind of useless though and seems silly.

 I haven't tested this out yet to confirm, but I suspect that if you
 create a nova instance w/o a network, you can latter try to attach a
 network using the os-attach-interfaces API as long as you either provide
 a network ID *or* there is a public shared network or the tenant has a
 network at that point (nova looks those up if a specific network ID
 isn't provided).

 The high-level plan for get-me-a-network in nova was simply going to be
 if the user tries to boot an instance and doesn't provide a network, and
 there isn't a tenant network or public shared network to default to,
 then nova would call neutron's new auto-allocated-topology API to get a
 network. This, however, is a behavior change.

 So I guess the question now is how do we handle that behavior change in
 the nova API?

 We could add an auto-create-net boolean to the boot server request which
 would only be available in a microversion, then we could check that
 boolean in the compute API when we're doing network validation.

>>>
>>> I think a flag like this is the right approach. If it's currently valid
>>> to boot an instance without a network than there needs to be something
>>> to distinguish a request that wants a network created vs. a request that
>>> doesn't want a network.
>>>
>>> This is still hugely useful if all that's required from a user is to
>>> indicate that they would like a network, they still don't need to
>>> understand/provide details of the network.
>>
>> I was thinking a sort of opposite. Would this work?
>>
>> We add a new micro-version that does this:
>> * nothing specified: do the best we can to get a port created
>> (get-me-a-network, etc,), or fail if not possible
>> * --no-nics option (or similar) that says "please don't give me any nics"
>>
>> This means folks that don't want a network, reliably have a way to do
>> that. For everyone else, we do the same thing when using either
>> neutron or nova-network VLAN manager.
> 
> I think this pushes our microversions meaning a bit further than
> intended. I don't think the API should flip behaviors simply based on a
> microversion.
> 
> What about requiring nic information with the microversion? Make users
> indicate explicitly if they want a network or not and avoid changing a
> default behavior.

I think changing default behavior like that is totally within bounds,
and was part of the original design point of microversions (and why you
have to opt into them). So people that don't want a network that go past
that boundary know to start saying "hands-off".

I think if the point of the experience for this API is to be working out
of the box. So I very much like the idea of a defaults change here to
the thing we want to be easy. And an explicit option to disable it if
you want to do something more complicated.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Wiegley]

> On Feb 12, 2016, at 2:15 PM, Andrew Laski  wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
>> gives it one nic with an IP, right?
>> 
>> So how is this changing that behavior? Making it harder to use, for the
>> sake of preserving a really unusual corner case (no net with neutron),
>> seems a much worse user experience here.
> 
> I was just going off of the behavior Matt described, that it was
> possible to boot with no network by leaving that out of the request. If
> the behavior already differs based on what networking backend is in use
> then we've put users in a bad spot, and IMO furthers my case for having
> explicit parameters in the request. I'm really not seeing how "--nic
> auto|none" is any harder than leaving all network related parameters off
> of the boot request, and it avoids potential confusion as to what will
> happen.

It hurts discoverability, and “expectedness”. If I’m new to openstack, having 
it default boot unusable just means the first time I use ’nova boot’, I’ll end 
up with a useless VM. People don’t read docs first, it should “just work” as 
far as that’s sane. And OpenStack has a LOT of these little annoyances for the 
sake of strict correctness while optimizing for an unusual or rare case.

The original stated goal of this simpler neutron api was to get back to the 
simpler nova boot. I’d like to see that happen.

Thanks,
doug

> 
>> 
>> Thanks,
>> doug
>> 
>> 
>>> On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>> 
>>> On 02/12/2016 02:41 PM, Andrew Laski wrote:
>>> 
> I think if the point of the experience for this API is to be
> working out
>> of the box. So I very much like the idea of a defaults change
>> here to the thing we want to be easy. And an explicit option to
>> disable it if you want to do something more complicated.
>>> 
 I think this creates a potential for confusing behavior for users. 
 They're happily booting instances with no network on 2.1, as silly
 as that might be, and then decide "ooh I'd like to use fancy new
 flag foo which is available in 2.35". So they add the flag to their
 request and set the version to 2.35 and suddenly multiple things
 change about their boot process because they missed that 2.24(or
 whatever) changed a default behavior. If this fits within the scope
 of microversions then users will need to expect that, but it's
 something that would be likely to trip me up as a user of the API.
>>> 
>>> I agree - that's always been the trade-off with microversions. You
>>> never get surprises, but you can't move to a new feature in 2.X
>>> without also having to get everything that was also introduced in
>>> 2.X-1 and before. The benefit, of course, is that the user will have
>>> changed something explicitly before getting the new behavior, and at
>>> least has a chance of figuring it out.
>>> 
>>> - -- 
>>> 
>>> - -- Ed Leafe
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>> Comment: GPGTools - https://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>> 
>>> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
>>> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
>>> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
>>> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
>>> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
>>> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
>>> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
>>> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
>>> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
>>> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
>>> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
>>> GcPgzIoclwLrVooRqOSf
>>> =Dqga
>>> -END PGP SIGNATURE-
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/12/2016 02:41 PM, Andrew Laski wrote:

>> I think if the point of the experience for this API is to be
>> working out
>>> of the box. So I very much like the idea of a defaults change
>>> here to the thing we want to be easy. And an explicit option to
>>> disable it if you want to do something more complicated.

> I think this creates a potential for confusing behavior for users. 
> They're happily booting instances with no network on 2.1, as silly
> as that might be, and then decide "ooh I'd like to use fancy new
> flag foo which is available in 2.35". So they add the flag to their
> request and set the version to 2.35 and suddenly multiple things
> change about their boot process because they missed that 2.24(or
> whatever) changed a default behavior. If this fits within the scope
> of microversions then users will need to expect that, but it's
> something that would be likely to trip me up as a user of the API.

I agree - that's always been the trade-off with microversions. You
never get surprises, but you can't move to a new feature in 2.X
without also having to get everything that was also introduced in
2.X-1 and before. The benefit, of course, is that the user will have
changed something explicitly before getting the new behavior, and at
least has a chance of figuring it out.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
+C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
GcPgzIoclwLrVooRqOSf
=Dqga
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
> gives it one nic with an IP, right?
> 
> So how is this changing that behavior? Making it harder to use, for the
> sake of preserving a really unusual corner case (no net with neutron),
> seems a much worse user experience here.

I was just going off of the behavior Matt described, that it was
possible to boot with no network by leaving that out of the request. If
the behavior already differs based on what networking backend is in use
then we've put users in a bad spot, and IMO furthers my case for having
explicit parameters in the request. I'm really not seeing how "--nic
auto|none" is any harder than leaving all network related parameters off
of the boot request, and it avoids potential confusion as to what will
happen.

> 
> Thanks,
> doug
> 
> 
> > On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 02/12/2016 02:41 PM, Andrew Laski wrote:
> > 
> >>> I think if the point of the experience for this API is to be
> >>> working out
>  of the box. So I very much like the idea of a defaults change
>  here to the thing we want to be easy. And an explicit option to
>  disable it if you want to do something more complicated.
> > 
> >> I think this creates a potential for confusing behavior for users. 
> >> They're happily booting instances with no network on 2.1, as silly
> >> as that might be, and then decide "ooh I'd like to use fancy new
> >> flag foo which is available in 2.35". So they add the flag to their
> >> request and set the version to 2.35 and suddenly multiple things
> >> change about their boot process because they missed that 2.24(or
> >> whatever) changed a default behavior. If this fits within the scope
> >> of microversions then users will need to expect that, but it's
> >> something that would be likely to trip me up as a user of the API.
> > 
> > I agree - that's always been the trade-off with microversions. You
> > never get surprises, but you can't move to a new feature in 2.X
> > without also having to get everything that was also introduced in
> > 2.X-1 and before. The benefit, of course, is that the user will have
> > changed something explicitly before getting the new behavior, and at
> > least has a chance of figuring it out.
> > 
> > - -- 
> > 
> > - -- Ed Leafe
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> > Comment: GPGTools - https://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > 
> > iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> > U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> > iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> > ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> > Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> > +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> > VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> > tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> > 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> > B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> > uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> > GcPgzIoclwLrVooRqOSf
> > =Dqga
> > -END PGP SIGNATURE-
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 05:29 PM, Doug Wiegley wrote:
> 
> > On Feb 12, 2016, at 3:17 PM, Andrew Laski  wrote:
> > 
> > 
> > 
> > On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
> >> 
> >>> On Feb 12, 2016, at 2:15 PM, Andrew Laski  wrote:
> >>> 
> >>> 
> >>> 
> >>> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>  Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
>  gives it one nic with an IP, right?
>  
>  So how is this changing that behavior? Making it harder to use, for the
>  sake of preserving a really unusual corner case (no net with neutron),
>  seems a much worse user experience here.
> >>> 
> >>> I was just going off of the behavior Matt described, that it was
> >>> possible to boot with no network by leaving that out of the request. If
> >>> the behavior already differs based on what networking backend is in use
> >>> then we've put users in a bad spot, and IMO furthers my case for having
> >>> explicit parameters in the request. I'm really not seeing how "--nic
> >>> auto|none" is any harder than leaving all network related parameters off
> >>> of the boot request, and it avoids potential confusion as to what will
> >>> happen.
> >> 
> >> It hurts discoverability, and “expectedness”. If I’m new to openstack,
> >> having it default boot unusable just means the first time I use ’nova
> >> boot’, I’ll end up with a useless VM. People don’t read docs first, it
> >> should “just work” as far as that’s sane. And OpenStack has a LOT of
> >> these little annoyances for the sake of strict correctness while
> >> optimizing for an unusual or rare case.
> >> 
> >> The original stated goal of this simpler neutron api was to get back to
> >> the simpler nova boot. I’d like to see that happen.
> > 
> > I'm not suggesting that the default boot be unusable. I'm saying that
> > just like it's required to pass in a flavor and image/volume to boot an
> > instance why not require the user to specify something about the
> > network. And that network request can be as simple as specifying "auto"
> > or "none". That seems to meet all of the requirements without the
> > confusion of needing to guess what the default behavior will be when
> > it's left off because it can apparently mean different things based on
> > which backed is in use. For users that don't read the docs they'll get
> > an immediate failure response indicating that they need to specify
> > something about the network versus the current and proposed state where
> > it's not clear what will happen unless they've read the docs on
> > microversions and understand which network service is being used.
> 
> I understand what you’re saying, and we’re almost down to style here. We
> have the previous nova-net ‘nova boot’ behavior, plus I think a VM with a
> network is kinda nonsensical, so adding that hoop for the default case
> doesn’t make sense to me. I’m not sure we’ll convince each other here,
> and that’s ok, I’ve said my peace.  :-)

Me too :)

Thanks for the discussion.


> 
> Thanks,
> doug
> 
> > 
> >> 
> >> Thanks,
> >> doug
> >> 
> >>> 
>  
>  Thanks,
>  doug
>  
>  
> > On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 02/12/2016 02:41 PM, Andrew Laski wrote:
> > 
> >>> I think if the point of the experience for this API is to be
> >>> working out
>  of the box. So I very much like the idea of a defaults change
>  here to the thing we want to be easy. And an explicit option to
>  disable it if you want to do something more complicated.
> > 
> >> I think this creates a potential for confusing behavior for users. 
> >> They're happily booting instances with no network on 2.1, as silly
> >> as that might be, and then decide "ooh I'd like to use fancy new
> >> flag foo which is available in 2.35". So they add the flag to their
> >> request and set the version to 2.35 and suddenly multiple things
> >> change about their boot process because they missed that 2.24(or
> >> whatever) changed a default behavior. If this fits within the scope
> >> of microversions then users will need to expect that, but it's
> >> something that would be likely to trip me up as a user of the API.
> > 
> > I agree - that's always been the trade-off with microversions. You
> > never get surprises, but you can't move to a new feature in 2.X
> > without also having to get everything that was also introduced in
> > 2.X-1 and before. The benefit, of course, is that the user will have
> > changed something explicitly before getting the new behavior, and at
> > least has a chance of figuring it out.
> > 
> > - -- 
> > 
> > - -- Ed Leafe
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> > Comment: GPGTools - 

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 03:11 PM, Sean Dague wrote:
> On 02/12/2016 02:19 PM, Andrew Laski wrote:
> > 
> > 
> > On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote:
> >> On 12 February 2016 at 18:17, Andrew Laski  wrote:
> >>>
> >>>
> >>> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
>  Forgive me for thinking out loud, but I'm trying to sort out how nova
>  would use a microversion in the nova API for the get-me-a-network
>  feature recently added to neutron [1] and planned to be leveraged in
>  nova (there isn't a spec yet for nova, I'm trying to sort this out for a
>  draft).
> 
>  Originally I was thinking that a network is required for nova boot, so
>  we'd simply check for a microversion and allow not specifying a network,
>  easy peasy.
> 
>  Turns out you can boot an instance in nova (with neutron as the network
>  backend) without a network. All you get is a measly debug log message in
>  the compute logs [2]. That's kind of useless though and seems silly.
> 
>  I haven't tested this out yet to confirm, but I suspect that if you
>  create a nova instance w/o a network, you can latter try to attach a
>  network using the os-attach-interfaces API as long as you either provide
>  a network ID *or* there is a public shared network or the tenant has a
>  network at that point (nova looks those up if a specific network ID
>  isn't provided).
> 
>  The high-level plan for get-me-a-network in nova was simply going to be
>  if the user tries to boot an instance and doesn't provide a network, and
>  there isn't a tenant network or public shared network to default to,
>  then nova would call neutron's new auto-allocated-topology API to get a
>  network. This, however, is a behavior change.
> 
>  So I guess the question now is how do we handle that behavior change in
>  the nova API?
> 
>  We could add an auto-create-net boolean to the boot server request which
>  would only be available in a microversion, then we could check that
>  boolean in the compute API when we're doing network validation.
> 
> >>>
> >>> I think a flag like this is the right approach. If it's currently valid
> >>> to boot an instance without a network than there needs to be something
> >>> to distinguish a request that wants a network created vs. a request that
> >>> doesn't want a network.
> >>>
> >>> This is still hugely useful if all that's required from a user is to
> >>> indicate that they would like a network, they still don't need to
> >>> understand/provide details of the network.
> >>
> >> I was thinking a sort of opposite. Would this work?
> >>
> >> We add a new micro-version that does this:
> >> * nothing specified: do the best we can to get a port created
> >> (get-me-a-network, etc,), or fail if not possible
> >> * --no-nics option (or similar) that says "please don't give me any nics"
> >>
> >> This means folks that don't want a network, reliably have a way to do
> >> that. For everyone else, we do the same thing when using either
> >> neutron or nova-network VLAN manager.
> > 
> > I think this pushes our microversions meaning a bit further than
> > intended. I don't think the API should flip behaviors simply based on a
> > microversion.
> > 
> > What about requiring nic information with the microversion? Make users
> > indicate explicitly if they want a network or not and avoid changing a
> > default behavior.
> 
> I think changing default behavior like that is totally within bounds,
> and was part of the original design point of microversions (and why you
> have to opt into them). So people that don't want a network that go past
> that boundary know to start saying "hands-off".
> 
> I think if the point of the experience for this API is to be working out
> of the box. So I very much like the idea of a defaults change here to
> the thing we want to be easy. And an explicit option to disable it if
> you want to do something more complicated.

I think this creates a potential for confusing behavior for users.
They're happily booting instances with no network on 2.1, as silly as
that might be, and then decide "ooh I'd like to use fancy new flag foo
which is available in 2.35". So they add the flag to their request and
set the version to 2.35 and suddenly multiple things change about their
boot process because they missed that 2.24(or whatever) changed a
default behavior. If this fits within the scope of microversions then
users will need to expect that, but it's something that would be likely
to trip me up as a user of the API.


> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

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

[Doug Wiegley]

Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically gives it 
one nic with an IP, right?

So how is this changing that behavior? Making it harder to use, for the sake of 
preserving a really unusual corner case (no net with neutron), seems a much 
worse user experience here.

Thanks,
doug


> On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> 
>>> I think if the point of the experience for this API is to be
>>> working out
 of the box. So I very much like the idea of a defaults change
 here to the thing we want to be easy. And an explicit option to
 disable it if you want to do something more complicated.
> 
>> I think this creates a potential for confusing behavior for users. 
>> They're happily booting instances with no network on 2.1, as silly
>> as that might be, and then decide "ooh I'd like to use fancy new
>> flag foo which is available in 2.35". So they add the flag to their
>> request and set the version to 2.35 and suddenly multiple things
>> change about their boot process because they missed that 2.24(or
>> whatever) changed a default behavior. If this fits within the scope
>> of microversions then users will need to expect that, but it's
>> something that would be likely to trip me up as a user of the API.
> 
> I agree - that's always been the trade-off with microversions. You
> never get surprises, but you can't move to a new feature in 2.X
> without also having to get everything that was also introduced in
> 2.X-1 and before. The benefit, of course, is that the user will have
> changed something explicitly before getting the new behavior, and at
> least has a chance of figuring it out.
> 
> - -- 
> 
> - -- Ed Leafe
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> GcPgzIoclwLrVooRqOSf
> =Dqga
> -END PGP SIGNATURE-
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Wiegley]

> On Feb 12, 2016, at 3:17 PM, Andrew Laski  wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
>> 
>>> On Feb 12, 2016, at 2:15 PM, Andrew Laski  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
 Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
 gives it one nic with an IP, right?
 
 So how is this changing that behavior? Making it harder to use, for the
 sake of preserving a really unusual corner case (no net with neutron),
 seems a much worse user experience here.
>>> 
>>> I was just going off of the behavior Matt described, that it was
>>> possible to boot with no network by leaving that out of the request. If
>>> the behavior already differs based on what networking backend is in use
>>> then we've put users in a bad spot, and IMO furthers my case for having
>>> explicit parameters in the request. I'm really not seeing how "--nic
>>> auto|none" is any harder than leaving all network related parameters off
>>> of the boot request, and it avoids potential confusion as to what will
>>> happen.
>> 
>> It hurts discoverability, and “expectedness”. If I’m new to openstack,
>> having it default boot unusable just means the first time I use ’nova
>> boot’, I’ll end up with a useless VM. People don’t read docs first, it
>> should “just work” as far as that’s sane. And OpenStack has a LOT of
>> these little annoyances for the sake of strict correctness while
>> optimizing for an unusual or rare case.
>> 
>> The original stated goal of this simpler neutron api was to get back to
>> the simpler nova boot. I’d like to see that happen.
> 
> I'm not suggesting that the default boot be unusable. I'm saying that
> just like it's required to pass in a flavor and image/volume to boot an
> instance why not require the user to specify something about the
> network. And that network request can be as simple as specifying "auto"
> or "none". That seems to meet all of the requirements without the
> confusion of needing to guess what the default behavior will be when
> it's left off because it can apparently mean different things based on
> which backed is in use. For users that don't read the docs they'll get
> an immediate failure response indicating that they need to specify
> something about the network versus the current and proposed state where
> it's not clear what will happen unless they've read the docs on
> microversions and understand which network service is being used.

I understand what you’re saying, and we’re almost down to style here. We have 
the previous nova-net ‘nova boot’ behavior, plus I think a VM with a network is 
kinda nonsensical, so adding that hoop for the default case doesn’t make sense 
to me. I’m not sure we’ll convince each other here, and that’s ok, I’ve said my 
peace.  :-)

Thanks,
doug

> 
>> 
>> Thanks,
>> doug
>> 
>>> 
 
 Thanks,
 doug
 
 
> On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> 
>>> I think if the point of the experience for this API is to be
>>> working out
 of the box. So I very much like the idea of a defaults change
 here to the thing we want to be easy. And an explicit option to
 disable it if you want to do something more complicated.
> 
>> I think this creates a potential for confusing behavior for users. 
>> They're happily booting instances with no network on 2.1, as silly
>> as that might be, and then decide "ooh I'd like to use fancy new
>> flag foo which is available in 2.35". So they add the flag to their
>> request and set the version to 2.35 and suddenly multiple things
>> change about their boot process because they missed that 2.24(or
>> whatever) changed a default behavior. If this fits within the scope
>> of microversions then users will need to expect that, but it's
>> something that would be likely to trip me up as a user of the API.
> 
> I agree - that's always been the trade-off with microversions. You
> never get surprises, but you can't move to a new feature in 2.X
> without also having to get everything that was also introduced in
> 2.X-1 and before. The benefit, of course, is that the user will have
> changed something explicitly before getting the new behavior, and at
> least has a chance of figuring it out.
> 
> - -- 
> 
> - -- Ed Leafe
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> 

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

[Jay Pipes]

On 02/12/2016 02:18 PM, Doug Wiegley wrote:

I thought one of the original notions behind this was to make ‘nova
boot’ as simple as in the nova-net case, which would imply not
needing to use —nic at all. I personally like the idea of the flag
being for the no network case.


This would be my preference as well, even though it's technically a 
backwards-incompatible API change.


The idea behind get-me-a-network was specifically to remove the current 
required complexity of the nova boot command with regards to networking 
options and allow a return to the nova-net model where an admin could 
auto-create a bunch of unassigned networks and the first time a user 
booted an instance and did not specify any network configuration (the 
default, sane behaviour in nova-net), one of those unassigned networks 
would be grabbed for the troject, I mean prenant, sorry.


So yeah, the "opt-in to having no networking at all with a 
--no-networking or --no-nics option" would be my preference.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Laski]

On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
> 
> > On Feb 12, 2016, at 2:15 PM, Andrew Laski  wrote:
> > 
> > 
> > 
> > On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
> >> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
> >> gives it one nic with an IP, right?
> >> 
> >> So how is this changing that behavior? Making it harder to use, for the
> >> sake of preserving a really unusual corner case (no net with neutron),
> >> seems a much worse user experience here.
> > 
> > I was just going off of the behavior Matt described, that it was
> > possible to boot with no network by leaving that out of the request. If
> > the behavior already differs based on what networking backend is in use
> > then we've put users in a bad spot, and IMO furthers my case for having
> > explicit parameters in the request. I'm really not seeing how "--nic
> > auto|none" is any harder than leaving all network related parameters off
> > of the boot request, and it avoids potential confusion as to what will
> > happen.
> 
> It hurts discoverability, and “expectedness”. If I’m new to openstack,
> having it default boot unusable just means the first time I use ’nova
> boot’, I’ll end up with a useless VM. People don’t read docs first, it
> should “just work” as far as that’s sane. And OpenStack has a LOT of
> these little annoyances for the sake of strict correctness while
> optimizing for an unusual or rare case.
> 
> The original stated goal of this simpler neutron api was to get back to
> the simpler nova boot. I’d like to see that happen.

I'm not suggesting that the default boot be unusable. I'm saying that
just like it's required to pass in a flavor and image/volume to boot an
instance why not require the user to specify something about the
network. And that network request can be as simple as specifying "auto"
or "none". That seems to meet all of the requirements without the
confusion of needing to guess what the default behavior will be when
it's left off because it can apparently mean different things based on
which backed is in use. For users that don't read the docs they'll get
an immediate failure response indicating that they need to specify
something about the network versus the current and proposed state where
it's not clear what will happen unless they've read the docs on
microversions and understand which network service is being used.

> 
> Thanks,
> doug
> 
> > 
> >> 
> >> Thanks,
> >> doug
> >> 
> >> 
> >>> On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>> 
> >>> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> >>> 
> > I think if the point of the experience for this API is to be
> > working out
> >> of the box. So I very much like the idea of a defaults change
> >> here to the thing we want to be easy. And an explicit option to
> >> disable it if you want to do something more complicated.
> >>> 
>  I think this creates a potential for confusing behavior for users. 
>  They're happily booting instances with no network on 2.1, as silly
>  as that might be, and then decide "ooh I'd like to use fancy new
>  flag foo which is available in 2.35". So they add the flag to their
>  request and set the version to 2.35 and suddenly multiple things
>  change about their boot process because they missed that 2.24(or
>  whatever) changed a default behavior. If this fits within the scope
>  of microversions then users will need to expect that, but it's
>  something that would be likely to trip me up as a user of the API.
> >>> 
> >>> I agree - that's always been the trade-off with microversions. You
> >>> never get surprises, but you can't move to a new feature in 2.X
> >>> without also having to get everything that was also introduced in
> >>> 2.X-1 and before. The benefit, of course, is that the user will have
> >>> changed something explicitly before getting the new behavior, and at
> >>> least has a chance of figuring it out.
> >>> 
> >>> - -- 
> >>> 
> >>> - -- Ed Leafe
> >>> -BEGIN PGP SIGNATURE-
> >>> Version: GnuPG v2
> >>> Comment: GPGTools - https://gpgtools.org
> >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>> 
> >>> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> >>> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> >>> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> >>> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> >>> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> >>> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> >>> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> >>> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> >>> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> >>> 

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

[Kevin Benton]

>plus I think a VM with a network is kinda nonsensical,

On the contrary, that's when I find them the most useful!
On Feb 12, 2016 14:33, "Doug Wiegley"  wrote:

>
> > On Feb 12, 2016, at 3:17 PM, Andrew Laski  wrote:
> >
> >
> >
> > On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
> >>
> >>> On Feb 12, 2016, at 2:15 PM, Andrew Laski  wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>  Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
>  gives it one nic with an IP, right?
> 
>  So how is this changing that behavior? Making it harder to use, for
> the
>  sake of preserving a really unusual corner case (no net with neutron),
>  seems a much worse user experience here.
> >>>
> >>> I was just going off of the behavior Matt described, that it was
> >>> possible to boot with no network by leaving that out of the request. If
> >>> the behavior already differs based on what networking backend is in use
> >>> then we've put users in a bad spot, and IMO furthers my case for having
> >>> explicit parameters in the request. I'm really not seeing how "--nic
> >>> auto|none" is any harder than leaving all network related parameters
> off
> >>> of the boot request, and it avoids potential confusion as to what will
> >>> happen.
> >>
> >> It hurts discoverability, and “expectedness”. If I’m new to openstack,
> >> having it default boot unusable just means the first time I use ’nova
> >> boot’, I’ll end up with a useless VM. People don’t read docs first, it
> >> should “just work” as far as that’s sane. And OpenStack has a LOT of
> >> these little annoyances for the sake of strict correctness while
> >> optimizing for an unusual or rare case.
> >>
> >> The original stated goal of this simpler neutron api was to get back to
> >> the simpler nova boot. I’d like to see that happen.
> >
> > I'm not suggesting that the default boot be unusable. I'm saying that
> > just like it's required to pass in a flavor and image/volume to boot an
> > instance why not require the user to specify something about the
> > network. And that network request can be as simple as specifying "auto"
> > or "none". That seems to meet all of the requirements without the
> > confusion of needing to guess what the default behavior will be when
> > it's left off because it can apparently mean different things based on
> > which backed is in use. For users that don't read the docs they'll get
> > an immediate failure response indicating that they need to specify
> > something about the network versus the current and proposed state where
> > it's not clear what will happen unless they've read the docs on
> > microversions and understand which network service is being used.
>
> I understand what you’re saying, and we’re almost down to style here. We
> have the previous nova-net ‘nova boot’ behavior, plus I think a VM with a
> network is kinda nonsensical, so adding that hoop for the default case
> doesn’t make sense to me. I’m not sure we’ll convince each other here, and
> that’s ok, I’ve said my peace.  :-)
>
> Thanks,
> doug
>
> >
> >>
> >> Thanks,
> >> doug
> >>
> >>>
> 
>  Thanks,
>  doug
> 
> 
> > On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 02/12/2016 02:41 PM, Andrew Laski wrote:
> >
> >>> I think if the point of the experience for this API is to be
> >>> working out
>  of the box. So I very much like the idea of a defaults change
>  here to the thing we want to be easy. And an explicit option to
>  disable it if you want to do something more complicated.
> >
> >> I think this creates a potential for confusing behavior for users.
> >> They're happily booting instances with no network on 2.1, as silly
> >> as that might be, and then decide "ooh I'd like to use fancy new
> >> flag foo which is available in 2.35". So they add the flag to their
> >> request and set the version to 2.35 and suddenly multiple things
> >> change about their boot process because they missed that 2.24(or
> >> whatever) changed a default behavior. If this fits within the scope
> >> of microversions then users will need to expect that, but it's
> >> something that would be likely to trip me up as a user of the API.
> >
> > I agree - that's always been the trade-off with microversions. You
> > never get surprises, but you can't move to a new feature in 2.X
> > without also having to get everything that was also introduced in
> > 2.X-1 and before. The benefit, of course, is that the user will have
> > changed something explicitly before getting the new behavior, and at
> > least has a chance of figuring it out.
> >
> > - --
> >
> > - -- Ed Leafe
> > -BEGIN PGP