Brigade: META: Brigade 1.0.0

[technosophos]

This ticket is a placeholder for capturing the Brigade 1.0.0 requirements. We have three major areas to polish before Brigade 1.0.0: Installation, Core, and UX

Installation

• [x] Create new repo with all charts for Brigade (Kashti, gateways, etc) _updated Oct 2018_ https://github.com/Azure/brigade/issues/718
  
  
  
  • [x] Improve the brigade chart to make it easier to configure edit (vadice): sounds like including Kashti (as below) was the main task here; so marking as done
  
  
  • [x] Kashti included in base Brigade chart (and documented) https://github.com/Azure/brigade-charts/issues/7
  
  
  • [x] Include other gateway charts here https://github.com/Azure/brigade/issues/718
  
  
• [x] Add brig dashboard command to open tunnel to Kashti and then connect to browser
• [x] brig project create|delete|update commands added
  
  
  
  • [x] And the deprecation of the brigade-project chart
  
  
  • [x] And the documentation of using kubectl edit to edit a brig project
  
  
  • [x] Remove the brigade-project chart
  
  
  • [x] Bring brigade project create into parity with the current chart #745
  
  
• [x] Add generic webhook support to API server (and make it configurable to turn off) #602
• [x] GitHub moved to new gateway #746

Core/Internals 🎉

• [x] Make Kashti nginx proxy traffic to the API server #535
• [x] Fix sort order bugs on API server post-cache update (See #511)
• [x] Improve Git sidecar (cf. #668)
• [x] Extract brigadier into external library and then use it within brigade worker #584

User Experience

• [x] Improve documentation #747
• [x] Examples and tutorials for common Brigade scenarios #748 -> moved to v1.1
• [x] [Kashti - project board](https://github.com/Azure/kashti/projects/4) - The Kashti project board can be tracked independently (vdice)

[squillace]

+1 :-)

[technosophos]

Made a few updates to this based on feedback from core devs and PMs. Changes are tagged update.

/cc @squillace @radu-matei

[lukepatrick]

Is brig project create intended to replace helm install brigade-project or helm inspect values brigade/brigade-project > myvalues.yaml ?

[technosophos]

Both (with an option to still edit a file by hand). Here's what my WIP looks like:

[lukepatrick]

Cool. This is a great list for 1.0 reqs, I think you hit the core categories of polish.

[bacongobbler]

I can take a look at the brig dashboard command. We had something similar in the deis CLI to open the web UI in the OS's default browser.

[bacongobbler]

In regards to making Kashti installed by default, do we wanna bring kashti into brigade's core, or continue to keep it as a separate project, loosely tied through the Helm chart that installs brigade?

I can see both sides of the coin here: if we want to have a separate roadmap for kashti then we should probably keep it separate, but if we want to keep brigade and kashti development closely tied together (e.g. if we make changes to brigade-api that'd affect kashti), then we should probably bring it in.

Any general thoughts on this? :)

[technosophos]

Here's my $0.02:

• Leave Kashti in its own repo
• Create a brigade-charts repo and put _all_ of the Brigade charts there
• Make the Kashti chart a dependency of the main chart, with a kashti.enabled flag like we have on other things

[bacongobbler]

SGTM

[technosophos]

Updated the items on the todo to reflect the new chart repo

[vdice]

Just a quick note to mention I'm not sure how I feel about Remove the brigade-project chart... putting it here as a placeholder for discussion. (Or perhaps this'd warrant a new discussion ticket?)

For those of us most comfortable managing a project via helm and the brigade-project chart, I'm wondering if this will still be the preferred approach even when both the chart and the brig cli are at parity. Wondering if we can continue to offer both in a sustainable way?

As an example, one benefit of using the Helm chart is the values.yaml file represents a mode of backup if/when the secret somehow was unintentionally changed/lost (or, some larger, cluster-impacting event occurred). The project could then just be recreated in the form of a new helm release in an arguably easier/faster method than going through the brig cli.

Either way, the secret values required by a project need some form of backup -- why not continue to offer the option for these to be in the form of a chart's values.yaml?

[radu-matei]

@vdice - brig project create has a --out flag:

-o, --out string            File where configuration should be saved. The configuration is stored as a JSON Kubernetes Secret

This is the intended use case for that flag - does it help your use case?

[vdice]

@radu-matei ah nice, thank you for the reminder. I think it would be valuable to be able to also get current config from a pre-existing project (brigade project get <project> -o json or brigade project export <project>) as the project may have been amended (and perhaps user had neglected to output the secret at that time). What do you think?

I guess as a more general question, what are the drawbacks of continuing to offer both methods? I'd certainly be fine with docs prioritizing project management with brig, but why not keep the chart around as well?

[radu-matei]

Hey, everyone!
Updated the initial ticket to point to new issues and created a new project board to better track the progress towards Brigade v1.0.0.

[vdice]

First v1.0.0 beta tag cut: https://github.com/Azure/brigade/releases/tag/v1.0.0-beta.1

[vdice]

Brigade v1.0.0 is out! Thanks, all!