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.sheph...@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.prokharc...@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.re...@citrix.com> wrote: >> >>>On 09/10/13 11:33 AM, "Darren Shepherd" <darren.s.sheph...@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. >>> >>> >> >> >
