Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Clark Boylan]

On Fri, Feb 26, 2016, at 04:06 AM, Matt Jarvis wrote:
> Out of interest, are there really OpenStack public clouds where the cloud
> provider doesn't automatically provision an initial network and router ?
> 
I can think of two off the top of my head. HPCloud definitely didn't
when I got my accounts (but may have later on?). The other isn't a true
public cloud but I had to provision all this on the new OSIC cloud.

Regardless of whether or not your cloud does a smart thing I think the
idea is to make sure that all clouds work by default and make user lives
easier regardless of the underlying networking choices that a cloud has
made.

Clark

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Robert Starmer]

Ha, now that's a truth :)

On Fri, Feb 26, 2016 at 7:34 AM, Matt Jarvis 
wrote:

> Agreed, although I've learned over the years that second guessing what
> actions customers may or may not take is usually a losing battle ;)
>
> On 26 February 2016 at 13:55, Robert Starmer  wrote:
>
>> For a user that's gone and deleted their network services, then wouldn't
>> they perhaps be savvy enough to deploy a network/subnet pair.  If they
>> don't want to pay for the router then this is what they'd be working
>> towards (by deleting their initially provisioned service).  As it stands
>> today, if you have a single network available (regardless of upstream
>> router), your "nova boot" process will associate the VM to that network
>> automatically.
>>
>> For the user who is trying to do something specific, giving them an
>> option (opt-out if you don't want a network), actually maps the most common
>> case  of user wants a VM to be able to get to the world to the default, and
>> the odd (and I haven't ever seen an actual use case where I want a VM
>> without a network of some nature associated to it) case of "I don't want
>> any network" an option by specifically calling that out on boot.
>>
>> And I personally am unaware of any service provider that doesn't give you
>> network access by default when you stand up a project.
>>
>>
>> On Fri, Feb 26, 2016 at 5:06 AM, Matt Jarvis <
>> matt.jar...@datacentred.co.uk> wrote:
>>
>>> As I've already said in this thread, we automatically provide an initial
>>> network and router for all our customers as part of our on-boarding process
>>> so in our case this problem doesn't actually exist unless customers delete
>>> their initial router and network. If a customer has already deleted these
>>> for some reason, my concern around an opt-out process is that we start
>>> automatically creating chargeable entities without the customer
>>> specifically asking for it.
>>>
>>> Out of interest, are there really OpenStack public clouds where the
>>> cloud provider doesn't automatically provision an initial network and
>>> router ?
>>>
>>> On 26 February 2016 at 11:36, Jeremy Stanley  wrote:
>>>
 On 2016-02-26 11:21:47 + (+), Matt Jarvis wrote:
 > From a public cloud perspective I'm not convinced that an opt-out
 argument
 > is the right way to go. A router in our context is a chargeable item,
 > because it has an external IP address, so automatically creating stuff
 > without the user specifying it is not an ideal outcome. Personally I'd
 > rather see an opt-in argument ie. option 1

 As a user of many public clouds, some of which use Nova network,
 some of which use Neutron with a common flat provider network, et
 cetera, _I_ want them to behave consistently when I ask them to boot
 a node rather than needing to remember that on some subset of them I
 also need to perform an unholy dance to convince them I really want
 to have access to the servers I've created.

 Making it so that some public cloud providers can continue to
 require completely different business logic than others just to have
 a reachable server basically shoots any hope we have as a community
 for consistency and "interoperability" in the head. Cloud providers
 seem to think that they'll attract me with their unique market
 differentiating features, but I could really care less. What I want
 is for OpenStack to succeed by providing a seamless experience where
 things look as identical as possible no matter what provider or
 environment I use. OpenStack doesn't need to compete against itself,
 there is plenty enough competition out there for us already even if
 we band together in a unity of design and function.
 --
 Jeremy Stanley

 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

>>>
>>>
>>> DataCentred Limited registered in England and Wales no. 05611763
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>
> DataCentred Limited registered in England and Wales no. 05611763
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Robert Starmer]

For a user that's gone and deleted their network services, then wouldn't
they perhaps be savvy enough to deploy a network/subnet pair.  If they
don't want to pay for the router then this is what they'd be working
towards (by deleting their initially provisioned service).  As it stands
today, if you have a single network available (regardless of upstream
router), your "nova boot" process will associate the VM to that network
automatically.

For the user who is trying to do something specific, giving them an option
(opt-out if you don't want a network), actually maps the most common case
 of user wants a VM to be able to get to the world to the default, and the
odd (and I haven't ever seen an actual use case where I want a VM without a
network of some nature associated to it) case of "I don't want any network"
an option by specifically calling that out on boot.

And I personally am unaware of any service provider that doesn't give you
network access by default when you stand up a project.


On Fri, Feb 26, 2016 at 5:06 AM, Matt Jarvis 
wrote:

> As I've already said in this thread, we automatically provide an initial
> network and router for all our customers as part of our on-boarding process
> so in our case this problem doesn't actually exist unless customers delete
> their initial router and network. If a customer has already deleted these
> for some reason, my concern around an opt-out process is that we start
> automatically creating chargeable entities without the customer
> specifically asking for it.
>
> Out of interest, are there really OpenStack public clouds where the cloud
> provider doesn't automatically provision an initial network and router ?
>
> On 26 February 2016 at 11:36, Jeremy Stanley  wrote:
>
>> On 2016-02-26 11:21:47 + (+), Matt Jarvis wrote:
>> > From a public cloud perspective I'm not convinced that an opt-out
>> argument
>> > is the right way to go. A router in our context is a chargeable item,
>> > because it has an external IP address, so automatically creating stuff
>> > without the user specifying it is not an ideal outcome. Personally I'd
>> > rather see an opt-in argument ie. option 1
>>
>> As a user of many public clouds, some of which use Nova network,
>> some of which use Neutron with a common flat provider network, et
>> cetera, _I_ want them to behave consistently when I ask them to boot
>> a node rather than needing to remember that on some subset of them I
>> also need to perform an unholy dance to convince them I really want
>> to have access to the servers I've created.
>>
>> Making it so that some public cloud providers can continue to
>> require completely different business logic than others just to have
>> a reachable server basically shoots any hope we have as a community
>> for consistency and "interoperability" in the head. Cloud providers
>> seem to think that they'll attract me with their unique market
>> differentiating features, but I could really care less. What I want
>> is for OpenStack to succeed by providing a seamless experience where
>> things look as identical as possible no matter what provider or
>> environment I use. OpenStack doesn't need to compete against itself,
>> there is plenty enough competition out there for us already even if
>> we band together in a unity of design and function.
>> --
>> Jeremy Stanley
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> DataCentred Limited registered in England and Wales no. 05611763
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Matt Jarvis]

