We have begun testing Packstack on Mitaka with delorean current. It doesn't look like the parameter filesystem_store_datadir defaults to the sane "/var/lib/glance/images" value anymore and instead now defaults to "None" as per https://github.com/openstack/glance/commit/fa30891cf659360207b71d9345666478d4554582 puppet-glance can already configure this properly with https://github.com/openstack/puppet-glance/blob/master/manifests/backend/file.pp but Packstack does not use it according to https://github.com/openstack/packstack/blob/master/packstack/puppet/templates/glance.pp. If Packstack means to use the file backend, it should include the file backend from puppet-glance. Relevant logs are attached but full job logs are available here: https://ci.centos.org/artifacts/rdo/jenkins-whayutin-poc-pastack-promote-64
Created attachment 1101909 [details] 172.19.3.120_provision_glance.log
Created attachment 1101910 [details] glance/api.log
Created attachment 1101911 [details] /etc/glance/glance-api.conf
Worth mentioning that this is a blocker for Mitaka test days due Dec 11th, a fix by then would be nice, otherwise we will need to document a workaround.
> It doesn't look like the parameter filesystem_store_datadir defaults to the > sane "/var/lib/glance/images" value anymore and instead now defaults to > "None" as per > https://github.com/openstack/glance/commit/ > fa30891cf659360207b71d9345666478d4554582 There must be more to this, that commit is included since Liberty release 11.0.0 so I'd like to understand how come it works in RDO Liberty. In openstack-* RPMs, distro defaults from *dist.conf should be applied, there's patch in python-oslo-config to load from /usr/share/<project>/*dist.conf Regardless, explicitly including file backend is the right thing to do in Packstack manifest, instead of relying on defaults.
Created attachment 1102446 [details] Reproducer This should be enough to reproduce the issue
So there's an actual glance_file.pp file: https://github.com/openstack/packstack/blob/master/packstack/puppet/templates/glance_file.pp This was introduced with the Swift backend support: https://github.com/openstack/packstack/commit/3e2bb3d5c93625e57a1840077e895feb81dcf5ba#diff-ccb1620e56ce8c728797f3417f0c0b4f So is it not applied properly then ?
Just confirming that it's not applied properly, I let packstack run - then added the contents of glance_file.pp to glance.pp, ran packstack again and it applied the following config: Notice: Compiled catalog for test-packstack-mitaka.openstacklocal in environment production in 1.30 seconds Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false. (at /usr/share/ruby/vendor_ruby/puppet/type.rb:816:in `set_default') Notice: /Stage[main]/Glance::Backend::File/Glance_api_config[glance_store/default_store]/ensure: created Notice: /Stage[main]/Glance::Backend::File/Glance_api_config[glance_store/filesystem_store_datadir]/ensure: created Notice: /Stage[main]/Glance::Backend::File/Glance_cache_config[glance_store/filesystem_store_datadir]/ensure: created Notice: /Stage[main]/Glance::Db::Sync/Exec[glance-manage db_sync]: Triggered 'refresh' from 3 events Notice: /Stage[main]/Glance::Registry/Service[glance-registry]: Triggered 'refresh' from 1 events Notice: /Stage[main]/Glance::Api/Service[glance-api]: Triggered 'refresh' from 4 events Notice: Finished catalog run in 2.84 seconds
Tested with the current OPM master-patches and packstack master and installed succesfully. Anyway i'm creating a packstack patch for it to explictly apply the glance::backend::file class.
@Ivan, can you let me know exactly how you got a successful install ? I can reliably reproduce this every time and included a workaround for the test day: https://gist.github.com/dmsimard/9ba4e52de736adac2ca0#file-packstack-sh-L26-L29
just apply this patch: https://review.openstack.org/254431 hopefully we'll get it merged before the test day
s/hopefully// :)
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Looks like this was fixed and can be closed?