Re: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and Nodepool repos

2018-01-18 Thread Darragh Bailey 
Hi Clark,


You might find the following series of commands help automate this a little
more.

git merge -s ours --no-commit feature/zuulv3
git read-tree -u --reset feature/zuulv3
git commit -m "replace mainline with feature/zuulv3"

Basically it replaces the current branch contents with everything that came
from feature/zuulv3, so no risk that changes get merged at all, whatever
was on the master branch is ignored.

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

On 12 Jan 2018 22:43, "Clark Boylan"  wrote:

> Hello,
>
> I think we are very close to being ready to merge the zuulv3 feature
> branch into master in both the Zuul and Nodepool repos. In particular we
> merged https://review.openstack.org/#/c/523951/ which should prevent
> breakages for anyone using that deployment method (single_node_ci) for an
> all in one CI suite.
>
> One thing I've noticed is that we don't have this same handling in the
> lower level individual service manifests. For us I don't think that is a
> major issue, we'll just pin our builders to the nodepool 0.5.0 tag, do the
> merge, then update our configs and switch back to master. But do we have
> any idea if it is common for third part CI's to bypass single_node_ci and
> construct their own like we do?
>
> As for the actual merging itself a quick test locally using `git merge -s
> recursive -X theirs feature/zuulv3` on the master branch of nodepool
> appears to work. I have to delete the files that the feature branch deleted
> by hand but otherwise the merge is automated. The resulting tree does also
> pass `tox -e pep8` and `tox -epy36` testing.
>
> We will probably want a soft freeze of both Zuul and Nodepool then do our
> best to get both merged together so that we don't have to remember which
> project has merged and which hasn't. Once that is done we will need to
> repropose any open changes on the feature branch to the master branch,
> abandon the changes on the feature branch then delete the feature branch.
> Might be a good idea to merge as many feature branch changes as possible
> before hand?
>
> Am I missing anything?
>
> Thank you,
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and Nodepool repos

2018-01-15 Thread James E. Blair 
Clark Boylan  writes:

> Hello,
>
> I think we are very close to being ready to merge the zuulv3 feature
> branch into master in both the Zuul and Nodepool repos. In particular
> we merged https://review.openstack.org/#/c/523951/ which should
> prevent breakages for anyone using that deployment method
> (single_node_ci) for an all in one CI suite.
>
> One thing I've noticed is that we don't have this same handling in the
> lower level individual service manifests. For us I don't think that is
> a major issue, we'll just pin our builders to the nodepool 0.5.0 tag,
> do the merge, then update our configs and switch back to master. But
> do we have any idea if it is common for third part CI's to bypass
> single_node_ci and construct their own like we do?
>
> As for the actual merging itself a quick test locally using `git merge
> -s recursive -X theirs feature/zuulv3` on the master branch of
> nodepool appears to work. I have to delete the files that the feature
> branch deleted by hand but otherwise the merge is automated. The
> resulting tree does also pass `tox -e pep8` and `tox -epy36` testing.
>
> We will probably want a soft freeze of both Zuul and Nodepool then do
> our best to get both merged together so that we don't have to remember
> which project has merged and which hasn't. Once that is done we will
> need to repropose any open changes on the feature branch to the master
> branch, abandon the changes on the feature branch then delete the
> feature branch. Might be a good idea to merge as many feature branch
> changes as possible before hand?
>
> Am I missing anything?
>
> Thank you,
> Clark

Thanks for looking into that!

I don't think we're in a great position to merge a lot of the
outstanding changes on the feature branch -- many of them are post 3.0
things and I don't want to distract us from stabilizing and finalizing
the release.  We may just want to plan on porting a bunch over.

Let's plan on performing the merge this Thursday, Jan 18th.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and Nodepool repos

2018-01-12 Thread Clark Boylan 
Hello,

I think we are very close to being ready to merge the zuulv3 feature branch 
into master in both the Zuul and Nodepool repos. In particular we merged 
https://review.openstack.org/#/c/523951/ which should prevent breakages for 
anyone using that deployment method (single_node_ci) for an all in one CI suite.

One thing I've noticed is that we don't have this same handling in the lower 
level individual service manifests. For us I don't think that is a major issue, 
we'll just pin our builders to the nodepool 0.5.0 tag, do the merge, then 
update our configs and switch back to master. But do we have any idea if it is 
common for third part CI's to bypass single_node_ci and construct their own 
like we do?

As for the actual merging itself a quick test locally using `git merge -s 
recursive -X theirs feature/zuulv3` on the master branch of nodepool appears to 
work. I have to delete the files that the feature branch deleted by hand but 
otherwise the merge is automated. The resulting tree does also pass `tox -e 
pep8` and `tox -epy36` testing.

We will probably want a soft freeze of both Zuul and Nodepool then do our best 
to get both merged together so that we don't have to remember which project has 
merged and which hasn't. Once that is done we will need to repropose any open 
changes on the feature branch to the master branch, abandon the changes on the 
feature branch then delete the feature branch. Might be a good idea to merge as 
many feature branch changes as possible before hand?

Am I missing anything?

Thank you,
Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra