Monty
The one missing aspect in this network model, is the ability to identify
/categorize a VNF VM, that i.e. Is using SRIOV and only cares about VLAN’s
Such VM’s would not have IP Addresses in some cases, and wouldn’t be
describable with the external/internal address labels.
I feel you need some other mechanism or tag to capture that type of server. Or
at least be able to account for them. (no-external-ip / or external-vlan , or
something)
It’s possible that the case I mention is what you refer to here “ Again, there
are more complex combinations possible. For now this is
focused on the 80% case. I'm deliberately ignoring questions like vpn or
tricircle-style intra-cloud networks for now. “
Regards
Rodolfo
Home/Office 732 5337671
On 5/14/17, 1:02 PM, "Monty Taylor" <mord...@inaugust.com> wrote:
Hey all!
LONG EMAIL WARNING
I'm working on a proposal to formalize a cloud profile document. (we
keep and support these in os-client-config, but it's grown up ad-hoc and
is hard for other languages to consume -so we're going to rev it and try
to encode information in it more sanely) I need help in coming up with
names for some things that we can, if not all agree on, at least not
have pockets of violent dissent against.
tl;dr: What do we name some enum values?
First, some long-winded background
== Background ==
The profile document is where we keep information about a cloud that an
API consumer needs to know to effectively use the cloud - and is stored
in a machine readable manner so that libraries and tools (including but
hopefully not limited to shade) can make appropriate choices.
Information in profiles is the information that's generally true for all
normal users. OpenStack is flexible, and some API consumers have
different access. That's fine - the cloud profiles are not for them.
Cloud profiles define the qualities about a cloud that end users can
safely expect to be true. Advanced use is never restricted by annotating
the general case.
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
Again, there are more complex combinations possible. For now this is
focused on the 80% case. I'm deliberately ignoring questions like vpn or
tricircle-style intra-cloud networks for now. If we can agree on an
outcome here - we can always come back and add words to describe more
things.
** Bikeshed #1 **
Are "internal" and "external" ok with folks as terms for those two ideas?
We need a term for each - if we prefer different terms, replacing their
use in the following is simple.
== Booting Servers ==
When booting a server, a typical user wants one of the following:
- Give me a server with an external address
- Give me a server with an internal address
- Give me a server with both
- Give me a server with very specific networking connections
The fourth doesn't need any help - it's the current state of the world
today and is well served. It's the "I have a network I am aware of
and/or a pre-existing floating ip, etc and I want to use them". This is
not about those people - they're fine.
Related to the first three cases, depending on how the cloud is
deployed, any of the following can be non-exclusively true:
- External addresses are provided via Fixed IPs
- External addresses are provided via Floating IPs
- Internal addresses are provided via Fixed IPs
- Internal addresses can be provided via Floating IPs
- Users can create and define their own internal networks
Additionally, External addresses can be IPv4 or IPv6
== Proposal - complete with Unpainted Sheds ==
I want to add information to the existing cloud profile telling the API
user which of the models above are available.
The cloud profile will gain a field called "network-models" which will
contain one or more names from an enum of pre-defined models. Multiple
values can be listed, because some clouds provide more than one option.
** Bikeshed #2 **
Anybody have a problem with the key name "network-models"?
(Incidentally, the idea from this is borrowed from GCE's
"compute#accessConfig" [0] - although they only have one model in their
enum: "ONE_TO_ONE_NAT")
In a perfect future world where we have per-service capabilities
discovery I'd love for such information to be exposed directly by
neutron. Therefore, I'd LOVE if we can at agree that the concepts are
concepts and on what to name them so that users who get the info from a
cloud profile today can get it from a discovery call in the future and
have some expectation that the terms carry the same meaning.
Reminder - this is about the 80% case. Complex cases are already handled.
** Bikeshed #3 **
What do we call the general concepts represented by fixed and floating
ips? Do we use the words "fixed" and "floating"? Do we instead try
something else, such as "direct" and "nat"?
I have two proposals for the values in our enum:
#1 - using fixed / floating
ipv4-external-fixed
ipv4-external-floating
ipv4-internal-fixed
ipv4-internal-floating
ipv6-fixed
#2 - using direct / nat
ipv4-external-direct
ipv4-external-nat
ipv4-internal-direct
ipv4-internal-nat
ipv6-direct
Does anyone have strong feelings one way or the other?
My personal preference is direct/nat. "floating" has a tendency to imply
different things to different people (just watch, we're going to have at
least one rabbit hole that will be an argument about the meaning of
floating ips) ... while anyone with a background in IT knows what "nat"
is. It's also a characteristic from a server/workload perspective that
is related to a choice the user might want to make:
Does the workload need the server to know its own IP?
Does the workload prefer to be behind NAT?
Does the workload not care and just wants connectivity?
On the other hand, "direct" isn't exactly a commonly used word in this
context. I asked a ton of people at the Summit last week and nobody
could come up with a better term for "IP that is configured inside of
the server's network stack". "non-natted", "attached", "routed" and
"normal" were all suggested. I'm not sure any of those are super-great -
so I'm proposing "direct" - but please if you have a better suggestion
please make it.
== Maybe Examples will make it Clearer ==
Some examples of how these would be applied in cloud profiles, based on
some public and private clouds. Using the direct/nat terms for the
examples- could just as easily get search/replaced:
vexxhost:
network-models:
- ipv4-external-direct
- ipv4-external-nat
- ipv4-internal-direct
- ipv6-direct
citycloud:
network-models:
- ipv4-external-nat
- ipv4-internal-direct
rackspace:
network-models:
- ipv4-external-direct
- ipv4-internal-direct
- ipv6-direct
infra-cloud:
network-models:
- ipv4-external-direct
- ipv6-direct
internap:
network-models:
- ipv4-external-direct
- ipv4-internal-direct
Having those available should allow for a user to express to a library
or framework such as shade or terraform:
"get me a server with an external ipv4 using direct if it's available
and nat if not"
create_server('my-server', external_network=True)
or
"get me a server with an external ipv4 using nat if it's available but
direct is ok"
create_server(
'my-server', external_network=True,
external_models=['ipv4-external-nat', 'ipv4-external-direct'])
or
"get me a server with an external ipv4 using direct and fail if it's not
available"
create_server(
'my-server', external_network=True,
external_models=['ipv4-external-direct'])
or
"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)
== Follow up future - Capabilities Discovery ==
This is WAY out of scope for right now, but here are some initial
thoughts about how the same values could be exposed from the API. It's
not necessary that we like this part - or that if we do that this API is
what we'd like. The important point would be that IF we decided to
expose this information via the API in the future that the same terms be
used.
Here's a straw man of how the info _could_ be exposed in the future:
1) In /capabilities (or whatever we call it)
Whenever we add capabilities discovery, the models in the cloud-profile
could be one of the fields exposed:
GET /capabilities.json
{
"capabilities": {
"network-models": {
"ipv4-external-nat",
"ipv4-internal-direct",
"ipv6-direct"
}
}
}
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"
]
},
{
"status": "ACTIVE",
"name": "GATEWAY_NET",
"id": "7004a83a-13d3-4dcd-8cf5-52af1ace4cae",
"network-models": [
"ipv4-external-nat",
]
},
{
"status": "ACTIVE",
"name": "my-awesome-network",
"id": "0be66687-9358-46cd-9093-9ce62cb4ece7",
"network-models": [
"ipv4-internal-direct"
]
}
]
}
OR
GET /networks
{
"networks": [
{
"status": "ACTIVE",
"name": "public",
"id": "6d6357ac-0f70-4afa-8bd7-c274cc4ea235",
"network-models": [
"ipv4-external-direct",
"ipv4-external-nat",
"ipv6-direct"
]
}
]
}
I'm not suggesting putting info on subnets, since one requests
connectivity from a network, not a subnet.
networks with more than one "direct" model ("ipv4-external-direct",
"ipv4-internal-direct", "ipv6-direct") would communicate "you get all
the listed models". A network with a direct model AND a nat model
communicate that the network can be used as a target for direct booting
_and_ can be used as a source of NAT.
It's worth noting that operators _could_ annotate their networks with
this information today using tags ... but since this is in service of
interoperability, just falling back on expecting operators to add some
specific strings to an otherwise free-form tags field seems like a thing
that would be messier to add to the Interop Guidelines in the future
compared to a strict set of pre-defined enum values with their own
non-overloaded field.
== Conclusion ==
Ok. I know that's yet-another billion-line pile of text from me. Sorry
about that. In case you've forgotten the bikeshed topics at this point:
* Internal and External OK?
* network-models OK?
* fixed/floating vs. direct/nat vs. something else?
Comments, feedback, concerns, raves and rants are all welcome.
[0]
https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.google.com_compute_docs_reference_latest_instances_addAccessConfig&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=6eHo-w50YOmlIIy6AzczUmVlsmgMmH34Va342s07hH0&s=rfHeN9Pae4c3GDUj3100WbxTURihVDVWe9BL61v1DOA&e=
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=6eHo-w50YOmlIIy6AzczUmVlsmgMmH34Va342s07hH0&s=27DdACmzldX39G68xu-VRASm5zcKs6YNCx23-Yz72GM&e=
__________________________________________________________________________
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
