I filed https://bugs.launchpad.net/tripleo/+bug/1693034, which I just marked as a duplicate of this bug. Though it points out a slight evolution in the issue that I'll drop in here.
Olilver reported the following about one week ago:
(undercloud) [stack@undercloud ~]$ echo $OS_AUTH_URL http://192.168.24.1:5000/
In my case (yesterday) the new stackrc as generated by tripleo-quickstart is using secure keystone:
(undercloud) [stack@undercloud ~]$ grep OS_AUTH_URL stackrc OS_AUTH_URL=https://192.168.24.2:13000/
Though upload-swift-artifacts is using the new port, it's using HTTP, not HTTPS:
(undercloud) [stack@undercloud ~]$ upload-puppet-modules -d puppet-modules Creating tarball... Tarball created. Authorization Failure. Authorization failed: (http://192.168.24.2:13000/auth/tokens): The resource could not be found. (HTTP 404) (undercloud) [stack@undercloud ~]$
Is the URL getting built incorrectly?
My version is: openstack-tripleo-common-7.0.1-0.20170512193241.bde811b.el7.centos.noarch
I filed https:/ /bugs.launchpad .net/tripleo/ +bug/1693034, which I just marked as a duplicate of this bug. Though it points out a slight evolution in the issue that I'll drop in here.
Olilver reported the following about one week ago:
(undercloud) [stack@undercloud ~]$ echo $OS_AUTH_URL 192.168. 24.1:5000/
http://
In my case (yesterday) the new stackrc as generated by tripleo-quickstart is using secure keystone:
(undercloud) [stack@undercloud ~]$ grep OS_AUTH_URL stackrc /192.168. 24.2:13000/
OS_AUTH_URL=https:/
Though upload- swift-artifacts is using the new port, it's using HTTP, not HTTPS:
(undercloud) [stack@undercloud ~]$ upload- puppet- modules -d puppet-modules 192.168. 24.2:13000/ auth/tokens): The resource could not be found. (HTTP 404)
Creating tarball...
Tarball created.
Authorization Failure. Authorization failed: (http://
(undercloud) [stack@undercloud ~]$
Is the URL getting built incorrectly?
My version is: openstack- tripleo- common- 7.0.1-0. 20170512193241. bde811b. el7.centos. noarch