tripleo-heat-templates: ipa fails with freeipa_ansible roles

Bug #1987644 reported by Cristian Le
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
New
Undecided
Unassigned

Bug Description

I get errors such as `Unable to discover domain, not provided on command line`, and I suspect is because they are not passed into here
https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/deployment/ipa/ipaservices-baremetal-ansible.yaml#L153-L172

I have tested on my own setup hard-coding overriding and it managed to get passed that section. My question is what exactly does this line do?
https://opendev.org/openstack/tripleo-heat-templates/src/commit/8e34b58d7057da53b70623a65208c31828a7781d/deployment/ipa/ipaservices-baremetal-ansible.yaml#L169-L172

Also where can I find some documentation on the ansible plugins that openstack defines? E.g. `map_merge` or the `if` in question here

Cristian Le (lecris)
description: updated
Revision history for this message
Cristian Le (lecris) wrote :

Also a spinoff issue of this, which I do not know where the find the component responsible of, is that when a network has all `name`, `name_lower` and `service_net_map_replace` specified, the ipa hostname is not well constructed, and it does not take into account `dns_domain`. E.g.:
```yaml
---
# network_data.yaml
- dns_domain: my-external.overcloud.lab
   name: External
   name_lower: overclouda_external
   service_net_map_replace: external
   subnets:
     overclouda_external_subnet: {...}
---
# overcloud_baremetal_deployment.yaml
- name: Controller
  count: 1
  defaults:
    network_config:
      default_route_network:
        - overclouda_external
    networks:
      - network: ctlplane
        vif: true
      - network: overclouda_external
      - network: overclouda_internal_api
      - network: overclouda_storage_mgmt
      - network: overclouda_storage
      - network: overclouda_tenant
    profile: controller
  hostname_format: controller-%index%
```
Then the hosts being generated in freeipa are like:
`controller-0.overcloudaexternal.overcloud.lab`
instead of the hostname that is used for freeipa services like `<email address hidden>`:
`controller-0.external.overcloud.lab`
But actually the correct behaviour would have been to be:
`controller-0.my-external.overcloud.lab`

Revision history for this message
Cristian Le (lecris) wrote :

And regarding the original issue, in order to replicate this issue, set `CloudDomain` different than the domain of the freeipa, i.e. if the freeipa is on `ipa.example.lab1`, set `CloudDomain` as:
```yaml
---
# tls-parameters.yaml
parameter_defaults:
  DnsSearchDomains: ['lab1', 'lab2']
  CloudDomain: openstack.lab2
```

Revision history for this message
Takashi Kajinami (kajinamit) wrote (last edit ):

map_merge or if is not part of ansible feature but these are heat template functions. The if conditions adds these two lines when IdMServer is set and is not empty. Did you set IdMServer and IdMDomain in your deployment templates ?

You can also check the ansible-playbook generated in ~/config-download to see whether these two variables (ipaclient_server and ipaclient_domain) are set or not.

Revision history for this message
Cristian Le (lecris) wrote (last edit ):

The documentation only indicates that we should set `CloudDomain` and in principles `IdMDomain` should be derived from there.
https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/tls-everywhere.html#set-parameters

In either case, even when I included `IdMDomain` it did not get picked up. I added it as such:
```
parameter_defaults:
  CloudDomain: example.com
  IdMDomain: example.com
```

Are there other syntaxes to define parameters? Where can I see if a parameter is derived from another?

Ok starting to understand the Heat template structure a bit. The parameters are written in the same file and I need to provide a servers list as well. Let's see if that fixes it. It is unclear how not setting `IdMDomain` the `freeipa_ansible.client` can detect it. The documentation of the role says that it must be provided

Revision history for this message
Takashi Kajinami (kajinamit) wrote :

The parameter description[1] says;

```
IDM domain to register IDM client. Typically, this is discovered through DNS and does not have to be set explicitly.
```

[1] https://github.com/openstack/tripleo-heat-templates/blob/5f7f6334c377e7cbd6012f35966bd18ed6709fc6/deployment/ipa/ipaservices-baremetal-ansible.yaml#L36-L40

I'm not an tls-e expert but my understanding is that as long as your IDM server can be lookup within DNSDomain then you don't need to add IdmDomain.

> It is unclear how not setting `IdMDomain` the `freeipa_ansible.client` can detect it.
Are you talking about the ipaclient role from ansible-freeipa or anything different ?
I could not find anything referring to freeipa_ansible.

Again, did you set BOTH IdMServer and IdMDomain in your deployment templates ?
If you set the parameter to non-empty value then IdMDomain should be passed to that ipaclient role. Unless you set IdMServer, IdMDomain is not passed to the role.

Revision history for this message
Cristian Le (lecris) wrote :

Sorry, yes, the role is `ansible-freeipa.ipaclient`.

The logic is that it first checks for `ipaserver_domain` and then `ipaclient_domain` and errors out when neither is set [1]. When I debugged the play, `ipaserver_domain` was not set. I am not sure what is responsible to set it, but that in principle should be the default method of configuration, using `CloudDomain`.

[1] https://github.com/freeipa/ansible-freeipa/blob/401d5d5acccfeaa421edb9d39647f0d0c1b71a67/roles/ipaclient/tasks/install.yml#L33

About the discovered through dns, that is unclear to the logic of that discovery. In principle, those should be group variables that set both `ipaserver_domain` and `ipaserver` is defined according to `CloudDomain` and the keytab info or undercloud registration.

But actually I don't think that the heat template would even handle this configuration properly, where the `CloudDomain` is different than ipaserver domain, even though the deploy documentation implies that it should work. For example, which `ipaclient_realm` will be used there?

Revision history for this message
Cristian Le (lecris) wrote (last edit ):

Indeed, I do not see `ipaserver_domain` being generated in `config_data/overcloud/inventory/tripleo`, and I do not see it in the heat template. So unless it is supposed to be injected into the groups somehow, there is something wrong in how the group vars is missing this.

But also, considering the logic of the role, `ipaserver_domain` has precedence to `ipaclient_domain`, so is it that `ipaserver_domain` is not generated in order to be able to overwrite it with `ipaclient_domain`? If so, than `IdMDomain` has to be required.

Edit: but indeed, setting both `IdMServer` and `IdMDomain` managed to get it working, until the next error pops up

Revision history for this message
Takashi Kajinami (kajinamit) wrote :

IdMServer and IdMDomain are not rendered into inventory but into the playbook generated by config download. Once you set both these two parameters, you see these values are defined in a playbook yaml file under the config-download directory.

Because the problem was resolved by setting both IdMServer and IdMDomain, which looks the expected way to override the ipaclient_domain parameter, I'd close this as invalid but let me know in case you have any concern.

Revision history for this message
Cristian Le (lecris) wrote :

My only concern is to either:
- Update the documentation to to indicate that we should include those parameters as well
- Confirm that there is/was a mechanism to define `ipaserver_domain` or `ipaclient_domain` in the group vars. I.e. the reference to "Typically, this is discovered through DNS and does not have to be set explicitly."

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.