As I've already said in this thread, we automatically provide an initial
network and router for all our customers as part of our on-boarding process
so in our case this problem doesn't actually exist unless customers delete
their initial router and network. If a customer has already deleted these
for some reason, my concern around an opt-out process is that we start
automatically creating chargeable entities without the customer
specifically asking for it.

Out of interest, are there really OpenStack public clouds where the cloud
provider doesn't automatically provision an initial network and router ?

On 26 February 2016 at 11:36, Jeremy Stanley  wrote:

> On 2016-02-26 11:21:47 + (+), Matt Jarvis wrote:
> > From a public cloud perspective I'm not convinced that an opt-out
> argument
> > is the right way to go. A router in our context is a chargeable item,
> > because it has an external IP address, so automatically creating stuff
> > without the user specifying it is not an ideal outcome. Personally I'd
> > rather see an opt-in argument ie. option 1
>
> As a user of many public clouds, some of which use Nova network,
> some of which use Neutron with a common flat provider network, et
> cetera, _I_ want them to behave consistently when I ask them to boot
> a node rather than needing to remember that on some subset of them I
> also need to perform an unholy dance to convince them I really want
> to have access to the servers I've created.
>
> Making it so that some public cloud providers can continue to
> require completely different business logic than others just to have
> a reachable server basically shoots any hope we have as a community
> for consistency and "interoperability" in the head. Cloud providers
> seem to think that they'll attract me with their unique market
> differentiating features, but I could really care less. What I want
> is for OpenStack to succeed by providing a seamless experience where
> things look as identical as possible no matter what provider or
> environment I use. OpenStack doesn't need to compete against itself,
> there is plenty enough competition out there for us already even if
> we band together in a unity of design and function.
> --
> Jeremy Stanley
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Robert Starmer]

cool, then option 2 makes sense.

On Thu, Feb 25, 2016 at 9:41 PM, Kevin Benton  wrote:

> The router is automatically created as well and is attached to the tenants
> network and an external network with the flag 'is_default' set to true.
> On Feb 24, 2016 6:25 PM, "Robert Starmer"  wrote:
>
>> Most service environments I've worked with will deploy (often
>> automatically) a first tenant network and router, allowing for the simple
>> case of "deploy a vm, and it auto attaches to the only network" model.  So
>> in effect, this is anticipated, if not expected, behavior.  If on the other
>> hand, there is no network, does the auto-network process also create a
>> router, and associate that router with an "external" network with floating
>> address/etc.?  If not, then isn't the --nic=auto case effectively
>> equivalent to the no network case anyway? there's still neutron work to be
>> done, and the VM will likely need to have a DHCP lease re-established if a
>> router is also attached so that the network has anything other than local
>> meaning.
>>
>> I.e., what was the original use case of this auto-created network (which
>> sounds like it's here to stay regardless).  Does someone have a pointer to
>> the spec that defines the use case of this.
>>
>> But even so, I'd say I prefer model 2 over the others, but perhaps a
>> warning needs to be generated, especially if the network isn't router
>> connected automatically, otherwise, the end user is going to be confused as
>> to why internet connectivity isn't available ("I see a network attached,
>> but I can't get to the internet").
>>
>> Just my $0.02
>> Robert
>>
>> On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller  wrote:
>>
>>> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
>>>  wrote:
>>> >
>>> >
>>> > On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>>> >>
>>> >>
>>> >>
>>> >> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> ___
>>> >>> Kris Lindgren
>>> >>> Senior Linux Systems Engineer
>>> >>> GoDaddy
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 2/19/16, 10:07 AM, "Matt Riedemann" 
>>> >>> wrote:
>>> >>>
>>>  There is a long contentious dev thread going on here [1] about how
>>> Nova
>>>  should handle the Neutron auto-allocate-topology API (referred to
>>> as the
>>>  'get-me-a-network' effort).
>>> 
>>>  The point is to reduce the complexity for users to simply boot an
>>>  instance and be able to ssh into it without having to first setup
>>>  networks/subnets/routers in neutron and then specify a nic when
>>> booting
>>>  the instance. If the planets are aligned, and no nic is provided (or
>>>  available to the project), then nova would call the new neutron API
>>> to
>>>  auto-allocate the network and use that to create a port to associate
>>>  with the instance.
>>> 
>>>  There is existing behavior in Nova where you can boot an instance
>>> and
>>>  get no networking with neutron as the backend. You can later add
>>>  networking by attaching an interface. The nova dev team has no idea
>>> how
>>>  common this use case is though.
>>> 
>>>  There will be a microversion to the nova API with the
>>> get-me-a-network
>>>  support. The debate is what the default behavior should be when
>>> using
>>>  that microversion. The options are basically:
>>> 
>>>  1. If no nic is provided at boot and none are available, don't
>>> provide a
>>>  network (existing behavior). If the user wants a network
>>> auto-allocated,
>>>  they specify something like: --nic=auto
>>> >>>
>>> >>>
>>> >>> This is my preferred choice - keep the functionality exactly the same
>>> >>> as the way it is today.  Users (if this is available) can opt-in.
>>> Not
>>> >>> 100% familiar with micro-version - but is it possible to opt-out of
>>> >>> this micro-version all together, but have other, later,
>>> micro-versions?
>>> >>
>>> >>
>>> >> Users/clients opt into a microversion by specifying a header with the
>>> >> version in the request. You can't skip microversions. If your client
>>> >> support 2.10 and then you wanted to support 2.18, for example, you
>>> have
>>> >> to also build in support for handling 2.11-2.17.
>>> >>
>>> >>>
>>> >>>
>>> 
>>>  In this case the user has to opt into auto-allocating the network.
>>> 
>>>  2. If no nic is provided at boot and none are available, nova will
>>>  attempt to auto-allocate the network from neutron. If the user
>>>  specifically doesn't want networking on instance create (for
>>> whatever
>>>  reason), they have to opt into that behavior with something like:
>>>  --nic=none
>>> 
>>>  This is closer in behavior to how booting an instance works with
>>>  nova-network, but it is a change in 

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Kevin Benton]

