You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alena Prokharchyk <Al...@citrix.com> on 2012/08/10 19:33:53 UTC
asf/vpc branch merge
Considering that there is a code freeze happening soon, and as the main
part for VPC feature development is complete + the VPC code
has been well tested by cloudStack QA engineers, it's time to discuss
merging the asf/vpc branch into asf/master. At this point its too hard to
break it to several components-to-merge as there were too many single
commits for the last couple of months from 7 developers involved in the
process + we were doing the daily merges with master branch in order to
keep asf/vpc branch up to date. It makes it hard to componentize at this
point without running into lots of rebase conflicts
So most likely it will be done as a single merge if
the merge gets approved by the community. We would highly
appreciate any help involving code/documentation review as well as any
other suggestions on how to make this particular merge safer and smoother.
And the suggestions made towards the merge process in general, will all be
addressed in the future.
We've tried to keep vpc branch in sync with asf/master by performing daily
merges from master branch to vpc, so there shouldn't be too many
conflicts. The VPC code went through several rounds of QA including the
regression testing for existing network components. Most of the VPC code
resides in the new classes added as a part of the feature; but some
existing Network related code got some changes and can be considered for
the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
particular as well as some Agent APIs and cloudStack UI). The VPC FS
contains the reference to new classes (including client/agent APIs)
created for the VPC feature (see the link below).
Functional specification:
http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+spe
c
Engineer participated in VPC development:
Sheng Yang - S2SVPN implementation
Alena Prokharchyk - Client/Agent APIs,
VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
Anthony Xu - All VirtualRuter script changes + feature implementation for
Xen resource
Kelven Yang - Implementation for VmWare resource
Sonny Chhan/Jessica Wang/Brian Federle - UI component
QA test cases execution matrix:
http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
I'm well aware the 4.0 will be branched on Monday, so once the merge is
approved, I can do the merge over the weekend including doing basic
regression for the networking key components on the merged branch.
-Alena.
Re: asf/vpc branch merge
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 8/10/12 1:56 PM, "David Nalley" <da...@gnsa.us> wrote:
>You mention the main part is done, what is left for this feature for
>it to be completely done?
>
>--David
>
Bug fixes mostly. There are also some feature limitations for the current
release - VPC is supported for Xen/VmWare hypervisors only; we are
planning to add support for KVM later.
-Alena.
Re: asf/vpc branch merge
Posted by David Nalley <da...@gnsa.us>.
You mention the main part is done, what is left for this feature for
it to be completely done?
--David
RE: asf/vpc branch merge
Posted by Sheng Yang <Sh...@citrix.com>.
I've fixed the s2s vpn db schema issue.
Thanks!
--Sheng
-----Original Message-----
From: Alena Prokharchyk
Sent: Sunday, August 12, 2012 1:21 PM
To: cloudstack-dev@incubator.apache.org
Cc: Anthony Xu; Sheng Yang; Brian Federle
Subject: Re: asf/vpc branch merge
The asf/vpc branch merge to the master is completed. Some bugs were found during the final round of regression for the VPC
1) UI - enable Static nat button doesn't work neither from Networks tab, nor from the VPC. Brian is going to fix it.
2) create LB rule fails for VPC on th Virtual router side due to some error while programming haconfig. Anthony is going to look into it.
3) S2S vpn (part of VPC feature) - customer VPN db schema is not up to date, some changes weren't cherry-picked from citrix internal branch to asf/vpc. Sheng is going to take care of it.
The regression test for regular Isolated networks outside of vpc didn't raise any problems, except for the UI one (#1 above).
Sheng/Athony/Brian, please put all your fixes to master branch directly (and 4.0 once it's branched out). And double check that all vpc related changes from citrix internal branch are present in asf repo; I found couple of inconsistencies, and added them. Please fix the rest.
-Alena.
On 8/11/12 11:15 AM, "Ewan Mellor" <Ew...@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: 10 August 2012 13:19
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: asf/vpc branch merge
>>
>> As I'm not a git expert, I would appreciate any help from the
>>community in figuring out what is the best way to merge vpc branch
>>into master.
>>
>>
>> Couple of ways I can think of:
>>
>> 1) git checkout master; git merge -s recursive -Xignore-space-change
>> vpc
>>
>> Puts all commits from the vpc that are differnt from master, to the
>>master branch.
>>
>> Pros:
>>
>> * no tree rebase happens
>> * easier to revert individual commits if they cause any issues
>> * Have 0 conflicts after the merge is done (just tested on my local
>>branch)
>> * Very close to vpc branch, so reduces the chances for regression
>>bugs (vpc branch was tested)
>>
>>
>> Cons:
>>
>> * harder to track down all VPC commits as they've been happening for
>>a couple of months, and appear in the git log on the date they were
>>originally submitted.
>>
>>
>>
>> 2) Do interactive rebase on master from vpc and squash all the
>>commits into one
>>
>> git checkout master; git rebase -i asf/vpc
>>
>> Pros:
>>
>> * Easier to see all VPC changes as they come as a part of a single
>>commit
>>
>> Cons:
>>
>> * Requires rebase which leads to lots of conflicts.
>> * Not sure if there is an option to revert an individual commit
>>happened as a part of squashed commit.
>>
>>
>> I personally prefer way 1) as it doesn't lead to conflicts + leaves
>>less chances for regression bugs as the asf/master structure becomes
>>very similar to the structure of asf/vpc branch, and this branch was
>>tested.
>> But let me know if anybody sees any downsides of doing the merge this
>>way and can suggest a better way.
>>
>>
>> Thank you,
>> -Alena.
>>
>>
>>
>> On 8/10/12 10:33 AM, "Alena Prokharchyk"
>> <Al...@citrix.com>
>> wrote:
>>
>> >
>> >Considering that there is a code freeze happening soon, and as the
>> >main part for VPC feature development is complete + the VPC code has
>> >been well tested by cloudStack QA engineers, it's time to discuss
>> >merging the asf/vpc branch into asf/master. At this point its too
>> >hard to break it to several components-to-merge as there were too
>> >many single commits for the last couple of months from 7 developers
>> >involved in the process
>> >+ we were doing the daily merges with master branch in order to keep
>> >asf/vpc branch up to date. It makes it hard to componentize at this
>> >point without running into lots of rebase conflicts
>> >
>> >So most likely it will be done as a single merge if the merge gets
>> >approved by the community. We would highly appreciate any help
>> >involving code/documentation review as well as any other suggestions
>> >on how to make this particular merge safer and smoother.
>> >And the suggestions made towards the merge process in general, will
>> >all be addressed in the future.
>> >
>> >We've tried to keep vpc branch in sync with asf/master by performing
>> >daily merges from master branch to vpc, so there shouldn't be too
>> >many conflicts. The VPC code went through several rounds of QA
>> >including the regression testing for existing network components.
>> >Most of the VPC code resides in the new classes added as a part of
>> >the feature; but some existing Network related code got some changes
>> >and can be considered for the review
>> >(NetworkManagerImpl/VirtualNetworkApplianceManager in particular as
>> >well as some Agent APIs and cloudStack UI). The VPC FS contains the
>> >reference to new classes (including client/agent APIs) created for
>> >the
>>VPC
>> feature (see the link below).
>> >
>> >
>> >Functional specification:
>> >
>> >http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functio
>> >nal
>> >+sp
>> >e
>> >c
>> >
>> >
>> >Engineer participated in VPC development:
>> >
>> >Sheng Yang - S2SVPN implementation
>> >Alena Prokharchyk - Client/Agent APIs,
>> >VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>> >Anthony Xu - All VirtualRuter script changes + feature
>> >implementation for Xen resource Kelven Yang - Implementation for
>> >VmWare resource
>> Sonny
>> >Chhan/Jessica Wang/Brian Federle - UI component
>> >
>> >
>> >QA test cases execution matrix:
>> >
>> >http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>> >
>> >
>> >I'm well aware the 4.0 will be branched on Monday, so once the merge
>> >is approved, I can do the merge over the weekend including doing
>> >basic regression for the networking key components on the merged branch.
>
>I think that option 1 is the best. You've been keeping the VPC branch
>up to date with master as you've gone along, so using git merge at this
>point sounds like the best option. Also, everything has been reviewed
>on the way in to the VPC branch, so I don't think that there's a need
>for you to rebase/squash everything for master.
>
>There haven't been any objections, so please go ahead and start that
>merge. If you can do it this weekend that will clear the way for us to
>branch on Monday morning, but I'll make sure that we've checked that
>you're done before we take that branch, so if it spills into Monday
>then don't worry too much about it.
>
>Thanks,
>
>Ewan.
>
>
Re: asf/vpc branch merge
Posted by Alena Prokharchyk <Al...@citrix.com>.
The asf/vpc branch merge to the master is completed. Some bugs were found
during the final round of regression for the VPC
1) UI - enable Static nat button doesn't work neither from Networks tab,
nor from the VPC. Brian is going to fix it.
2) create LB rule fails for VPC on th Virtual router side due to some
error while programming haconfig. Anthony is going to look into it.
3) S2S vpn (part of VPC feature) - customer VPN db schema is not up to
date, some changes weren't cherry-picked from citrix internal branch to
asf/vpc. Sheng is going to take care of it.
The regression test for regular Isolated networks outside of vpc didn't
raise any problems, except for the UI one (#1 above).
Sheng/Athony/Brian, please put all your fixes to master branch directly
(and 4.0 once it's branched out). And double check that all vpc related
changes from citrix internal branch are present in asf repo; I found
couple of inconsistencies, and added them. Please fix the rest.
-Alena.
On 8/11/12 11:15 AM, "Ewan Mellor" <Ew...@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: 10 August 2012 13:19
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: asf/vpc branch merge
>>
>> As I'm not a git expert, I would appreciate any help from the community
>>in
>> figuring out what is the best way to merge vpc branch into master.
>>
>>
>> Couple of ways I can think of:
>>
>> 1) git checkout master; git merge -s recursive -Xignore-space-change vpc
>>
>> Puts all commits from the vpc that are differnt from master, to the
>>master
>> branch.
>>
>> Pros:
>>
>> * no tree rebase happens
>> * easier to revert individual commits if they cause any issues
>> * Have 0 conflicts after the merge is done (just tested on my local
>>branch)
>> * Very close to vpc branch, so reduces the chances for regression bugs
>>(vpc
>> branch was tested)
>>
>>
>> Cons:
>>
>> * harder to track down all VPC commits as they've been happening for a
>> couple of months, and appear in the git log on the date they were
>>originally
>> submitted.
>>
>>
>>
>> 2) Do interactive rebase on master from vpc and squash all the commits
>>into
>> one
>>
>> git checkout master; git rebase -i asf/vpc
>>
>> Pros:
>>
>> * Easier to see all VPC changes as they come as a part of a single
>>commit
>>
>> Cons:
>>
>> * Requires rebase which leads to lots of conflicts.
>> * Not sure if there is an option to revert an individual commit
>>happened as a
>> part of squashed commit.
>>
>>
>> I personally prefer way 1) as it doesn't lead to conflicts + leaves
>>less chances
>> for regression bugs as the asf/master structure becomes very similar to
>>the
>> structure of asf/vpc branch, and this branch was tested.
>> But let me know if anybody sees any downsides of doing the merge this
>>way
>> and can suggest a better way.
>>
>>
>> Thank you,
>> -Alena.
>>
>>
>>
>> On 8/10/12 10:33 AM, "Alena Prokharchyk" <Al...@citrix.com>
>> wrote:
>>
>> >
>> >Considering that there is a code freeze happening soon, and as the main
>> >part for VPC feature development is complete + the VPC code has been
>> >well tested by cloudStack QA engineers, it's time to discuss merging
>> >the asf/vpc branch into asf/master. At this point its too hard to break
>> >it to several components-to-merge as there were too many single commits
>> >for the last couple of months from 7 developers involved in the process
>> >+ we were doing the daily merges with master branch in order to keep
>> >asf/vpc branch up to date. It makes it hard to componentize at this
>> >point without running into lots of rebase conflicts
>> >
>> >So most likely it will be done as a single merge if the merge gets
>> >approved by the community. We would highly appreciate any help
>> >involving code/documentation review as well as any other suggestions on
>> >how to make this particular merge safer and smoother.
>> >And the suggestions made towards the merge process in general, will all
>> >be addressed in the future.
>> >
>> >We've tried to keep vpc branch in sync with asf/master by performing
>> >daily merges from master branch to vpc, so there shouldn't be too many
>> >conflicts. The VPC code went through several rounds of QA including the
>> >regression testing for existing network components. Most of the VPC
>> >code resides in the new classes added as a part of the feature; but
>> >some existing Network related code got some changes and can be
>> >considered for the review
>> >(NetworkManagerImpl/VirtualNetworkApplianceManager in particular as
>> >well as some Agent APIs and cloudStack UI). The VPC FS contains the
>> >reference to new classes (including client/agent APIs) created for the
>>VPC
>> feature (see the link below).
>> >
>> >
>> >Functional specification:
>> >
>> >http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional
>> >+sp
>> >e
>> >c
>> >
>> >
>> >Engineer participated in VPC development:
>> >
>> >Sheng Yang - S2SVPN implementation
>> >Alena Prokharchyk - Client/Agent APIs,
>> >VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>> >Anthony Xu - All VirtualRuter script changes + feature implementation
>> >for Xen resource Kelven Yang - Implementation for VmWare resource
>> Sonny
>> >Chhan/Jessica Wang/Brian Federle - UI component
>> >
>> >
>> >QA test cases execution matrix:
>> >
>> >http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>> >
>> >
>> >I'm well aware the 4.0 will be branched on Monday, so once the merge is
>> >approved, I can do the merge over the weekend including doing basic
>> >regression for the networking key components on the merged branch.
>
>I think that option 1 is the best. You've been keeping the VPC branch up
>to date with master as you've gone along, so using git merge at this
>point sounds like the best option. Also, everything has been reviewed on
>the way in to the VPC branch, so I don't think that there's a need for
>you to rebase/squash everything for master.
>
>There haven't been any objections, so please go ahead and start that
>merge. If you can do it this weekend that will clear the way for us to
>branch on Monday morning, but I'll make sure that we've checked that
>you're done before we take that branch, so if it spills into Monday then
>don't worry too much about it.
>
>Thanks,
>
>Ewan.
>
>
RE: asf/vpc branch merge
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> Sent: 10 August 2012 13:19
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: asf/vpc branch merge
>
> As I'm not a git expert, I would appreciate any help from the community in
> figuring out what is the best way to merge vpc branch into master.
>
>
> Couple of ways I can think of:
>
> 1) git checkout master; git merge -s recursive -Xignore-space-change vpc
>
> Puts all commits from the vpc that are differnt from master, to the master
> branch.
>
> Pros:
>
> * no tree rebase happens
> * easier to revert individual commits if they cause any issues
> * Have 0 conflicts after the merge is done (just tested on my local branch)
> * Very close to vpc branch, so reduces the chances for regression bugs (vpc
> branch was tested)
>
>
> Cons:
>
> * harder to track down all VPC commits as they've been happening for a
> couple of months, and appear in the git log on the date they were originally
> submitted.
>
>
>
> 2) Do interactive rebase on master from vpc and squash all the commits into
> one
>
> git checkout master; git rebase -i asf/vpc
>
> Pros:
>
> * Easier to see all VPC changes as they come as a part of a single commit
>
> Cons:
>
> * Requires rebase which leads to lots of conflicts.
> * Not sure if there is an option to revert an individual commit happened as a
> part of squashed commit.
>
>
> I personally prefer way 1) as it doesn't lead to conflicts + leaves less chances
> for regression bugs as the asf/master structure becomes very similar to the
> structure of asf/vpc branch, and this branch was tested.
> But let me know if anybody sees any downsides of doing the merge this way
> and can suggest a better way.
>
>
> Thank you,
> -Alena.
>
>
>
> On 8/10/12 10:33 AM, "Alena Prokharchyk" <Al...@citrix.com>
> wrote:
>
> >
> >Considering that there is a code freeze happening soon, and as the main
> >part for VPC feature development is complete + the VPC code has been
> >well tested by cloudStack QA engineers, it's time to discuss merging
> >the asf/vpc branch into asf/master. At this point its too hard to break
> >it to several components-to-merge as there were too many single commits
> >for the last couple of months from 7 developers involved in the process
> >+ we were doing the daily merges with master branch in order to keep
> >asf/vpc branch up to date. It makes it hard to componentize at this
> >point without running into lots of rebase conflicts
> >
> >So most likely it will be done as a single merge if the merge gets
> >approved by the community. We would highly appreciate any help
> >involving code/documentation review as well as any other suggestions on
> >how to make this particular merge safer and smoother.
> >And the suggestions made towards the merge process in general, will all
> >be addressed in the future.
> >
> >We've tried to keep vpc branch in sync with asf/master by performing
> >daily merges from master branch to vpc, so there shouldn't be too many
> >conflicts. The VPC code went through several rounds of QA including the
> >regression testing for existing network components. Most of the VPC
> >code resides in the new classes added as a part of the feature; but
> >some existing Network related code got some changes and can be
> >considered for the review
> >(NetworkManagerImpl/VirtualNetworkApplianceManager in particular as
> >well as some Agent APIs and cloudStack UI). The VPC FS contains the
> >reference to new classes (including client/agent APIs) created for the VPC
> feature (see the link below).
> >
> >
> >Functional specification:
> >
> >http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional
> >+sp
> >e
> >c
> >
> >
> >Engineer participated in VPC development:
> >
> >Sheng Yang - S2SVPN implementation
> >Alena Prokharchyk - Client/Agent APIs,
> >VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
> >Anthony Xu - All VirtualRuter script changes + feature implementation
> >for Xen resource Kelven Yang - Implementation for VmWare resource
> Sonny
> >Chhan/Jessica Wang/Brian Federle - UI component
> >
> >
> >QA test cases execution matrix:
> >
> >http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
> >
> >
> >I'm well aware the 4.0 will be branched on Monday, so once the merge is
> >approved, I can do the merge over the weekend including doing basic
> >regression for the networking key components on the merged branch.
I think that option 1 is the best. You've been keeping the VPC branch up to date with master as you've gone along, so using git merge at this point sounds like the best option. Also, everything has been reviewed on the way in to the VPC branch, so I don't think that there's a need for you to rebase/squash everything for master.
There haven't been any objections, so please go ahead and start that merge. If you can do it this weekend that will clear the way for us to branch on Monday morning, but I'll make sure that we've checked that you're done before we take that branch, so if it spills into Monday then don't worry too much about it.
Thanks,
Ewan.
Re: asf/vpc branch merge
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 8/11/12 1:18 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>
>On 08/10/2012 10:19 PM, Alena Prokharchyk wrote:
>> As I'm not a git expert, I would appreciate any help from the community
>>in
>> figuring out what is the best way to merge vpc branch into master.
>>
>>
>> Couple of ways I can think of:
>>
>> 1) git checkout master; git merge -s recursive -Xignore-space-change vpc
>>
>> Puts all commits from the vpc that are differnt from master, to the
>>master
>> branch.
>>
>> Pros:
>>
>> * no tree rebase happens
>> * easier to revert individual commits if they cause any issues
>> * Have 0 conflicts after the merge is done (just tested on my local
>>branch)
>> * Very close to vpc branch, so reduces the chances for regression bugs
>> (vpc branch was tested)
>>
>>
>> Cons:
>>
>> * harder to track down all VPC commits as they've been happening for a
>> couple of months, and appear in the git log on the date they were
>> originally submitted.
>>
>>
>>
>> 2) Do interactive rebase on master from vpc and squash all the commits
>> into one
>>
>
>Have you thought about rebasing the vpc branch against master?
>
>$ git checkout vpc
>$ git rebase master
>$ git checkout master
>$ git merge vpc
>
>It will then come in as one clean commit if you squash it all during
>your vpc rebase.
>
>I did that with RBD to make it one nice commit which could be reverted
>if any issues would occur.
>
>Wido
Yes, Wido, I've tried to do that as a part of 2) and ran into tons of
conflicts. The conflicts are explained by the fact the changes were coming
in to vpc branch for more than 2 months in a form of cherry picks along
with daily merges with master branch, and rebase was never done on the vpc
to master.
I agree that for the future merges it might be the best way to go -
interactive rebase and squash (may be into multiple commit groups per
component basis). For this time, I'll probably go with 1) as the branch in
this state was already tested. And of course, I'll run another round of
feature testing + regression before pushing everything into repo.
-Alena.
>
>> git checkout master; git rebase -i asf/vpc
>>
>> Pros:
>>
>> * Easier to see all VPC changes as they come as a part of a single
>>commit
>>
>> Cons:
>>
>> * Requires rebase which leads to lots of conflicts.
>> * Not sure if there is an option to revert an individual commit happened
>> as a part of squashed commit.
>>
>>
>> I personally prefer way 1) as it doesn't lead to conflicts + leaves less
>> chances for regression bugs as the asf/master structure becomes very
>> similar to the structure of asf/vpc branch, and this branch was tested.
>> But let me know if anybody sees any downsides of doing the merge this
>>way
>> and can suggest a better way.
>>
>>
>> Thank you,
>> -Alena.
>>
>>
>>
>> On 8/10/12 10:33 AM, "Alena Prokharchyk" <Al...@citrix.com>
>> wrote:
>>
>>>
>>> Considering that there is a code freeze happening soon, and as the main
>>> part for VPC feature development is complete + the VPC code
>>> has been well tested by cloudStack QA engineers, it's time to discuss
>>> merging the asf/vpc branch into asf/master. At this point its too hard
>>>to
>>> break it to several components-to-merge as there were too many single
>>> commits for the last couple of months from 7 developers involved in the
>>> process + we were doing the daily merges with master branch in order to
>>> keep asf/vpc branch up to date. It makes it hard to componentize at
>>>this
>>> point without running into lots of rebase conflicts
>>>
>>> So most likely it will be done as a single merge if
>>> the merge gets approved by the community. We would highly
>>> appreciate any help involving code/documentation review as well as any
>>> other suggestions on how to make this particular merge safer and
>>>smoother.
>>> And the suggestions made towards the merge process in general, will
>>>all be
>>> addressed in the future.
>>>
>>> We've tried to keep vpc branch in sync with asf/master by performing
>>>daily
>>> merges from master branch to vpc, so there shouldn't be too many
>>> conflicts. The VPC code went through several rounds of QA including the
>>> regression testing for existing network components. Most of the VPC
>>>code
>>> resides in the new classes added as a part of the feature; but some
>>> existing Network related code got some changes and can be considered
>>>for
>>> the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
>>> particular as well as some Agent APIs and cloudStack UI). The VPC FS
>>> contains the reference to new classes (including client/agent APIs)
>>> created for the VPC feature (see the link below).
>>>
>>>
>>> Functional specification:
>>>
>>>
>>>http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+
>>>sp
>>> e
>>> c
>>>
>>>
>>> Engineer participated in VPC development:
>>>
>>> Sheng Yang - S2SVPN implementation
>>> Alena Prokharchyk - Client/Agent APIs,
>>> VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>>> Anthony Xu - All VirtualRuter script changes + feature implementation
>>>for
>>> Xen resource
>>> Kelven Yang - Implementation for VmWare resource
>>> Sonny Chhan/Jessica Wang/Brian Federle - UI component
>>>
>>>
>>> QA test cases execution matrix:
>>>
>>> http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>>>
>>>
>>> I'm well aware the 4.0 will be branched on Monday, so once the merge is
>>> approved, I can do the merge over the weekend including doing basic
>>> regression for the networking key components on the merged branch.
>>>
>>>
>>> -Alena.
>>>
>>>
>>
>>
>
Re: asf/vpc branch merge
Posted by Wido den Hollander <wi...@widodh.nl>.
On 08/10/2012 10:19 PM, Alena Prokharchyk wrote:
> As I'm not a git expert, I would appreciate any help from the community in
> figuring out what is the best way to merge vpc branch into master.
>
>
> Couple of ways I can think of:
>
> 1) git checkout master; git merge -s recursive -Xignore-space-change vpc
>
> Puts all commits from the vpc that are differnt from master, to the master
> branch.
>
> Pros:
>
> * no tree rebase happens
> * easier to revert individual commits if they cause any issues
> * Have 0 conflicts after the merge is done (just tested on my local branch)
> * Very close to vpc branch, so reduces the chances for regression bugs
> (vpc branch was tested)
>
>
> Cons:
>
> * harder to track down all VPC commits as they've been happening for a
> couple of months, and appear in the git log on the date they were
> originally submitted.
>
>
>
> 2) Do interactive rebase on master from vpc and squash all the commits
> into one
>
Have you thought about rebasing the vpc branch against master?
$ git checkout vpc
$ git rebase master
$ git checkout master
$ git merge vpc
It will then come in as one clean commit if you squash it all during
your vpc rebase.
I did that with RBD to make it one nice commit which could be reverted
if any issues would occur.
Wido
> git checkout master; git rebase -i asf/vpc
>
> Pros:
>
> * Easier to see all VPC changes as they come as a part of a single commit
>
> Cons:
>
> * Requires rebase which leads to lots of conflicts.
> * Not sure if there is an option to revert an individual commit happened
> as a part of squashed commit.
>
>
> I personally prefer way 1) as it doesn't lead to conflicts + leaves less
> chances for regression bugs as the asf/master structure becomes very
> similar to the structure of asf/vpc branch, and this branch was tested.
> But let me know if anybody sees any downsides of doing the merge this way
> and can suggest a better way.
>
>
> Thank you,
> -Alena.
>
>
>
> On 8/10/12 10:33 AM, "Alena Prokharchyk" <Al...@citrix.com>
> wrote:
>
>>
>> Considering that there is a code freeze happening soon, and as the main
>> part for VPC feature development is complete + the VPC code
>> has been well tested by cloudStack QA engineers, it's time to discuss
>> merging the asf/vpc branch into asf/master. At this point its too hard to
>> break it to several components-to-merge as there were too many single
>> commits for the last couple of months from 7 developers involved in the
>> process + we were doing the daily merges with master branch in order to
>> keep asf/vpc branch up to date. It makes it hard to componentize at this
>> point without running into lots of rebase conflicts
>>
>> So most likely it will be done as a single merge if
>> the merge gets approved by the community. We would highly
>> appreciate any help involving code/documentation review as well as any
>> other suggestions on how to make this particular merge safer and smoother.
>> And the suggestions made towards the merge process in general, will all be
>> addressed in the future.
>>
>> We've tried to keep vpc branch in sync with asf/master by performing daily
>> merges from master branch to vpc, so there shouldn't be too many
>> conflicts. The VPC code went through several rounds of QA including the
>> regression testing for existing network components. Most of the VPC code
>> resides in the new classes added as a part of the feature; but some
>> existing Network related code got some changes and can be considered for
>> the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
>> particular as well as some Agent APIs and cloudStack UI). The VPC FS
>> contains the reference to new classes (including client/agent APIs)
>> created for the VPC feature (see the link below).
>>
>>
>> Functional specification:
>>
>> http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+sp
>> e
>> c
>>
>>
>> Engineer participated in VPC development:
>>
>> Sheng Yang - S2SVPN implementation
>> Alena Prokharchyk - Client/Agent APIs,
>> VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>> Anthony Xu - All VirtualRuter script changes + feature implementation for
>> Xen resource
>> Kelven Yang - Implementation for VmWare resource
>> Sonny Chhan/Jessica Wang/Brian Federle - UI component
>>
>>
>> QA test cases execution matrix:
>>
>> http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>>
>>
>> I'm well aware the 4.0 will be branched on Monday, so once the merge is
>> approved, I can do the merge over the weekend including doing basic
>> regression for the networking key components on the merged branch.
>>
>>
>> -Alena.
>>
>>
>
>
Re: asf/vpc branch merge
Posted by Alena Prokharchyk <Al...@citrix.com>.
As I'm not a git expert, I would appreciate any help from the community in
figuring out what is the best way to merge vpc branch into master.
Couple of ways I can think of:
1) git checkout master; git merge -s recursive -Xignore-space-change vpc
Puts all commits from the vpc that are differnt from master, to the master
branch.
Pros:
* no tree rebase happens
* easier to revert individual commits if they cause any issues
* Have 0 conflicts after the merge is done (just tested on my local branch)
* Very close to vpc branch, so reduces the chances for regression bugs
(vpc branch was tested)
Cons:
* harder to track down all VPC commits as they've been happening for a
couple of months, and appear in the git log on the date they were
originally submitted.
2) Do interactive rebase on master from vpc and squash all the commits
into one
git checkout master; git rebase -i asf/vpc
Pros:
* Easier to see all VPC changes as they come as a part of a single commit
Cons:
* Requires rebase which leads to lots of conflicts.
* Not sure if there is an option to revert an individual commit happened
as a part of squashed commit.
I personally prefer way 1) as it doesn't lead to conflicts + leaves less
chances for regression bugs as the asf/master structure becomes very
similar to the structure of asf/vpc branch, and this branch was tested.
But let me know if anybody sees any downsides of doing the merge this way
and can suggest a better way.
Thank you,
-Alena.
On 8/10/12 10:33 AM, "Alena Prokharchyk" <Al...@citrix.com>
wrote:
>
>Considering that there is a code freeze happening soon, and as the main
>part for VPC feature development is complete + the VPC code
>has been well tested by cloudStack QA engineers, it's time to discuss
>merging the asf/vpc branch into asf/master. At this point its too hard to
>break it to several components-to-merge as there were too many single
>commits for the last couple of months from 7 developers involved in the
>process + we were doing the daily merges with master branch in order to
>keep asf/vpc branch up to date. It makes it hard to componentize at this
>point without running into lots of rebase conflicts
>
>So most likely it will be done as a single merge if
>the merge gets approved by the community. We would highly
>appreciate any help involving code/documentation review as well as any
>other suggestions on how to make this particular merge safer and smoother.
>And the suggestions made towards the merge process in general, will all be
>addressed in the future.
>
>We've tried to keep vpc branch in sync with asf/master by performing daily
>merges from master branch to vpc, so there shouldn't be too many
>conflicts. The VPC code went through several rounds of QA including the
>regression testing for existing network components. Most of the VPC code
>resides in the new classes added as a part of the feature; but some
>existing Network related code got some changes and can be considered for
>the review (NetworkManagerImpl/VirtualNetworkApplianceManager in
>particular as well as some Agent APIs and cloudStack UI). The VPC FS
>contains the reference to new classes (including client/agent APIs)
>created for the VPC feature (see the link below).
>
>
>Functional specification:
>
>http://wiki.cloudstack.org/display/RelOps/Inter-VLAN+Routing+functional+sp
>e
>c
>
>
>Engineer participated in VPC development:
>
>Sheng Yang - S2SVPN implementation
>Alena Prokharchyk - Client/Agent APIs,
>VpcManager/VpcVirtualNetworkApplianceManager/NetworkACLManager
>Anthony Xu - All VirtualRuter script changes + feature implementation for
>Xen resource
>Kelven Yang - Implementation for VmWare resource
>Sonny Chhan/Jessica Wang/Brian Federle - UI component
>
>
>QA test cases execution matrix:
>
>http://wiki.cloudstack.org/display/QA/Inter-VLAN+Test+Execution
>
>
>I'm well aware the 4.0 will be branched on Monday, so once the merge is
>approved, I can do the merge over the weekend including doing basic
>regression for the networking key components on the merged branch.
>
>
>-Alena.
>
>