Hi Adrian, Thanks for taking a look at Whirr and compiling this list! I agree with most of the points, the only one that may be tricky is 5, since I think Hadoop may be relying on the reverse-lookup capabilities of InetAddress. However, it would be good to clean this up if possible. Does jclouds have tests that run on GAE?
+1 to creating JIRAs on these. Cheers, Tom On Tue, Jul 20, 2010 at 12:14 AM, Adrian Cole <[email protected]> wrote: > Hi, team. > > I submitted a patch to update whirr to jclouds 1.0-beta-6 [1]. This is a > stable release. > > I have some initial feedback, and cool helping out with it, too: > > 1. Dependencies seems to be aws-centric. jclouds-aws shouldn't be a > mandatory dependency. In fact, it is probably better to add the known > working jclouds provider artifacts as optional and only in the core module. > In the near future, jclouds will include an composite artifact called > jclouds-allcompute (or something) which would have optional deps on all > working compute providers. [2] > > 2. Not all compute providers have ubuntu. I suggest that for starters, we > do not specify ubuntu and make sure that the installers work on at least > ubuntu or centos. AFAICT, this shouldn't be a problem, as jclouds already > tests installation of java during its integration tests. > > 3. In jclouds we've switched to consistently use "provider", "identity", > and "credential" everywhere. It would be nice to switch whirr to this > convention while it is young as it will help connect the code concepts > together. > > 4. Integration tests that connect remotely are running by default. This > should be stopped and switched to stub by default and live by profile. > > 5. It would be best for us to switch off using InetAddress as it makes whirr > incompatible in google-appengine, which is a useful feature. Strings are > generally ok, and if you need to check if the item is a hostname or not, > there are classes available to help [3]. > > 6. The ComputeService object is thread-safe, and better off shared inside > the Service object. Regardless, it must be closed in order to release > threadpools. > > > I think this is enough for now. I can submit create JIRAs and submit > patches on all of the above, if you are ok with them. > > Cheers, > -Adrian > > [1] https://issues.apache.org/jira/secure/attachment/12449899/WHIRR-23.patch > [2] http://code.google.com/p/jclouds/issues/detail?id=317 > [3] > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/net/InternetDomainName.html >