The router is automatically created as well and is attached to the tenants
network and an external network with the flag 'is_default' set to true.
On Feb 24, 2016 6:25 PM, "Robert Starmer"  wrote:

> Most service environments I've worked with will deploy (often
> automatically) a first tenant network and router, allowing for the simple
> case of "deploy a vm, and it auto attaches to the only network" model.  So
> in effect, this is anticipated, if not expected, behavior.  If on the other
> hand, there is no network, does the auto-network process also create a
> router, and associate that router with an "external" network with floating
> address/etc.?  If not, then isn't the --nic=auto case effectively
> equivalent to the no network case anyway? there's still neutron work to be
> done, and the VM will likely need to have a DHCP lease re-established if a
> router is also attached so that the network has anything other than local
> meaning.
>
> I.e., what was the original use case of this auto-created network (which
> sounds like it's here to stay regardless).  Does someone have a pointer to
> the spec that defines the use case of this.
>
> But even so, I'd say I prefer model 2 over the others, but perhaps a
> warning needs to be generated, especially if the network isn't router
> connected automatically, otherwise, the end user is going to be confused as
> to why internet connectivity isn't available ("I see a network attached,
> but I can't get to the internet").
>
> Just my $0.02
> Robert
>
> On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller  wrote:
>
>> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
>>  wrote:
>> >
>> >
>> > On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>> >>
>> >>
>> >>
>> >> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> Kris Lindgren
>> >>> Senior Linux Systems Engineer
>> >>> GoDaddy
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 2/19/16, 10:07 AM, "Matt Riedemann" 
>> >>> wrote:
>> >>>
>>  There is a long contentious dev thread going on here [1] about how
>> Nova
>>  should handle the Neutron auto-allocate-topology API (referred to as
>> the
>>  'get-me-a-network' effort).
>> 
>>  The point is to reduce the complexity for users to simply boot an
>>  instance and be able to ssh into it without having to first setup
>>  networks/subnets/routers in neutron and then specify a nic when
>> booting
>>  the instance. If the planets are aligned, and no nic is provided (or
>>  available to the project), then nova would call the new neutron API
>> to
>>  auto-allocate the network and use that to create a port to associate
>>  with the instance.
>> 
>>  There is existing behavior in Nova where you can boot an instance and
>>  get no networking with neutron as the backend. You can later add
>>  networking by attaching an interface. The nova dev team has no idea
>> how
>>  common this use case is though.
>> 
>>  There will be a microversion to the nova API with the
>> get-me-a-network
>>  support. The debate is what the default behavior should be when using
>>  that microversion. The options are basically:
>> 
>>  1. If no nic is provided at boot and none are available, don't
>> provide a
>>  network (existing behavior). If the user wants a network
>> auto-allocated,
>>  they specify something like: --nic=auto
>> >>>
>> >>>
>> >>> This is my preferred choice - keep the functionality exactly the same
>> >>> as the way it is today.  Users (if this is available) can opt-in.  Not
>> >>> 100% familiar with micro-version - but is it possible to opt-out of
>> >>> this micro-version all together, but have other, later,
>> micro-versions?
>> >>
>> >>
>> >> Users/clients opt into a microversion by specifying a header with the
>> >> version in the request. You can't skip microversions. If your client
>> >> support 2.10 and then you wanted to support 2.18, for example, you have
>> >> to also build in support for handling 2.11-2.17.
>> >>
>> >>>
>> >>>
>> 
>>  In this case the user has to opt into auto-allocating the network.
>> 
>>  2. If no nic is provided at boot and none are available, nova will
>>  attempt to auto-allocate the network from neutron. If the user
>>  specifically doesn't want networking on instance create (for whatever
>>  reason), they have to opt into that behavior with something like:
>>  --nic=none
>> 
>>  This is closer in behavior to how booting an instance works with
>>  nova-network, but it is a change in the default behavior for the
>> neutron
>>  case, and that is a cause for concern for any users that have written
>>  tools to expect that default behavior.
>> >>>
>> >>>
>> >>>
>> >>> I don't like this but I think other people might.  

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Matt Jarvis]

On our public cloud we do exactly as Robert describes - as part of our
customer onboarding process, we automatically create a default network and
router to our provider network, so that a tenant can just spin up a VM if
they want to. Obviously the customer can then delete this if they wish, but
it gets them started.

On 25 February 2016 at 00:19, Robert Starmer  wrote:

