| Summary: | match provider names between image factory and deltacloud | |||
|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> | |
| Component: | aeolus-conductor | Assignee: | Richard Su <rwsu> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Shveta <ssachdev> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 0.3.1 | CC: | dajohnso, deltacloud-maint, imcleod, markmc, morazi, rwsu, ssachdev | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 715601 (view as bug list) | Environment: | ||
| Last Closed: | Type: | --- | ||
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 715601 | |||
|
Description
wes hayutin
2011-06-21 20:05:01 UTC
Ian, we want to standardize on rhevm. Can you make the change to imagefactory? I can do the same in conductor. Richard, Just to clarify the entity being discussed here is the target name (aka cloud type) _not_ the provider name. Provider names map to the specific instances of a particular cloud type/target (for example, the regions within EC2 or specific RHEV-M instances within a private cloud). In any case, I will add code to this sprint that will map vsphere to vmware and rhevm to rhev-m internally. (Or perhaps the other way around). I now map "rhevm" to "rhev-m" and "vsphere" to "vmware" internally in the Factory. Either reference will continue to work. This is pushed and available as the 0.2.3 interim release here: http://repos.fedorapeople.org/repos/aeolus/image-factory/0.2.3/ This doesn't give us a complete solution because the rhev-m and vmware names continue to appear in IWHD and Conductor etc. I've posted image_factory and conductor patches to switch completely over to deltacloud driver names: https://fedorahosted.org/pipermail/aeolus-devel/2011-July/002899.html Leaving in ON_QA for now until those changes have been discussed Changes for conductor and configure have been pushed. RPMS are being rebuilt and is scheduled to be pushed to fedorapeople tomorrow. Thanks Richard. This is the image_factory commit: https://github.com/aeolusproject/image_factory/commit/658730b259d2dc8465814024a95b22d7810fca64 Moving back to MODIFIED until the build is available to QE Fixed on: aeolus-conductor-0.3.0-0.fc14.20110707174454gita8e98af.noarch.rpm aeolus-configure-2.0.1-0.fc14.20110706084705git542b456.noarch.rpm removing from tracker Its still different for vmware ./bin/deltacloudd -i vmware -r 10.65.201.233 -p 3001 Starting Deltacloud API :: vmware :: http://10.65.201.233:3001/api ERROR: no such file to load -- deltacloud/drivers/vmware/vmware_driver.rb [root@snowstorm server]# ./bin/deltacloudd -i vsphere -r 10.65.201.233 -p 3001 Starting Deltacloud API :: vsphere :: http://10.65.201.233:3001/api >> Thin web server (v1.2.5 codename This Is Not A Web Server) >> Debugging ON >> Maximum connections set to 1024 >> Listening on 10.65.201.233:3001, CTRL+C to stop (In reply to comment #9) > Its still different for vmware > > ./bin/deltacloudd -i vmware -r 10.65.201.233 -p 3001 > Starting Deltacloud API :: vmware :: http://10.65.201.233:3001/api > > ERROR: no such file to load -- deltacloud/drivers/vmware/vmware_driver.rb > [root@snowstorm server]# ./bin/deltacloudd -i vsphere -r 10.65.201.233 -p 3001 > Starting Deltacloud API :: vsphere :: http://10.65.201.233:3001/api vsphere is now the provider type codename used by conductor, image factory and deltacloud You shouldn't see the "vmware" name used anywhere Mark, did I see in the patch that vsphere is the codename but will alias vmware to vsphere. Which would be a good thing, just making sure I saw that correctly. Thanks Wes , i tried pushing vmware image with aeolus-image it does'nt work with vsphere and works with vmare So i think its still different. Is that what you meant in the bug ? ================================================================ [root@snowstorm ~]#aeolus-image push --provider vsphere --id c794e7d6-b167-45b7-894c-8877bd284e9b /usr/lib/ruby/gems/1.8/gems/aeolus-cli-0.0.1/lib/push_command.rb:21:in `run': undefined method `each' for #<Qmf2::QmfAgentException:0x7f19870ec7f0> (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/aeolus-cli-0.0.1/lib/config_parser.rb:199:in `push' from /usr/lib/ruby/gems/1.8/gems/aeolus-cli-0.0.1/lib/config_parser.rb:30:in `send' from /usr/lib/ruby/gems/1.8/gems/aeolus-cli-0.0.1/lib/config_parser.rb:30:in `process' from /usr/lib/ruby/gems/1.8/gems/aeolus-cli-0.0.1/bin/aeolus-image:6 from /usr/bin/aeolus-image:19:in `load' from /usr/bin/aeolus-image:19 2011-07-14 11:21:56 warning Connection [56850 localhost:5672] closed [root@snowstorm ~]# aeolus-image push --provider vmware --id c794e7d6-b167-45b7-894c-8877bd284e9b Provider Image: 1447ac95-42ab-4af1-a0ce-a57a0f4b4c86 Image: c794e7d6-b167-45b7-894c-8877bd284e9b Build: a4f27c74-486b-459b-bc8d-6073580214a1 Status: PUSHING Percent Complete: 0 2011-07-18 18:46:38,456 DEBUG imagefactory.builders.BaseBuilder.RHEL6Builder pid(8780) Message: Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/imagefactory/builders/FedoraBuilder.py", line 129, in build_image
raise ImageFactoryException("Invalid build target (%s) passed to build_image()" % (self.target))
ImageFactoryException: Invalid build target (vmware) passed to build_image()
building targets resolve to vsphere not vmware now..
According to Mark McLoughlin thats the correct behavior.
deltacloud can handle either vmware or vsphere..
[root@hp-ml150g6-01 ~]# API_PROVIDER=vsphere.virt.lab.eng.bos.redhat.com deltacloudd -i vsphere -t 900 -r hp-ml150g6-01.rhts.eng.bos.redhat.com -p 3006 -e production
Starting Deltacloud API :: vsphere :: vsphere.virt.lab.eng.bos.redhat.com :: http://hp-ml150g6-01.rhts.eng.bos.redhat.com:3006/api
>> Thin web server (v1.2.5 codename This Is Not A Web Server)
>> Debugging ON
>> Maximum connections set to 1024
>> Listening on hp-ml150g6-01.rhts.eng.bos.redhat.com:3006, CTRL+C to stop
10.16.66.140 - - [18/Jul/2011 18:40:37] "GET /api HTTP/1.1" 200 934 0.5425
10.16.66.140 - - [18/Jul/2011 18:40:37] "GET /api HTTP/1.1" 200 934 0.0098
10.16.66.140 - - [18/Jul/2011 18:40:38] "GET /api HTTP/1.1" 200 934 0.0093
10.16.66.140 - - [18/Jul/2011 18:40:38] "GET /api/hardware_profiles HTTP/1.1" 200 1818 0.0184
10.16.66.140 - - [18/Jul/2011 18:41:22] "GET /api HTTP/1.1" 200 934 0.0151
10.16.66.140 - - [18/Jul/2011 18:41:23] "GET /api?force_auth=1 HTTP/1.1" 200 934 0.3568
10.16.66.140 - - [18/Jul/2011 18:41:23] "GET /api HTTP/1.1" 200 934 0.0097
10.16.66.140 - - [18/Jul/2011 18:41:23] "GET /api HTTP/1.1" 200 934 0.0088
10.16.66.140 - - [18/Jul/2011 18:41:23] "GET /api/realms HTTP/1.1" 200 842 0.4680
^C>> Stopping ...
[root@hp-ml150g6-01 ~]# API_PROVIDER=vsphere.virt.lab.eng.bos.redhat.com deltacloudd -i vmware -t 900 -r hp-ml150g6-01.rhts.eng.bos.redhat.com -p 3006 -e production
Starting Deltacloud API :: vmware :: vsphere.virt.lab.eng.bos.redhat.com :: http://hp-ml150g6-01.rhts.eng.bos.redhat.com:3006/api
>> Thin web server (v1.2.5 codename This Is Not A Web Server)
>> Debugging ON
>> Maximum connections set to 1024
>> Listening on hp-ml150g6-01.rhts.eng.bos.redhat.com:3006, CTRL+C to stop
release pending... release pending... perm close closing out old bugs |