argoproj
/
gitops-engine
mirror of https://github.com/argoproj/gitops-engine.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

addressed review feedback from Jay

This commit is contained in:
Daniel Holbach 2019-11-28 16:32:01 +01:00
parent 5946820661
commit d3f2ce3ad7
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/faq.md
View File

@ -16,32 +16,32 @@
**A**: Our primary motives for coming together to do this are:
- ArgoCD and Flux are two of the main GitOps projects, solving very similar problems, having very similar views on implementing GitOps.
- Argo CD and Flux CD are two of the main GitOps projects, solving very similar problems, having very similar views on implementing GitOps.
- We want to offer a shared vision for GitOps and the best possible GitOps experience for everyone.
- We hope to bring a bigger community together than we can on our own.
- We want to learn from each other's approaches and offer the best in breed GitOps solution out there.
----
**Q**: What can current Flux users look forward to from this collaboration with Argo?
**Q**: What can current Flux CD users look forward to from this collaboration with Argo CD?
**A**: Here are a few of our favourites:
- Syncing will be more efficient. Instead of polling, flux will use Kubernetes Informers to get information from the cluster.
- Users will see a great (if not huge) reduction in K8S API calls and etcd traffic
We can increase the syncing frequency.
- Advanced syncing features such as pre-post sync hooks and sync waves
- Overall performance and efficiency improvements (registry scanning excluded) are the major gains for Flux users.
- Given the concept GitOps is quite young, and all people involved were involved early on (or present during the birth), I think people get an even more experienced team working on core features.
- Syncing will be more efficient. Instead of polling, Flux CD will use Kubernetes Informers to get information from the cluster.
- Users will see a great (if not huge) reduction in K8S API calls and etcd traffic.
- We can increase the syncing frequency.
- Advanced syncing features such as pre-post sync hooks and sync waves.
- Overall performance and efficiency improvements (registry scanning excluded) are the major gains for Flux CD users.
- Given the concept of GitOps is quite young, and all people involved were involved early on (or present during the birth), we hope this will result in an even more experienced team working on core features.
----
**Q**: What can current Argo users look forward to from this collaboration with Flux?
**Q**: What can current Argo CD users look forward to from this collaboration with Flux CD?
**A**: We hope Argo CD might get the following:
- Docker registry monitoring feature. It would be fantastic if we could extract existing Flux code into a reusable component which works for both Argo CD and Flux.
- Better cluster management experience. Right now Argo CD users use app of apps pattern which is not perfect. Perhaps we can learn from Flux community and contribute to GitOps engine to improve both Argo CD and Flux.
- Docker registry monitoring feature. It would be fantastic if we could extract existing Flux CD code into a reusable component which works for both Argo CD and Flux CD.
- Better cluster management experience. Right now Argo CD users use app of apps pattern which is not perfect. Perhaps we can learn from Flux CD community and contribute to GitOps engine to improve both Argo CD and Flux CD.
- Advanced Git related features like GPG commit verification, git secrets.
- Simplified installations/management.
@ -49,7 +49,7 @@ We can increase the syncing frequency.
**Q**: Does this project scope just synchronization of environment (git sync operator) or does it include progressive delivery?
**A**: We will be starting to work on a spec 2020.
**A**: We will be starting to work on a spec for progressive delivery alignment between Argo Rollouts and Weave Flagger in 2020.
----
@ -67,7 +67,7 @@ We also want to highlight that before we even start doing this we want to be pro
**A**: It was hard for the right reasons. We wanted to design something which ticked off all these points:
1. Realistic both in theory and practice (e.g. starting a new project from scratch didn't make sense, creating a Frankenstein-like project from pieces of both projects also didn't make sense).
1. Would allow us keep us nurturing the communities of ArgoCD and Flux, towards a common product, without jeopardizing them (e.g. without disrespecting the communities).
1. Would allow us keep us nurturing the communities of Argo CD and Flux CD, towards a common product, without jeopardizing them (e.g. without disrespecting the communities).
1. Useful. Both projects would benefit from it as a first step towards a joint product/solution.
In addition to that finding a common language, without falling into project specific terms (keeping it really abstract), was also quite a challenge, e.g. what a repository is to Flux, is an application to Argo.
In addition to that finding a common language, without falling into project specific terms (keeping it really abstract), was also quite a challenge, e.g. what a repository is to Flux CD, is an application to Argo CD.