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. 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. 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? Carl [1] https://review.openstack.org/#/c/300207/3/specs/newton/subnet-service-types.rst __________________________________________________________________________ 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