1. cncf-tag-app-delivery@lists.cncf.io
  2. Messages
   Date   
Application Definitions Follow Up

Thomas Schuetz
 

Hello Everyone!

In the last TAG Meeting, we discussed the need for Application Definitions and some topics around this. We created a document where we want to collect ideas to proceed with this (and maybe publish it).

Call to Action: If you have ideas or comments around this topic, please add them here: https://docs.google.com/document/d/1bWw7xXy_2_8OFWCVGAtPfUrW6WyxIDUB8h8Hf6Tkr0w/edit#heading=h.7f6n9xa8uf5t.

We will proceed to discuss this topic in the next TAG meeting (https://community.cncf.io/events/details/cncf-tag-app-delivery-presents-tag-app-delivery-general-meeting-2023-03-15/).

Thanks in advance for your contribution!
[Platforms] "Platforms for cloud-native computing" final content ready

Josh Gavant
 

Hi TAG members. As discussed in #310 and thanks to many great contributors, WG Platforms has wrapped up content development for our whitepaper defining Platforms for cloud-native computing and we're pleased to share it with you all for final review: https://github.com/cncf/tag-app-delivery/blob/platforms-v1alpha1/platforms-whitepaper/v1alpha1/paper.md
 
The WG's goal in publishing this whitepaper is to help enterprise leaders and platform builders understand what internal platforms are and the values they promise; and offer succinct guidance on building effective platforms and platform teams. We believe effective platforms will a) enable cloud users to get more from cloud computing and b) help CNCF projects position themselves to users as part of such a platform.

Alongside your review we're seeking a copy-edit and preparing a web site and other channels to distribute this broadly. We'll shift from `v1alpha1` to `v1` to signify final acceptance, along the lines of this draft PR. We intend to publish in early April in time for Kubecon Amsterdam. Follow and contribute to progress here: https://github.com/cncf/tag-app-delivery/milestone/2.
 
The next goals of WG Platforms include the following, follow along in these GitHub issues and join our meetings and Slack channel to learn more and contribute!
 
  1. Gather user feedback on platform adoption and the paper's guidance and improve it
  2. Go deep into individual platform capabilities and drive reduction of complexity in them
  3. Develop example platforms based on our work as guidance to users

Thank you for your feedback and support!

Best,
Josh
Re: Platforms definition whitepaper ready for review

mayreply@...
 

Hey all, this far I've been an observer and I'm looking forward to participating in meetings going forward.

Just want to confirm the date for Tue the 17th, as I had 2nd and 4th Tuesdays in my calendar. If this was already worked out elsewhere, my apologies!

Best,

Friel


On Tue, Jan 3, 2023, 7:31 AM Josh Gavant <joshgavant@...> wrote:
Hi TAG and happy new year! WG Platforms finished 2022 by building the whitepaper described in https://github.com/cncf/tag-app-delivery/issues/246 to define what a cloud-native platform is, why it's valuable, overarching attributes to seek from cloud-native platforms, and the capabilities such a platform should include. We're now preparing to iterate on the final content for this release and publish it in the coming weeks.

Call to action: please share your feedback on the initial proposed content (and publishing framework), all linked from this GitHub "milestone": https://github.com/cncf/tag-app-delivery/milestone/1

For a bit of background: The first goal of the Platforms definition whitepaper is to inform enterprise leaders, enterprise architects, and platform team leaders why they should implement platform engineering and what attributes and capabilities they should seek and evaluate as they implement platforms. A second goal is to provide a framework for us in the WG to dive deeper and seek opportunities for simplification and standardization in the identified capability domains, such as secrets management, observability, data services, etc.

Consider joining the wg-platforms Slack channel too for more interactive conversation: https://cloud-native.slack.com/archives/C020RHD43BP

For reference, the initial draft of the paper with lots of comments is here: https://docs.google.com/document/d/1UDL3E5BqPyDdzV1wek9o8xR-nLJQXEEMU1qIMCgq5cI/

Thanks in advance for your contributions!

Re: Platforms definition whitepaper ready for review

Josh Gavant
 

Hi Aaron,

Thanks for the question. This is an extra "working" meeting specifically to focus on the whitepaper *content*. The regularly scheduled meeting couldn't go that deep on hot topics and seeking volunteers for sections.

Goal is definitely to be streamlined and avoid extra meetings, we'll be agile and adjust to make people's participation as productive and useful as possible!

Thanks!
Josh

On Fri, Jan 13, 2023, 12:58 Aaron Friel <friel@...> wrote:
Hey all, this far I've been an observer and I'm looking forward to participating in meetings going forward.

Just want to confirm the date for Tue the 17th, as I had 2nd and 4th Tuesdays in my calendar. If this was already worked out elsewhere, my apologies!

Best,

Friel

On Tue, Jan 3, 2023, 7:31 AM Josh Gavant <joshgavant@...> wrote:
Hi TAG and happy new year! WG Platforms finished 2022 by building the whitepaper described in https://github.com/cncf/tag-app-delivery/issues/246 to define what a cloud-native platform is, why it's valuable, overarching attributes to seek from cloud-native platforms, and the capabilities such a platform should include. We're now preparing to iterate on the final content for this release and publish it in the coming weeks.

Call to action: please share your feedback on the initial proposed content (and publishing framework), all linked from this GitHub "milestone": https://github.com/cncf/tag-app-delivery/milestone/1

For a bit of background: The first goal of the Platforms definition whitepaper is to inform enterprise leaders, enterprise architects, and platform team leaders why they should implement platform engineering and what attributes and capabilities they should seek and evaluate as they implement platforms. A second goal is to provide a framework for us in the WG to dive deeper and seek opportunities for simplification and standardization in the identified capability domains, such as secrets management, observability, data services, etc.

Consider joining the wg-platforms Slack channel too for more interactive conversation: https://cloud-native.slack.com/archives/C020RHD43BP

For reference, the initial draft of the paper with lots of comments is here: https://docs.google.com/document/d/1UDL3E5BqPyDdzV1wek9o8xR-nLJQXEEMU1qIMCgq5cI/

Thanks in advance for your contributions!

Re: Platforms definition whitepaper ready for review

Josh Gavant
 

Hi folks - we'll be reviewing hot topics related to the whitepaper's content and seeking owners for section reviews in a meeting this Tuesday Jan. 17 @ 1600 UTC.

Here's the meeting event page to add to your calendar with agenda and links: https://community.cncf.io/events/details/cncf-tag-app-delivery-presents-review-platforms-whitepaper/

We'd love to learn from your feedback and participation there and/or asynchronously in GitHub and Slack. Thanks!

~Josh
Re: Platforms definition whitepaper ready for review

alexis richardson
 

this is actually a really nice validation of the initial assumptions of CNCF, that an industry platform could emerge from collections of loosely coupled cloud native tools.


On Tue, Jan 3, 2023 at 3:31 PM Josh Gavant <joshgavant@...> wrote:
Hi TAG and happy new year! WG Platforms finished 2022 by building the whitepaper described in https://github.com/cncf/tag-app-delivery/issues/246 to define what a cloud-native platform is, why it's valuable, overarching attributes to seek from cloud-native platforms, and the capabilities such a platform should include. We're now preparing to iterate on the final content for this release and publish it in the coming weeks.

Call to action: please share your feedback on the initial proposed content (and publishing framework), all linked from this GitHub "milestone": https://github.com/cncf/tag-app-delivery/milestone/1

For a bit of background: The first goal of the Platforms definition whitepaper is to inform enterprise leaders, enterprise architects, and platform team leaders why they should implement platform engineering and what attributes and capabilities they should seek and evaluate as they implement platforms. A second goal is to provide a framework for us in the WG to dive deeper and seek opportunities for simplification and standardization in the identified capability domains, such as secrets management, observability, data services, etc.

Consider joining the wg-platforms Slack channel too for more interactive conversation: https://cloud-native.slack.com/archives/C020RHD43BP

For reference, the initial draft of the paper with lots of comments is here: https://docs.google.com/document/d/1UDL3E5BqPyDdzV1wek9o8xR-nLJQXEEMU1qIMCgq5cI/

Thanks in advance for your contributions!

Platforms definition whitepaper ready for review

Josh Gavant
 

Hi TAG and happy new year! WG Platforms finished 2022 by building the whitepaper described in https://github.com/cncf/tag-app-delivery/issues/246 to define what a cloud-native platform is, why it's valuable, overarching attributes to seek from cloud-native platforms, and the capabilities such a platform should include. We're now preparing to iterate on the final content for this release and publish it in the coming weeks.

Call to action: please share your feedback on the initial proposed content (and publishing framework), all linked from this GitHub "milestone": https://github.com/cncf/tag-app-delivery/milestone/1

For a bit of background: The first goal of the Platforms definition whitepaper is to inform enterprise leaders, enterprise architects, and platform team leaders why they should implement platform engineering and what attributes and capabilities they should seek and evaluate as they implement platforms. A second goal is to provide a framework for us in the WG to dive deeper and seek opportunities for simplification and standardization in the identified capability domains, such as secrets management, observability, data services, etc.

Consider joining the wg-platforms Slack channel too for more interactive conversation: https://cloud-native.slack.com/archives/C020RHD43BP

For reference, the initial draft of the paper with lots of comments is here: https://docs.google.com/document/d/1UDL3E5BqPyDdzV1wek9o8xR-nLJQXEEMU1qIMCgq5cI/

Thanks in advance for your contributions!
[gitops-wg] 📢 GitOpsCon relocates to Open Source Summit

Scott Rigby
 

Hi everyone!

You may have heard the news: GitOpsCon is joining forces with CdCon and moving from KubeCon + CloudNativeCon to Open Source Summit starting in 2023! 

Check out this blog post which explains everything: https://opengitops.dev/blog/cdcon+gitopscon-at-open-source-summit/

Please let me and the rest of the GitOpsCon program committee know if you have any questions.

Looking forward to seeing you all there!

--
Scott Rigby
mypronouns.org/he-him
Developer Experience, Weaveworks
Re: [gitops-wg] GitOps & Environmental Sustainability Subgroup meeting

Scott Rigby
 

Thanks Niklas, Niki, and everyone involved in this subgroup 🌎

On Wed, Oct 19, 2022 at 4:10 PM Niklas <hi@...> wrote:
Hey everyone,

for the first GitOps & Environmental Sustainability Subgroup 🌱 meeting Niki created an issue in the project's repository. We want to meet Tuesday 15th November at 6pm CET/12pm ET/9am PT. So everyone who's interested is invited to join us for our first meeting talking how to save emissions and make this world a little bit greener with GitOps.

Have a great day!
Niklas

--
Scott Rigby
Developer Experience, Weaveworks
[gitops-wg] GitOps & Environmental Sustainability Subgroup meeting

Niklas
 

Hey everyone,

for the first GitOps & Environmental Sustainability Subgroup 🌱 meeting Niki created an issue in the project's repository. We want to meet Tuesday 15th November at 6pm CET/12pm ET/9am PT. So everyone who's interested is invited to join us for our first meeting talking how to save emissions and make this world a little bit greener with GitOps.

Have a great day!
Niklas
[gitops-wg] Maintainer and Governance updates

Scott Rigby
 

Hello everyone!

Please see this PR which updates OpenGitOps governance to Move top level power to maintainers #123.
While there are overlapping members, once that PR is merged, the OpenGitOps project will have governance independent of the GitOps WG.

Also please join us in welcoming new maintainers, and thanking emeritus maintainers, which will be up to date once Add more alumni to maintainer emeritus section #124 is merged.

--
Scott Rigby
mypronouns.org/he-him
Developer Experience, Weaveworks
Today's TAG App Delivery meeting

Reitbauer, Alois
 

Who is planning to join the meeting today? If you have a agenda item, feel to add it for today.

 

// Alois

This email may contain confidential information. If it appears this message was sent to you by mistake, please let us know of the error. In this case, we also ask that you do not further forward the content and delete it. Thank you for your cooperation and understanding. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20.

New Maintainers OpenGitOps Working Group

Christian Hernandez
 

For transparency, New Maintainers have been nominated for the OpenGitOps Working Group




Christian Hernandez

(626) 502-8310

Developer Experience and Community Management

Argo Project Marketing SIG & OpenGitOps Maintainer
Re: [gitops-wg] Improving GitOps usability

Brian Grant
 

On Wed, May 25, 2022 at 4:25 AM Chris Short via lists.cncf.io <chris=chrisshort.net@...> wrote:
Thank you for bringing this to the group. I legit wish I had this when I was working in the Duke Health system. Would've made our lives much easier.

I can see extensive use of this being made in highly regulated environments right off the bat. This is also useful if you want to create safe, happy paths for folks to release their services/code with the downside of if you're not on the happy path you're going to have to go through other approval process(es) of some sort. This has been a practice for a while just never quite this tight (nor this native to Kubernetes).

w/r/t GUIs: By default, I don't think GUIs are necessary for GitOps tooling.

BTW, on GUIs being necessary:

A GUI isn't strictly necessary, but this makes it Possible. It also makes other types of automation possible. 

It eliminates the requirement of manual editing of templates, patches, code written using configuration languages, or code written using general-purpose languages in an IDE or text editor in order to do something even as simple as adding a field to a resource.
 
If there is an edit source option in the GUI, a request should be made to commit a changeset through normal approval processes, not a direct commit to the source of truth. This can be managed a number of ways but, we should strive to encourage folks to build out tooling in a production-ready manner with appropriate safeguards either in place or documented where needed.

w/r/t writing back to the repo: To be clear, this needs to be safeguarded somehow; drift detection only works if there's something different to compare against. If you're saving your diffs back to the git repo while breaking your environment you'll wish you hadn't when you realize prod is down and there's 17 revisions to rollback through. I urge some caution here and ask folks to remember the rigor needed to approve changes to environments and/or known good configurations. That's where we as a subproject could write something up or reference something so folks can build out their approval processes in a GitOps way to save some headaches (approval processes only work if they're followed).
He/Him/His
TZ=America/Detroit


On Wed, May 25, 2022 at 4:59 AM Stefan Prodan <stefan@...> wrote:
Flux controllers read config from git but can't push changes back.
Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/ 
Re: [gitops-wg] Improving GitOps usability

Chris Short <cbshort@...>
 

Will watch video for sure.

To be clear, you don't have to use git, any object store that's versioned will do. If git is in the way, use something that works and is versioned.

Also, I think it was Dan or Scott that said if you're pulling from latest all the time you're gonna have a bad time.

Chris Short
He/Him/His
Sr. Developer Advocate, AWS Kubernetes (GitOps)
TZ=America/Detroit

On May 25, 2022, at 09:41, Brian Grant via lists.cncf.io <briangrant=google.com@...> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

On Wed, May 25, 2022 at 4:25 AM Chris Short via lists.cncf.io <chris=chrisshort.net@...> wrote:
Thank you for bringing this to the group. I legit wish I had this when I was working in the Duke Health system. Would've made our lives much easier.

I can see extensive use of this being made in highly regulated environments right off the bat. This is also useful if you want to create safe, happy paths for folks to release their services/code with the downside of if you're not on the happy path you're going to have to go through other approval process(es) of some sort. This has been a practice for a while just never quite this tight (nor this native to Kubernetes).

The Backstage plugin is in its early stages. The review/approval flow needs to have at least diffs added. Some of that functionality can be seen in our earlier prototype:

There are also validation functions that run, akin to admission control in Kubernetes.

w/r/t GUIs: By default, I don't think GUIs are necessary for GitOps tooling. If there is an edit source option in the GUI, a request should be made to commit a changeset through normal approval processes, not a direct commit to the source of truth. This can be managed a number of ways but, we should strive to encourage folks to build out tooling in a production-ready manner with appropriate safeguards either in place or documented where needed.

Whatever safeguards are desired can be done through this flow. 

In the prototype video above, we showed generation of pull requests. Pull requests are somewhat of a pain due to different APIs and models in different providers, and the need to set up branch protections and CODEOWNERS, map identities between providers and possibly impersonate users, and so on. We moved away from pull requests to automated branching and merging. We are not directly committing to the main branch. If the repo is only for configuration packages, then a configuration-change-focused workflow can be used.

Additionally, once fully automating configuration generation and the change control workflow, we found git was not helping us and caused some challenges, so we're in the progress of adding container images as storage, which can be versioned similarly to git, are ubiquitously available in production environments, are more granular, support package-level metadata, and have more standardized APIs than git providers. 


w/r/t writing back to the repo: To be clear, this needs to be safeguarded somehow; drift detection only works if there's something different to compare against. If you're saving your diffs back to the git repo while breaking your environment you'll wish you hadn't when you realize prod is down and there's 17 revisions to rollback through. I urge some caution here and ask folks to remember the rigor needed to approve changes to environments and/or known good configurations. That's where we as a subproject could write something up or reference something so folks can build out their approval processes in a GitOps way to save some headaches (approval processes only work if they're followed).

Of course, monitoring the live state is desirable in a closed-loop system, just as if changes were made more manually. 

Additionally, pulling from HEAD is tantamount to using the :latest tag on container images. It's simpler to orchestrate (well, except for rollbacks), but has similar risks.

He/Him/His
TZ=America/Detroit


On Wed, May 25, 2022 at 4:59 AM Stefan Prodan <stefan@...> wrote:
Flux controllers read config from git but can't push changes back.
Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/ 
Re: [gitops-wg] Improving GitOps usability

Brian Grant
 

I tried to respond to this message yesterday, but the reply didn't go through.

The similar twitter thread is here:

On Tue, May 24, 2022 at 2:51 PM Josh Gavant <joshgavant@...> wrote:
Thanks for sharing Brian. The most significant bit to consider IMO is that kpt enables syncing back to the git repo, whereas the likes of Flux and ArgoCD are one-way only (AFAIK) - the ArgoCD and Flux controllers read config from git but can't push changes back.

There are a number of other capabilities also, some mentioned in the twitter thread above. 

The ability to sync back to the git repo in turn enables you to provide a forms-based GUI over kpt and then use kpt to push changes back.

This could lead us to ask: should other GitOps tools also offer an "edit in GUI and sync back to git" option? And/or should such a capability be developed independently of any specific GitOps operator?

The package orchestrator can be used with any GitOps operator. The only interaction with the GitOps sync mechanism currently is through git.

There's a small integration in the backstage UI plugin, to create the necessary sync resource and poll status, but it could be extended to support multiple GitOps tools, or could be made pluggable.
 
Re: [gitops-wg] Improving GitOps usability

Brian Grant
 

On Wed, May 25, 2022 at 4:25 AM Chris Short via lists.cncf.io <chris=chrisshort.net@...> wrote:
Thank you for bringing this to the group. I legit wish I had this when I was working in the Duke Health system. Would've made our lives much easier.

I can see extensive use of this being made in highly regulated environments right off the bat. This is also useful if you want to create safe, happy paths for folks to release their services/code with the downside of if you're not on the happy path you're going to have to go through other approval process(es) of some sort. This has been a practice for a while just never quite this tight (nor this native to Kubernetes).

The Backstage plugin is in its early stages. The review/approval flow needs to have at least diffs added. Some of that functionality can be seen in our earlier prototype:

There are also validation functions that run, akin to admission control in Kubernetes.

w/r/t GUIs: By default, I don't think GUIs are necessary for GitOps tooling. If there is an edit source option in the GUI, a request should be made to commit a changeset through normal approval processes, not a direct commit to the source of truth. This can be managed a number of ways but, we should strive to encourage folks to build out tooling in a production-ready manner with appropriate safeguards either in place or documented where needed.

Whatever safeguards are desired can be done through this flow. 

In the prototype video above, we showed generation of pull requests. Pull requests are somewhat of a pain due to different APIs and models in different providers, and the need to set up branch protections and CODEOWNERS, map identities between providers and possibly impersonate users, and so on. We moved away from pull requests to automated branching and merging. We are not directly committing to the main branch. If the repo is only for configuration packages, then a configuration-change-focused workflow can be used.

Additionally, once fully automating configuration generation and the change control workflow, we found git was not helping us and caused some challenges, so we're in the progress of adding container images as storage, which can be versioned similarly to git, are ubiquitously available in production environments, are more granular, support package-level metadata, and have more standardized APIs than git providers. 


w/r/t writing back to the repo: To be clear, this needs to be safeguarded somehow; drift detection only works if there's something different to compare against. If you're saving your diffs back to the git repo while breaking your environment you'll wish you hadn't when you realize prod is down and there's 17 revisions to rollback through. I urge some caution here and ask folks to remember the rigor needed to approve changes to environments and/or known good configurations. That's where we as a subproject could write something up or reference something so folks can build out their approval processes in a GitOps way to save some headaches (approval processes only work if they're followed).

Of course, monitoring the live state is desirable in a closed-loop system, just as if changes were made more manually. 

Additionally, pulling from HEAD is tantamount to using the :latest tag on container images. It's simpler to orchestrate (well, except for rollbacks), but has similar risks.

He/Him/His
TZ=America/Detroit


On Wed, May 25, 2022 at 4:59 AM Stefan Prodan <stefan@...> wrote:
Flux controllers read config from git but can't push changes back.
Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/ 
Re: [gitops-wg] Improving GitOps usability

Chris Short <chris@...>
 

Thank you for bringing this to the group. I legit wish I had this when I was working in the Duke Health system. Would've made our lives much easier.

I can see extensive use of this being made in highly regulated environments right off the bat. This is also useful if you want to create safe, happy paths for folks to release their services/code with the downside of if you're not on the happy path you're going to have to go through other approval process(es) of some sort. This has been a practice for a while just never quite this tight (nor this native to Kubernetes).

w/r/t GUIs: By default, I don't think GUIs are necessary for GitOps tooling. If there is an edit source option in the GUI, a request should be made to commit a changeset through normal approval processes, not a direct commit to the source of truth. This can be managed a number of ways but, we should strive to encourage folks to build out tooling in a production-ready manner with appropriate safeguards either in place or documented where needed.

w/r/t writing back to the repo: To be clear, this needs to be safeguarded somehow; drift detection only works if there's something different to compare against. If you're saving your diffs back to the git repo while breaking your environment you'll wish you hadn't when you realize prod is down and there's 17 revisions to rollback through. I urge some caution here and ask folks to remember the rigor needed to approve changes to environments and/or known good configurations. That's where we as a subproject could write something up or reference something so folks can build out their approval processes in a GitOps way to save some headaches (approval processes only work if they're followed).
He/Him/His
TZ=America/Detroit


On Wed, May 25, 2022 at 4:59 AM Stefan Prodan <stefan@...> wrote:
Flux controllers read config from git but can't push changes back.
Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/ 
Re: [gitops-wg] Improving GitOps usability

Stefan Prodan
 

Flux controllers read config from git but can't push changes back.
Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/ 
Re: [gitops-wg] Improving GitOps usability

Josh Gavant
 

Thanks for sharing Brian. The most significant bit to consider IMO is that kpt enables syncing back to the git repo, whereas the likes of Flux and ArgoCD are one-way only (AFAIK) - the ArgoCD and Flux controllers read config from git but can't push changes back.

The ability to sync back to the git repo in turn enables you to provide a forms-based GUI over kpt and then use kpt to push changes back.

This could lead us to ask: should other GitOps tools also offer an "edit in GUI and sync back to git" option? And/or should such a capability be developed independently of any specific GitOps operator?
1 - 20 of 315