Open Stack

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.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
>> 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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160226/9a203cee/attachment.html>