Date   

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
 

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
 

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?


[gitops-wg] Improving GitOps usability

Brian Grant
 

Hi. It was suggested to me that this topic may be of interest to the GitOps WG. I'd be happy to come discuss it during a meeting, or on the mailing list.

We created a WYSIWYG GUI experience layered over GitOps that reduces the friction of interacting with Kubernetes configuration and git. This shows a simple use case to start (not app delivery), but I think shows the potential of the approach. The experience has no YAML editing, no patch authoring, no templates, no coding for configuration consumers, and low coding for platform builders. It leverages a similar transformation-based approach as kustomize that I call Configuration as Data. There's also no manual branching, editing, committing, tagging, pushing, merging, etc., which sounds like not a big deal, but having done it by hand lots of times, it's more friction than one might think, especially for small changes or for non-developers. 

https://cloud.google.com/blog/products/containers-kubernetes/lets-improve-gitops-usability
https://www.youtube.com/watch?v=L_x7z4CXHDw
https://twitter.com/bgrant0607/status/1525109177504280576
https://twitter.com/bgrant0607/status/1526231548109869061
https://kpt.dev/guides/rationale

Take a look and let me know what you think.

It's in the early stages, but I'm excited about it.

We are looking to engage with the community to advance the technology forward.

Project contact info is here: https://kpt.dev/contact/
The code can be found here: https://github.com/orgs/GoogleContainerTools/repositories?q=kpt&type=all&language=&sort=


[gitops-wg] Welcome Chris Short as co-chair 🎉

Scott Rigby
 

Hi everyone!

This is a follow-up to "[gitops-wg] Co-Chair voting" on this list.

Chris Short has been voted in as GitOps WG co-chair, along with Dan Garfield and myself. 🎉

See CHAIRS.md for the list of current and past WG chairs.
See MAINTAINERS for list of current and past OpenGitOps maintainers.

--
Scott Rigby
Developer Experience, Weaveworks


Re: [gitops-wg] Co-Chair voting

Stephen Novak
 

+1 for Chris

On Thu, Jan 27, 2022 at 3:34 PM Blixt, Henrik via lists.cncf.io <henrik_blixt=intuit.com@...> wrote:

An interested party +1 for Chris.

 

Henrik

 

From: <cncf-tag-app-delivery@...> on behalf of Christian Hernandez <chernand@...>
Date: Thursday, January 27, 2022 at 2:02 PM
To: Scott Rigby <scott@...>
Cc: "cncf-tag-app-delivery@..." <cncf-tag-app-delivery@...>
Subject: Re: [cncf-tag-app-delivery] [gitops-wg] Co-Chair voting

 

This email is from an external sender.

 

I also vote for Chris Short +1

 

---

Christian Hernandez, RHCA

senior Principal Technical Marketing Manager

Hybrid Platforms Customer & Field Engagement

Red Hat, Inc

christian@...

Mobile: 626.502.8310

Slack:  chernand

Image removed by sender.

 

 

On Thu, Jan 27, 2022 at 12:23 PM Scott Rigby <scott@...> wrote:

Hi everyone,

 

This is a follow-up to the "Call for Co-Chair nominations" email sent on Jan 16.

Per GitOps WG Governance co-chair voting will also take place on this mailing list, and anyone listed in interested-parties.md at least one week prior to election is eligible to vote.


In that email, voting by maintainers began last Friday and concludes this Friday (Tomorrow). However, no one has yet voted on this mailing list. This is our first co-chair vote – I expect there to be more participation next time. Dan Garfield suggested we extend the vote until next Friday, Feb 4, and I agree that would give more of the listed interested parties a chance to participate if they wish.

In this round, Chris Short was the only nominee added by last Friday, when voting began, so this is what we will vote on.

My vote for Chris Short as GtiOps WG co-chair is +1, binding

--

Scott Rigby
Developer Experience, Weaveworks



--
Stephen Novak


Re: [gitops-wg] Co-Chair voting

Blixt, Henrik
 

An interested party +1 for Chris.

 

Henrik

 

From: <cncf-tag-app-delivery@...> on behalf of Christian Hernandez <chernand@...>
Date: Thursday, January 27, 2022 at 2:02 PM
To: Scott Rigby <scott@...>
Cc: "cncf-tag-app-delivery@..." <cncf-tag-app-delivery@...>
Subject: Re: [cncf-tag-app-delivery] [gitops-wg] Co-Chair voting

 

This email is from an external sender.

 

I also vote for Chris Short +1

 

---

Christian Hernandez, RHCA

senior Principal Technical Marketing Manager

Hybrid Platforms Customer & Field Engagement

Red Hat, Inc