> Most service environments I've worked with will deploy (often
> automatically) a first tenant network and router, allowing for the simple
> case of "deploy a vm, and it auto attaches to the only network" model.  So
> in effect, this is anticipated, if not expected, behavior.  If on the other
> hand, there is no network, does the auto-network process also create a
> router, and associate that router with an "external" network with floating
> address/etc.?  If not, then isn't the --nic=auto case effectively
> equivalent to the no network case anyway? there's still neutron work to be
> done, and the VM will likely need to have a DHCP lease re-established if a
> router is also attached so that the network has anything other than local
> meaning.
>
> I.e., what was the original use case of this auto-created network (which
> sounds like it's here to stay regardless).  Does someone have a pointer to
> the spec that defines the use case of this.
>
> But even so, I'd say I prefer model 2 over the others, but perhaps a
> warning needs to be generated, especially if the network isn't router
> connected automatically, otherwise, the end user is going to be confused as
> to why internet connectivity isn't available ("I see a network attached,
> but I can't get to the internet").
>
> Just my $0.02
> Robert
>
> On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller  wrote:
>
>> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
>>  wrote:
>> >
>> >
>> > On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>> >>
>> >>
>> >>
>> >> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> Kris Lindgren
>> >>> Senior Linux Systems Engineer
>> >>> GoDaddy
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 2/19/16, 10:07 AM, "Matt Riedemann" 
>> >>> wrote:
>> >>>
>>  There is a long contentious dev thread going on here [1] about how
>> Nova
>>  should handle the Neutron auto-allocate-topology API (referred to as
>> the
>>  'get-me-a-network' effort).
>> 
>>  The point is to reduce the complexity for users to simply boot an
>>  instance and be able to ssh into it without having to first setup
>>  networks/subnets/routers in neutron and then specify a nic when
>> booting
>>  the instance. If the planets are aligned, and no nic is provided (or
>>  available to the project), then nova would call the new neutron API
>> to
>>  auto-allocate the network and use that to create a port to associate
>>  with the instance.
>> 
>>  There is existing behavior in Nova where you can boot an instance and
>>  get no networking with neutron as the backend. You can later add
>>  networking by attaching an interface. The nova dev team has no idea
>> how
>>  common this use case is though.
>> 
>>  There will be a microversion to the nova API with the
>> get-me-a-network
>>  support. The debate is what the default behavior should be when using
>>  that microversion. The options are basically:
>> 
>>  1. If no nic is provided at boot and none are available, don't
>> provide a
>>  network (existing behavior). If the user wants a network
>> auto-allocated,
>>  they specify something like: --nic=auto
>> >>>
>> >>>
>> >>> This is my preferred choice - keep the functionality exactly the same
>> >>> as the way it is today.  Users (if this is available) can opt-in.  Not
>> >>> 100% familiar with micro-version - but is it possible to opt-out of
>> >>> this micro-version all together, but have other, later,
>> micro-versions?
>> >>
>> >>
>> >> Users/clients opt into a microversion by specifying a header with the
>> >> version in the request. You can't skip microversions. If your client
>> >> support 2.10 and then you wanted to support 2.18, for example, you have
>> >> to also build in support for handling 2.11-2.17.
>> >>
>> >>>
>> >>>
>> 
>>  In this case the user has to opt into auto-allocating the network.
>> 
>>  2. If no nic is provided at boot and none are available, nova will
>>  attempt to auto-allocate the network from neutron. If the user
>>  specifically doesn't want networking on instance create (for whatever
>>  reason), they have to opt into that behavior with something like:
>>  --nic=none
>> 
>>  This is closer in behavior to how booting an instance works with
>>  nova-network, but it is a change in the default behavior for the
>> neutron
>>  case, and that is a 

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Assaf Muller]

On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
 wrote:
>
>
> On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>>
>>
>>
>> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>>>
>>>
>>>
>>> ___
>>> Kris Lindgren
>>> Senior Linux Systems Engineer
>>> GoDaddy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2/19/16, 10:07 AM, "Matt Riedemann" 
>>> wrote:
>>>
 There is a long contentious dev thread going on here [1] about how Nova
 should handle the Neutron auto-allocate-topology API (referred to as the
 'get-me-a-network' effort).

 The point is to reduce the complexity for users to simply boot an
 instance and be able to ssh into it without having to first setup
 networks/subnets/routers in neutron and then specify a nic when booting
 the instance. If the planets are aligned, and no nic is provided (or
 available to the project), then nova would call the new neutron API to
 auto-allocate the network and use that to create a port to associate
 with the instance.

 There is existing behavior in Nova where you can boot an instance and
 get no networking with neutron as the backend. You can later add
 networking by attaching an interface. The nova dev team has no idea how
 common this use case is though.

 There will be a microversion to the nova API with the get-me-a-network
 support. The debate is what the default behavior should be when using
 that microversion. The options are basically:

 1. If no nic is provided at boot and none are available, don't provide a
 network (existing behavior). If the user wants a network auto-allocated,
 they specify something like: --nic=auto
>>>
>>>
>>> This is my preferred choice - keep the functionality exactly the same
>>> as the way it is today.  Users (if this is available) can opt-in.  Not
>>> 100% familiar with micro-version - but is it possible to opt-out of
>>> this micro-version all together, but have other, later, micro-versions?
>>
>>
>> Users/clients opt into a microversion by specifying a header with the
>> version in the request. You can't skip microversions. If your client
>> support 2.10 and then you wanted to support 2.18, for example, you have
>> to also build in support for handling 2.11-2.17.
>>
>>>
>>>

 In this case the user has to opt into auto-allocating the network.

 2. If no nic is provided at boot and none are available, nova will
 attempt to auto-allocate the network from neutron. If the user
 specifically doesn't want networking on instance create (for whatever
 reason), they have to opt into that behavior with something like:
 --nic=none

 This is closer in behavior to how booting an instance works with
 nova-network, but it is a change in the default behavior for the neutron
 case, and that is a cause for concern for any users that have written
 tools to expect that default behavior.
