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 . Support of secured glance was added to nova in Juno > cycle , 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 - . > > I've created quick fix for the devstack - , 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. >  - https://bugs.launchpad.net/devstack/+bug/1405484 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. rob __________________________________________________________________________ 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