christian@...

Mobile: 626.502.8310

Slack:  chernand

 

 

On Thu, Jan 27, 2022 at 12:23 PM Scott Rigby <scott@...> wrote:

Hi everyone,

 

This is a follow-up to the "Call for Co-Chair nominations" email sent on Jan 16.

Per GitOps WG Governance co-chair voting will also take place on this mailing list, and anyone listed in interested-parties.md at least one week prior to election is eligible to vote.


In that email, voting by maintainers began last Friday and concludes this Friday (Tomorrow). However, no one has yet voted on this mailing list. This is our first co-chair vote – I expect there to be more participation next time. Dan Garfield suggested we extend the vote until next Friday, Feb 4, and I agree that would give more of the listed interested parties a chance to participate if they wish.

In this round, Chris Short was the only nominee added by last Friday, when voting began, so this is what we will vote on.

My vote for Chris Short as GtiOps WG co-chair is +1, binding

--

Scott Rigby
Developer Experience, Weaveworks


Re: [gitops-wg] Co-Chair voting

Christian Hernandez
 

I also vote for Chris Short +1


---

Christian Hernandez, RHCA

senior Principal Technical Marketing Manager

Hybrid Platforms Customer & Field Engagement

Red Hat, Inc

christian@...

Mobile: 626.502.8310

Slack:  chernand



On Thu, Jan 27, 2022 at 12:23 PM Scott Rigby <scott@...> wrote:
Hi everyone,
 
This is a follow-up to the "Call for Co-Chair nominations" email sent on Jan 16.

Per GitOps WG Governance co-chair voting will also take place on this mailing list, and anyone listed in interested-parties.md at least one week prior to election is eligible to vote.

In that email, voting by maintainers began last Friday and concludes this Friday (Tomorrow). However, no one has yet voted on this mailing list. This is our first co-chair vote – I expect there to be more participation next time. Dan Garfield suggested we extend the vote until next Friday, Feb 4, and I agree that would give more of the listed interested parties a chance to participate if they wish.

In this round, Chris Short was the only nominee added by last Friday, when voting began, so this is what we will vote on.

My vote for Chris Short as GtiOps WG co-chair is +1, binding

--

Scott Rigby
Developer Experience, Weaveworks


Re: [gitops-wg] Co-Chair voting

Dan Garfield
 

Chris Short +1 Binding!

Dan Garfield

Co-founder & Chief Open Source Officer

Check out our upcoming Webinars






On Thu, Jan 27, 2022 at 1:20 PM Scott Rigby <scott@...> wrote:
Hi everyone,
 
This is a follow-up to the "Call for Co-Chair nominations" email sent on Jan 16.

Per GitOps WG Governance co-chair voting will also take place on this mailing list, and anyone listed in interested-parties.md at least one week prior to election is eligible to vote.

In that email, voting by maintainers began last Friday and concludes this Friday (Tomorrow). However, no one has yet voted on this mailing list. This is our first co-chair vote – I expect there to be more participation next time. Dan Garfield suggested we extend the vote until next Friday, Feb 4, and I agree that would give more of the listed interested parties a chance to participate if they wish.

In this round, Chris Short was the only nominee added by last Friday, when voting began, so this is what we will vote on.

My vote for Chris Short as GtiOps WG co-chair is +1, binding

--

Scott Rigby
Developer Experience, Weaveworks


[gitops-wg] Co-Chair voting

Scott Rigby
 

Hi everyone,
 
This is a follow-up to the "Call for Co-Chair nominations" email sent on Jan 16.

Per GitOps WG Governance co-chair voting will also take place on this mailing list, and anyone listed in interested-parties.md at least one week prior to election is eligible to vote.

In that email, voting by maintainers began last Friday and concludes this Friday (Tomorrow). However, no one has yet voted on this mailing list. This is our first co-chair vote – I expect there to be more participation next time. Dan Garfield suggested we extend the vote until next Friday, Feb 4, and I agree that would give more of the listed interested parties a chance to participate if they wish.

In this round, Chris Short was the only nominee added by last Friday, when voting began, so this is what we will vote on.

My vote for Chris Short as GtiOps WG co-chair is +1, binding

--

Scott Rigby
Developer Experience, Weaveworks


Re: [gitops-wg] Thank you Leo, and Call for Co-Chair nominations

Chris Short
 

Hi all,

Thank you, Leo, for your stewardship. We wouldn't be here without you. I would like to nominate myself for the OpenGitOps chair seat that Leo is vacating.

