-
Notifications
You must be signed in to change notification settings - Fork 16
Rebase instructions for versions 3.10
This is a how-to for syncing a given tag from service-catalog upstream and updating this repository. (Previous versions required a subtree merge into the openshift/origin repository, but that is no longer required.)
- git clone of service-catalog repo from
git@github.com:openshift/service-catalog.git - $
git remote add upstream https://github.com/kubernetes-incubator/service-catalog
Because git allows you to set up your remotes as you wish, we'll define the remotes by name and URL here:
$ git remote -v # in the service-catalog repo
jpeeler git@github.com:jpeeler/service-catalog.git (fetch)
jpeeler git@github.com:jpeeler/service-catalog.git (push)
origin git@github.com:openshift/service-catalog.git (fetch)
origin git@github.com:openshift/service-catalog.git (push)
upstream https://github.com/kubernetes-incubator/service-catalog (fetch)
upstream https://github.com/kubernetes-incubator/service-catalog (push)
(Note that in the above jpeeler should be your github user id.)
All of the following steps are for this repo.
$ git fetch upstream
2. Rebase master branch with the latest tag. This branch is used for master image builds and is checked in CI.
$ git checkout master
$ git rebase $TAG
$ git checkout -b $TAG-update
$ git push jpeeler
# create pull request
Once the pull request is done, there could potentially be a conflict with the Makefile.sc. file. Use the web console to fix the merge so that the CI run can be successful (otherwise CI will bail out due to the merge conflict).
Given the desire to atomically update the code along with the tag and since file conflicts should be rare, the pull request can be closed once CI is successful. The code can now be force pushed to master along with the tag:
$ git checkout master
$ git push origin --force-with-lease && git push origin $TAG
When updating non-master branches, the same exact process is followed including one extra step. There is an UPSTREAM-VERSION file that must be amended with the $TAG. This file is used to populate upstream version information in the enterprise builds since the tagging is done in a different repo and the upstream tags aren't carried over.
Start here when there's a new upstream release.
+
|
+--------------------v--------------------+
| GIT:kubernetes-incubator/service-catalog|
| 1 |
+--------------------+--------------------+
|
| rebase and push new tag
|
|
+---------------v---------------+
|GIT:openshift/service-catalog |
|2 |
+---------------+---------------+
The remaining notes are mostly OpenShift specific, but still applicable.
Upon code landing in the openshift/service-catalog repo, hack/build-release.sh is called. This script calls hack/build-images.sh, which contains a list of images and the directories containing the required Dockerfiles. Eventually, hack/push-release.sh is called which pushes the origin-service-catalog image to dockerhub.
When "oc cluster up --enable=service-catalog" is executed, the template in examples/service-catalog/service-catalog.yaml is used. (Technically it's not used directly, generated "bindata" is. There are several bindata golang sources that are created/updated via hack/update-generated-bindata.sh) The template has a variable for the service catalog image to use named SERVICE_CATALOG_IMAGE. The variable is currently set to openshift/origin-service-catalog:latest.
Changes to look for include:
- new Admission Controllers or image argument changes (check if charts/catalog/templates/apiserver-deployment.yaml has been changed upstream)
- RBAC changes that would need to be reflected in service-catalog-rbac.yaml as well.
If examples/service-catalog/service-catalog.yaml was updated in origin, you must regenerate bindata by running hack/update-generated-bindata.sh and adding the updated files (pkg/oc/bootstrap/bindata.go) to a new commit.
Double check for any necessary Origin SC deployment changes that should be made to the yaml deployment file (examples/service-catalog/service-catalog.yaml). Role changes? New Admission Controllers? Change in arguments? Review the commit for Service Catalog, specifically all changes in the charts sub directory.
Note that catalog renames may impact you here. In Origin, take a look at pkg/oc/bootstrap/docker/openshift/servicecatalog.go which is used to install Service Catalog. It creates Cluster Roles enabling admin to interact with Service Instance & Bindings, creates the Catalog namespace, instantiates the catalog services and registers the catalog API Server with the API Aggregator.
The Template Service Broker is registered with Service Catalog, API renaming could impact install/service-catalog-broker-resources/template-service-broker-registration.yaml
If you made changes to service-catalog.yaml or template-service-broker-registration.yaml you must run update-generated-bindata.sh
Update bindata
$ hack/update-generated-bindata.sh
This may result in changes to bindata.go, if so, include this in your commit.
In order to best test the rebase, rebuilding everything is best to ensure that openshift is in sync with service catalog. You can probably get away with just updating cmd/oc:
$ make build WHAT=cmd/oc
The purpose here is to ensure you pick up RBAC changes.
$ make
Create openshift/origin image with latest code & push to docker
$ hack/build-local-images.py
Build Service Catalog binary using openshift/service-catalog:
$ hack/env make build-images
Run oc cluster up with latest images
$ oc cluster up --tag=latest --enable=service-catalog --loglevel=5
Set the security context to admin for running e2e
$ oc login -u system:admin
Build the Service Catalog E2E test in the openshift/service-catalog repo
upstream:
$ make -f Makefile.sc bin/e2e.test
openshift:
$ OS_BUILD_ENV_PRESERVE=bin/ hack/env NO_DOCKER=1 make -f Makefile.sc bin/e2e.test
Setup environment and run E2E
$ export KUBECONFIG=~/.kube/config
$ SERVICECATALOGCONFIG=$KUBECONFIG bin/e2e.test -v 10 -alsologtostderr -broker-image openshift/user-broker:canary
You can also manually execute the e2e and add additional options:
* enable verbose output: -v 10 -alsologtostderr
* specify specific tests: -ginkgo.focus= where is either walkthrough, ServiceBroker or ServiceInstance
$ bin/e2e.test -v 10 -alsologtostderr -ginkgo.focus=ServiceBroker