using templated catalog causes issues creating/listing new services/endpoints

[Darren Birkett]

This is an issue in HAVANA

We are using a templated catalog for the initial list of services and endpoints, which works fine.

Trying to add a service works, but the following behaviour is observed with various keystoneclient commands:

keystone catalog:
= only the list of services from the template is shown

keystone service-list:
= only the manually added service is shown

keystone endpoint-list:
= only the manually added endpoints (for the manually created service) are shown

keystone endpoint-get --service <my manually added service>
"publicURL endpoint for <my manually added service> not found"

keystone endpoint-get --service <a service from the templated catalog>
= publicurl is shown

[ZhiQiang Fan (aji-zqfan)]

IMHO, this is the expected behaviour since you're using static catalog.

[Dolph Mathews (dolph)]

ZhiQiang Fan: I agree with the general notion, but if you dig into the details of this behavior, it's far from expected.

At minimum, it's poor user feedback. When using the templated backend, two "catalogs" are stored in memory-- one that supports basic read/write, and one that is actually used to build the token catalog. Looking at the implementation, I think the templated catalog should be loaded into the KVS backend, and the KVS backend should be used to render the catalog.

Unfortunately, the scope of effort required to "fix" this wanders into blueprint / new features territory so I don't think it would be backportable to havana. "Fixing" this may also be dependent on https://blueprints.launchpad.net/keystone/+spec/dogpile-kvs-backends (which is re-writing the KVS driver).

[ZhiQiang Fan (aji-zqfan)]

I agree it can be a minor new feature other than a bug fix

the static catalog is meant to have no dynamic cli management ability, if not, how could it be static

[Dolph Mathews (dolph)]

ZhiQiang Fan: I disagree, in that the static bit is useful primarily for seeding keystone with data on startup. I don't see any reason to deny R/W operations at runtime (although, we currently do). +1 for it being a minor new feature, however!

[Ning Sun (ning-sun)]

is this bug fixed in Kilo?

[David Stanek (dstanek)]

This is not fixed and I am tempted to mark it as WONTFIX. I had a patch to fix the feedback problem and actually give the user an error if they tried to do any write operation. I'll have to find that and revive it.

Is there a real usecase for this outside of development? I have two issues will adding write support. The first is that we'll either have to persist it to another file somewhere or it goes away. The second is that the written changes will only apply to the keystone instance that handled the API call. If there are multiple keystone instances in a cluster then the user would have to hit each one. It seems to me that this will likely lead to an inconsistent catalog in real deployments.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/158442
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=b1b4350017c8e0177193b3b013c3d9c9f9b9d23a
Submitter: Jenkins
Branch: master

commit b1b4350017c8e0177193b3b013c3d9c9f9b9d23a
Author: David Stanek <email address hidden>
Date: Tue Feb 17 19:05:56 2015 +0000

    Removes KVS catalog backend

    The templated backend relied on the KVS backend to implement some
    functionality. The functionality (CRUD for endpoint, services, etc.) is
    arguably incorrect since it won't actually change the contents of the
    catalog. The read only methods have been fixed to use the templated data
    and the write methods raise NotImplemented.

    bp: removed-as-of-mitaka
    Partial-Bug: #1077282
    Closes-Bug: #1367113
    Closes-Bug: #1269789
    Change-Id: Iaa68b18f0b6d7e9f5dc0cbf7d21a3d90dcdc1ea4

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 9.0.0.0b3 development milestone.