Yeah, there already was some debate about virtual networks on the mailing list, but we never came to a concrete conclusion what to do with it.
One of the ideas was also to include a special API for networking (libcloud.networking.*) which would be pretty coupled with the compute one and have a bunch of methods which take Node object as an argument.
Some things I have noticed in your patch:
- shouldn't IP address be stored on the NodeNetwork object, not in the extra dictionary? Maybe this attribute should also be a list? (requires more exploration about the existing provider APIs)
- is there any special reason why you changed the _new_ signature in OpenStack driver? Before the change it was "backward" compatible and it could be used with args, not it can only be used with kwargs.
- _fixxpath, _findall - those two methods are already in libcloud.utils, lets re-use them
- there are some style changes in the same patch which makes it harder to review. Next time it would be nice if the style changes would be in a separate patch (yes, I know that's easier said that done with SVN )
- I see some pep8 violations just by looking at the patch (mostly line lengths)
Other things to keep in mind:
- In a lot of cases, virtual networks won't be returned in the same request as the Node objects which means we might need to preform an extra HTTP request.
I would be ok with one extra HTTP request in list_nodes, but if it would result in N extra requests in some drivers we might need to rethink the concept or include some kind of retry mechanism in the core.
The problem is that most of the APIs I have worked with so far aren't really reliable which means if list_nodes() would result in (1 + N) HTTP requests and we would throw on the first error it would rarely succeed (N = number of nodes).
IIRC some other ppl (including some ppl from Rackspace) were already looking at the possibility to add support for virtual networks to the Libcloud. I will appoint them to this ticket so you can all collaborate on a solution.
It would also make it easier if we split this ticket into multiple ones:
- Unified support for virtual networks
- OpenStack cleanup
- OpenNebula cleanup and improvements
In any case, like you have said this patch would require exploring "virtual network" concept for more providers and of course a lot of unit tests