[
https://issues.apache.org/jira/browse/LIBCLOUD-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133339#comment-13133339
]
Tomaz Muraus commented on LIBCLOUD-121:
---------------------------------------
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 :)
> OpenNebula Driver Improvements and Additional Driver Updates
> ------------------------------------------------------------
>
> Key: LIBCLOUD-121
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-121
> Project: Libcloud
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.6.0
> Environment: Latest Libcloud trunk with contents of diff operating on
> Debian 6.0 (Stable).
> Reporter: Hutson Betts
> Priority: Minor
> Labels: api-change, patch
> Attachments: update.diff
>
>
> I'm attaching a diff/patch that contains modifications to several compute
> drivers; OpenNebula in particular.
> With regard to OpenNebula, these changes include the ability to request a
> list of virtual networks provided by the OpenNebula infrastructure provider.
> Furthermore, the OpenNebula NodeDriver has been extended to extract the disk
> and network descriptions from the compute XML description. Disks and networks
> are instantiated as NodeImage and NodeNetwork objects and then attached to a
> newly instantiated Node. To support this capability, I added a NodeNetwork
> class to the base compute class.
> Furthermore, I modified the Opsource and OpenStack drivers to match in
> consistency with the OpenNebula driver. This also included changes to include
> httplib. I hope to extend that work later to other drivers, if the work is
> desired.
> This patch really requires additional, more in-depth testing, during this
> following week, but I wanted to present that patch for consideration, and
> comments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
