Introduce the airy create command

[ljupcovangelski]

This issue is about introducing the airy create command. At first we ignore how the Kubernetes cluster is created and we are only expecting the path of the kubeconfig. So the command should roughly look like this

airy create --kubeconfig=./kube.conf

The default location for the kubeconfig should be ~/.airy/kube.conf, which is now created by the ./scripts/bootstrap.sh.

We will further discuss the flags later in the comments to the issue.

In order to accomplish this, the whole bash provisioning needs to be rewritten. Here are the required steps and the other relqted issues:

• [x] Provision the kafka topics with a kubernetes job #1016
• [x] Deploy the kubernetes resources from helm templates #1014
• [x] Create traefik ingress controller in the kubernetes cluster
• [x] Change the hostnames for core #1022
• [x] Apply scheduling and waiting for resources to be there #1015
• [ ] Print out messages about how to access and start using Airy Core
• [x] Introduce the minikube provider #1041

After this issue is finished, we can proceed with how do we create the kubernetes cluster, both locally and in the cloud.

(The original issue was intended for a different purpose. The description was added after the first round of discussions).

[lucapette]

from #1020

After the successful creation of Airy Core, we need to print-out the output for how to access the platform.

Currently we print out:

The webhooks
The API endpoint
Info about how to create the first user.

Definitely part of the requirement here is defining the output. But, to be fair, I think we should start from the way the command UI looks like. Here's some early questions:

• We can do providers in two ways (at least I can think of two but probably there's more):
  • airy create --provider=local --args etc...
  • airy create local --args etc.. When I thought about this, I assumed I'd like the former more but now that I see them written down I think the latter is better: it's more explicit, no need for funky work on args that are provider dependent, each command gets its own docs/description.
• What does the command exactly do? From what I'm reading in #1015 I think there's some confusion about this and lack of clarity (I didn't even think we'd have an airy start command at first as I personally assumed airy create would do the exact same thing that we have now with the bootstrap. after all that's the main goal here: get rid of the bootstrap script in a way we can have multiple providers much more easily)
• What's the output? I think we should define this a little upfront. It will also clarify in detail: the steps we have to build, the different responsibilities of each step. I will propose something about this later today. I want to think bout it for a minute and the previous questions are more important

[bitboxer]

Maybe also adding a link to a docs page that says: horray for installing and running airy. Here are three awesome things you can do with it 🤔 ?

[pascal-holy]

👍 for airy create local. Since the two deployment options are so different it makes sense to also document them in more detail than it would be possible on a flag.

I think it is ok to say Minikube is a requirement for Airy Core and that the users should install it on their own. In case they already have Minikube and are using it for something else they can use the namespace feature.

We should also discuss where the airy.yaml comes into place. We could copy it to the local machine on airy init and ask the user to modify it to their needs before executing the create. This means we should also have a --config flag on the create that you pass the path to the airy.yaml

The next thing we need are the helm charts. I would actually stick with Helm since it does a lot of work for us and can even do more for us with this new way of deploying. For example, we could get the helm charts from the repo directly instead of cloning them to the local machine.

[ljupcovangelski]

As I understood from the discussion, we split the issues in two big sections:

1. How do we create the kubernetes cluster (1.1 How do we create it locally, 1.2. How do we create it in AWS, 1.3. How do we create it in GCP, ...)
2. Once the Kubernetes cluster is there, how do we provision all the airy components, start them one by one and print out the message on how it can be accessed.

I imagined this issue to be only about the 1.1 part. How do we create the Kubernetes cluster locally. As I understood the discussion, talking directly to VirtualBox to create an instance and use Alpine+k3s on top.

In terms of the airy start command, that is a different topic for now. The command which will create Airy Core with all of its components until one can successfully use it is airy create.

About the flag, I vote for having a flag, as it is more clear like that to me. Otherwise, I find airy create aws a bit strange.

airy create --provider=local
airy create --provider=aws
airy create --provider=gcp

Just a note that every different provider will probably require its own flags (example: airy create --provider=aws --aws-profile=prod)

[lucapette]

I think now that I can see both proposal on paper, I agree with @ljupcovangelski about the high-level UI. airy create --provider=aws plus aws prefixed args is really nice.

As for creating the cluster locally, I do agree with @pascal-airy that is ok to require them to provide a minikube (technically though, I think we'll ask them to point us to a valid/working kube.conf so we wouldn't even need to depend on minikube. We can suggest to use that in the docs though. And I would because minikube is real nice). Having the local provider working with virtualbox would make the local provider "special" as it's the only one that would require us to create an image so there's that as well. Asking the user to point airy create to a kube.conf is fair enough (I think) and requires a lot less work on our side. Hopefully, we'll make it so easy to run it in the cloud that most people will choose that option anyway.

@pascal-airy raises a good point about the airy.yaml. But I think it's out of the responsibility of the airy create command, at least initially. So I propose this workflow:

• airy create creates core according to the provider config provided
• the command starts what we think it's good defaults (what we now have as default is good for now)
• we write in the docs "use airy.aml" for configuring parts of it

As for the output, I'm thinking we should provide high level step-by-step messages:

• ⚙️ Creating core with provider X
• 🚀 Starting core with default config (link to the docs for config here)
• 🎉 Your Airy Core is ready:
  • link to the api url
  • link to the ui
  • link to more docs

Maybe "too fancy" but I'd love to provide a little progressbar next to each message that goes away once the step is completed. It would provide a sense of progress.

As I see it, apart from what I just wrote here in the comments the only missing thing from the description of this issue (so that we can start working on it aka remove the needs discussion label) is a step in the todo list about treafik? As I understand it we don't mention that anywhere but there's no way around it?

[ljupcovangelski]

* `airy create` creates core according to the provider config provided

Do you mean the kubernetes config perhaps? Because currently airy create doesn't depend on a specific provider.

* we write in the docs "use airy.aml" for configuring parts of it

@pascal-airy if I understand correctly, I like your proposal to do:

airy create --kube-config=kube.conf --config=airy.yaml

At the end of the create command, if a config file is specified we also do config apply

As for the output, I'm thinking we should provide high level step-by-step messages:

* tada Your Airy Core is ready:

  * link to the api url
  * link to the ui
  * link to more docs

For this information we need the loadbalancer, which is provider dependent.

As I see it, apart from what I just wrote here in the comments the only missing thing from the description of this issue (so that we can start working on it aka remove the needs discussion label) is a step in the todo list about treafik? As I understand it we don't mention that anywhere but there's no way around it? Included.

I don't understand what do we want exactly, do we want to leave the option for different local Kubernetes deployments? I thought that airy create --provider=local is VirtualBox+k3s.

[lucapette]

So no I do mean what I said about airy create, from the perspective of the user the details don't matter. airy create creates the core instance "somewhere in the provider".

I don't think it makes sense to mix create and configuration. At least short term. It would also make it harder for people to test things anyway. And the airy config apply is very fast/friendly anyway.

About the output being provider dependent... that's kind of always true. Especially if we want to provide a progress bar. What I wanted to focus on is the formatting/style of the output.

As for the local provider, we should have an issue where we discuss how we do this. (I don't think we should rely on virtualbox, as @pascal-airy said we can get away by asking the user to point airy create to their local cluster via minikube)

[ljupcovangelski]

I agree for the configuration part. So we would have a two-step process.

airy create... (generates kube.conf file at the end)
airy config apply --kube-config=kube.conf --config=airy.yaml

[paulodiniz]

👍 I really like the way the @lucapette talked about this

The airy command only speaks kubernetes language

Having said that, the output of airy create is a kube.conf file which is stored locally (maybe it points to a cloud provider, but the conf file is always stored locally). So why do we need a airy config apply ?

Isn't airy config apply a step of the create command?

[lucapette]

👍 I really like the way the @lucapette talked about this

The airy command only speaks kubernetes language

Having said that, the output of airy create is a kube.conf file which is stored locally (maybe it points to a cloud provider, but the conf file is always stored locally). So why do we need a airy config apply ?

Isn't airy config apply a step of the create command?

I think it can be but it doesn't have to be. And my position short term is "let's ignore the config of the instance itself" as it brings a lot of "catch-22" kind of problems into the conversation (things like: should you have a config already somewhere? does the CLI need to "template it" for you? the UX then looks strange as you first configure then create?). So I'm not saying we should never do this, I'm saying let's ignore the problem and refine it once we have the infra of the airy create command done. That way we'll also have a more informed opinion about how to go with creation vs configuration of the instance

[paulodiniz]

I've update https://github.com/airyhq/airy/pull/1084

• Default provider is aws
• kubeconfig parameter is hidden
• Command "speaks" kubernetes

[lucapette]

done in #1240