On Fri, Oct 23, 2009 at 1:52 AM, Michael Neale <michael.neale(a)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(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
>
--
Michael D Neale
home:
www.michaelneale.net
blog:
michaelneale.blogspot.com
_______________________________________________
deltacloud-devel mailing list
deltacloud-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/deltacloud-devel
--
-j