Dear Tomaž, Actually, ipcalc.Network seems like a fantastic drop-in replacement for networking.base.Network. It provides all the functionality I mentioned in the previous e-mail, plus IPv6 support, and doctests.
Furthermore, we can stay with the VPCNetwork (Amazon's Virtual Private
CLoud) idea, sub-classing ipcalc.Network and adding functionality for a
list of sub-networks, of type ipcalc.Network, the ability to create
sub-networks (we could use the __contains__ functionality of the base
class to validate subnet addresses.), and then to retrieve a list of
sub-networks.
However, I wouldn't be quite sure how to handle create_node taking a
list of Network objects. For OpenNebula, and potentially others, we
would need a class that contains an IP address and Network ID as
properties.
Therefore, would a special class, say NetworkInterface, be required with
the following properties:
ID of type C{string}
IP of type L{ipcalc.IP}
In networking.base, we could have:
Network(ipcalc.Network):
def NetworkInterface create_interface(IP)
# verify IP falls within subnet.
NetworkInterface():
ID
IP
In networking.drivers.ec2, we could have:
VPCNetwork(ipcalc.Network):
sub_networks = []
def bool create_sub_network(ipcalc.Network)
def [Network]s list_sub_networks():
return sub_networks
In compute.drivers.opennebula, we could have:
def [Network]s ex_list_networks():
return [Network]s
>>> networks = ex_list_networks()
>>> networkInterface =
networks[0].create_interface(ip=IP('192.168.0.5'))
>>> create_node(..., interfaces=[networkInterface])
I went a little overboard, but once you mentioned ipcalc it seemed to be
an excellent choice for handling network descriptions. However, as you
mentioned, the issue with regard to a library dependency could be
problematic.
Worst case, we just roll each ipcalc update into libcloud.
If the above suggestion, or inclusion of ipcalc would seem to be too
much, we can go with the other approach. Implementing those functions
mentioned in the previous e-mail shouldn't be too much trouble.
--
Hutson Betts
Computer Science and Engineering
Texas A&M University
On Sun, 2011-11-13 at 21:11 +0100, Tomaž Muraus wrote:
> On Sun, Nov 13, 2011 at 7:44 PM, Hutson Betts <[email protected]> wrote:
>
> > Dear Tomaž
> >
> >
> > >
> > > > If there is a term that could better describe that property, please let
> > > > me know. Even a netmask, or address class property in place of Size
> > would
> > > > work.
> > > > I would only need to implement methods to convert between the general
> > > > property and the property used by the cloud provider.
> > > >
> > >
> > > OK, this makes more sense now. Hmm, I can't decide if we should just
> > > combine address + size variable and allow user to pass in an address in
> > > CIDR notation.
> >
> > Instantiating a CIDR-derived Network may be a better approach than
> > using "address" and "size" as parameters for creating a Network.
> > Specifying the network in terms of CIDR avoids semantic confusion on
> > what an address, or size imply (As we've already discovered between us.).
> >
> > However, if we create a network in the following manner:
> > network = Network('192.168.0.0/24')
> >
> > I would request methods for extracting its properties, such as:
> > network.subnet()
> > network.netmask()
> > network.standard_non_broadcast_ips()
> > network.standard_broadcast_ip()
> > ...
> >
> > That way, in the OpenNebula driver, or other drivers which approach
> > networks in the same way, we can get the 'address' and 'size' using
> > well understood vocabulary.
> > >>> address = network.subnet()
> > >>> size = len(network.standard_non_broadcast_ips())
> >
>
> Yeah, adding those methods to the base Network class should be relatively
> easy, right? If needed we could also add an optional dependency for ipcalc
> or a similar library (if possible, we should try to avoid adding
> unnecessary dependencies though).
>
>
> >
> > Furthermore, for Amazon which allows for a network to be further
> > sub-divided into subnets, Amazon's virtual private cloud networking driver
> > (When ever it's
> > created), could subclass the Network class, and return NONE for the
> > other public functions.
> > >>> network = VPCNetwork('192.168.0.0/16')
> > >>> network.subnet()
> > None
> >
> > Furthermore, it could then support an additional public function for
> > breaking the network into parts by taking a Network as input: >>>
> > network.create_sub_network(Network('192.168.0.0/24'))
> >
> > And a list of networks within the virtual private cloud could be returned:
> > >>> network.vpc_networks()
> > [<Network: ...>, <Network: ...>]
> >
> > Just some ideas.
> >
> > --
> > Hutson Betts
> > Computer Science and Engineering
> > Texas A&M University
> >
> >
> >
> >
signature.asc
Description: This is a digitally signed message part
