One question, are the schema-XtoX.sql files generated after/around code freeze from the difference in the old and current schema files, or are they manually created as schema changes occur?
On Thu, Nov 15, 2012 at 2:01 PM, Marcus Sorensen <[email protected]>wrote: > That's fine, I can change the patch referenced for CLOUDSTACK-226 so that > it doesn't apply to KVM, and then changing the unique index will allow > things to work for KVM. > > If the only problem is the bridge naming, as was changed with KVM > (previously the same vlan on two different physical nics would end up with > the same bridge name which obviously wouldn't work), then this is fine, and > the bridge naming can be reviewed for Xen or other hypervisors as desired. > I just wanted to do a sanity check and make sure there wasn't any other > technical reason why someone couldn't choose to have two or more > independent networks on their physical interfaces. Or something already > known in the code that would break due to this. > > > On Thu, Nov 15, 2012 at 1:37 PM, Prachi Damle <[email protected]>wrote: > >> Chiradeep/Alex, >> >> Can we use the same vlan on two different physical networks in one >> datacenter? >> >> If it is possible to share the same vlan on different physical networks >> of the datacenter, we could update the DB unique constraint to (`vnet`, >> `data_center_id`, 'physical_network_id') as Marcus suggests. >> >> But if vnet ranges need to be separate, maybe we need some KVM specific >> solution... >> >> -Prachi >> -----Original Message----- >> From: Alena Prokharchyk >> Sent: Thursday, November 15, 2012 11:51 AM >> To: [email protected]; Prachi Damle >> Subject: Re: same vlan on different nics >> >> Marcus, >> >> Prachi would be the best person to answer this question as she added the >> constraint to create-schema.sql: >> >> 8836a08e (prachi 2011-11-08 11:23:37 -0800 658) >> CONSTRAINT `fk_op_dc_vnet_alloc__physical_network_id` FOREIGN KEY >> (`physical_network_id`) REFERENCES `physical_network' >> >> Commit id is 8836a08e. >> >> -Alena. >> >> >> On 11/15/12 7:40 AM, "Marcus Sorensen" <[email protected]> wrote: >> >> >https://issues.apache.org/jira/browse/CLOUDSTACK-226 >> > >> >It looks like this was fixed (11fe086adab8e790018343252ed08aac9a27b1c6) >> >by making sure that a particular vlan range can only exist on one >> >physical network. Is there any technical reason for this? It looks like >> >the fix worked around the unique key restriction in the database >> >schema, is that the only limiting factor? We recently changed the >> >naming scheme of KVM bridges to allow the same vlan to be used on >> >different physical networks, so I can make the solution KVM specific. >> > >> >I'm just not sure why this limitation was created in the first place >> >(the schema, not the fix) and want to gather some info before doing too >> much. >> >I'd rather just make the key unique to vlan on physical network and let >> >the individual doing the implementation decide if they want to do >> >multiple >> >layer2 domains to their boxes or not. >> > >> >> >> >
