Thanks Carl for bringing this up, comments below.
On 05/26/2016 02:04 PM, Carl Baldwin wrote:
Hi folks,
Some (but not all) of you will remember a discussion we had about
service subnets at the last mid-cycle. We've been iterating a little
bit on a spec [1] and we have just one issue that we'd like to get a
little bit more feedback on.
As a summary: To me, the idea of this spec is to reserve certain
subnets for certain kinds of ports. For example, DVR FIP gateway
ports, and router ports. The goal of this is to be able to use
subnets with private addresses for these kinds of ports instead of
wasting public IP addresses.
The remaining question is how to expose this through the API. I had
thought about just attaching a list of device_owners to the subnet
resource. If a list is attached, then only ports with the right
device_owner will be allocated IP addresses from that subnet. I
thought this would be an easy way to implement it and I thought since
device owner is already exposed through the API, maybe it would be
acceptable. However, there is some concern that this exposes too much
of the internal implementation. I understand this concern.
At the mid-cycle we had discussed some enumeration values that
combined several types to avoid having to allow a list of types on a
subnet. They were going to look like this:
dvr_gateway -> ["network:floatingip_agent_gateway"]
router_gateway -> ["network:floatingip_agent_gateway",
"network:router_gateway"]
The idea was that we'd only allow one value for a subnet and the
difference between the two would be whether you wanted router ports to
use private IPs. I think it would be clearer if we just have simpler
definitions of types and allow a list of them.
Yes, this was the original plan - two values (well, three since None was
default), each mapping to a set of owners.
At this point the enumeration values map simply to device owners. For example:
router_ports -> "network:router_gateway"
dvr_fip_ports -> "network:floatingip_agent_gateway"
It was at this point that I questioned the need for the abstraction at
all. Hence the proposal to use the device owners directly.
I would agree, think having another name to refer to a device_owner makes it
more confusing. Using it directly let's us be flexible for deployers, and
allows for using additional owners values if/when they are added.
Armando expressed some concern about using the device owner as a
security issue. We have the following policy on device_owner:
"not rule:network_device or rule:context_is_advsvc or
rule:admin_or_network_owner"
At the moment, I don't see this as much of an issue. Do you?
I don't, since only admins should be able to set device_owner to these values
(that's the policy we're talking about here, right?).
To be honest, I think Armando's other comment - "Do we want to expose
device_owner via tha API or leave it an implementation detail?" is important as
well. Even though I think an admin should know this level of neutron detail,
will they really? It's hard to answer that question being so close to the code.
-Brian
[1]
https://review.openstack.org/#/c/300207/3/specs/newton/subnet-service-types.rst
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
