ESD support for TCP listeners

[abattye]

Hi,

This is conceptually related to #660 I think, but when we apply a ESD to a TCP listener the http and oneconnect profiles are added by default, changing the VS behaviour, transparent to the end user. e.g. our use case is to apply an iRule to a TCP listener to support use of the proxy protocol to make the original source IP available for nodes on TCP listeners, we think a common scenario. When we do this its breaking end user LB scenarios.

We've worked around it with this https://github.com/sapcc/f5-openstack-agent/commit/363c9d8e60ceab8065c2c1d623cd97b62aa2b660, using essentially the same logic used for session persistence. Is this something you could add to a future release or accept a pull request for? We'd also be interested in your feedback on the use of ESDs in TCP/L4 scenarios and if you have any ideas on how to address the semantic incongruity of using L7 policies to affect L4 behaviour?

Thanks

Andrew

[dflanigan]

@jlongstaf could you review this and see if this issue is related to our work on #660 ?

[jlongstaf]

Our implementation of ESD assumed L7 listeners, but this is an incorrect assumption. We should not be adding HTTP and OneConnect profiles for TCP listeners. We are happy to accept pull requests, but if not, we will fix this as in the commit referenced above.

[jgruber]

Remember that the tenant has no idea what a L7 or L4 listener is. They picked a TCP listener. If the reason it needs to be migrated to a standard virtual server is because the ESD (which the provider defines, not the tenant) has profiles in it other then lbaas_ctcp or lbaas_stcp, then the agent is responsible for migrating this to a standard virtual server, then applying the ESD.

We can't break the API contract because an ESD is applied.

[richbrowne]

I am a little confused and would appreciate some guidance. Is the expected behavior for this to switch to a standard virtual whenever an ESD is applied to a TCP listener? It is possible to maintain the BIG-IP virtual as a fastL4 and use some iRules or policies. We could add an http profile to this virtual by default without changing the type of the virtual. So the listener profile would include /Common/fastl4 and /Common/http.

The patch does not seem to change the virtual type from fastl4 to standard when the ESD is applied --unless that is happening somewhere else. It does explicitly set the state back to fastL4 when the ESD is removed.

Here are a couple of proposals:

1. Switch to standard virtual whenever an ESD is applied to a TCP listener. Switch back when the ESD is removed.
2. Keep the fastl4 profile on the virtual and add the http profile (not the oneconnect). Apply persistence profiles, policies, and rules as specified in the ESD definition. Other ESD keys, for TCP and SSL profiles would be ignored.
3. This is an enhancement to option 2. We extend the ESD template to allow a user to specify whether or not to add a http or oneconnect profile. This allow a user finer grained control over how to configure the virtual.

I believe 3 is the best option, but can only implement 1 or 2 for now. What would you like to see?

Thanks.

[jgruber]

As we talked about... I would stay even simpler for now. If a L7 policy applies an ESD, the virtual server should automatically become a 'standard' virtual service.

We can file an enhancement to allow for a virtual_server_type tag in the ESD which will make this explicit. The default will match a standard virtual server. We'll write up the enhancement to be clear that the ESD named by the L7 policy with the lowest position number will be the one used to dictate the virtual_server_type. We'll write up the logic for conflicts in the enhancement request.

[abattye]

In case you're interested this is how we solved the problem and its covering nearly all our current use cases. Our approach is that the end user has to explicity select ESDs which compose the advanced service they need. So if they need something not supported by fastL4 they need to include a service that converts it to a standard listener. These choices and implications are documented and the end user is then fully aware of what they can expect from their listeners. https://github.com/sapcc/f5-openstack-agent/blob/mitaka-m3/f5_openstack_agent/lbaasv2/drivers/bigip/listener_service.py#L795