>>>
>>>
>>>
>>> I don't like this but I think other people might.  Really I would like
>>> to see a config option detailing how the cloud admin wants to handle
>>> this behavior.
>>
>>
>> With the push for more consistent API behavior across public OpenStack
>> clouds, making the API configurable with config options is not really a
>> thing we want to do anymore since it's not discoverable. If cloud A
>> doesn't support this but cloud B does, even though you've specified the
>> same microversion for both, it's confusing and unreliable. Of course we
>> already have some of this situation already since not all of the virt
>> driver backends support 100% of the REST API, but I don't think we want
>> to add to that if we can help it.
>
>
> Thinking about this again today, nova is going to be checking that the
> auto-allocate-topolocy extension is enabled in neutron. So if you just don't
> enable that extension, you've effectively disabled the nic=auto option in
> nova. Basically like a config option.

Only you kinda can't:
https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41

get-me-a-network is enabled by default, so if you're running a recent
enough Neutron you're just going to get that extension enabled.

>
>
>>
>>>

 3. If no nic is provided at boot and none are available, fail the
 request and force the request to be explicit, i.e. provide a specific
 nic, or auto, or none. This is a fail-fast scenario to force users to
 really state what they want.
>>>
>>>
>>> I don't like this option at all.  You are chaning what people must
>>> provide on the bootline and this as far as I can tell is a breaking
>>> change.
>>
>>
>> Yes it's a breaking change, but with a microversion you have to opt into
>> it, so you have to be aware of it when you make the request. Just FYI.
>>
>>>

 --

 As with any microversion change, we hope 

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Matt Riedemann]

On 2/20/2016 5:29 PM, Matt Riedemann wrote:



On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:



___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 2/19/16, 10:07 AM, "Matt Riedemann" 
wrote:


There is a long contentious dev thread going on here [1] about how Nova
should handle the Neutron auto-allocate-topology API (referred to as the
'get-me-a-network' effort).

The point is to reduce the complexity for users to simply boot an
instance and be able to ssh into it without having to first setup
networks/subnets/routers in neutron and then specify a nic when booting
the instance. If the planets are aligned, and no nic is provided (or
available to the project), then nova would call the new neutron API to
auto-allocate the network and use that to create a port to associate
with the instance.

There is existing behavior in Nova where you can boot an instance and
get no networking with neutron as the backend. You can later add
networking by attaching an interface. The nova dev team has no idea how
common this use case is though.

There will be a microversion to the nova API with the get-me-a-network
support. The debate is what the default behavior should be when using
that microversion. The options are basically:

1. If no nic is provided at boot and none are available, don't provide a
network (existing behavior). If the user wants a network auto-allocated,
they specify something like: --nic=auto


This is my preferred choice - keep the functionality exactly the same
as the way it is today.  Users (if this is available) can opt-in.  Not
100% familiar with micro-version - but is it possible to opt-out of
this micro-version all together, but have other, later, micro-versions?


Users/clients opt into a microversion by specifying a header with the
version in the request. You can't skip microversions. If your client
support 2.10 and then you wanted to support 2.18, for example, you have
to also build in support for handling 2.11-2.17.






In this case the user has to opt into auto-allocating the network.

2. If no nic is provided at boot and none are available, nova will
attempt to auto-allocate the network from neutron. If the user
specifically doesn't want networking on instance create (for whatever
reason), they have to opt into that behavior with something like:
--nic=none

This is closer in behavior to how booting an instance works with
nova-network, but it is a change in the default behavior for the neutron
case, and that is a cause for concern for any users that have written
tools to expect that default behavior.



I don't like this but I think other people might.  Really I would like
to see a config option detailing how the cloud admin wants to handle
this behavior.


With the push for more consistent API behavior across public OpenStack
clouds, making the API configurable with config options is not really a
thing we want to do anymore since it's not discoverable. If cloud A
doesn't support this but cloud B does, even though you've specified the
same microversion for both, it's confusing and unreliable. Of course we
already have some of this situation already since not all of the virt
driver backends support 100% of the REST API, but I don't think we want
to add to that if we can help it.


Thinking about this again today, nova is going to be checking that the 
auto-allocate-topolocy extension is enabled in neutron. So if you just 
don't enable that extension, you've effectively disabled the nic=auto 
option in nova. Basically like a config option.








3. If no nic is provided at boot and none are available, fail the
request and force the request to be explicit, i.e. provide a specific
nic, or auto, or none. This is a fail-fast scenario to force users to
really state what they want.


I don't like this option at all.  You are chaning what people must
provide on the bootline and this as far as I can tell is a breaking
change.


Yes it's a breaking change, but with a microversion you have to opt into
it, so you have to be aware of it when you make the request. Just FYI.





--

As with any microversion change, we hope that users are reading the docs
and aware of the changes in each microversion, but we can't guarantee
that, so changing default behavior (case 2) requires discussion and
input, especially from outside the dev team.

If you or your users have any input on this, please respond in this
thread of the one in the -dev list.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html


--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Matt Riedemann]

On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:



___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 2/19/16, 10:07 AM, "Matt Riedemann"  wrote:


There is a long contentious dev thread going on here [1] about how Nova
should handle the Neutron auto-allocate-topology API (referred to as the
'get-me-a-network' effort).

The point is to reduce the complexity for users to simply boot an
instance and be able to ssh into it without having to first setup
networks/subnets/routers in neutron and then specify a nic when booting
the instance. If the planets are aligned, and no nic is provided (or
available to the project), then nova would call the new neutron API to
auto-allocate the network and use that to create a port to associate
with the instance.

There is existing behavior in Nova where you can boot an instance and
get no networking with neutron as the backend. You can later add
networking by attaching an interface. The nova dev team has no idea how
common this use case is though.

There will be a microversion to the nova API with the get-me-a-network
support. The debate is what the default behavior should be when using
that microversion. The options are basically:

1. If no nic is provided at boot and none are available, don't provide a
network (existing behavior). If the user wants a network auto-allocated,
they specify something like: --nic=auto


This is my preferred choice - keep the functionality exactly the same as the 
way it is today.  Users (if this is available) can opt-in.  Not 100% familiar 
with micro-version - but is it possible to opt-out of this micro-version all 
together, but have other, later, micro-versions?


Users/clients opt into a microversion by specifying a header with the 
version in the request. You can't skip microversions. If your client 
support 2.10 and then you wanted to support 2.18, for example, you have 
to also build in support for handling 2.11-2.17.







In this case the user has to opt into auto-allocating the network.

2. If no nic is provided at boot and none are available, nova will
attempt to auto-allocate the network from neutron. If the user
specifically doesn't want networking on instance create (for whatever
reason), they have to opt into that behavior with something like: --nic=none

This is closer in behavior to how booting an instance works with
nova-network, but it is a change in the default behavior for the neutron
case, and that is a cause for concern for any users that have written
tools to expect that default behavior.



I don't like this but I think other people might.  Really I would like to see a 
config option detailing how the cloud admin wants to handle this behavior.


With the push for more consistent API behavior across public OpenStack 
clouds, making the API configurable with config options is not really a 
thing we want to do anymore since it's not discoverable. If cloud A 
doesn't support this but cloud B does, even though you've specified the 
same microversion for both, it's confusing and unreliable. Of course we 
already have some of this situation already since not all of the virt 
driver backends support 100% of the REST API, but I don't think we want 
to add to that if we can help it.






3. If no nic is provided at boot and none are available, fail the
request and force the request to be explicit, i.e. provide a specific
nic, or auto, or none. This is a fail-fast scenario to force users to
really state what they want.


I don't like this option at all.  You are chaning what people must provide on 
the bootline and this as far as I can tell is a breaking change.


Yes it's a breaking change, but with a microversion you have to opt into 
it, so you have to be aware of it when you make the request. Just FYI.






--

As with any microversion change, we hope that users are reading the docs
and aware of the changes in each microversion, but we can't guarantee
that, so changing default behavior (case 2) requires discussion and
input, especially from outside the dev team.

If you or your users have any input on this, please respond in this
thread of the one in the -dev list.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html

--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Kris G. Lindgren]

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 2/19/16, 10:07 AM, "Matt Riedemann"  wrote:

>There is a long contentious dev thread going on here [1] about how Nova 
>should handle the Neutron auto-allocate-topology API (referred to as the 
>'get-me-a-network' effort).
>
>The point is to reduce the complexity for users to simply boot an 
>instance and be able to ssh into it without having to first setup 
>networks/subnets/routers in neutron and then specify a nic when booting 
>the instance. If the planets are aligned, and no nic is provided (or 
>available to the project), then nova would call the new neutron API to 
>auto-allocate the network and use that to create a port to associate 
>with the instance.
>
>There is existing behavior in Nova where you can boot an instance and 
>get no networking with neutron as the backend. You can later add 
>networking by attaching an interface. The nova dev team has no idea how 
>common this use case is though.
>
>There will be a microversion to the nova API with the get-me-a-network 
>support. The debate is what the default behavior should be when using 
>that microversion. The options are basically:
>
>1. If no nic is provided at boot and none are available, don't provide a 
>network (existing behavior). If the user wants a network auto-allocated, 
>they specify something like: --nic=auto

This is my preferred choice - keep the functionality exactly the same as the 
way it is today.  Users (if this is available) can opt-in.  Not 100% familiar 
with micro-version - but is it possible to opt-out of this micro-version all 
together, but have other, later, micro-versions?


>
>In this case the user has to opt into auto-allocating the network.
>
>2. If no nic is provided at boot and none are available, nova will 
>attempt to auto-allocate the network from neutron. If the user 
>specifically doesn't want networking on instance create (for whatever 
>reason), they have to opt into that behavior with something like: --nic=none
>
>This is closer in behavior to how booting an instance works with 
>nova-network, but it is a change in the default behavior for the neutron 
>case, and that is a cause for concern for any users that have written 
>tools to expect that default behavior.


I don't like this but I think other people might.  Really I would like to see a 
config option detailing how the cloud admin wants to handle this behavior.

>
>3. If no nic is provided at boot and none are available, fail the 
>request and force the request to be explicit, i.e. provide a specific 
>nic, or auto, or none. This is a fail-fast scenario to force users to 
>really state what they want.

I don't like this option at all.  You are chaning what people must provide on 
the bootline and this as far as I can tell is a breaking change. 

>
>--
>
>As with any microversion change, we hope that users are reading the docs 
>and aware of the changes in each microversion, but we can't guarantee 
>that, so changing default behavior (case 2) requires discussion and 
>input, especially from outside the dev team.
>
>If you or your users have any input on this, please respond in this 
>thread of the one in the -dev list.
>
>[1] 
>http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Silence Dogood]

>From a purely benchmarking aspect it makes sense.  It's like a burn in test
case use.  That only makes it make sense.

On Fri, Feb 19, 2016 at 5:09 PM, Kevin Bringard (kevinbri) <
kevin...@cisco.com> wrote:

