feat: deploy-cli for scaffolding

[abhimanyu003]

This is moved from
https://github.com/RSS-Engineering/undercloud-deploy-cli

All the steps on how to run are README as well.

How to run

1. Export all these env

export UC_DEPLOY="<full_local_path_to_undercloud_deploy_repo>"
export DEPLOY_NAME="<cluster_name>"
export UC_DEPLOY_GIT_URL=git@github.com:RSS-Engineering/undercloud-deploy.git
export UC_DEPLOY_SSH_FILE=<path_to_ssh_private_key_file>
export DNS_ZONE=<cluster_name>.dev.undercloud.rackspace.net
export UC_DEPLOY_EMAIL="<your_email>"
export UC_AIO=yes

2. go run *.go all
3. go run *.go help

Note: go run *.go is only used during dev if you don't have binary locally, or like to test changes.

[cardoe]

Overall I think it covers what we've got and really shows the gaps of how we want to improve. Looking at this and the diff tool makes me think about some k8s integration for that and bringing it to this as another sub command.

[cardoe]

Maybe a "goal" flow of this is...

# install understack

understack deploy init $DEPLOY_NAME # where it makes `pwd/$DEPLOY_NAME` and populates a directory structure?

A lot of those environment variables are a one time thing or not even needed if you're using a separate ArgoCD without baking it into your combined cluster.

[skrobul]

what do you think about removing the dependency on the kubeseal binary and using the package directly?

[cardoe]

what do you think about removing the dependency on the kubeseal binary and using the package directly?

I honestly don't even want to have kubeseal a requirement but some step that prior to committing your secrets you do something with them.

[abhimanyu003]

what do you think about removing the dependency on the kubeseal binary and using the package directly?

That is what I was thinking as well, I have to check how it's working as it's having lots of parameter.

[cardoe]

These were still there from my prior review.

[cardoe]

❯ go run *.go help
2025/04/23 10:00:13 WARN DNS_ZONE env not set for shell
exit status 1

I cannot see the help without having DNS_ZONE as an environment variable.

[cardoe]

Maybe a "goal" flow of this is...

# install understack

understack deploy init $DEPLOY_NAME # where it makes `pwd/$DEPLOY_NAME` and populates a directory structure?

A lot of those environment variables are a one time thing or not even needed if you're using a separate ArgoCD without baking it into your combined cluster.

So I see the name is still the same. Not that understack is a good binary name but were you planning on changing that in a follow on?

Further I think requiring the env vars all the time (and the DNS_ZONE to even see help) isn't where we want to go. As I've played with this further I think we save some of these values.

understack deploy [--deploy-path $UC_DEPLOY] init $DEPLOY_NAME

Where --deploy-path defaults to the value of $UC_DEPLOY and lastly current working directory if unset entirely? It then creates a $DEPLOY_NAME directory and inside that directory we can create config.yaml with the contents...

---
name: $DEPLOY_NAME

Then we can have further operations to set dns_zone in that file. Then it can be used for all other commands?

[cardoe]

So biggest review comment would be to have a more descriptive commit messages in the end.

[cardoe]

We'll iterate further in tree.