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

bigip_virtual_server doesn't care irules' sequence #1430

Closed
shinobe179 opened this issue Jul 25, 2019 · 7 comments · Fixed by #1523
Assignees
Labels

Comments

@shinobe179
Copy link

@shinobe179 shinobe179 commented Jul 25, 2019

ISSUE TYPE
  • Bug Report
COMPONENT NAME
  • bigip_virtual_server
ANSIBLE VERSION
$ ansible --version
ansible 2.8.1
PYTHON VERSION
$ python --version
Python 2.7.5
BIGIP VERSION
Sys::Version
Main Package
  Product     BIG-IP
  Version     12.1.2
CONFIGURATION
$ ansible --version
ansible 2.8.1
  config file = None
OS / ENVIRONMENT
$ cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
SUMMARY
STEPS TO REPRODUCE

I prepared 2 yml files.
"main.yaml" is an input of ansible-playbook command.
When ansible processes main.yml, it reads objects.yml by vars_files and update some BIG-IP objects according to objects.yml.

$ cat main.yml
---
- name: SETUP FOR SERVICE A
  hosts: testlb
  vars_files:
    - ./objects.yml

  tasks:
    - name: SETUP PROVIDER
      set_fact:
        provider:
          server: "{{ansible_host}}"
          user: "{{ansible_user}}"
          password: "{{ansible_ssh_pass}}"
          server_port: "{{bigip_server_port}}"
          validate_certs: "no"

    - name: UPDATE NODES
    # using bigip_node, ommited

    - name: UPDATE POOLS
    # using bigip_pool, ommited

    - name: UPDATE POOL MEMBERS
    # using bigip_pool_member, ommited

    - name: UPDATE IRULES
      loop: "{{irules}}"
      bigip_irule:
        provider: "{{provider}}"
        module: ltm
        name: "{{item.name}}"
        content: "{{lookup('file', '{{item.content}}')}}"
        state: "{{item.state}}"
        validate_certs: "no"

    - name: UPDATE VERTUAL SERVERS
      loop: "{{virtual_servers}}"
      bigip_virtual_server:
        provider: "{{provider}}"
        name: "{{item.name}}"
        state: "{{item.state}}"
        type: "{{item.type}}"
        source: "{{item.source}}"
        destination: "{{item.destination}}"
        port: "{{item.port}}"
        pool: "{{item.pool}}"
        enabled_vlans: "{{item.enabled_vlans}}"
        source_port: "{{item.source_port}}"
        ip_protocol: "{{item.ip_protocol}}"
        irules: "{{item.irules}}"
        profiles: "{{item.profiles}}"
        validate_certs: "no"

...

$ cat objects.yml
---
nodes:
  - address: 192.0.2.1
    name: service-a_web_1
    state: present
    monitors:
      - icmp
  - address: 192.0.2.2
    name: service-a_web_2
    state: present
    monitors:
      - icmp
  - address: 192.0.2.3
    name: service-a_cms_1
    state: present
    monitors:
      - icmp
  - address: 192.0.2.4
    name: service-a_cms_2
    state: present
    monitors:
      - icmp
  - address: 192.0.2.101
    name: service-a_sorry_1
    state: present
    monitors:
      - icmp

pools:
  - name: service-a_web_pool
    state: present
    monitors:
      - http
    lb_method: round-robin
  - name: service-a_cms_pool
    state: present
    monitors:
      - http
    lb_method: round-robin
  - name: service-a_sorry_pool
    state: present
    monitors:
      - http
    lb_method: round-robin

pool_members:
  - pool: service-a_web_pool
    port: 80
    aggregate:
      - name: service-a_web_1
        address: 192.0.2.1
      - name: service-a_web_2
        address: 192.0.2.2
  - pool: service-a_cms_pool
    port: 80
    aggregate:
      - name: service-a_cms_1
        address: 192.0.2.3
      - name: service-a_cms_2
        address: 192.0.2.4
  - pool: service-a_sorry_pool
    port: 80
    aggregate:
      - name: service-a_sorry_1
        address: 192.0.2.101

irules:
  - name: service-a_irule
    content: ./irule/service-a_cms_irule
    state: absent
  - name: service-a_cms_irule
    content: ./irule/service-a_cms_irule
    state: present
  - name: service-a_sorry_irule
    content: ./irule/service-a_sorry_irule
    state: present

virtual_servers:
  - name: service-a_80_vs
    state: present
    type: standard
    source: 0.0.0.0/0
    destination: 198.51.100.1/32
    port: 80
    pool: service-a_web_pool
    enabled_vlans:
      - test_vlan
    source_port: preserve
    ip_protocol: tcp
    irules:
      - service-a_cms_irule
      - service-a_sorry_irule
    profiles:
      - tcp
      - http
...

At first, I executed main.yml with objects.yml, It worked.
There are 2 service-a_80_vs's irules like below:

  • service-a_cms_irule
  • service-a_sorry_irule

Next, I rewrited objects.yml to reorder iRules assigned service-a_80_vs, like below:

virtual_servers:
  - name: service-a_80_vs
    state: present
    type: standard
    source: 0.0.0.0/0
    destination: 198.51.100.1/32
    port: 80
    pool: service-a_web_pool
    enabled_vlans:
      - test_vlan
    source_port: preserve
    ip_protocol: tcp
    irules:
-     - service-a_cms_irule
-     - service-a_sorry_irule
+     - service-a_sorry_irule
+     - service-a_cms_irule
    profiles:
      - tcp
      - http

I executed ansible again, but iRules assigned the VS were not reorderd.

EXPECTED RESULTS

I expected iRules are reorderd, like below:

  • service-a_sorry_irule
  • service-a_cms_irule
ACTUAL RESULTS

iRules were not reorderd. I checked GUI too.
In my understanding, Assigning iRules to VS is order-sensitive.

TASK [UPDATE VERTUAL SERVERS] ***************************************************************************************************************************************************************************
ok: [testlb] => (item={'name': 'service-a_80_vs', 'state': 'present', 'type': 'standard', 'source': '0.0.0.0/0', 'destination': '198.51.100.1/32', 'port': 80, 'pool': 'service-a_web_pool', 'enabled_vlans': ['test_vlan'], 'source_port': 'preserve', 'ip_protocol': 'tcp', 'irules': ['service-a_sorry_irule', 'service-a_cms_irule'], 'profiles': ['tcp', 'http']})

PLAY RECAP **********************************************************************************************************************************************************************************************
testlb.example.com     : ok=7    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
Guessing

Following part seems to cause of this issue. Should it sort iRules?

https://github.com/F5Networks/f5-ansible/blob/devel/library/modules/bigip_virtual_server.py#L3237-L3238

@wojtek0806

This comment has been minimized.

Copy link
Collaborator

@wojtek0806 wojtek0806 commented Aug 7, 2019

usually iRule order does not matter unless you have duplicate iRule events, only then the order of iRules is taken into consideration:

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-irules-concepts-11-6-0/3.html

@wojtek0806 wojtek0806 added the question label Aug 7, 2019
@focrensh

This comment has been minimized.

Copy link
Contributor

@focrensh focrensh commented Aug 7, 2019

You can also adjust order of execution within an irule with "priority".

https://devcentral.f5.com/s/articles/the101-irules-101-events-amp-priorities

@shinobe179

This comment has been minimized.

Copy link
Author

@shinobe179 shinobe179 commented Aug 7, 2019

usually iRule order does not matter unless you have duplicate iRule events

I'm exactly worried about a case I have duplicate events across multiple iRules.
If 2 iRules(a_irule and b_irule) are attached a VS, and both conditions is fulfilled(e.g. HTTP request to "example.com/b/index.html"), the destination pool is decided by the order of iRules(later iRule), doesn't it?

# a_irule

when HTTP_REQUEST {
  {[HTTP:host] equals "example.com"} {
    pool a_pool
  }
}

# b_irule

when HTTP_REQUEST {
  {[HTTP:path] starts_with "/b/"} {
    pool b_pool
  }
}
@wojtek0806 wojtek0806 self-assigned this Aug 13, 2019
@wojtek0806 wojtek0806 added backlog bug and removed question labels Aug 13, 2019
@wojtek0806

This comment has been minimized.

Copy link
Collaborator

@wojtek0806 wojtek0806 commented Aug 13, 2019

FMFA-316

@shinobe179

This comment has been minimized.

Copy link
Author

@shinobe179 shinobe179 commented Aug 17, 2019

Thank you for adding this issue to your backlog.
I didn't know prioirty, I may use it in iRules as workaround.

@Sam-Hall

This comment has been minimized.

Copy link

@Sam-Hall Sam-Hall commented Oct 11, 2019

Thank you for adding this issue to your backlog.
I didn't know prioirty, I may use it in iRules as workaround.

I'd say that "priority" is absolutely the correct solution to iRule ordering, not a workaround. I normally use it in every event, like this for example...
when HTTP_REQUEST priority 600

@shinobe179

This comment has been minimized.

Copy link
Author

@shinobe179 shinobe179 commented Oct 12, 2019

Hi Sam, thanks for your comment. I understand it, but I manage a sequence of iRules by only the order of iRules in each VS/SNAT, and changing this regulation is a little difficult. So at least “for me”, priority is just a workaround.

wojtek0806 added a commit to wojtek0806/f5-ansible that referenced this issue Oct 18, 2019
@wojtek0806 wojtek0806 added in-action and removed backlog labels Oct 18, 2019
wojtek0806 added a commit that referenced this issue Oct 18, 2019
fixes #1430
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.