[openstack-dev] Devstack, Tempest, and TLS

Clark Boylan cboylan at sapwetik.org
Tue Sep 27 21:58:31 UTC 2016


On Fri, Sep 23, 2016, at 05:04 PM, 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.
> 
> Tempest passes against devstack with some edits to one of the object
> tests to properly handle 304s [1].
> 
> Multinode devstack and tempest pass with a small change to devstack-gate
> [2] to copy the CA to all test nodes which needs a small change to
> devstack [3] to avoid overwriting the CA. Note the devstack-gate change
> needs to deal with some new ansible issues so isn't ready for merging
> just yet.
> 
> 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.
> 
> 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.
> 
> Should I be filing bugs for these things? are they known issues? is
> anyone interested in simplifying our configs?
> 
> [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

Another quick update on this. Enough of these changes have merged that
we are now running with tls-proxy enabled on changes against master in
the "vanilla" devstack/tempest jobs. You should be seeing https urls
floating around now.

I still need to get https://review.openstack.org/373219 in before we can
turn this on for multinode testing but it does appear to be working now.
Change 372374 can be used to verify the neutron multinode job passes
with 373219 in place. Reviews very welcome. I have been trying to use
topic:devstack-tls to group together things ready for review.

Once multinode testing has tls-proxy enabled the next thing I think we
should be talking about is enabling this by default in devstack. As
mentioned before ironic doesn't work due to IPA images not trusting
glance's cert. Swift's functional tests don't currently work against
https keystone as they assume http as well. All this to say if you have
a devstack plugin or testing that depends on devstack now would be a
great time to turn on tls-proxy and see if your things work with it
(easy mode is depends-on 373219). I think that if we can identify places
where it doesn't work and fixing it would require a lot of effort we
should just proactively disable it in the jobs. That way we can turn it
on by default for the default vanilla case.

Thank you,
Clark



More information about the OpenStack-dev mailing list