I've been an advocate for GitOps for since 2018 (if not earlier). My background in DevOps has led to my discovery of and participation in GitOps, in general. I'm an active maintainer of the OpenGitOps group, and GitOps is under my purview within the AWS Kubernetes organization. This combination gives me both a desire and actual job function for the responsibility of a chair.

Additionally, I'm also a Kubernetes contributor and CNCF Ambassador. I spend my time in SIG-ContribEx, onboarded many Kubernetes contributors into the org, and help maintain the K8s Upstream Marketing Team. I have helped write the Upstream Marketing team's governance and ethos and write or edit several SIG profiles (and other blog posts). Additionally, I've worked with other orgs in Kubernetes on stickier issues like deprecation of PSPs and dockershim. I'm known to moderate meetings, including release retrospectives. I feel I bring a lot to the table in terms of institutional knowledge regarding CNCF and the inner workings of SIG ContribEx that would help OpenGitOps excel.

Thank you,
He/Him/His
TZ=America/Detroit


On Sun, Jan 16, 2022 at 5:07 PM Scott Rigby <scott@...> wrote:
Hi everyone,
 
Leo is stepping down as a GitOps WG co-chair. He will be staying on as an OpenGitOps maintainer. See Leo’s note to the community here, and PR to the WG files in the TAG App Delivery repo here.
 
Thank you Leo! 💖we will still see you but with fewer responsibilities for the time being.

Per WG governance, we will hold a special election for a new co-chair. Note only existing maintainers are eligible for nomination. Elections are held on the TAG App Delivery mailing list. Please read the WG Governance in full for detailed information on responsibilities for each role in the OpenGitOps and GitOps WG community, the election process itself, and decision-making. This email is part of that process.

Relevant dates:
  • Co-chair nominations will be open until this Friday Jan 21 (giving a full work week), at which point voting opens on the TAG App Delivery mailing list
  • Voting open until the following Friday, Jan 28, 2022.
  • Results will be announced on the TAG mailing list and Slack that Friday

Thank you for your participation!

Scott for the GitOps Working Group Chairs and OpenGitOps Maintainers
--

Scott Rigby
Developer Experience, Weaveworks


[gitops-wg] Thank you Leo, and Call for Co-Chair nominations

Scott Rigby
 

Hi everyone,
 
Leo is stepping down as a GitOps WG co-chair. He will be staying on as an OpenGitOps maintainer. See Leo’s note to the community here, and PR to the WG files in the TAG App Delivery repo here.
 
Thank you Leo! 💖we will still see you but with fewer responsibilities for the time being.

Per WG governance, we will hold a special election for a new co-chair. Note only existing maintainers are eligible for nomination. Elections are held on the TAG App Delivery mailing list. Please read the WG Governance in full for detailed information on responsibilities for each role in the OpenGitOps and GitOps WG community, the election process itself, and decision-making. This email is part of that process.

Relevant dates:
  • Co-chair nominations will be open until this Friday Jan 21 (giving a full work week), at which point voting opens on the TAG App Delivery mailing list
  • Voting open until the following Friday, Jan 28, 2022.
  • Results will be announced on the TAG mailing list and Slack that Friday

Thank you for your participation!

Scott for the GitOps Working Group Chairs and OpenGitOps Maintainers
--

Scott Rigby
Developer Experience, Weaveworks


[cooperative-delivery-wg] Friendly reminder - wg meeting is this week

Roberth Strand
 

Hey ya'll,

As we have had a bit of slow start, I wanted to remind folks that the working group meeting is the coming Wednesday at 8 am Pacific / 11 am Eastern / 17 CET. Feel free to jump into the meeting notes doc, where you will find info on where to join and where you can suggest agenda items for the upcoming meeting.

Thanks, and hope you all have a great week!

Roberth Strand
Crayon, Cloud Architect
Microsoft Azure MVP, HashiCorp Ambassador


Konveyor Sandbox Submission Follow Up

jlabocki@...
 

Greetings Alois Reitbauer, Jennifer Strejevitch, Hongchao Deng, Alex Jones, Thomas Schuetz (chairs and tech leads):

We appreciate the questions and feedback provided about Konveyor we received from the TOC. This topic attempts to answer some of the questions that came up during the sandbox application review. Would you be willing to review the questions and answers below and express whether or not you are supportive of Konveyor being moved into Sandbox status? If you are, I can then share this with the TOC and see if they can consider it.

