Automate Onboarding to Cluster via CLI

[HumairAK]

The steps here should be automated via the opfcli. The tricky part would be handling pgp keys.

Starting out the opfcli should take a config file that essentially imitates the fields from the onboarding issue templated found here.

onboarding_template:
  team_name: example_team
  list_of_namespaces:
    - name: ns_1
      quota: medium
      enable_monitoring: true
    - name: ns_2
      quota: large
      enable_monitoring: false
  list_of_users:
    - user_1
    - user_2
  project_description: "example description"
  env: MOC
  cluster: ZERO
  optional_pgp_keys:
    - key_1
    - key_2

Then for onboarding we can pass it to the cli like so:

$ opfcli onboard cluster --onboard-config config.yaml

cluster should be a subcommand of onboard which should be a subcommand of opfcli (eventually want to add other onboarding subcommands like opfcli onboard argocd).

Currently some of the logic for this process is already implemented, so this sub-command should just be calling that logic. Then add the additional bits for adding the resources to the appropriate cluster/env.

The next step following this issue will be to eventually have people fill out a yaml/form and have a bot perform the PR by running this cli command.

[tumido]

I think for the UX it would be better to support both of these 2 options:

1. Declarative - like the YAML you've mentioned
2. Interactive - like a wizard (imagine npm init or inquirer that I know from the JS world - I'd prefer to have this in golang in the end though...)

It think this ties back to the ultimate CLI idea we brainstormed some time ago (with no resolution as far as I remember). Ideally it would be nice to have an interactive/declarative wrapper around all these different tasks we'd like to automate.

[HumairAK]

one issue I'm seeing is right now we have a few scripts in bash, one in python (that @larsks has worked on) we will need to narrow down to one language if we are to wrap these, lest we start calling bash / python scripts from golang or something (yuck).

[HumairAK]

also tagging @ipolonsk as she has been helping with automating

[larsks]

@HumairAK I think we should open a separate issue for that discussion.

[HumairAK]

depends on: https://github.com/operate-first/apps/issues/637

[tumido]

@goern does Thoth/AICoE-CI use anything for parsing keywords from filed GH issues? Is there anything that we can use to extract data from an issue and feed it to the opfcli?

[HumairAK]

@larsks @tumido @4n4nd -- I've updated the issue body to reflect the implementation within the cli (before it was a script). If you have feedback/suggestions/improvements please suggest them.

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[HumairAK]

/remove-lifecycle stale

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[HumairAK]

/remove-lifecycle rotten

[goern]

/lifecycle frozen
/kind feature
/priority backlog

[Gregory-Pereira]

Since #44 got merged, can I close this issue? Or should I wait for the related changes in the notebook image or aicoe-ci task?