On Fri, Oct 23, 2009 at 1:52 AM, Michael Neale michael.neale@gmail.com wrote:
Hi Ivan - that is great to hear ! Will be nice to have RimuHosting...
So on that snippet of code, you will note it calls the flavors() method of the driver, and passes in the opts for filtering... It then returns the first one if 1 is returned (and hopefully only 1 !).
So in your flavors driver method - if you use something like:
res = filter_on( res, :id, opts ) at the end... then it will use the build in filter method to only return the one that the flavor() method wants. Note that this applies to all the collection methods it seems - need to use the filter method I think.
It seems a bit odd to me, but if you like at the ec2 or rackspace drivers you can see how that works (Bob or someone else want to comment why it is like that).
Maybe I am misunderstanding the question, but the idea was just to have a generic collection filtering mechanism, though I think the implementation could use a bit of cleaning up. For instance, I think it would be nicer if you could pass in a hash of things to filter on, like in active record, then flavors could just be in base_driver, there is a little too much repetition there atm for my taste. Custom stuff like Ivan's Flavor-building list could then just be injected/mixed into the base method.
If you can sort that out, plus add in some realms method (you can just return a single Realm if you like, just representing something about where the data centre is, or where they are, if relevant, just anything !) then that would be nice. And I think we could then put it into the main repo (and I can update the website content/doco probably).
I think we should also reconsider this '1 repo per driver' setup we have right now, it is not going to scale well. Perhaps instead, we should have a driver repo, with subdirs for each impl?
Let me know if that makes a bit more sense?
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
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel