Installation method that doesn't require a Git checkout + make

[mkjpryor]

It would be really nice to have an installation method for the AWX operator that doesn't rely on the presence of Git and make.

A Helm chart would be perfect, but even static manifests would be better than the current method IMHO.

[shanemcd]

Maybe we could have a workflow that runs on the release published event, that uploads the output of the target introduced in https://github.com/ansible/awx-operator/pull/627 as a release asset. To support overriding the namespace, we could document how to use with kubectl kustomize.

I'm about to disappear on vacation for about a month, so I won't be working on this any time soon. If someone wants to send a PR, I'd be happy to review when I return.

[Throckmortra]

+1, current installation method makes this difficult to create IAC for

[shanemcd]

Folks, please don't leave comments like this ^. GitHub allows for adding 👍 to the issue itself. The only thing you're doing here is creating notification spam.

[hungtran84]

@mkjpryor you can make use of kustomize with any k8s operator such as Argo CD, FluxCD, Jenkins X to deploy it. Depend on your environment, you can tweak it a bit to make awx deploy/setup totally IAC.

For my large-scale environment, I would have multiple AWX instances in the different Azure AKS clusters and have them integrated with self-hosted Active Directory. Moreover, I can also load AWX secrets from Azure Keyvault as well.

[mkjpryor]

@hungtran84

How do you do that without a git clone and make deploy? Those are the bits I am trying to avoid.

[hungtran84]

get the version that you want to deploy to your environment, have it checked in your own/private repo and restructure it to meet your requirement.

For example (in my case):

ops/awx
├── base
│   ├── awx-instances
│   │   ├── akv-secrets.yaml
│   │   ├── awx.yaml
│   │   ├── ingress.yaml
│   │   └── kustomization.yaml
│   └── awx-operator
│       ├── kustomization.yaml
│       └── operator.yaml
└── overlays
    └── staging
        ├── awx-instances
        │   ├── akv-secrets_patch.yaml
        │   ├── awx_patch.yaml
        │   ├── ingress_patch.yaml
        │   └── kustomization.yaml
        └── awx-operator
            ├── kustomization.yaml
            └── manager_patch.yaml

In the end, let any CD tool automatically scan/deploy/update your AWX operator and instance. ArgoCD is very good candidate.

[mkjpryor]

@hungtran84 It looks like you are proposing manually maintaining my own installation.

That is exactly what I want to avoid as I don't want to have to remember to update the manifests every time a new operator version is released and risk missing something.

Something like a Helm chart for installing the operator or the ability to install with the OLM is what I am after, where each person who wants to install the AWX operator without git clone and make doesn't need to have their own set of manifests...

This is especially irritating now that the operator is namespaced, and requires a separate installation for every namespace.

[mkjpryor]

For anyone who is interested, I made this for my own usage: https://github.com/stackhpc/awx-operator-helm

I can't promise it will be maintained, but it works for 0.15.0.

Essentially, manifests generated using make gen-resources then a limited number of variables added to customise things like the image used and the resource requests and limits.

[davidkarlsen]

Should this issue be closed now, as it seems to template all things:

helm fetch && tar xzf:

tree
.
├── awx-operator
│   ├── Chart.yaml
│   ├── README.md
│   ├── templates
│   │   ├── NOTES.txt
│   │   ├── _helpers.tpl
│   │   ├── awx-deploy.yaml
│   │   ├── clusterrole-awx-operator-metrics-reader.yaml
│   │   ├── clusterrole-awx-operator-proxy-role.yaml
│   │   ├── clusterrolebinding-awx-operator-proxy-rolebinding.yaml
│   │   ├── configmap-awx-operator-awx-manager-config.yaml
│   │   ├── customresourcedefinition-awxbackups.awx.ansible.com.yaml
│   │   ├── customresourcedefinition-awxrestores.awx.ansible.com.yaml
│   │   ├── customresourcedefinition-awxs.awx.ansible.com.yaml
│   │   ├── deployment-awx-operator-controller-manager.yaml
│   │   ├── postgres-config.yaml
│   │   ├── role-awx-operator-awx-manager-role.yaml
│   │   ├── role-awx-operator-leader-election-role.yaml
│   │   ├── rolebinding-awx-operator-awx-manager-rolebinding.yaml
│   │   ├── rolebinding-awx-operator-leader-election-rolebinding.yaml
│   │   ├── service-awx-operator-controller-manager-metrics-service.yaml
│   │   └── serviceaccount-awx-operator-controller-manager.yaml
│   └── values.yaml
└── awx-operator-0.25.0.tgz

2 directories, 22 files

the CRDs should probably go into the crd directory: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

update: actually CRDs seems OK now: https://github.com/ansible/awx-operator/blob/c23001681990cf8bb670f7c6adc36491adbb7a7d/Makefile#L299 - maybe the latest has not yet been published?