Andrew Lazarev wrote:
> Hi Nova experts,
> Some time ago I figured out that devstack fails to stack with
> USE_SSL=True option because it doesn't configure nova to work with
> secured glace [1]. Support of secured glance was added to nova in Juno
> cycle [2], but it looks strange for me.
> Glance client takes settings form '[ssl]' section. The same section is
> used to set up nova server SSL settings. Other clients have separate
> sections in the config file (and switching to session use now),  e.g.
> related code for cinder - [3].
> I've created quick fix for the devstack - [4], but it would be nice to
> shed a light on nova plans around glance config before merging a
> workaround for devstack.
> So, the questions are:
> 1. Is it normal that glance client reads from '[ssl]' config section?
> 2. Is there a plan to move glance client to sessions use and move
> corresponding config section to '[glance]'?
> 3. Are any plans to run CI for USE_SSL=True use case?

YES! It is quite a battle to keep SSL (native SSL and tls-proxy) working
in devstack given the pace of development of the related projects. I've
got a couple of reviews out now which may bring things to a state where
the tempest smoke suite will pass in SSL mode.

> [1] -

I haven't seen that. What does your local.conf look like? Honestly I
mostly test with the configuration that devstack-gate uses to have any
chance of SSL being part of CI.

Note too that I'm trying hard to be able to stop using service-specific
CA options and instead add all CA certs to the global cert store and
then things will just work. I originally start pushing for per-client
SSL config sections and got pushback from a number of PTLs that didn't
want their config options exploding.

That leads to the python-requests problem. It includes a nifty function,
where(), which returns the location of the global CA bundle. Packagers
set this to match what is on individual platforms (Debian, Ubuntu &
Fedora/RHEL anyway).

Unfortunately devstack often requires newer versions that ships with the
OS's causing pip to install the upstream version, which of course
defaults to using the bundle it ships, which ends up breaking lots of
things. I'm stumped as to how to fix that. I made a ham-handed attempt
at fixing it last year and was appropriately smacked down.


OpenStack Development Mailing List (not for usage questions)

Reply via email to