Kolla-ansible can't create default server pool for Designate

Hi Wojtek, I think there is a chicken and egg problem with your proposal - we need to configure the pool ID in designate config, but need designate to be running in order to query the pool ID.

I checked the code for designate manage, and if the pool is not found then it is created. https://opendev.org/openstack/designate/src/commit/d9fb34767c5bd9f8f822acc2b91715db45ab68db/designate/manage/pool.py#L156

Hi Mark,
I'm not sure but you may have right with chicken and egg. I first installed designate then change configuration and run kolla-ansible reconfigure so I fixed it manually. I do not check if installation is possible when default_pool_id is not defined in first steps.

Maybe better is to fix designate-manage, I also checked source, look from line 110
https://opendev.org/openstack/designate/src/commit/d9fb34767c5bd9f8f822acc2b91715db45ab68db/designate/manage/pool.py#L110

When there is no 'id' in yaml file, in line 120 exception PoolNotFound will be raised and serviced in line 144, pool will be created in line 156 as you wrote.

When there is 'id' in yaml, exception raised in line 112 will be serviced in line 114. After 'continue' in line 118 next pool from yaml will be serviced in next iteration of loop so **pool will not be created**

Part of designate-manage.log:
2019-12-09 19:38:12.617 25 CRITICAL designate.manage.pool [designate-manage - - - - -] Bad ID Supplied for pool. pool_id: 67ccc1ba-b3df-47f5-be34-79aa711e1735 message: Could not find Pool
Traceback (most recent call last):

  File "/var/lib/kolla/venv/lib/python3.6/site-packages/designate/rpc.py", line 238, in exception_wrapper
    return f(self, *args, **kwargs)

  File "/var/lib/kolla/venv/lib/python3.6/site-packages/designate/central/service.py", line 2277, in get_pool
    return self.storage.get_pool(context, pool_id)

  File "/var/lib/kolla/venv/lib/python3.6/site-packages/designate/storage/impl_sqlalchemy/__init__.py", line 983, in get_pool
    return self._find_pools(context, {'id': pool_id}, one=True)

  File "/var/lib/kolla/venv/lib/python3.6/site-packages/designate/storage/impl_sqlalchemy/__init__.py", line 911, in _find_pools
    sort_dir)

  File "/var/lib/kolla/venv/lib/python3.6/site-packages/designate/sqlalchemy/base.py", line 250, in _find
    raise exc_notfound(msg)

designate.exceptions.PoolNotFound: Could not find Pool
: designate.exceptions_Remote.PoolNotFound_Remote: Could not find Pool

Regards,
Wojtek

I see, thanks for the explanation. Is this something you can work on?

I can confirm that this is still not fixed and that the generated id of the pool is not matching the one used in the pool.
- the pool exists in designate-worker
- user needs to manually update the id of the pool in passwords
- reconfigure -t designate

user can add zones and create pools in both horizon and via cli.

Possible duplicate (but not exact): https://bugs.launchpad.net/kolla-ansible/+bug/1866601

Designate seems to create the default pool called "default" with config-specified default_pool_id via migrations (during the bootstrap): https://opendev.org/openstack/designate/src/branch/master/designate/storage/impl_sqlalchemy/migrate_repo/versions/070_liberty.py#L391-L395

Maybe it's designate's bug:
https://bugs.launchpad.net/designate/+bug/1881277

duplicate: https://bugs.launchpad.net/designate/+bug/1881277

I find out this is exactly a bug in designate. not related to kolla-ansible.

the default_pool_id config under section [service:central] does not work properly when running command "designate-manage database xxx" or "designate-manage pool xxxx".

This is because the code below:
https://opendev.org/openstack/designate/src/branch/master/designate/cmd/manage.py#L59
https://opendev.org/openstack/designate/src/branch/master/designate/manage/pool.py#L65

the code in manage.py says, even if we execute "designate-manage database", we also load the default cli params for command "designate-manage pool"

then the code in pool.py, it is recursively defined default_pool_id from cli by the default opts values in conf. that means "register_default_opts" <-- overwrite by real conffile <-- overwrite again by cli default opts.

I think we need someone help from designate project to suggest how to fix it in designate.

hi, this is a designate bug, the default_pool_id opt didn't registered before executing designate-manage database sync. i have proposed a patch [1] to fix it.

we will create a default pool with the right default_pool_id now. and then default pool can be updated by `desigante manage update`[2]

this works for me.

[1]https://review.opendev.org/#/c/751245/
[2]https://opendev.org/openstack/designate/src/branch/master/designate/manage/pool.py#L167

This issue has been fixed in designate in Victoria, according to the above comment.