Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Meeting

Jump to bottom
Daniel Holbach edited this page Feb 26, 2019 · 39 revisions

Flux dev meeting

The Flux developer community holds public meetings to discuss where Flux is going, to get feedback and to create an opportunity to get to know each other face-to-face and in a more immediate fashion than on Slack.

The next meeting is going to take place:

  • When: TBD
  • Where: Zoom

Before joining, make sure you install the Zoom client and test Microphone/video settings. If you prefer not to be on camera, or just want to listen in, that's absolutely fine too.

Past meetings

Agenda and notes

Next meeting: 2019-02-26

Agenda

  • Review of actions from last meeting

Minutes

  • Attendees:
  • Video upload:
  • Minutes: <add notes here>

2019-02-26

Agenda

  • Review of actions from last meeting
  • Flux roadmap
  • Integration tests, next steps
  • Plan next meeting

Minutes

2018-11-28

Agenda

This is going to be the first meeting, we'll want to get to know each other in our community and get feedback. If you're interested in joining the community, this will be a good place to get involved.

  1. Quick introductions (who are you, how do you use Flux)
    If you prefer not to introduce yourself, or just listen in, that's totally fine!
  2. State of Flux (Michael)
  3. Future plans:
    1. Helm Operator 1.0
    2. Themed releases
    3. Integration test machinery
  4. Feedback and questions
  5. Next meeting

Minutes

  • Attendees: Brant Bobby, Daniel Holbach, Hidde Beydals, Michael Bridgen, Nick Cabatoff, Stefan Prodan
  • Video upload: https://zoom.us/recording/play/j3XnvYfXYunpobpanrDZ3F-UarqTye7L0QNk9zS04HjNQR8Aqj5OCSg2D47VzQhq?continueMode=true
  • Minutes:
    • Introductions:
      • Michael Bridgen, London, Weaveworks, Lead Dev on Flux, RabbitMQ/VMWare before. Mostly works on Flux.
      • Daniel Holbach, Berlin, Weaveworks, Community Manager, Ubuntu dev communities before. Wants to bring more fun, and a bit more structure into Flux dev community.
      • Nick Cabatoff, used to work at Intelerad, was looking for a CD system, discovered Flux, liked it, decided to get more involved. Moved on to Hashicorp recently.
      • Brant Bobby, works in Canada, looks into transitioning to Kubernetes as a greenfield project. Flux looks like the best option for a CD system there. Is a very enthusiastic user.
      • Hidde Beydals, his story is very similar to Brant's. (Hidde's connection dropped here.)
      • Stefan Prodan, Weaveworks, Developer Experience team. Works on Flux and GitOps.
    • State of Flux (Michael):
      • Flux is not just a Weaveworks project any more. Hidde Beydals, Justin Barrick, Nick Cabatoff joined as maintainers.
      • Flux is used as part of Weaveworks's commercial Weave Cloud product. Rollout progress was added to WC's UI. A PR is in progress to add this to fluxctl release.
      • Another PR that's in the works: Garbage collection for objects which are not part of the Git repo any more.
      • Helm operator: still in beta, but steadily improving. Sees a lot of love through PRs and issues. Let's try to get it to its "1.0" release. It's what multiplied attention to Flux.
      • Supporting syncing multiple Git repos. Very popular request.
      • Support thing like kustomize natively or support composition of CI tooling. Ideas and help welcome!
    • Plans/request/ideas:
      • Helm operator 1.0 - what's missing?
        • Secrets for getting keys for each helm release
        • Some issues open for polish and reliability.
        • Making it less chatty in the logs.
        • Make it follow all of the design spec.
        • No huge drawbacks at this point. Definitely covers the 80%.
        • Let's review open issues and put together a shopping list. Review together. Make it theme of the next set of releases. Ask people to test. Get feedback.
        • ACTION: Daniel/Michael to put together straw-man.
        • Discussion:
          • Hidde: works fine in their setting.
          • Brant: works Helm for external apps, not own apps.
          • Hidde: Use Helm for launching apps with different settings.
          • Brant: Still figuring out how to use Helm for "multi-user support".
          • Somewhat unclear how people organise their environments. Flux needs to stay flexible.
          • Stefan: Flux per namespaces/teams. Clearer structure which responsibilities are with Flux and which are for the helm-operator.
          • Stefan: simple CICD pipeline with Helm releases and Github Actions are possible now.
          • Michael: It'd be great to make Flux more usable with CI pipelines. Waiting for stuff to happen is not easy with Kubernetes.
          • Stefan: use Progress Deadlines? Need a timeout somewhere. Depending on what kind of workload (StatefulSet or not).
          • Michael: let Flux honour deadline, otherwise use Flux setting. Needs design.
          • Stefan: this enables to give feedback to e.g. Github.
          • Michael: previous work on notifications on rollout status (Roli, Elena).
      • Themed releases, ideas
        • User experience: small things like making fluxctl installs easier, crystal-clear log messages.
        • Docs/tutorials: e.g. automated annotations.
      • Integration tests
        • Nick worked on this, some discussion. Let's revive this work. Would be great to get contributors involved with writing tests too. Michael helped with this as well. Raise confidence in not causing regressions.
        • ACTION: Michael/Nick to see what's still missing.
        • Stefan: let's use flux-get-started(?), it covers e.g. all kinds of annotations.
        • Stefan: Damien wrote code to make integration test automations easy. It's used in eksctl.
      • Next meeting
        • ACTION: Daniel: find out on Slack if we need meeting time? Target early next year.
        • Ask for agenda items ahead of time. Try monthly for now. (We compared to Scope's fortnightly meetings.)
        • Focus on design decisions and feedback as opposed to reviewing issues/PRs there.
      • Mailing list
        • Let's use one for long-form design decisions. Slack not really good for asynchronous discussions, not good for planning - some people prefer not to use Slack.
        • ACTION: Michael to set up mailing list.
      • Thanks
        • Thanks to the new maintainers who stepped up!
        • Thanks to everyone who helped out in the past weeks. Flux has got a really great team together!
Clone this wiki locally