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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/deltacloud-devel