Marcus, usually upgrade script XtoY.sql is manually created right after the X gets branched out from master. Then when whoever does DB changes for the future release Y, should include them to the upgrade path. It's not just schema diff; sometimes DB data migration/changes are required, so we can't generate the sql diff on the fly. As an example, if not null constraint is introduced for the table, the committer should update the field in existing Dbs with not null data.
-Alena. On 11/19/12 2:07 PM, "Marcus Sorensen" <[email protected]> wrote: > > > >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. >> > > > > > > > > > > > > > > > > >
