Brigade: Parameter -f not working properly

[d46]

While creating a project by using -f parameter and giving an initial parameters project is creating but not working accurately. Projects are differentiating with their names as I understand. While creating from file I should set name in the JSON structure like (Without a name, I'm getting error.)

... 
"metadata": {
  "name": "some-name"
..
}
..

But while triggering webhooks and looking into logs in the brigade-github-app I see an error log something saying like

project brigade-XXXX not found.

At some point, it is generating a name for the project instead using the name from config for Kubernetes.

Also, I cannot delete the project from CLI which are created with -f (brig)

Output of brig version: v1.4.0

Output of kubectl version: 1.16

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Metal

[krancour]

What was the workflow you followed, exactly?

I have good results if I do this:

$ brig project create
? VCS or no-VCS project? VCS
? Project Name brigadecore/empty-testbed
? Full repository name github.com/brigadecore/empty-testbed
? Clone URL (https://github.com/your/repo.git) https://github.com/brigadecore/empty-testbed.git
? Add secrets? No
? Where should the project's shared secret come from?  [Use arrows to move, enter to select, type to filter, ? for more ? Where should the project's shared secret come from? Auto-generate one now
Auto-generated a Shared Secret: "173x08BZkmtps3tE24ObFHlt"
? Configure GitHub Access? No
? Configure advanced options No
Project ID: brigade-4897c99315be5d2a2403ea33bdcb24f8116dc69613d5917d879d5f

$ brig project get brigadecore/empty-testbed -o json > ~/proj.json

$ brig project delete brigadecore/empty-testbed

$ brig project create -f ~/proj.json --no-prompts
Project ID: brigade-4897c99315be5d2a2403ea33bdcb24f8116dc69613d5917d879d5f

$ brig project list
NAME                        ID                                                              REPO                                
brigadecore/empty-testbed   brigade-4897c99315be5d2a2403ea33bdcb24f8116dc69613d5917d879d5f  github.com/brigadecore/empty-testbed

Are you sure everything is good in the JSON you're pointing to?

[vdice]

I think the issue here is that there aren't any guard rails preventing a user from supplying any well-formed k8s secret (with the minimum expected fields from Brigade) via brig project create -f secret.json. As @krancour has shown, it seems that the _assumption_ is the user starts with a secret from a pre-existing project. But I don't see that explicitly stated in the CLI flag descriptions or Brigade documentation. And, indeed, I reproduce what @d46 sees if I supply my own/unadorned secret and create the project from it:

 $ cat test-project-secret.json
{
  "metadata": {
    "name": "mynewproject",
    "annotations": {
      "projectName": "mynewproject"
    }
  }
}
 $ b project create -f test-project-secret.json -x
Project ID: mynewproject

When I inspect a Brigade project (e.g. via brig project get myproject -o json) after creating it via brig project create, I see the following in the metadata section:

 $ brig project get myproject -o json
{
    "metadata": {
        "name": "brigade-9a76b440a0db5ffd45f655871fe955a3f7a2de2506333e71709d06",
        "creationTimestamp": null,
        "labels": {
            "app": "brigade",
            "component": "project",
            "heritage": "brigade"
        },
        "annotations": {
            "projectName": "myproject"
        }
    },
...

So it appears the common project name (myproject) is placed in metadata.annotations.projectName, while Brigade/brig assigns the metadata.name field a value according to its project ID pattern.

Therefore, I'm confused on why we have the support for creating projects from arbitrary k8s secrets (via -f) if Brigade/brig isn't behind the scenes either updating metadata.name to be a value according to the expected project ID pattern _or_ has a way to allow for (meaning, support finding/returning projects with) user-defined values for metadata.name.

[krancour]

@vdice I think you're right. There's an unstated assumption that the secret is a valid descriptor of a project. Besides being unstated, that assumption isn't validated anywhere, and it's probably opening the door to some unspecified behaviors.

The Brigade 2.0 prototype relies on a workflows like this more heavily. (Projects are always defined with a file instead of an interactive process.) In that prototype, the new API validates the projects using JSON schema.

There is no Brigade API here in 1.x where brig talks directly to the k8s API, but what do you think about adapting the approach a little? We could build some JSON schema right into brig and validate projects client-side before submitting them to k8s.

[vdice]

We could build some JSON schema right into brig and validate projects client-side before submitting them to k8s.

I could definitely see the utility in this. In the case of the user-supplied metadata.name field not adhering to Brigade's implicit expectations, would brig just return the error to the user -- or update the field itself? Do we think the schema validation for 1.x projects will be useful into 2.0, K8s-centric as it is currently? If so, I'd support the investment... if not, perhaps I'd be less enthusiastic.

Alternatively, I wonder if we should just clarify the current assumptions in the docs. Meaning (if I have this right), -f/--config is only meant to be used with a pre-existing/Brigade-created secret and for all other fresh/new project creation needs, brig project create (sans -f/--config) or helm install brigade/brigade-project should be used, as mentioned in the https://docs.brigade.sh/topics/projects docs.

[krancour]

In the case of the user-supplied metadata.name field not adhering to Brigade's implicit expectations, would brig just return the error to the user -- or update the field itself?

I definitely didn't think this far into it. 🤷‍♂️

Do we think the schema validation for 1.x projects will be useful into 2.0, K8s-centric as it is currently? If so, I'd support the investment... if not, perhaps I'd be less enthusiastic.

If Brigade 2.0 ends up looking anything like the prototype, then the domain model is different enough from 1.x that you couldn't share a schema between 1.x and 2.0.

The suggestion to use JSON schema client-side in 1.x is based on an assumption that it's something that could be banged out in an afternoon, and admittedly, that was with a supposition that the schema doesn't even need to be perfect, but just good enough to help sidestep known issues like this one.

Alternatively, I wonder if we should just clarify the current assumptions in the docs.

I'm also ok with that since I think we'd prefer seeing time spend on 2.0.

[d46]

Hey!! I wonder what is the use case of the -f / --config. If we assume that using for the pre-existing project that output will be project already exist the reason of identity duplication at metadata.name. So if we try to change the metadata.name field then the case will fall into my first case. Also, the same thing will happen for creating project after deleting the previous one because metadata.name is always changing.

Why I'm using -f / --config is that I'm generating projects configs with custom-workers and too many secret variables from CLI tool. Also, saving projects in a repo with their configs seems very clear way to store for me.

How about making a workaround for the name field instead of having an investment for 2.0? I'm really excited for 2.0 btw.

[vdice]

Hi @d46 , while we mull over a potential workaround specifically for this name field scenario (I agree, it may be worth the investment for this specific use case), I wanted to see if you've tried managing projects yet via the brigade-project Helm chart? See also https://docs.brigade.sh/topics/projects/#creating-and-managing-a-project-the-old-way

Since you mentioned favoring the approach of saving projects (with extensive secret config) in a repo, I thought I'd suggest the Helm chart approach, as that's exactly what I do for my Brigade projects. My personal repo of Brigade projects (I use Keybase) is then a collection of Helm chart values, each one representing project config. Admittedly, it requires some familiarity with Helm (project creation is then a helm install brigade/brigade-project -f my-project-values.yaml command, etc.)

[d46]

Helm way is completely what I want. I had missed out this on documentation. Thanks a lot!

I'm starting to use Keybase.. Very great product btw :)