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

Make ansible facts not flat #104

Open
rmkraus opened this issue Nov 26, 2020 · 2 comments
Open

Make ansible facts not flat #104

rmkraus opened this issue Nov 26, 2020 · 2 comments

Comments

@rmkraus
Copy link
Member

rmkraus commented Nov 26, 2020

Currently, the structure of ansible facts is flat. They should probably be put into a structure the represents the structure of the yaml file.

@rmkraus rmkraus created this issue from a note in Config Transition (To do) Nov 26, 2020
@jharmison-redhat
Copy link
Member

I'd like to discuss the yml file format and see if we can come up with a good plan for what it should look like, how the roles and playbooks use data from it, and what the method for reading/writing it should look like.

I think that something like the following would be a good replacement for config.sh:

faros-config.yml:

network:
  router:
    port_forward:
      - SSH to Bastion
      - HTTPS to Cluster API
      - HTTP to Cluster Apps
      - HTTPS to Cluster Apps
      - HTTPS to Cockpit Panel
    lan:
      network: 192.168.8.0/24
      interfaces:
        - eno1
        - eno5
      dns:
        forward_resolvers:
          - 10.1.1.1
      dhcp:
        ignore_macs:
          - name: node-0-eno1
            mac: da:d5:de:ad:be:ef
          - name: node-0-eno2
            mac: da:d5:de:ad:be:ef
          - name: node-0-eno3
            mac: da:d5:de:ad:be:ef
        extra_reservations:
          - name: wifi
            mac: da:d5:de:ad:be:ef
            ip: 192.168.8.127
          - name: chassis
            mac: da:d5:de:ad:be:ef
            ip: 192.168.8.50
          - name: bastion-ilo
            mac: da:d5:de:ad:be:ef
            ip: 192.168.8.51
          - name: client
            mac: da:d5:de:ad:be:ef
            ip: 192.168.8.52
bastion:
  become_pass: <ultrasecret>
cluster:
  pull_secret: '{"auths":{"cloud.openshift.com":{"auth":"sometoken","email":"some@example.com"}}}' # etc
  managerment_interface:
    provider: ilo
    user: Administrator
    password: <ultrasecret>
  nodes:
    - name: node-0
      mac: da:d5:de:ad:be:ef
      mgmt_mac: fe:eb:da:ed:5d:ad
    - name: node-1
      mac: da:d5:de:ad:be:ef
      mgmt_mac: fe:eb:da:ed:5d:ad
    - name: node-2
      mac: da:d5:de:ad:be:ef
      mgmt_mac: fe:eb:da:ed:5d:ad

As you move to clean up playbook organization, they could come to expect this file be located in a specific place inside the container and you could read it directly using vars_files, or we could extend the inventory.py to define the appropriate variables for the appropriate nodes (for instance, most of this would belong only to the bastion) after reading in this file from the data directory.

I've seen some desire to make configuration items optional, and as long as the playbooks and roles default the inventory variables appropriately it would work well.

One note is that this hierarchical structure is very nice to work with, but in the case of roles, defaults/main.yml won't be able to override specific dictionary keys - only entire dictionaries. There are three ways to handle the defaulting from this structure that I see:

  1. Use the inventory.py transformation method to flatten them as they're applied to inventory vars, with underscores in place of subelements, and default the flattened vars via role defaults.
  2. Combine default dicts with inventory dicts in tasks/main.yml directly in each role using the combine filter.
  3. Default elements on each line the variables are called, allowing roles to be more flexible in their behavior in the case of undefined variables (some auto-detecting, some omitting params, etc.)

If you can elaborate some on the direction you're looking to take all of this, I can work on implementing.

@jharmison-redhat
Copy link
Member

Also, add to the above suggested layout information about the disks.... either to the cluster.nodes array or a dedicated storage section.

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

No branches or pull requests

2 participants