Bug 1161257
| Summary: | Is python-boto really still required? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Colin Walters <walters> | ||||
| Component: | cloud-init | Assignee: | Garrett Holmstrom <gholms> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | apevec, gholms, Jan.van.Eldik, mattdm, p, shardy, s | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | cloud-init-0.7.5-8.fc21 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-11-12 02:42:51 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
revno: 910 [merge] committer: Scott Moser <smoser> branch nick: trunk timestamp: Fri 2014-01-17 16:34:53 -0500 message: drop requirement on boto for its boto.utils.get_instance_metadata() We had a requirement on boto only to use boto.utils.get_instance_metadata(). That had actually caused some pain in the past. This removes a Requires and also one that wasn't python3. Created attachment 954599 [details]
Drop boto
Colin, what's the urgency of this? Should we try to get it in F21? (In reply to Matthew Miller from comment #3) > Colin, what's the urgency of this? Should we try to get it in F21? It causes Atomic F21 to pull in python3, not a showstopper. But a definite Would Be Nice. Oh hey, I see that it's pulling it in for the Cloud Base image too. We really should fix this. cloud-init-0.7.5-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/cloud-init-0.7.5-8.fc21 Package cloud-init-0.7.5-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cloud-init-0.7.5-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14597/cloud-init-0.7.5-8.fc21 then log in and leave karma (feedback). *** Bug 1161945 has been marked as a duplicate of this bug. *** cloud-init-0.7.5-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. |
git annotate says that the Requires: python-boto was introduced with 49078476, which is: commit 4907847669583e847b2249e5c140b12f008c01bc Author: Garrett Holmstrom <gholms> AuthorDate: Fri Sep 23 10:44:26 2011 -0700 Commit: Garrett Holmstrom <gholms> CommitDate: Sat Sep 24 15:59:01 2011 -0700 Initial build (0.6.2-0.1.bzr450) Now from what I can tell of the history, at one point cloud-init did depend on boto. But AFAICS, the current sources do not: $ grep -r boto . ./ChangeLog: - drop dependency on boto for crawling ec2 metadata service. ./ChangeLog: - for boto > 0.6.0 there was a lazy load of the metadata added, when ./ChangeLog: - have the cloudstack datasource test the url before calling into boto to ./ChangeLog: avoid the long wait for boto to finish retrying and finally fail when ./cloudinit/sources/__init__.py: # data that makes boto populate a string for 'klist' rather ./doc/examples/seed/README: python -c 'import boto.utils, yaml; print( ./doc/examples/seed/README: yaml.dump(boto.utils.get_instance_metadata()))' ./doc/examples/seed/meta-data:# python -c 'import boto.utils, yaml; print(yaml.dump(boto.utils.get_instance_metadata()))' ./doc/rtd/topics/datasources.rst:.. _boto: http://docs.pythonboto.org/en/latest/ (All examples or docs) Does it possibly call something in /usr/bin? Looks like no: $ for x in $(rpm -ql python-boto | grep /usr/bin | sed -e s,/usr/bin/,,); do grep -r $x .; done ./ChangeLog: - support setting of Acquire::HTTP::Proxy via 'apt_proxy' ./LICENSE:owned or controlled by the contributor, whether already acquired or ./LICENSE:hereafter acquired, that would be infringed by some manner, permitted ./cloudinit/config/cc_apt_configure.py:PROXY_TPL = "Acquire::HTTP::Proxy \"%s\";\n" ./cloudinit/config/cc_apt_configure.py: cfgs = (('apt_proxy', 'Acquire::HTTP::Proxy "%s";'), ./cloudinit/config/cc_apt_configure.py: ('apt_http_proxy', 'Acquire::HTTP::Proxy "%s";'), ./cloudinit/config/cc_apt_configure.py: ('apt_ftp_proxy', 'Acquire::FTP::Proxy "%s";'), ./cloudinit/config/cc_apt_configure.py: ('apt_https_proxy', 'Acquire::HTTPS::Proxy "%s";')) ./cloudinit/config/cc_apt_pipelining.py: 'Acquire::http::Pipeline-Depth "%s";\n') ./cloudinit/config/cc_apt_pipelining.py:# Acquire::http::Pipeline-Depth can be a value ./cloudinit/helpers.py: yield self._acquire(name, freq) ./cloudinit/helpers.py: def _acquire(self, name, freq): ./cloudinit/helpers.py: raise LockFailure("Failed to acquire lock for %s" % name) ./cloudinit/patcher.py: imp.acquire_lock() ./doc/examples/cloud-config-chef-oneiric.txt: Q8NqqR6pydprRFqWe47hsAN7BoYuhWqTtOLSBmnAnzTR5pURoqcquWYiiEavZixJ ./doc/examples/cloud-config-chef.txt: Q8NqqR6pydprRFqWe47hsAN7BoYuhWqTtOLSBmnAnzTR5pURoqcquWYiiEavZixJ ./doc/examples/cloud-config-disk-setup.txt:# are allowed and the actual device is acquired from the cloud datasource. ./doc/examples/cloud-config.txt:# apt_proxy (configure Acquire::HTTP::Proxy) ./doc/examples/cloud-config.txt:# These affect Acquire::FTP::Proxy and Acquire::HTTPS::Proxy respectively ./doc/examples/cloud-config.txt:# apt_pipelining (configure Acquire::http::Pipeline-Depth) ./tests/unittests/test_handler/test_handler_apt_configure.py: r"acquire::%s::proxy\s+[\"']%s[\"'];\n" % (ptype, value), ./tests/unittests/test_handler/test_handler_apt_configure.py: r"acquire::%s::proxy\s+[\"']%s[\"'];\n" % (ptype, value),