8:21 p.m.
Hi, All
I have tried to run an autoscaling stack by Heat
on the Openstack Liberty environment.
The environment consists of the RHEL7.1 nodes and
Openstack Liberty was installed by PackStack.
At the first time I ran an autoscaling stack, it didn't work
because of an installation problem; python-redis had not been
installed.
After installation of python-redis, I tried again and the
autoscaling stack is working now.
But I found another problem. The following message
periodically appears in /var/log/heat/heat-engine.log
2015-12-01 17:23:25.034 6231 WARNING heat.common.context
[req-22848a8b-892b-4996-bf12-56d17181d878 - f023b311e4364188be9dc2ca33726467] Using the
keystone_authtoken user as the heat trustee user directly is deprecated. Please add the
trustee credentials you need to the trustee section of your heat.conf file.
I looked /etc/heat/heat.conf made by PackStack and
confirmed no trustee section is in it.
I also compared the content of my heat.conf with the following
web page.
http://docs.openstack.org/draft/install-guide-rdo/heat-install.html
I noticed the following things besides the trustee section issue.
(A) My heat.conf has some definitions in below
which aren't used in the DEFAULT section of
the draft web page.
deferred_auth_method = trusts
trusts_delegated_roles = heat_stack_owner
(B) The keystone_authtoken sections have many differences.
My heat.conf:
[keystone_authtoken]
admin_user=heat
admin_password=***
admin_tenant_name=services
identity_uri=http://10.0.2.11:35357
auth_uri=http://10.0.2.11:5000/v2.0
Draft Page:
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = heat
password = HEAT_PASS
My questions is
Can I configure the heat-engine service not to croak
the warning message about trustee?
Sincerely
--
Takenaka Kazuhiro < takenaka_kazuhiro_p7(a)lab.ntt.co.jp >
1:08 p.m.
On Fri, Dec 04, 2015 at 11:21:24AM +0900, Takenaka Kazuhiro wrote:
Hi, All
I have tried to run an autoscaling stack by Heat
on the Openstack Liberty environment.
The environment consists of the RHEL7.1 nodes and
Openstack Liberty was installed by PackStack.
At the first time I ran an autoscaling stack, it didn't work
because of an installation problem; python-redis had not been
installed.
After installation of python-redis, I tried again and the
autoscaling stack is working now.
But I found another problem. The following message
periodically appears in /var/log/heat/heat-engine.log
2015-12-01 17:23:25.034 6231 WARNING heat.common.context
[req-22848a8b-892b-4996-bf12-56d17181d878 - f023b311e4364188be9dc2ca33726467] Using the
keystone_authtoken user as the heat trustee user directly is deprecated. Please add the
trustee credentials you need to the trustee section of your heat.conf file.
I looked /etc/heat/heat.conf made by PackStack and
confirmed no trustee section is in it.
I also compared the content of my heat.conf with the following
web page.
http://docs.openstack.org/draft/install-guide-rdo/heat-install.html
I noticed the following things besides the trustee section issue.
(A) My heat.conf has some definitions in below
which aren't used in the DEFAULT section of
the draft web page.
deferred_auth_method = trusts
trusts_delegated_roles = heat_stack_owner
Yes these entries are no longer required:
- deferred_auth_method = trusts is the default (since kilo)
- heat_stack_owner is no longer required because by default we delegate
all roles, since Launchpad bug #1376562 was fixed.
(B) The keystone_authtoken sections have many differences.
My heat.conf:
[keystone_authtoken]
admin_user=heat
admin_password=***
admin_tenant_name=services
identity_uri=http://10.0.2.11:35357
auth_uri=http://10.0.2.11:5000/v2.0
Draft Page:
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = heat
password = HEAT_PASS
Not sure about this - IIRC authtoken supports several argument formats for
backwards compatibility, so we need to ensure we're documenting the
currently preferred one.
My questions is
Can I configure the heat-engine service not to croak
the warning message about trustee?
Yes, you need to configure the "trustee" section in heat.conf, which means
heat will no longer use the keystone_authtoken to initialize the auth
plugin associated with deferred authentication via trusts.
Unfortunately, this isn't currently documented or exposed in our sample
config. I'm working on a patch to fix that which I hope to post soon, you
can follow progress here:
https://bugs.launchpad.net/heat/+bug/1300246
Steve
3:02 p.m.
- deferred_auth_method = trusts is the default (since kilo)
- heat_stack_owner is no longer required because by default we delegate
all roles, since Launchpad bug #1376562 was fixed.
You also need to configure heat to use keystone v3. Packstack,
at least as of Kilo, was still configuring keystone v2.0 by default,
see https://bugs.launchpad.net/packstack/+bug/1464371 (my bug report)
Trust delegation requires the v3 API, unless I've missed something.
There appear to be a number of issues with globally enabling keystone v3
being addressed in Red Hat OpenStack Liberty version, many of the bugs
in this query are related to keystone v3 bugs:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=keystone%20v3
It doesn't look like you want to globally set Keystone v3 while these
are bugs outstanding, but you can change it in the Heat config file directly
to only affect the Heat service.
> (B) The keystone_authtoken sections have many differences.
>
> My heat.conf:
> [keystone_authtoken]
> admin_user=heat
> admin_password=***
> admin_tenant_name=services
> identity_uri=http://10.0.2.11:35357
> auth_uri=http://10.0.2.11:5000/v2.0
^^^^
Trust delegation requires the v3 API in the line above
> Draft Page:
> auth_uri = http://controller:5000
> auth_url = http://controller:35357
> auth_plugin = password
> project_domain_id = default
> user_domain_id = default
> project_name = service
> username = heat
> password = HEAT_PASS
Not sure about this - IIRC authtoken supports several argument formats
for backwards compatibility, so we need to ensure we're documenting the
currently preferred one.
> My questions is
>
> Can I configure the heat-engine service not to croak the warning
> message about trustee?
Yes, you need to configure the "trustee" section in heat.conf, which
means heat will no longer use the keystone_authtoken to initialize the
auth plugin associated with deferred authentication via trusts.
Unfortunately, this isn't currently documented or exposed in our sample
config. I'm working on a patch to fix that which I hope to post soon,
you can follow progress here:
https://bugs.launchpad.net/heat/+bug/1300246
Steve
Regards,
John Haller
3:29 p.m.
> - deferred_auth_method = trusts is the default (since kilo)
> - heat_stack_owner is no longer required because by default we delegate
> all roles, since Launchpad bug #1376562 was fixed.
You also need to configure heat to use keystone v3. Packstack, at least as
of Kilo, was still configuring keystone v2.0 by default, see
https://bugs.launchpad.net/packstack/+bug/1464371 (my bug report) Trust
delegation requires the v3 API, unless I've missed something.
I found from one of my coworkers that the v2.0 API supports trusts,
but only from the external API endpoint, not the internal. If the VM has
a route to the external API, you can use v2.0, but otherwise need v3.
So, I did miss something.
Regards,
John Haller
5:16 p.m.
On Fri, Dec 04, 2015 at 09:02:39PM +0000, Haller, John H (John) wrote:
> - deferred_auth_method = trusts is the default (since kilo)
> - heat_stack_owner is no longer required because by default we delegate
> all roles, since Launchpad bug #1376562 was fixed.
You also need to configure heat to use keystone v3. Packstack,
at least as of Kilo, was still configuring keystone v2.0 by default,
see https://bugs.launchpad.net/packstack/+bug/1464371 (my bug report)
Trust delegation requires the v3 API, unless I've missed something.
You need to have keystone v3 enabled in the keystone service, but heat
works around endpoints with the v2.0 path transparently, so there's nothing
to do with packstack etc AFAIK.
You don't have to do anything at all to configure heat to use keystone v3,
except ensure you haven't disabled it in the keystone configuration.
A lot of folks get confused between keystone v3 being enabled
(keystone.conf option, defaulted to on), and the v2.0 endpoint in the
catalog, which is irelevant to heat, because we've been s/v2.0/v3 where
appropriate since we started using trusts in 2013.
Steve
3068
days inactive
3068
days old
4 comments
3 participants
participants (3)
-
Haller, John H (John) -
Steven Hardy -
Takenaka Kazuhiro