On 05/15/2017 11:44 AM, Ian Wells wrote:
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.
Thanks for diving in - no foot-mouth worries here. It's a hard topic.
On 14 May 2017 at 10:02, Monty Taylor <mord...@inaugust.com <mailto:mord...@inaugust.com>> wrote: First off, we need to define two terms: "external" - an address that can be used for north-south communication off the cloud "internal" - an address that can be used for east-west communication with and only with other things on the same cloud I'm going through the network detail of this and picking out shortcomings, so please understand that before you read on. 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.
Yes. The _general_ answer is that this is not supposed to attempt to describe all of the networking possibilities - but also exactly what you sayd, we don't want to _contradict_ those things.
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.
Right. So 'external' isn't intended to describe destination, as much as 'does this go to other things' and 'if so how'.
You're totally right - if there are more than one "external" domain, this information will be insufficient. I'd expect each of the networks in question to be tagged as "external" - but the choice of where they go is a time when a user is going to need more information.
Related to an above reponse though - let's say a user has a cloud that connects to three network domains that are not in the cloud in question. A, B and C. At no point in that user's life is "I want a VM that has external connectivity" going to be a sensible request. They will, out of necessity, always need to say "I want a VM that can connect to domain A" - which is already very nicely handled.
This is definitely inspired by the Public Clouds, since this is one of the top 2 things it's super hard for users to figure out and that we currently have to paper over for them in client libraries. (image upload, fwiw, is the other) But I hope it degrades well for more complex private clouds. That is - the existence of (or lack of) such tags on a private cloud should not impact the existing experience for those users at all.
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?
Yes, internal is intended to be in cloud. It's intended to handle the "please give me a server that can't talk to things that aren't in my personal private network" case. Similar to the external case, if a user has more than one project networks, there is no way "I want a VM that does not have external connectivity" will be a useful thing to say. They'll have to say "I want a VM that is attached to the network I created for my database tier" - and again that's currently handled nicely.
In the current proposal IPv6 isn't covered in more depth because the question with IPv6 is (in my experience - obviously could be wrong) - "can I get me some IPv6".
As for NAT - I included internal NAT for completeness because I heard that someone added the ability to neutron to be able to get floating ips from one neutron private network and use them to connect to a different neutron private network. I have not seen this in action myself, nor do I want it - but it seemed having an enum value to cover it wasn't expensive.
As to why we cover NAT at all - that's more to do with workloads running on the server. Some workloads like to be able to look at the IP stack on the server and see their own network information (kerberos comes to mind) while others don't care. And some folks may be designing apps that assume they're behind NAT of some sort. On some clouds both are available, so a user with a preference to form needs to be able to express that.
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'.
That's in the follow up suggestion for how the tags could get applied to neutron networks - but even without it the metadata is useful.
If your request is "I want a server with external connectivity" and the info you have about the cloud says "this cloud has direct external and does not have nat" - then you can know that your next step is not "create a network, a subnet and a router and connect them". If you don't, you have to resort to things like "look for a network that has either router:external or one of the provider network flags since those are typically external routing networks. try to boot a vm on it. If that works, awesome. If it doesn't, try to create a network, subnet and router"
So these are a step, but they're not the whole journey for sure. (also, more coming soon about those questions)
[...] "get me a server with only an internal ipv4 and please fail if that isn't possible" create_server( 'my-server', external_network=False, internal_network=True) 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?
This is example/straw-man library code showing how a library could expose an interface that makes use of these things.
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.
YES! Exactly. In fact, the cloud profile is currently a static file that we just keep in a python library. There is another proposal to suggest a way that vendors can provide a file directly themselves.
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.
Yup. 1000% agree (it's like you're reading my mind)
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. 2) As information on networks themselves: GET /networks.json { "networks": [ { "status": "ACTIVE", "name": "GATEWAY_NET_V6", "id": "54753d2c-0a58-4928-9b32-084c59dd20a6", "network-models": [ "ipv4-internal-direct", "ipv6-direct" ] }, [...] 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. 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). 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.
Yah. This part is MUCH less well sketched out - for the reasons you're pointing at. It actually does start to hit on to more difficult semantic questions.
However, the intent here is to answer what sort of things you get from a network. So, while you can get a non-routed IPv4 on boot and then later connect a router and make a floating ip and attach it - that doesn't change the fact that the IPv4 you get from _that_ network is an internal IPv4. The network that you'd get the floating IP from to attach to the IPv4 you got from this network would have ipv4-external-nat associated with it.
(It's sort of an attempt to answer the question you asked earlier- if a user now knows that they can get internal IPv4, and external IPv4 via NAT, which network should they request those services from.)
I'm not suggesting putting info on subnets, since one requests connectivity from a network, not a subnet. 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.
Right. But servers are booted on networks.
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.
Yes - I agree. I'm phrasing it in terms of servers because that's the driving use case (and also for the 80% case ports are completely a hidden implementation detail) - but you are absolutely correct - we're actually discussing how to get a port that can be connected _to_ via what type of access.
It's also important to note that this is very much centered around in-bound connectivity "How do things connect to the port in question?" Rather than "how is traffic routed from the port in question?" That's largely driven by coming from a direction of "I want to run workload X that has the need that other types of things with qualities of Y be able to connect to it- how do I do that?"
Thanks for engaging! Excellent questions ... I hope my babbling makes the intent more rather than less clear. :)
Monty __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev