<div dir="ltr">Agreed, although I've learned over the years that second guessing what actions customers may or may not take is usually a losing battle ;) </div><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2016 at 13:55, Robert Starmer <span dir="ltr"><<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>And I personally am unaware of any service provider that doesn't give you network access by default when you stand up a project.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Feb 26, 2016 at 5:06 AM, Matt Jarvis <span dir="ltr"><<a href="mailto:matt.jarvis@datacentred.co.uk" target="_blank">matt.jarvis@datacentred.co.uk</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">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. <div><br></div><div>Out of interest, are there really OpenStack public clouds where the cloud provider doesn't automatically provision an initial network and router ? </div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2016 at 11:36, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2016-02-26 11:21:47 +0000 (+0000), Matt Jarvis wrote:<br>
> From a public cloud perspective I'm not convinced that an opt-out argument<br>
> is the right way to go. A router in our context is a chargeable item,<br>
> because it has an external IP address, so automatically creating stuff<br>
> without the user specifying it is not an ideal outcome. Personally I'd<br>
> rather see an opt-in argument ie. option 1<br>
<br>
</span>As a user of many public clouds, some of which use Nova network,<br>
some of which use Neutron with a common flat provider network, et<br>
cetera, _I_ want them to behave consistently when I ask them to boot<br>
a node rather than needing to remember that on some subset of them I<br>
also need to perform an unholy dance to convince them I really want<br>
to have access to the servers I've created.<br>
<br>
Making it so that some public cloud providers can continue to<br>
require completely different business logic than others just to have<br>
a reachable server basically shoots any hope we have as a community<br>
for consistency and "interoperability" in the head. Cloud providers<br>
seem to think that they'll attract me with their unique market<br>
differentiating features, but I could really care less. What I want<br>
is for OpenStack to succeed by providing a seamless experience where<br>
things look as identical as possible no matter what provider or<br>
environment I use. OpenStack doesn't need to compete against itself,<br>
there is plenty enough competition out there for us already even if<br>
we band together in a unity of design and function.<br>
<span><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>
<br>
</div></div></div></div><div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span></div></div><span class=""><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span>