[
https://issues.apache.org/jira/browse/LIBCLOUD-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133445#comment-13133445
]
Hutson Betts commented on LIBCLOUD-121:
---------------------------------------
My next step was to begin looking at (libcloud.networking.*) and see how that
capability can be supported.
- Storing IP as a member of NodeNetwork rather than a member of the dictionary
was a temporary decision so that I could avoid a permanent decision at this
time. See, in OpenNebula, when requesting the XML description of a network,
such as /network/[ID], the ID, and name are returned in addition to the network
address and network size (which combined is equivalent to CIDR notation).
However, the network description returned as part of the node description gives
the ID and name, and the IP assigned to the node. Therefore, only the ID and
name are consistent between those two representations of a network. In regard
to IPs, I would consider a list more appropriate since I see no reason a node
couldn't have more than one IP address on a single network.
- Chaning __new__ would be a result of my somewhat extreme programming
mentality as I saw a difference between OpenStack and the other drivers. I'll
revert my change and update the patches. Thank you for catching my mistake.
- I didn't realize _fixxpath and _fixall where in libcloud.utils. I'll go ahead
and modify OpenStack to use utils and include that in my updated patch.
- Another consequence of my more extreme programming mentality. However, I can
at least split the Opsource and OpenStack style diffs into separate files for
review. It'll just be difficult to break down the work in a more granular
manner simply because I did all my work in unison on the same branch. On
another note, I use bazaar for my VCS so I'll see what other features it gives
me in this regard.
- There shouldn't be any, or at least very few, PEP8 violations in the
OpenNebula file after inclusion of the patch. I ran PEP8 over the result of
that file only, and resolved a few issues but pep8 kept crashing on me. It's
possible there are pep8 violations in the Opsource and OpenStack drivers that I
didn't notice, and didn't catch since I didn't run pep8 on those, and could
correct in another patch.
- If I were to request all information on each virtual network for a node, it
could lead to N requests as you mentioned. That's why I'm relying on the
information already provided within the node description for the special case
of OpenNebula.
I'll create a ticket associated with OpenStack/Opsource cleanup, and a ticket
for OpenNebula cleanup and improvements.
- Should I include the NodeNetwork addition as part of the OpenNebula patch, or
as part of a greater "Unified Networking" ticket?
> 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
