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
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).
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).
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
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
yes - I realised after I sent it that allowing the flavours methods etc... to do the filtering allows for better scaling (imagine having 10000 instances, ideally you want the pass to the cloud provider a query to get the matches !).
On the other note - yes having > 1 driver running at a time would be a good idea, I don't think it would be too hard to do.
On Sat, Oct 24, 2009 at 7:53 AM, Jason Guiditta jason.guiditta@gmail.com wrote:
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
--
-j
On Thu, Oct 22, 2009 at 11: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
Ivan, thanks for the effort to get this driver together. As Michael said, the issue is that your flavors method as implemented does not call filter_on. I would amend his snippet to add as the last line of your flavors(): filter_on(res, :id, opts) It need not be assigned to a variable here, as all you want to do is return the collection, which filter_on does for you. Also, you shouldn't even need the flavor method, as that is generic and defined in base_driver. Once you have the filtering right, it should just work. Kind of hard to ack as I do not have a rimu account (is there some sort of free developer signup we could use?), though I otherwise agree with Michael's comments. Also, for it to work (and you may have done this in your local version), framework's environment.rb file needs to be updated with something like:
diff --git a/config/environment.rb b/config/environment.rb index eab79e2..560dc2f 100644 --- a/config/environment.rb +++ b/config/environment.rb @@ -51,8 +51,9 @@ Rails::Initializer.run do |config| end
#DEFAULT_DRIVER=:ec2 -DEFAULT_DRIVER=:mock +#DEFAULT_DRIVER=:mock #DEFAULT_DRIVER=:rhevm +DEFAULT_DRIVER=:rimuhosting
unless defined?( DRIVER ) @@ -81,4 +82,6 @@ case DRIVER DRIVER_CLASS_NAME = "Ec2Driver" when :rhevm DRIVER_CLASS_NAME = "RHEVMDriver" + when :rimuhosting + DRIVER_CLASS_NAME = "RimuHostingDriver" end
deltacloud-devel@lists.fedorahosted.org
-
Ivan Meredith -
jason.guiditta -
Michael Neale