> Sorry for top posting.
>
> Just wanted to say I agree with Monty (and didn't want you to have to
> scroll way down to read it). When we switched to neutron the thing people
> said was "Why do I have to do all this other stuff now?". So long as the
> tools exist for folks to do more powerful things if they want to, I'm all
> for making the simplest use case just that: simple. I think if there's any
> issue with this approach it'll be with the people who are unlearning their
> behavior.
>
> -- Kevin
>
>
>
>
> On 2/19/16, 1:21 PM, "Monty Taylor"  wrote:
>
> >On 02/19/2016 11:07 AM, Matt Riedemann wrote:
> >> There is a long contentious dev thread going on here [1] about how Nova
> >> should handle the Neutron auto-allocate-topology API (referred to as the
> >> 'get-me-a-network' effort).
> >>
> >> The point is to reduce the complexity for users to simply boot an
> >> instance and be able to ssh into it without having to first setup
> >> networks/subnets/routers in neutron and then specify a nic when booting
> >> the instance. If the planets are aligned, and no nic is provided (or
> >> available to the project), then nova would call the new neutron API to
> >> auto-allocate the network and use that to create a port to associate
> >> with the instance.
> >>
> >> There is existing behavior in Nova where you can boot an instance and
> >> get no networking with neutron as the backend. You can later add
> >> networking by attaching an interface. The nova dev team has no idea how
> >> common this use case is though.
> >
> >Fascinating. I have never wanted to do this. I cannot imagine wanting to
> >do this. I also have never heard anyone express a desire to do this.
> >
> >> There will be a microversion to the nova API with the get-me-a-network
> >> support. The debate is what the default behavior should be when using
> >> that microversion. The options are basically:
> >
> >The command line tool always uses the latest microversion, right?
> >
> >> 1. If no nic is provided at boot and none are available, don't provide a
> >> network (existing behavior). If the user wants a network auto-allocated,
> >> they specify something like: --nic=auto
> >>
> >> In this case the user has to opt into auto-allocating the network.
> >
> >This would not be horrible, but still requires a user to take an action
> >that they would not expect to need to do just to do the simple thing
> >(boot a vm) So it's my least favorite.
> >
> >> 2. If no nic is provided at boot and none are available, nova will
> >> attempt to auto-allocate the network from neutron. If the user
> >> specifically doesn't want networking on instance create (for whatever
> >> reason), they have to opt into that behavior with something like:
> >> --nic=none
> >>
> >> This is closer in behavior to how booting an instance works with
> >> nova-network, but it is a change in the default behavior for the neutron
> >> case, and that is a cause for concern for any users that have written
> >> tools to expect that default behavior.
> >
> >This is my most favorite - because it accomplishes the simplest case
> >"boot me a vm without me requesting anything out of the ordinary about
> >it" in the simplest way "nova boot"
> >
> >> 3. If no nic is provided at boot and none are available, fail the
> >> request and force the request to be explicit, i.e. provide a specific
> >> nic, or auto, or none. This is a fail-fast scenario to force users to
> >> really state what they want.
> >
> >I like this better than 1 but less than 2. The nice part is that the
> >error message can at least communicate to the user that they need to say
> >"--nic=$something" - which is at least active communication on our part.
> >But if there is no network available, then the _only_ valid choices are
> >none and auto, (specific nic wouldn't be a result here because in that
> >case the user currently gets the "I can't figure out which network to
> >use" errror - and again the "no" nic is a strange case that is the least
> >likely thing a user wants to do.
> >
> >> --
> >>
> >> As with any microversion change, we hope that users are reading the docs
> >> and aware of the changes in each microversion, but we can't guarantee
> >> that, so changing default behavior (case 2) requires discussion and
> >> input, especially from outside the dev team.
> >
> >That is totally fair and I think you're right about that. It is a change
> >- but in this particular case I think we can extrapolate pretty well
> >about what people do and how they use clouds.
> >
> >Getting an IP address in an OpenStack Cloud is hard already - AND it's
> >very common for clouds to restrict API calls for port/fixed-ip
> >manipulation, so I doubt VERY seriously that anyone is deliberately
> >going through additional 

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Kevin Bringard (kevinbri)]

Sorry for top posting. 

Just wanted to say I agree with Monty (and didn't want you to have to scroll 
way down to read it). When we switched to neutron the thing people said was 
"Why do I have to do all this other stuff now?". So long as the tools exist for 
folks to do more powerful things if they want to, I'm all for making the 
simplest use case just that: simple. I think if there's any issue with this 
approach it'll be with the people who are unlearning their behavior.

-- Kevin




On 2/19/16, 1:21 PM, "Monty Taylor"  wrote:

>On 02/19/2016 11:07 AM, Matt Riedemann wrote:
>> There is a long contentious dev thread going on here [1] about how Nova
>> should handle the Neutron auto-allocate-topology API (referred to as the
>> 'get-me-a-network' effort).
>>
>> The point is to reduce the complexity for users to simply boot an
>> instance and be able to ssh into it without having to first setup
>> networks/subnets/routers in neutron and then specify a nic when booting
>> the instance. If the planets are aligned, and no nic is provided (or
>> available to the project), then nova would call the new neutron API to
>> auto-allocate the network and use that to create a port to associate
>> with the instance.
>>
>> There is existing behavior in Nova where you can boot an instance and
>> get no networking with neutron as the backend. You can later add
>> networking by attaching an interface. The nova dev team has no idea how
>> common this use case is though.
>
>Fascinating. I have never wanted to do this. I cannot imagine wanting to 
>do this. I also have never heard anyone express a desire to do this.
>
>> There will be a microversion to the nova API with the get-me-a-network
>> support. The debate is what the default behavior should be when using
>> that microversion. The options are basically:
>
>The command line tool always uses the latest microversion, right?
>
>> 1. If no nic is provided at boot and none are available, don't provide a
>> network (existing behavior). If the user wants a network auto-allocated,
>> they specify something like: --nic=auto
>>
>> In this case the user has to opt into auto-allocating the network.
>
>This would not be horrible, but still requires a user to take an action 
>that they would not expect to need to do just to do the simple thing 
>(boot a vm) So it's my least favorite.
>
>> 2. If no nic is provided at boot and none are available, nova will
>> attempt to auto-allocate the network from neutron. If the user
>> specifically doesn't want networking on instance create (for whatever
>> reason), they have to opt into that behavior with something like:
>> --nic=none
>>
>> This is closer in behavior to how booting an instance works with
>> nova-network, but it is a change in the default behavior for the neutron
>> case, and that is a cause for concern for any users that have written
>> tools to expect that default behavior.
>
>This is my most favorite - because it accomplishes the simplest case 
>"boot me a vm without me requesting anything out of the ordinary about 
>it" in the simplest way "nova boot"
>
>> 3. If no nic is provided at boot and none are available, fail the
>> request and force the request to be explicit, i.e. provide a specific
>> nic, or auto, or none. This is a fail-fast scenario to force users to
>> really state what they want.
>
>I like this better than 1 but less than 2. The nice part is that the 
>error message can at least communicate to the user that they need to say 
>"--nic=$something" - which is at least active communication on our part. 
>But if there is no network available, then the _only_ valid choices are 
>none and auto, (specific nic wouldn't be a result here because in that 
>case the user currently gets the "I can't figure out which network to 
>use" errror - and again the "no" nic is a strange case that is the least 
>likely thing a user wants to do.
>
>> --
>>
>> As with any microversion change, we hope that users are reading the docs
>> and aware of the changes in each microversion, but we can't guarantee
>> that, so changing default behavior (case 2) requires discussion and
>> input, especially from outside the dev team.
>
>That is totally fair and I think you're right about that. It is a change 
>- but in this particular case I think we can extrapolate pretty well 
>about what people do and how they use clouds.
>
>Getting an IP address in an OpenStack Cloud is hard already - AND it's 
>very common for clouds to restrict API calls for port/fixed-ip 
>manipulation, so I doubt VERY seriously that anyone is deliberately 
>going through additional needless steps to get a working IP.
>
>> If you or your users have any input on this, please respond in this
>> thread of the one in the -dev list.
>
>I earnestly suggest #2. I believe it is the behavior users are more 
>likely to expect than anything else.
>
>
>___
>OpenStack-operators mailing list

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

[Monty Taylor]

On 02/19/2016 11:07 AM, Matt Riedemann wrote:

There is a long contentious dev thread going on here [1] about how Nova
should handle the Neutron auto-allocate-topology API (referred to as the
'get-me-a-network' effort).

The point is to reduce the complexity for users to simply boot an
instance and be able to ssh into it without having to first setup
networks/subnets/routers in neutron and then specify a nic when booting
the instance. If the planets are aligned, and no nic is provided (or
available to the project), then nova would call the new neutron API to
auto-allocate the network and use that to create a port to associate
with the instance.

There is existing behavior in Nova where you can boot an instance and
get no networking with neutron as the backend. You can later add
networking by attaching an interface. The nova dev team has no idea how
common this use case is though.


Fascinating. I have never wanted to do this. I cannot imagine wanting to 
do this. I also have never heard anyone express a desire to do this.



There will be a microversion to the nova API with the get-me-a-network
support. The debate is what the default behavior should be when using
that microversion. The options are basically:


The command line tool always uses the latest microversion, right?


1. If no nic is provided at boot and none are available, don't provide a
network (existing behavior). If the user wants a network auto-allocated,
they specify something like: --nic=auto

In this case the user has to opt into auto-allocating the network.


This would not be horrible, but still requires a user to take an action 
that they would not expect to need to do just to do the simple thing 
(boot a vm) So it's my least favorite.



2. If no nic is provided at boot and none are available, nova will
attempt to auto-allocate the network from neutron. If the user
specifically doesn't want networking on instance create (for whatever
reason), they have to opt into that behavior with something like:
--nic=none

This is closer in behavior to how booting an instance works with
nova-network, but it is a change in the default behavior for the neutron
case, and that is a cause for concern for any users that have written
tools to expect that default behavior.


This is my most favorite - because it accomplishes the simplest case 
"boot me a vm without me requesting anything out of the ordinary about 
it" in the simplest way "nova boot"



3. If no nic is provided at boot and none are available, fail the
request and force the request to be explicit, i.e. provide a specific
nic, or auto, or none. This is a fail-fast scenario to force users to
really state what they want.


I like this better than 1 but less than 2. The nice part is that the 
error message can at least communicate to the user that they need to say 
"--nic=$something" - which is at least active communication on our part. 
But if there is no network available, then the _only_ valid choices are 
none and auto, (specific nic wouldn't be a result here because in that 
case the user currently gets the "I can't figure out which network to 
use" errror - and again the "no" nic is a strange case that is the least 
likely thing a user wants to do.



--

As with any microversion change, we hope that users are reading the docs
and aware of the changes in each microversion, but we can't guarantee
that, so changing default behavior (case 2) requires discussion and
input, especially from outside the dev team.


That is totally fair and I think you're right about that. It is a change 
- but in this particular case I think we can extrapolate pretty well 
about what people do and how they use clouds.


Getting an IP address in an OpenStack Cloud is hard already - AND it's 
very common for clouds to restrict API calls for port/fixed-ip 
manipulation, so I doubt VERY seriously that anyone is deliberately 
going through additional needless steps to get a working IP.



If you or your users have any input on this, please respond in this
thread of the one in the -dev list.


I earnestly suggest #2. I believe it is the behavior users are more 
likely to expect than anything else.



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators