Currently if you wish to leverage any of the Openstack Ansible modules http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack You need to have the python-shade library installed. With more and more parts of Red Hat using Ansible, and those parts wanting to be able to leverage these modules for integration with our RHOS product, we need to have this library shipped both upstream (in RDO?) and downstream (in RHOS?). It doesn't necessarily have to be shipped by the RHOS team, but considering it is an Openstack project, that seems most likely. This helps us sell the story of using Red Hat Ansible for Managing Openstack clouds (and does not interfere or diminish our story around TripleO, these modules are more useful for seeding your overcloud with data once it's been deployed). Fedora Package review for python-shade https://www.google.com/url?q=https://bugzilla.redhat.com/show_bug.cgi?id%3D1271768&sa=D&ust=1495395586005000&usg=AFQjCNFiXDXl1k1Qt2OynYb0Jk76WxfieQ
For reference, previous discussion on rdo-list: https://www.redhat.com/archives/rdo-list/2016-August/msg00213.html https://www.redhat.com/archives/rdo-list/2016-November/msg00045.html
Note: OpenShiftOnOpenStack is also very interested in this being included.
(In reply to Mike Burns from comment #14) > Note: OpenShiftOnOpenStack is also very interested in this being included. There is a bit of a spanner in the works here though, in that for the OpenShift deployment effort there will be a need to have python-shade (and its dependencies) on an OpenShift node that is not OpenStack entitled. This could potentially be resolved by cross shipping python-shade in OCP, but right now it still has dependencies on the client libraries. An alternative might be to ship it alongside the clients in the RHEL child channel where they are made available (in addition to the RHOSP channels) as it is similar in terms of the way it is used - that is it is used by consumers of an OpenStack cloud from remote machines that may or may not have a RHOSP subscription.
(In reply to Stephen Gordon from comment #15) > This could potentially be resolved by cross shipping python-shade in OCP, > but right now it still has dependencies on the client libraries. An > alternative might be to ship it alongside the clients in the RHEL child > channel where they are made available (in addition to the RHOSP channels) as > it is similar in terms of the way it is used - that is it is used by > consumers of an OpenStack cloud from remote machines that may or may not > have a RHOSP subscription. There is an existing effort to remove those dependencies. We should make that high priority for the next release.
There are now limited client libraries still needed for python-shade, but work needs done in RDO to make sure it has right set of BuildRequires/Requires and that it installs and functions as expected when packaged. https://github.com/openstack-infra/shade/blob/master/requirements.txt https://review.rdoproject.org/r/#/c/9012/
Initial builds in
We've gotten rid of all of the python-*client depends in shade now, so it should be good to sync with all the places. Is there anything I can do to help?
(In reply to Monty Taylor from comment #34) > We've gotten rid of all of the python-*client depends in shade now, so it > should be good to sync with all the places. Is there anything I can do to > help? we should get the rdo/rpm-master .spec file updated to match now that they are all removed in queens cycle.
proposed patch to enable check section of .spec and update Req's/BR in RDO will need to get review and get those patches landed soon
Hello, it would be really good to get this shipped with OSP 13 at least but ideally OSP 10 onwards to make working with Ansible inventories and OpenStack a load easier (for my use case). Any news on this?
a version of python-shade was released as part of RC see channels, unknown on testing status.
python-shade is being exercised every time we deploy OpenShift on OpenStack. Not every bit of shade functionality is tested that way and I'm not aware of any test plans for shade, but it should be a good smoke test at least.
According to our records, this should be resolved by python-shade-1.27.1-1.el7ost. This build is available now.
Dropping FutureFeature as it's a required bit for Container Images.
Verified in RHOS-13 2018-05-23.1 puddle, which ships python2-shade-1.27.1-1. $ sudo rpm -i http://rhos-release.virt.bos.redhat.com/repos/rhos-release/rhos-release-latest.noarch.rpm $ sudo rhos-release 13 -P -p 2018-05-23.1 Installed: /etc/yum.repos.d/rhos-release-rhel-7.5.repo Installed: /etc/yum.repos.d/rhos-release-ceph-3.repo Installed: /etc/yum.repos.d/rhos-release-ceph-osd-3.repo Installed: /etc/yum.repos.d/rhos-release-13.repo # rhos-release 13 -p 2018-05-23.1 $ sudo yum list python2-shade Loaded plugins: search-disabled-repos Installed Packages python2-shade.noarch 1.27.1-1.el7ost @rhelosp-13.0-puddle [rhelosp-13.0-puddle] name=RHOS-13.0 # puddle_baseurl=http://download.lab.bos.redhat.com/rcm-guest/puddles/OpenStack/13.0-RHEL-7/2018-05-23.1/RH7-RHOS-13.0/$basearch/os baseurl=http://download.lab.bos.redhat.com/rcm-guest/puddles/OpenStack/13.0-RHEL-7/2018-05-23.1/RH7-RHOS-13.0/$basearch/os gpgcheck=0 enabled=1 The same python2-shade version is shipped in the RHOS GA release (2018-06-21.2 puddle) [1] [1] http://download-node-02.eng.bos.redhat.com/rcm-guest/puddles/OpenStack/13.0-RHEL-7/GA/RH7-RHOS-13.0/x86_64/os/Packages/python2-shade-1.27.1-1.el7ost.noarch.rpm