Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandbox debugging #89

Merged
merged 5 commits into from
Aug 7, 2024
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 19 additions & 2 deletions .vscode/launch.json
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,6 @@
"program": "${workspaceFolder}/cmd/porch/main.go",
"args": [
"--secure-port=4443",
// "--v=7",
// "--standalone-debug-mode",
"--kubeconfig=${env:KUBECONFIG}",
"--cache-directory=${workspaceFolder}/.cache",
"--function-runner=172.18.255.201:9445",
Expand All @@ -25,6 +23,25 @@
"WEBHOOK_HOST": "localhost"
}
},
{
"name": "Launch Override Server",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/porch/main.go",
"args": [
"--secure-port=4443",
"--kubeconfig=${userHome}/.kube/config",
"--cache-directory=${workspaceFolder}/.cache",
"--function-runner=172.18.0.202:9445",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the IP of the function-runner the only difference between "Launch Server" and "Launch Override Server"? If yes, could we avoid copy-pasting here by using e.g. environment variables?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or even better can we use the same IP in both setups? What prevents this?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would vote for the environmental variable approach.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed in the latest PR.

"--repo-sync-frequency=60s"
],
"cwd": "${workspaceFolder}",
"env": {
"CERT_STORAGE_DIR": "${workspaceFolder}/.build/pki/tmp",
"WEBHOOK_HOST": "localhost"
}
},
{
"name": "Launch Controllers",
"type": "go",
Expand Down
46 changes: 46 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
MYGOBIN := $(shell go env GOPATH)/bin
BUILDDIR=$(CURDIR)/.build
CACHEDIR=$(CURDIR)/.cache
export DEFAULTPORCHCONFIGDIR ?= /tmp/kpt-pkg/nephio/core/porch
export DEPLOYPORCHCONFIGDIR ?= $(BUILDDIR)/deploy
DEPLOYKPTCONFIGDIR=$(BUILDDIR)/kpt_pkgs
PORCHDIR=$(abspath $(CURDIR))
Expand Down Expand Up @@ -256,6 +257,26 @@ run-in-kind-no-controller: IMAGE_TAG=test
run-in-kind-no-controller: SKIP_CONTROLLER_BUILD=true
run-in-kind-no-controller: load-images-to-kind deployment-config-no-controller deploy-current-config ## Build and deploy porch without the controllers into a kind cluster

.PHONY: run-default
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we achieve the same effect by something similar to the following process:

  • add these lines to the bashrc of the sandbox VM:
export DEPLOYPORCHCONFIGDIR=/tmp/kpt-pkg/nephio/core/porch
export KIND_CONTEXT_NAME=<whatever is the name of the kind cluster in the Nephio sandbox :)>
  • reuse the existing make targets: run-in-kind-*

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the simplest solution IMO is to undeploy the porch instance that was deployed by the ansible playbook (call kpt live destroy /tmp/kpt-pkg/nephio/core/porch) and then reinstall it with make run-in-kind. and then use the same development process that is currently documented.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the simplest solution IMO is to undeploy the porch instance that was deployed by the ansible playbook (call kpt live destroy /tmp/kpt-pkg/nephio/core/porch) and then reinstall it with make run-in-kind. and then use the same development process that is currently documented.

The problem there is that if you uninstall, it undefines all the package variants and packagerevisions that are put in place by the Nephio install.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we achieve the same effect by something similar to the following process:

* add these lines to the bashrc of the sandbox VM:
export DEPLOYPORCHCONFIGDIR=/tmp/kpt-pkg/nephio/core/porch
export KIND_CONTEXT_NAME=<whatever is the name of the kind cluster in the Nephio sandbox :)>
* reuse the existing make targets: `run-in-kind-*`

The problem I had was that I couldn't get kpt to play nicely with the old and new package. I tried to use the existing targets but because the underlying kpt wouldn't work, they failed. Maybe you could take a look @kispaljr

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the simplest solution IMO is to undeploy the porch instance that was deployed by the ansible playbook (call kpt live destroy /tmp/kpt-pkg/nephio/core/porch) and then reinstall it with make run-in-kind. and then use the same development process that is currently documented.

The problem there is that if you uninstall, it undefines all the package variants and packagerevisions that are put in place by the Nephio install.

