cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: what's the reason for the placeholder nic in VPC/VR?
Date Wed, 09 Oct 2013 20:31:11 GMT
Valid question and concern. Here is the history:

V1.0 No notion of the NaaS yet, no networks/nics tables; guest type and
all network related info - public ip, mac, netmask - for the VR is stored
in domain_router table

V2.1 NaaS added. Although each router has entries in the nics table, and
its possible to retrieve the guest network info from there, network_id
holding guestNetworkId for the VR, was added to the domain_router table. I
can't recall who added it, and the reason why it was done this way, but
most of the code for the VR reads guest network info from
domain_router.network_id. And it's always 1-1 relationship between VR and
guest network. We also continue storing public_ip/netmask/mac_address of
the VR public nic in domain_router table.

V3.0 VPC was added. Now VR can have more than one network, so we created
this table to maintain VR to guest network refs there, and moved
network_id to VR ref from domain_router table to router_network_ref. I
agree the right fix should have been - change all the code reading
network_id info from domain_router, to read it from nics instead. But back
then we just needed the quick fix for VPC to support 1 VR - n guest
networks case, and didn't want to introduce the regressions in existing
code, so we've done it this way.

Following needs to be fixed (DB upgrade too)

* get rid of router_network_ref table and always retrieve guest network
info from nics table.
* vm_instance/domain_router/console_proxy/secondary_storage_vm table - get
rid of 
private_ip_address/private_mac_address/public_mac_address/public_mac_addres
s fields that exist since 1.0. Again, because all this info can be
retrieved via nics. And right now we just duplicate this data across
vm_instance/domain_router/console_proxy/secondary_storage_vm tables, and
sometimes read it from there, and sometimes from nics. We should always
read it from nics, as this table has the most reliable and current info.


-Alena.


On 10/9/13 12:59 PM, "Darren Shepherd" <darren.s.shepherd@gmail.com> wrote:

>Okay, that makes sense.  Another random question.  Why does
>router_network_ref exist?  Is it not sufficient to just find a
>DomainRouter VM that has a nic attached to the network?  It seems to
>be for RvR?  Is that right?  Still I don't understand why the table is
>needed.
>
>Darren
>
>On Wed, Oct 9, 2013 at 9:50 AM, Alena Prokharchyk
><Alena.Prokharchyk@citrix.com> wrote:
>> I've just tested it on the latest master, don't see placeholder nic
>> created for the VPC VR.
>>
>> In addition to the case Murali explained, placeholder nic is being
>>created
>> per Shared network case using VR as DHCP provider. Its done to preserve
>> the same ip address for the case when VR is being expunged/re-created
>> during the network restart/Vrdestroy. As a result of expunge VR its nic
>>is
>> being cleaned up - and ip released - , so we had to make sure that the
>>new
>> VR would get the same ip. More details are in
>> 26b892daf3cdccc2e25711730c7e1efcdec7d2dc, CLOUDSTACK-1771.
>>
>> -Alena.
>>
>>
>> On 10/9/13 2:57 AM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:
>>
>>>On 09/10/13 11:33 AM, "Darren Shepherd" <darren.s.shepherd@gmail.com>
>>>wrote:
>>>
>>>>Why is a placeholder nic created before the VRs for the VPC are
>>>>created?
>>>>
>>>>Darren
>>>>
>>>
>>>Generally place holder nic is used in cases where cloudstack uses a
>>>subnet
>>>IP from the guest subnet, but ip is not used for any VM nic's. In most
>>>of
>>>the external network devices, needs a subnet IP from the guest network
>>>CIDR, cloudstack creates a place holder nic and allocates a subnet ip.
>>>
>>>
>>
>>
>



Mime
View raw message