Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hostGroup parameter doesn't work if VirtualServerName is specified #2867

Closed
mikeoleary opened this issue May 1, 2023 · 2 comments · Fixed by #2903
Closed

hostGroup parameter doesn't work if VirtualServerName is specified #2867

mikeoleary opened this issue May 1, 2023 · 2 comments · Fixed by #2903

Comments

@mikeoleary
Copy link

Setup Details

CIS Version : 2.12.1
BIGIP Version: Big IP 17.1.0.1
AS3 Version: 3.25
Agent Mode: AS3
Orchestration: K8S
Pool Mode: Cluster

Description

hostGroup and VirtualServerName attributes cannot be used at the same time.

Some ideas:

  • Could we fix this so that the VirtualServerName field is ignored if hostGroup is used, or throw an error if both exist?
  • or could you add this note to the documentation to say that hostGroup and VirtualServerName should not be used at the same time?
  • Or log entries in CIS to make it more obvious if this is quiety ignored?

Steps To Reproduce

  1. Create 2x VirtualServers as below. Define BOTH hostGroup and VirtualServerName.
  2. Apply and observe logs on CIS do not give you much info (even with DEBUG level) but /var/log/restnoded/restnoded.log will tell you:
severe: [appsvcs] {"message":"Declaration failed: 01070333:3: Virtual Server /kubernetes/Shared/hello_world_vs2_443 illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /kubernetes/Shared/hello_world_vs_443.","level":"error"}
apiVersion: "cis.f5.com/v1"
kind: VirtualServer
metadata:
  name: hello-world-virtual-server
  namespace: nginx-ingress
  labels:
    f5cr: "true"
spec:
  host: demo.my-f5.com
  hostGroup: mike
  tlsProfileName: hello-world-tls
  virtualServerAddress: "20.96.103.238"
  virtualServerName: demo               ### <--- this line should not be used if hostGroup is being used for multiple VS resources.
  httpTraffic: allow
  pools:
  - path: /
    service: nginx-ingress
    servicePort: 80
    monitor:
      type: http
      interval: 10
      timeout: 31
      send: "/"
      recv: ""


apiVersion: "cis.f5.com/v1"
kind: VirtualServer
metadata:
  name: hello-world-virtual-server2
  namespace: nginx-ingress
  labels:
    f5cr: "true"
spec:
  host: demo2.my-f5.com
  hostGroup: mike
  tlsProfileName: hello-world-tls2
  virtualServerAddress: "20.96.103.238"
  virtualServerName: demo2               ### <--- this line should not be used if hostGroup is being used for multiple VS resources.
  httpTraffic: allow
  pools:
  - path: /
    service: nginx-ingress2
    servicePort: 80
    monitor:
      type: http
      interval: 10
      timeout: 31
      send: "/"
      recv: ""

Expected Result

I expected I could use the above VS definitions to create 2x VS that share the same IP address, even if I left the VirtualServerName attribute in them.

Actual Result

I need to remove the VirtualServerName attribute from both before this will work.

Diagnostic Information

<Configuration files, error messages, logs>
Note: Sanitize the data. For example, be mindful of IPs, ports, application names and URLs
Note: The following F5 article outlines the information required when opening an issue.
https://support.f5.com/csp/article/K60974137

Observations (if any)

@mikeoleary mikeoleary added bug untriaged no JIRA created labels May 1, 2023
@trinaths
Copy link
Contributor

trinaths commented May 4, 2023

Created [CONTCNTR-3950] for internal tracking.

@thomas-cripps-fg
Copy link

Also experiencing this, can anything be included to edit the description of sorts? Easiest way for me to understand what the virtual server is processing is the policy it creates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants