I should be able to add multiple rules to a content view filter

[jwbernin]

SUMMARY

The current model in use in katello_content_view_filter only allows the addition of a single rule per filter item. If the same call is reissued with the same filter name and a different rule, the rule is replaced rather than appended to. I would like to be able to either append to a rule with a follow-on play, or I would like to be able to specify multiple rules within a given filter.

ISSUE TYPE

• Feature Idea

[sean797]

I think if you supply the same name, but a different rule_name this should work?

On Tue, 4 Feb 2020 at 18:08, John Berninger notifications@github.com wrote:

SUMMARY

The current model in use in katello_content_view_filter only allows the addition of a single rule per filter item. If the same call is reissued with the same filter name and a different rule, the rule is replaced rather than appended to. I would like to be able to either append to a rule with a follow-on play, or I would like to be able to specify multiple rules within a given filter. ISSUE TYPE

• Feature Idea

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theforeman/foreman-ansible-modules/issues/695?email_source=notifications&email_token=ADEG46Y6TPZAOKUMMWWNT53RBGOHRA5CNFSM4KP2TYVKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IK6YJHQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEG463HVVJJ3OMWNOLPVV3RBGOHRANCNFSM4KP2TYVA .

[evgeni]

Yepp, setting different rule_names should work. It just defaults to the same value as the filter name itself.

[jwbernin]

rule_name is an alias of package_name so when I set a rule_name, I get [WARNING]: Both option rule_name and its alias package_name are set. and the rule is replaced, not appended to.

[evgeni]

ah, can you post your whole playbook then to reproduce please?

[jwbernin]

---
- name: Add filters
  hosts: localhost

  tasks:
    - name: Add filter
      katello_content_view_filter:
        username: admin
        password: password
        server_url: "https://satellite.example.com"
        validate_certs: false
        name: "pkg filter 1"
        organization: MyOrg
        content_view: rhel7
        filter_type: "rpm"
        package_name: "389-ds-base"
        version: "0:1.3.1.6-26.el7_0"
        inclusion: true

    - name: Add filter
      katello_content_view_filter:
        username: admin
        password: password
        server_url: "https://satellite.example.com"
        validate_certs: false
        name: "pkg filter 1"
        organization: MyOrg
        content_view: rhel7
        filter_type: "rpm"
        package_name: "389-ds-base"
        version: "0:1.3.3.1-13.el7"
        inclusion: true

[jwbernin]

That is the smallest reproducer snippet - it will result in one filter with one rule, when it should have one filter with two rules.

[evgeni]

Right, so after looking (long enough) at your example, the Katello UI around this, and the code of our module, I think that we should follow the workflow Katello UI does here, and split the module into two: cv_filter and cv_filter_rule, that way you first have to create a filter, and then, can add/remove as many rules to/from it as you like.

Another way would be to allow a rules list in the current module, and then compare the rules with the existing ones, but I think I prefer separate modules.

I'll leave that up to the discussion in the triage session next week (ping @wbclark @theforeman/ansible-modules ;))

[parmstro]

I agree with evgeni that this needs to be broken apart. This is how it is implemented with hammer (hammer content-view filter rule create args). The challenge that I run into is specifying a large configuration and writing clean code to iterate over multiple filter definitions. Imagine having multiple definitions such as below, and crawling them to build a configuration. The katello_content_view_filter does not easily allow for adding multiple rules for rpm filters. (also the module code includes "architecture" in the rpm rule spec, but doesn't implement it in the module definition so no way to specify basearch). The other odd behaviour is that when you are trying to create the rule "IncludePackagesNoErrata" listed below which is intended to add all packages in all repositories that have no errata AND do not specify rule_name, package_name, or package_group in the call to the module, It actually adds a rule called IncludePackagesNoErrata in the filter like it is a package. This is not the expected filter.

  - name: "TestContentView"
    desc: "Delete Me"
    org: "TestOrg"
    repositories:
    - name: "Red Hat Ansible Engine 2.9 RPMs for Red Hat Enterprise Linux 7 Server x86_64"
      product: "Red Hat Ansible Engine"
    - name: "Red Hat Satellite Tools 6.6 for RHEL 7 Server RPMs x86_64"
      product: "Red Hat Enterprise Linux Server"
    - name: "Red Hat Enterprise Linux 7 Server - Extras RPMs x86_64"
      product: "Red Hat Enterprise Linux Server"
    - name: "Red Hat Enterprise Linux 7 Server - Optional RPMs x86_64 7Server"
      product: "Red Hat Enterprise Linux Server"
    - name: "Red Hat Enterprise Linux 7 Server - RH Common RPMs x86_64 7Server"
      product: "Red Hat Enterprise Linux Server"
    - name: "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server"
      product: "Red Hat Enterprise Linux Server"
    filters:
    - name: "IncludePackagesNoErrata"
      type: "rpm"
      inclusion: "true"
      description: "Include all packages with no errata for all repositories"
      original_packages: true
      repositories: "[]"
    - name: "IncludeErrataByDate"
      type: "erratum"
      inclusion: "true"
      description: "Include all errata updated as of the 1st of the month"
      original_packages: false
      repositories: "[]"
      rules:
      - name: "errata-by-date-{{ errata_end_date }}"
        end_date: "{{ errata_end_date }}"
        date_type: "issued"
        types:
        - "enhancement"
        - "bugfix"
        - "security"
    - name: "NoFireFox"
      type: "rpm"
      inclusion: "false"
      description: "Do provide Firefox to be installed on servers"
      original_packages: false
      repositories: "[]"
      rules:
      - name: "firefox*"
        basearch: "x86_64"

[itcultus]

If you split this, how will you ensure the idempotency?
And how will you ensure that a specific filter has only the rules that are defined in the inventory?
Following what hammer is doing in the CLI is not always replicated with Ansible; I want to have my CV/CCVs filters etc at a specific state. If the module supports idempotency at the rule level, how will I achieve idempotency at the filter level (which is even more important)?

[parmstro]

@itcultus ... Hmmm... Idempotency. You will to run into this sort of issue with any hierarchical structure that you are trying to develop. How do you make a system idempotent when it consists of many related and hierarchical parts. Certain configuration may not be able to exist until other elements exist. How far do you go back this up the hierarchy chain. If I want to ensure that if my content view exists, it is idempotent....?? Do I add all the repos, filters, files, containers, etc. in one module? It is the module action that has to be idempotent - i.e. it always delivers a known and defined end state regardless of the beginning state based on the end state defined by the parameters. What the underlying system looks like is why we are writing ansible playbooks. Much like the way the foreman/katello implements the concept of filters, a filter exists or does not exist. Simple idempotency. If it exists, it has no rules yet assigned. If you remove it, it removes all the rules along with the filter. Once it exists, you ensure that it has the proper filter rules attached. Having the modules work in an understandable fashion relative to the way that an administrator is managing the application and trained on using the system is also important IMO. It makes using the modules that much easier.

Then again, I could HMHUMA.

[parmstro]

This issue should be resolved with the release of v3.9.0