Hi John, Thanks for your guidance. I am new to Libcloud, and would appreciate the code reviews. I agree with you; I think that building a core driver for VCC is a sensible course of action.
To get started with the driver, is there a specific list of files I need to modify from the Git repos? So far, I have noted the following for editing: (essentially, just adding the VCC names) Libcloud.compute.providers.py Libcloud.compute.types.py To get started with the Verizon Cloud Compute driver I plan to create: Libcloud.common.verizon.py (provides authentication headers and handles requests) Libcloud.compute.drivers.vcc.py (driver for VCC; resource management on cloud resources) Libcloud.test.copmute.test_vcc.py (test cases and runs on vcc.py functions) I am completely new to Libcloud, so if I am missing essential modifications or necessary files, please let me know. I am doing my best to follow coding conventions and Libcloud standards, but if anything I am doing seems weird, please shoot me a message. Thanks, Michael Kaldawi On 7/21/14, 5:48 PM, "John Carr" <[email protected]> wrote: >Hi Michael, > >As a developer and end user I personally prefer providers that are >'upstream’. > >Carlos has made the right choice with libcloud-vagrant. I’d love to see >something like that in core when it is ready, but getting the semantics >right will be trickier than a normal cloud driver so it makes sense to >let it mature externally. > >For a straight http based cloud compute driver i’d expect it to make more >sense to aim to go straight upstream. In particular, if you are new to >libcloud the code review will be very valuable. And by being a core >driver your tests will be run and be expected to pass before releases are >made. So a new libcloud release is far less likely to break VCC support >if its in core than if it was packaged seperately. > >Cheers, >John > >On 21 Jul 2014, at 21:50, Kaldawi, Michael <[email protected]> >wrote: > >> Carlos, >> >> Thanks a bunch for your very complete response and quick turnaround >>time. >> Your answers are very helpful, and they will help me create a model for >> the VCC (Verizon Cloud Compute) driver. >> >> I will continue to ask questions on this email list as I analyze current >> Libcloud drivers and develop my own. I greatly appreciate any >>assistance. >> >> Thanks again Carlos, >> Michael Kaldawi >> >> >> On 7/21/14, 3:30 PM, "Carlos Valiente" <[email protected]> wrote: >> >>> Hi, Michael! >>> >>>> 1. Why is your libcloud-vagrant driver not in the Libcloud repo? >>> >>> Mainly because I don't know whether the Libcloud guys (or anyone else) >>> might be interested at all in libcloud-vagrant, so I started working >>> on it under my personal Github account. >>> >>> I'm using libcloud-vagrant at work, and I need to update it frequently >>> (I have just released version 0.2.0, for instance, since the >>> deployment support in the initial release was badly broken). The >>> release process of Apache Libcloud is much slower (understandably), so >>> it would not be a good choice for me until libcloud-vagrant >>> stabilizes. >>> >>>> Is it common practice to release the first version outside of the >>>> libcloud repo? >>> >>> I'm not sure about that --- someone else in this list will definitely >>> be able to answer! >>> >>>> Did you follow the libcloud coding standards? >>> >>> I tried to, yes --- they're very sensible: PEP 8, common idioms ... so >>> it's for your own benefit to follow them. >>> >>>> 2. Will you be listed as a ³Third Party Provider² on the Libcloud >>>> developers page? >>> >>> I should ask for that, yes. >>> >>>> 3. Are there any things you wish you knew when you started writing the >>>> driver that you now know? >>> >>> I would have tried to run my first scripts using both my Vagrant >>> provider and another one, to make sure I got the sematics write (which >>> I'm sure I haven't, since I did not check). Having an exhaustive test >>> suite with about 90% coverage has been very helpful, too. >>> >>> C >> >
