You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2012/11/15 16:40:17 UTC
same vlan on different nics
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.
Re: same vlan on different nics
Posted by Alena Prokharchyk <Al...@citrix.com>.
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" <sh...@gmail.com> 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
><sh...@gmail.com> 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
><Pr...@citrix.com> 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: cloudstack-dev@incubator.apache.org; 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" <sh...@gmail.com> 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.
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: same vlan on different nics
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <sh...@gmail.com>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 <Pr...@citrix.com>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: cloudstack-dev@incubator.apache.org; 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" <sh...@gmail.com> 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.
>> >
>>
>>
>>
>
Re: same vlan on different nics
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <Pr...@citrix.com>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: cloudstack-dev@incubator.apache.org; 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" <sh...@gmail.com> 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.
> >
>
>
>
RE: same vlan on different nics
Posted by Prachi Damle <Pr...@citrix.com>.
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: cloudstack-dev@incubator.apache.org; 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" <sh...@gmail.com> 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.
>
Re: same vlan on different nics
Posted by Alena Prokharchyk <Al...@citrix.com>.
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" <sh...@gmail.com> 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.
>