Currently (as of 16.0.9), a default install that uses a the Glance file store with a local (i.e. non-NFS) /var/lib/glance/images yields the following error when trying to upload an image.
$ openstack image create --disk-format=qcow2 --container-format=bare --file cirros.qcow2 --public cirros
Error finding address for http://192.168.122.101:9292/v2/images/934f0b78-ba7e-48f7-a7fa-f612f56de130/file: [Errno 32] Broken pipe
The reason is that /var/lib/images in the Glance container is owned by root:root immediately post-install, rather than glance:glance. As far as i can tell, the reason for this is as follows:
https://review.openstack.org/#/q/I716c9fe35391629532e67e212d45ea27a5422d1b introduced a change that only creates the /var/lib/glance/directory if it does not already exist:
- name: Stat the images directory
stat:
path: "{{ glance_system_user_home }}/images/"
changed_when: false
register: images_stat
- name: Create glance images dir
file:
path: "{{ glance_system_user_home }}/images/"
state: directory
owner: "{{ glance_system_user_name }}"
group: "{{ glance_system_group_name }}"
mode: "0755"
when:
- not images_stat.stat.exists | default(false) | bool
However, in a default (non-NFS) install, that directory isn't created from within the container, it is bind-mounted into it from /openstack/log/<host>_glance_container-<suffix> — which the lxc-containers-create.yml playbook does create with root:root permissions. So in that scenario, images_stat.stat.exists is always true, and the "Create glance images dir" task never fixes up the incorrect permissions, and Glance breaks.
Note that this will only affect fresh installs. Anything that was set up with Pike before that change was introduced will work just fine, because there the images directory does already exist, and it has the correct ownership.
I don't know what's the best way to fix this. Though I have no way to test with NFS, I am assuming that just removing the when check (or, for that matter, the preceding stat task altogether, images_stat.stat.exists isn't used anywhere else) would probably break NFS-based configurations — I am guessing that that was the motivation behind https://review.openstack.org/#/q/I716c9fe35391629532e67e212d45ea27a5422d1b in the first place.
I should probably add: deploying with 16.0.8 should be fine too; the problematic change was cherry-picked into stable/pike 4 commits after the 16.0.8 release was cut:
$ git describe 8885125fb65da72
16.0.8-4-g8885125
So, for anyone making a fresh install with 16.0.8 and then doing an in-place upgrade to 16.0.9, this problem should not affect them.