On 09/24/2016 02:04 AM, Clark Boylan wrote:
Earlier this month there was a thread on replacing stud in devstack for
the tls-proxy service [0]. Over the last week or so a bunch of work has
happened around this so I figured I would send an update.

<snip>

Also noticed that Ironic's devstack plugin isn't configured to deal with
a devstack that runs the other services with TLS. This is mostly
addressed by a small change to set the correct glance protocol and swift
url [4]. However tests for this continue to fail if TLS is enabled
because the IPA image does not trust the devstack created CA which has
signed the cert in front of glance.

There is a patch to implement such trust: https://review.openstack.org/358457

However, we lack a similar change for ironic-inspector still.


Would be great if people could review these. Assuming reviews happen we
should be able to run the core set of tempest jobs with TLS enabled real
soon now. This will help us avoid regressions like the one that hit OSC
in which it could no longer speak to a neutron fronted with a proxy
terminating TLS.

Also, I am learning that many of our services require redundant and
confusing configuration. Ironic for example needs to have
glance_protocol set even though it appears to get the actual glance
endpoint from the keystone catalog. You also have to tell it where to
find swift except that if it is already using the catalog why can't it
find swift there? Many service configs have an auth_url and auth_uri
under [keystone_authtoken]. The values for them are different, but I am
not sure why we need to have an auth_uri and auth_uri and why they
should be different urls (yes both are urls). Cinder requires you set
both osapi_volume_base_URL and public_endpoint to get proper https
happening.

Note: I think everything in [keystone_authtoken] sections comes from keystonemiddleware, not from services.


Should I be filing bugs for these things? are they known issues? is
anyone interested in simplifying our configs?

+1, please do. Thanks for looking into it.


[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/102843.html
[1] https://review.openstack.org/#/c/374328/
[2] https://review.openstack.org/373219
[3] https://review.openstack.org/375724
[4] https://review.openstack.org/375649

Thanks,
Clark

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to