Here are some comments for your patch: - Imo, if we decide to create a new API it should be called networking, not network
- Network class currently has an 'address' attribute. This doesn't seem flexible enough for a standard library. It should probably have public_ips and private_ips attributes which are both lists. - What is size attribute doing on a Network object? - get_uuid used the way it currently is used in the networking API is pretty much useless. In the compute API we build a Node UUID, by running SHA1 on the node id and a driver type. We should either do something like this in the networking API or get rid of this method all together. Even better, we should just put it in a base NodeDriver class and do something like SHA(id + api_name + provider). iirc all the classes should have id and a provider attribute. - list and destroy methods look OK, but we should think (and research) more about which arguments create method should take so it is possible to make it work with multiple providers. Some other things we still need to decide / think about them: - Virtual networking APIs are usually pretty coupled with compute ones. Should it be a separate API (libcloud.networking.*) or should it live in the compute one (libcloud.compute.networking.*)? - Virtual networking APIs usually also provide some kind of access to a firewall. How do we plan to integrate this into it? - I do think we should start simple (method for listing, creating and deleting), but we should also make it flexible enough so it won't limit or prevent us from adding more things in the future. Starting simple also means we should be able to support multiple providers from the beginning. Thanks, Tomaz On Wed, Nov 9, 2011 at 6:42 AM, Hutson Betts <[email protected]> wrote: > I was wondering if someone could take a look at the following attached > patch. It's a new component to the Libcloud library to support virtual > network drivers. > > I added a driver for OpenNebula, covering versions 1.4 through to the > present version of OpenNebula. > Furthermore, I added additional test classes for testing the new driver. > > My next step is to test in a mockup of my cloud computing production > environment. > > -- > Hutson Betts > Computer Science and Engineering > Texas A&M University > >