OK, I will try this out

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way a tiny opinion, is it possible to use _ like DEFAULT_PORCH_CONFIG_DIR it increases the readability.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is all changed int he new version of the PR.

run-default: undeploy-config deploy-default-config ## Run the default deployment in $(DEFAULTPORCHCONFIGDIR) in kind

.PHONY: run-override-in-kind
run-override-in-kind: IMAGE_REPO=porch-kind
run-override-in-kind: IMAGE_TAG=test
run-override-in-kind: undeploy-config load-images-to-kind deployment-config deploy-override-config ## Run the override deployment in $(DEPLOYPORCHCONFIGDIR) in kind

.PHONY: run-override-in-kind-no-server
run-override-in-kind-no-server: IMAGE_REPO=porch-kind
run-override-in-kind-no-server: IMAGE_TAG=test
run-override-in-kind-no-server: SKIP_PORCHSERVER_BUILD=true
run-override-in-kind-no-server: undeploy-config load-images-to-kind deployment-config-no-server deploy-override-config ## Run the override deployment in $(DEPLOYPORCHCONFIGDIR) in kind without the porch server

.PHONY: run-override-in-kind-no-controller
run-override-in-kind-no-controller: IMAGE_REPO=porch-kind
run-override-in-kind-no-controller: IMAGE_TAG=test
run-override-in-kind-no-controller: SKIP_CONTROLLER_BUILD=true
run-override-in-kind-no-controller: undeploy-config load-images-to-kind deployment-config-no-controller deploy-override-config ## Run the override deployment in $(DEPLOYPORCHCONFIGDIR) in kind without the porch controller

.PHONY: destroy
destroy: ## Deletes all porch resources installed by the last run-in-kind-* command
kpt live destroy $(DEPLOYPORCHCONFIGDIR)
Expand Down Expand Up @@ -329,6 +350,31 @@ deploy-current-config: ## Deploy the configuration that is currently in $(DEPLOY
@kubectl rollout status deployment porch-server --namespace porch-system 2>/dev/null || true
@echo "Done."

.PHONY: deploy-default-config
deploy-default-config: ## Deploy or redeploy the default Porch deployments in $(DEFAULTPORCHCONFIGDIR)
kubectl apply -f $(DEFAULTPORCHCONFIGDIR)/2-function-runner.yaml
kubectl apply -f $(DEFAULTPORCHCONFIGDIR)/3-porch-server.yaml
kubectl apply -f $(DEFAULTPORCHCONFIGDIR)/9-controllers.yaml

.PHONY: deploy-override-config
deploy-override-config: ## Deploy the override Porch deployments in $(DEPLOYPORCHCONFIGDIR)
kubectl apply -f $(DEPLOYPORCHCONFIGDIR)/9-controllers.yaml
kubectl apply -f $(DEPLOYPORCHCONFIGDIR)/3-porch-server.yaml
kubectl apply -f $(DEPLOYPORCHCONFIGDIR)/3-porch-server-endpoints.yaml || true
kubectl apply -f $(DEPLOYPORCHCONFIGDIR)/2-function-runner.yaml
kubectl expose svc -n porch-system function-runner --name=xfunction-runner --type=LoadBalancer --load-balancer-ip='172.18.0.202'

.PHONY: undeploy-config
undeploy-config: ## Undeploy the default Porch deployments in $(DEFAULTPORCHCONFIGDIR) and $(DEPLOYPORCHCONFIGDIR)
kubectl delete -f $(DEFAULTPORCHCONFIGDIR)/9-controllers.yaml || true
kubectl delete -f $(DEFAULTPORCHCONFIGDIR)/3-porch-server.yaml || true
kubectl delete -f $(DEFAULTPORCHCONFIGDIR)/2-function-runner.yaml || true
kubectl delete -f $(DEPLOYPORCHCONFIGDIR)/9-controllers.yaml || true
kubectl delete -f $(DEPLOYPORCHCONFIGDIR)/3-porch-server-endpoints.yaml || true
kubectl delete -f $(DEPLOYPORCHCONFIGDIR)/3-porch-server.yaml || true
kubectl delete -f $(DEPLOYPORCHCONFIGDIR)/2-function-runner.yaml || true
kubectl delete svc -n porch-system xfunction-runner || true

PKG=gitea-dev
.PHONY: deploy-gitea-dev-pkg
deploy-gitea-dev-pkg:
Expand Down
Loading