[Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?
matt.jarvis at datacentred.co.uk
Fri Feb 26 14:34:35 UTC 2016
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 <robert at kumul.us> 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
> 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.jarvis at 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 <fungi at yuggoth.org> wrote:
>>> On 2016-02-26 11:21:47 +0000 (+0000), Matt Jarvis wrote:
>>> > From a public cloud perspective I'm not convinced that an opt-out
>>> > 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 at lists.openstack.org
>> DataCentred Limited registered in England and Wales no. 05611763
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators