<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I'm coming to this cold, so apologies when I put my foot in my mouth.  But I'm trying to understand what you're actually getting at, here - other than helpful simplicity - and I'm not following the detail of you're thinking, so take this as a form of enquiry.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 14 May 2017 at 10:02, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First off, we need to define two terms:<br>
"external" - an address that can be used for north-south communication off the cloud<br>
"internal" - an address that can be used for east-west communication with and only with other things on the same cloud<br></blockquote><div><br></div><div>I'm going through the network detail of this and picking out shortcomings, so please understand that before you read on.</div><div><br></div><div>I think I see what you're trying to accomplish, but the details don't add up for me.  The right answer might be 'you don't use this if you want fine detailed network APIs' - and that's fine - but I think the issue is not coming up with a model that contradicts the fine detail of what you can do with a network today and how you can put it to use.</div><div><br></div><div>1. What if there are more domains of connectivity, since a cloud can be connected to multiple domains?  I see this in its current form as intended for public cloud providers as much as anything, in which case there is probably only one definition of 'external', for instance, but if you want to make it more widely useful you could define off-cloud routing domain names, of which 'external' (or, in that context, 'internet') is one with a very specific meaning.</div><div><br></div><div>2. What is 'internal', precisely?  It seems to be in-cloud, though I don't entirely understand how NAT comes into that.  What of a route to the provider's internal network?  How does it apply when I have multiple tenant networks that can't talk to each other, when they're provisioned for me and I can't create them, and so on?  Why doesn't it apply to IPv6?</div><div><br></div><div>3. Why doesn't your format tell me how to get a port/address of the type in question?  Do you feel that everything will be consistent in that regard?  To my mind it's more useful - at the least - to tell me the *identity* of the network I should be using rather than saying 'such a thing is possible in the abstract'.</div><div><br></div><div>[...]<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"get me a server with only an internal ipv4 and please fail if that isn't possible"<br>
<br>
  create_server(<br>
      'my-server', external_network=False, internal_network=True)<br></blockquote><div><br></div><div>A comment on all of these: are you considering this to be an argument that is acted upon in the library, or available on the server?</div><div><br></div><div>Doing this in the library makes more sense to me.  I prefer the idea of documenting in machine-readable form how to use the APIs, because it means I can use a cloud without the cloud supporting the API.  For many clouds, the description could be a static file, but for more complex situations it would be possible to generate it programmatically per tenant.</div><div><br></div><div>Doing it the other way could also lead to cloud-specific code, and without some clearer specification it might also lead to cloud-specific behaviour.</div><div><br></div><div>It's also complexity that simply doesn't need to be in the cloud; putting it in the application gives an application with a newer library the opportunity to use an older cloud.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2) As information on networks themselves:<br>
<br>
GET /networks.json<br>
{<br>
  "networks": [<br>
    {<br>
      "status": "ACTIVE",<br>
      "name": "GATEWAY_NET_V6",<br>
      "id": "54753d2c-0a58-4928-9b32-084c5<wbr>9dd20a6",<br>
      "network-models": [<br>
        "ipv4-internal-direct",<br>
        "ipv6-direct"<br>
      ]<br>
    },<br></blockquote><div><br></div><div>[...]</div><div><br></div><div>I think the problem with this as a concept, if this is what you're eventually driving towards, is how you would enumerate this for a network.</div><div><br></div><div>IPv6 may be routed to the internet (or other domains) or it may not, but if it is it's not currently optional to be locally routed and not internet routed on a given network as it is for a v4 address to be fixed without a floating component.  (You've skipped this by listing only ipv6-direct, I think, as an option, where you have ipv4-fixed).</div><div><br></div><div>ipv4 may be routed to the internet if a router is connected, but I can connect a router after the fact and I can add a floating IP to a port after the fact too.  If you're just thinking in terms of 'when starting a VM, at this instant in time' then that might not be quite so much of an issue.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not suggesting putting info on subnets, since one requests connectivity from a network, not a subnet.<br></blockquote><div><br></div><div>Not accurate - I can select a subnet on a network, and it can change who I can talk to based on routes.  Neutron routers are attached to subnets, not networks.</div><div><br></div><div>On a final note, this is really more about 'how do I make a port with this sort of connectivity' with the next logical step being that many VMs only need one port.</div><div>-- </div><div>Ian.</div></div></div></div>