Re: Network API Models - RFC

[Jan Provazník <jp...@redhat.com>]

On 01/21/2013 05:57 PM, marios@redhat.com wrote:
> [patches also available from http://tracker.deltacloud.org/set/263]
>
> Initial implementation for networks - in particular seeking feedback
> with respect to models and how they 'sit' for vsphere/rhevm (I've taken
> CIMI, EC2 VPC and Openstack into consideration already). Initial
> implementation of 'networks' collection for EC2 driver (create, list, show
> and destroy VPC).
>
> marios
>

Hi,
overall, the models in this patchset look reasonable to me. After 
discussing this topic with Heat/PM and some other people, here are my 
findings:

1) There are 2 levels of networking support we would like to have:
   a) be able to specify an existing network (or subnet?) when
      launching an instance
   b) be able to dynamically create whole network/subnets or firewall
      rules when launching a deployment (cloud formation)

2) For RHEV it is currently not possible to achieve 1b. Network creation 
is admin task. Nice description is here [1]. Good news is that RHEV will 
probably support Quantum networking in future, currently there is POC 
where Quantum network can be used as an external network in ovirt [2] 
(note that dynamic network creation is not possible in this POC too). 
Will do more investigation about Quantum plans tomorrow.

Mapping RHEV networking entities to entities in Marios' proposal is a 
challenge. A user can just create VM's NICs for which she specifies 
network [3].
Network model reflects RHEV Network.
Subnet is not used in RHEV, some related info (netmask, ip range) might 
be fetched from host's NIC entity.
Port is not used in RHEV, most similar entity is VM's virtual NIC (which 
is associated with a virtual machine though).

When creating RHEV virtual machine, you specify network by creating 
virtual NIC for the machine in separate request. Also you can manage
interfaces for virtual machine.
I wonder if it makes sense to add another entity "VirtualInterface" 
which represents virtual network cards associated with an instance:
belongs_to :instance
belongs_to :network
string     :name

3) Didn't look too close but for vSphere 1b features are not possible 
too - the networking model abilities are similar to RHEV. Though their 
virtual distributed switch and VXLAN support looks promising and I could 
be wrong. Francesco was going to look at vSphere closer so he might 
bring more details.


I think it would make sense to implement step 1a for all major 
providers, this involves:
- add network listing (so a user can list available networks which she 
can specify then when launching an instance)
- extend instance create action to automatically add the instance into 
specified network (network name would be passed as another param)

In the next step network model would be extended to support 1b for 
providers which support it.

What do you think?
Jan



[1] 
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Technical_Reference_Guide/sect-Technical_Reference_Guide-Networking_in_Data_Centers_and_Clusters.-Logical_Networks.html

[2] http://www.ovirt.org/images/9/96/Ovirt-quantum-integration2.pdf

[3] 
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Example-Attach_NIC

Re: Network API Models - RFC

["marios@redhat.com" <ma...@redhat.com>]

On 13/02/13 10:31, Jan Provazník wrote:
> On 01/21/2013 05:57 PM, marios@redhat.com wrote:
>> [patches also available from http://tracker.deltacloud.org/set/263]
>>
>> Initial implementation for networks - in particular seeking feedback
>> with respect to models and how they 'sit' for vsphere/rhevm (I've taken
>> CIMI, EC2 VPC and Openstack into consideration already). Initial
>> implementation of 'networks' collection for EC2 driver (create, list,
>> show
>> and destroy VPC).
>>
>> marios
>>
> 
> Hi,
> overall, the models in this patchset look reasonable to me. After
> discussing this topic with Heat/PM and some other people, here are my
> findings:
> 
> 1) There are 2 levels of networking support we would like to have:
>   a) be able to specify an existing network (or subnet?) when
>      launching an instance
>   b) be able to dynamically create whole network/subnets or firewall
>      rules when launching a deployment (cloud formation)
> 
> 2) For RHEV it is currently not possible to achieve 1b. Network creation
> is admin task. Nice description is here [1]. Good news is that RHEV will
> probably support Quantum networking in future, currently there is POC
> where Quantum network can be used as an external network in ovirt [2]
> (note that dynamic network creation is not possible in this POC too).
> Will do more investigation about Quantum plans tomorrow.
> 
> Mapping RHEV networking entities to entities in Marios' proposal is a
> challenge. A user can just create VM's NICs for which she specifies
> network [3].
> Network model reflects RHEV Network.
> Subnet is not used in RHEV, some related info (netmask, ip range) might
> be fetched from host's NIC entity.
> Port is not used in RHEV, most similar entity is VM's virtual NIC (which
> is associated with a virtual machine though).
> 
> When creating RHEV virtual machine, you specify network by creating
> virtual NIC for the machine in separate request. Also you can manage
> interfaces for virtual machine.
> I wonder if it makes sense to add another entity "VirtualInterface"
> which represents virtual network cards associated with an instance:
> belongs_to :instance
> belongs_to :network
> string     :name
> 
> 3) Didn't look too close but for vSphere 1b features are not possible
> too - the networking model abilities are similar to RHEV. Though their
> virtual distributed switch and VXLAN support looks promising and I could
> be wrong. Francesco was going to look at vSphere closer so he might
> bring more details.
> 
> 
> I think it would make sense to implement step 1a for all major
> providers, this involves:
> - add network listing (so a user can list available networks which she
> can specify then when launching an instance)
> - extend instance create action to automatically add the instance into
> specified network (network name would be passed as another param)
> 
> In the next step network model would be extended to support 1b for
> providers which support it.
> 
> What do you think?
> Jan
> 

Jan - thanks for looking into RHEV-M and for making these notes. We are
planning a meeting this Friday - 15th @ 1600 Brno time - most likely a
google hangout - for further discussion and next steps. It would be
great if you can bring your ideas and notes to this meeting. We can meet
on #deltacloud channel and organise the hangout there.

thanks, marios


> 
> 
> [1]
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Technical_Reference_Guide/sect-Technical_Reference_Guide-Networking_in_Data_Centers_and_Clusters.-Logical_Networks.html
> 
> 
> [2] http://www.ovirt.org/images/9/96/Ovirt-quantum-integration2.pdf
> 
> [3]
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Example-Attach_NIC
>