Hey, first of, sorry for three day delay - I had some health issues after eastern holiday and a bit of work for one of my midterm exams.
That said, comments inline below: On Apr 8, 2012, at 9:54 PM, Jed Smith wrote: > Good afternoon, > > I am the mentor responsible for the DBaaS API implementation in > libcloud. Thank you first for your submission to libcloud and Google > Summer of Code. I have some technical concerns with your > implementation of the DBaaS API that I hope we can work on. Of course, I'm looking forward to feedback, both now and later! While I did research on libcloud before GSOC and played a bit with it to see if I find it interesting, I never developed libcloud itself and naturally presumed that details of the implementation will be discussed and decided upon later on. :) Another thing to note: code sample I provided was just a bit of pseudo code I wrote off the top of my head, used more as a "sketch" of my idea of API in a more programmatic way than anything specific because I wasn't familiar with libcloud's internals at that point. > > First, we do not support pulling in an external dependency, such as > boto, as one of the primary purposes of libcloud is to avoid becoming > a "library of libraries". I use Amazon's API every day, and I realize > how difficult it can be to work with. However, we cannot implement > this with boto as a dependency. It would be much better if you > utilized libcloud's HTTP primitives as the remainder of the library > does. Do you feel confident this is implementable without depending on > boto? While I didn't know about the libcloud's "not becoming library of libraries" decision beforehand, I understand the argument. I'm not yet familiar with libcloud's HTTP primitives, but yes, we can use HTTP requests to do all of that. For creating databases, and continuing with AWS as an example, one could use https://rds.amazonaws.com/ ?Action=CreateDBInstance &DBInstanceIdentifier=SimCoProd01 &Engine=mysql &MasterUserPassword=Password01 &AllocatedStorage=10 &MasterUsername=master &Version=2012-01-15 &DBInstanceClass=db.m1.large &DBSubnetGroupName=dbSubnetgroup01 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2011-05-23T05%3A54%3A53.578Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature> For modifying, Action=ModifyInstance would be used, etc. I'll leave out the httplib call at this point. > > Second, I don't believe the time is right to limit libcloud to Python > 2.6, and I personally feel like that your usage of ABC is a bit > overkill for the case at hand. If you look at any of the other drivers > in libcloud, we do not use ABCs for this purpose, and the DBaaS API > would then be unique in libcloud and strange for other maintainers to > work with. Is this implementable without ABCs? I think there shouldn't be any problems if we don't use ABC - since ABC is not used already I would even say that its better to implement it without it to maintain code consistency and support for <2.6. I see no problem in using Drivers as are used in current form to allow abstraction. > > Third, in your proposal, I don't get the impression that you'd want to > become responsible for this code once GSoC is over. Specifically, this > section: > >> I envision that since more and more of my consulting work for other >> customers requires cloud development in one form or another I will >> slowly try to begin using libcloud instead of vendor-specific libraries >> and, if needed, try to implement more features that are missing from >> libcloud. > > If I read between the lines, here, it sounds like the question posed > to you, specifically, about maintenance of the code post-GSoC, isn't a > priority for you. Can you elaborate on this point? I'm not precisely sure what kind of commitment would the project like to see afterwards. While I would like to continue developing core API and drivers for the provider or two (or three) for which I will write the drivers I don't think I can (at least not in a near-term after GSOC) write drivers for very many other cloud providers and maintain them afterwards... At least I would not like to promise a commitment I can't keep. This is something you/other libcloud developers are much better judges at - is writing another driver entirely starting from ground up work or is it more in the line of adjusting a few HTTP calls (personally I suspect somewhere in the middle?). I specifically tried to find a project that is at least remotely connected with my other (as in, not GSOC) work so that I can continue using (eating my own dog food) and developing it after GSOC. One way I can see myself developing drivers for other providers is through advocating usage of abstraction layer (libcloud) instead of lock-in to single provider when a company uses other provider than the ones already developed (though most companies used AWS). Hope this explains it a bit better? Don't hesitate to ask some more :) At this point I would also like to ask a question - since developing cloud library by definition means you need to run your code and tests in the cloud I can imagine this can get a bit expensive at some point. Do various providers give out developer accounts for such projects as are libcloud or boto or any other library out there? > > Have you used libcloud in the past? If not, I encourage you to do so > and study its code to see how the rest of the project is built. I haven't, with the exception of tinkering with its AWS part before I wrote application. Yes, that is intended course of action :) Cheers, Urban > > -- > Jed Smith > [email protected]
