Open Stack

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
>