| Summary: | Director deployed setup has v2 heat auth_uri which causes heat stack deploy to fail. | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Jeremy <jmelvin> |
| Component: | openstack-heat | Assignee: | Rabi Mishra <ramishra> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Amit Ugol <augol> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 (Liberty) | CC: | aschultz, jmelvin, mburns, ramishra, rhel-osp-director-maint, sbaker, shardy, srevivo, zbitter |
| Target Milestone: | --- | Flags: | ramishra:
needinfo?
(jmelvin) |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-09 15:16:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Heat shouldn't have any trouble finding the v3 endpoint, regardless of which URL you give it: http://git.openstack.org/cgit/openstack/heat/tree/heat/common/context.py?h=stable%2Fliberty#n130 So I think the issue here is that Heat is unaware that Ceilometer (apparently) requires Keystone v3 auth. (That's news to me as well.) How should we move forward with this ? I think this is probably a manifestation of the config problems discussed in https://bugs.launchpad.net/heat/+bug/1300246 Jeremy - can you please confirm if updating the heat.conf as described here fixes it? https://bugs.launchpad.net/heat/+bug/1300246/comments/6 Quoting from there, change the keystone_authtoken section to look like this, note the lack of any versions at all (this configuration should mean the keystoneclient auth plugin works out the correct version for us): auth_uri = http://10.224.8.10:5000 auth_url = http://10.224.8.10:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = heat password = <password> We may also need to update the config to add a trustee section, as discussed later in the bug mentioned above, and in the upstream docs (which were fixed as part of that bug): http://docs.openstack.org/liberty/install-guide-ubuntu/heat-install.html#install-and-configure-components If we can confirm these manual config changes work OK, it means we can reassign this to puppet-heat, and just modify there to achieve the required config. Also, please can you provide the full heat.conf so we can check for any other issues. Removing the version does not fix it. See my previous comment: "Supposedly, we should be able to specify a versionless URI that would leverage version discovery (e.g. http://10.224.8.10:5000) but this does not work – maybe in Mitaka? Since many of the other clients (e.g. Ceilometer) don’t leverage domains in the same way as Heat, we should be OK with other client settings using v2.0, but since Heat *does* leverage a domain for trusts-based auth, it makes no sense it would use an auth_uri specifically targeting v2.0 for identity/auth services. I found this thread, which steered me in the correct direction but did not solve our issue..." Also, we're already using trustee (domain-based) heat configuration -- that's the default Director deployment. Attempting to use password as the auth_plugin failed (I believe "password" will be deprecated soon as an auth model): http://hardysteven.blogspot.com/2014/04/heat-auth-model-updates-part-1-trusts.html Jeremy, Can you please share your heat.conf and confirm the RHOS version you're using? I just checked with a RHOS 8 installation and after adding the trustee section as below it seems to work fine. [trustee] user_domain_id = default password = <password> username = heat auth_url = http://192.0.2.6:35357 # No endpoint version auth_plugin = password I don't see puppet-heat configuring the trustee section in liberty(RHOS 8), it seems to be added in mitaka/RHOS9[1] [1] https://github.com/openstack/puppet-heat/blob/stable/mitaka/manifests/init.pp#L440 I checked the config and it does not seem have the 'trustee' section as mentioned in comment #7. Can you please add that and let us know if it works? Is there any update on this? This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release. |
Description of problem:Heat stack fails on configuring ceilometer alarm resource. heat resource-show 3fa487cc-4c74-409a-9a80-b683b33dc143 cpu_alarm_low WARNING (shell) "heat resource-show" is deprecated, please use "openstack stack resource show" instead +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Property | Value | +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ | attributes | {} | | creation_time | 2016-11-17T00:32:18 | | description | | | links | https://cygnus.ssc.lmco.com:13004/v1/4f6fa89e68cb480dbb1918d983f09ce7/stacks/Test/3fa487cc-4c74-409a-9a80-b683b33dc143/resources/cpu_alarm_low (self) | | | https://cygnus.ssc.lmco.com:13004/v1/4f6fa89e68cb480dbb1918d983f09ce7/stacks/Test/3fa487cc-4c74-409a-9a80-b683b33dc143 (stack) | | logical_resource_id | cpu_alarm_low | | physical_resource_id | | | required_by | | | resource_name | cpu_alarm_low | | resource_status | CREATE_FAILED | | resource_status_reason | Unauthorized: resources.cpu_alarm_low: The request you have made requires authentication. (HTTP 401) (Request-ID: req-a6678604-6227-4d9d-8244-df3be0464f06) | | resource_type | OS::Ceilometer::Alarm | | updated_time | 2016-11-17T00:32:18 | +------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+ Changing auth_uri in /etc/heat/heat.conf fixes the issue. # WORKING: auth_uri=http://10.224.8.10:5000/v3 # ORIGINAL (configured out of the box via Director) #auth_uri=http://10.224.8.10:5000/v2.0 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. set auth_uri to v2 2. run heat stack 3. Actual results: failed heat stack Expected results: successful heat stack deploy. Additional info: Supposedly, we should be able to specify a versionless URI that would leverage version discovery (e.g. http://10.224.8.10:5000) but this does not work – maybe in Mitaka? Since many of the other clients (e.g. Ceilometer) don’t leverage domains in the same way as Heat, we should be OK with other client settings using v2.0, but since Heat *does* leverage a domain for trusts-based auth, it makes no sense it would use an auth_uri specifically targeting v2.0 for identity/auth services. I found this thread, which steered me in the correct direction but did not solve our issue: http://openstack.10931.n7.nabble.com/devstack-keystone-Devstack-auth-token-and-keystone-v3-td46158.html FTA (from Steve Hardy no less): - Certain configurations of Heat *only* work with v3 tokens, because we create users in a non-default domain ******(We fall under this category, Heat lives in its own domain) ******( - Current devstack still configures versioned endpoints, with v2.0 keystone - Heat breaks in some circumstances on current devstack because of this. - Adding auth_version='v3.0' to the auth_token section of heat.conf fixes the problem. (this is supposed to be optional – you can specify the keystone version in the URI, or via a separate parameter. Red Hat’s heat.conf template didn’t even have this options templated) What's really annoying is that adding auth_version (above) has ***NO*** impact… so I have to specify the full, updated URI appending v3. This is contrary to what I see documented (using auth_version). There's either a disconnect in documentation, or possibly behavior, but we'd like to pinpoint the exact problem, and arrive at the proper configuration (even if that means sticking with a versioned URI)