Hi All.
Looking at the instances, flavors etc methods in the drivers - if we are required to filter them if an :id or :architecture key is in the opts hash - then why not do that in the framework itself anyway? Would be less confusion? (I am sure I am missing something though...).
If makes sense, anyone object to adding it in?
On Fri, Oct 23, 2009 at 2:34 PM, Ivan Meredith ivan@ivan.net.nz wrote:
Hi all, I work at RimuHosting and am currently working on getting a deltacloud driver coded for our api. I'm pretty interested in this project so if I can find time I would like to contribute more than just our driver. I've done an inital commit that you can find at http://github.com/hadashi/deltacloud-driver-rimuhosting I've had the framework server up and running with what I've done. In the process of writing and testing the driver I noticed some weird things going on, like the framework interface showing the flavors correctly (http://localhost:3000/api/flavors) but then only showing the same plan when going to different actually flavors such as http://localhost:3000/api/flavors/MIRO3B was actually showing the EU2 flavor. After looking at the base driver I saw why.. def flavor(credentials, opts) flavors = flavors(credentials, opts) return flavors.first unless flavors.empty? nil end That will always return the first flavor. I overrode it in my driver to look like def flavor(credentials, opts=nil) flav = flavors(credentials, opts) flav.each { |x| return x if x.id == opts[:id] } nil end and it worked properly. My question really is, Is the flavor method just not implemented fully yet, or am I missing something :). And if its not implemented yet, I guess you would take patches? (I'm not sure if what I did was OK, this is my first attempt at ruby.) Regards, Ivan Meredith RimuHosting
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel@lists.fedorahosted.org