Question: How or why would the Konveyor project ever move beyond sandbox to a graduated state?
Answer: While it is not always traditionally seen in this light, the Konveyor community believes that application modernization is not a one time activity. It is a constant ongoing operation. The Konveyor project has multiple tools within it currently that address various parts of the operations that would take place over time. For example:
    1. To start users may opt to simply rehost virtual machines to KubeVirt. This would be a low friction way to move workloads to Kubernetes. "Yay, my appliction is no on Kubernetes!"
    2. Once running on Kubernetes they might look at moving that application into containers (or a service of that application, i.e. - strangler pattern). In that case Tackle can help them assess and analyze their application. Shortly it will also create deployment manifests and other needed requirements in an automated fashion.
    3. Once running on Kubernetes they might look at replatforming that application to a newer version of Kubernetes on a different cluster and embracing GitOps. In that case, Crane could help them migrate the application with it's state and also remove environment specific dependencies (service cluster IPs). Crane can also help them move their application from a manual deployment into a pipeline based deployment.
    4. Once all this is done there is still a need for application modernization as they may want to make parts of their application serverless, etc. There is no doubt in my mind future enhancement to Kubernetes and the CNCF projects will create needs to once again modernize the same application. I hope this helps explain where the community sees the ongoing need.

Question: Do the Konveyor projects support non-vendor provided Kubernetes (i.e. OpenShift)?
Answer: The Konveyor projects do work with upstream versions of Kubernetes. While it is true that initially some of the projects had dependencies on OpenShift, the team has removed most of these dependencies and any future dependencies discovered would be fixed to ensure that the projects work with upstream Kubernetes. The community is committed to continually improving this experience and is open to helping others test on various distributions of Kubernetes. For example, this end to end demonstration was done on upstream Kubernetes and did not use OpenShift (except for one small portion that has since been addressed). The community did this on purpose because we wanted to find any issues that were happening and address them. Finally, you'll find the teams are making good progress on upstream documentation to ensure users have a good experience upstream first.
https://deploy-preview-1--crane-documentation.netlify.app/content/getting-started/overview/
https://tackle-docs.konveyor.io/documentation/doc-installing-and-using-tackle/master/index.html
https://forklift-docs.konveyor.io/documentation/doc-Migration_Toolkit_for_Virtualization/master/index.html
https://move2kube.konveyor.io/


 
Question: Do you have examples of GitHub issues associated with the project?
Answer: Each project within Konveyor has slight variations to their processes, but we are working in the completely open bi-weekly governance meeting to begin to see how we can bring the teams together in a more standard manner. Also, one example of external contributions is happening on move2kube within Konveyor. You can see the PRs here from external parties below:
https://github.com/konveyor/move2kube/commits?author=akhil-ghatiki (https://github.com/konveyor/move2kube/pulls?q=is%3Apr+Akhil+Ghatiki) https://github.com/konveyor/move2kube/commits?author=vovapi (https://github.com/konveyor/move2kube/pulls?q=is%3Apr+vovapi+is%3Aclosed) https://github.com/konveyor/move2kube/commits?author=MorrisLaw (https://github.com/konveyor/move2kube/pull/617) https://github.com/konveyor/move2kube/commits?author=Jan200101 (https://github.com/konveyor/move2kube/pull/53) https://github.com/konveyor/move2kube/commits?author=alealavi (https://github.com/konveyor/move2kube/pull/451)
https://github.com/konveyor/move2kube-api/commits?author=isabellaliu77 (https://github.com/konveyor/move2kube-api/pull/30) https://github.com/konveyor/move2kube-api/commits?author=burnerlee (https://github.com/konveyor/move2kube-api/pull/22) https://github.com/konveyor/move2kube-ui/commits?author=parkedwards (https://github.com/konveyor/move2kube-ui/pull/16) https://github.com/konveyor/move2kube-ui/commits?author=jams008 (https://github.com/konveyor/move2kube-ui/pull/14
In addition, we are aware of one customer using the Tackle project to assess/analyze applications to move to VMware's Tanzu Kuberenetes Grid (not OpenShift).

Given that Konveyor projects run on upstream Kubernetes, have external contribution, and are important on day-2 and we believe could have a path to graduation we would like your support to recommend Konveyor be granted Sandbox status. Are you supportive?



Re: Congratulations to our Cooperative Delivery Working Group co-chairs

Josh Gavant
 

Thank you Thomas and congratulations Roberth!

Looking forward to enabling users to more easily deliver and manage infrastructure capabilities and services in coordination with their applications.

One way we plan to start is by integrating some infrastructure services in podtato-head and demonstrating several ways of coordinating them with an app. Happily somebody tried that already today already with dapr! See:
  - https://blog.ediri.io/podtato-head-pulumi-and-azure-container-apps
  - https://github.com/podtato-head/podtato-head/pull/11

Please share your thoughts and ideas for this space with us in Slack, GitHub issues and in our biweekly meetings.

Thanks again and see you soon!

Best,
Josh

1 - 20 of 303