[Sandbox] KubeSlice

[pnavali]

Application contact emails

[email protected], [email protected], [email protected]

Project Summary

KubeSlice is a multi-cluster networking application for pod-to-pod communication across clusters.

Project Description

KubeSlice is an open-source project that simplifies multi-cluster networking for, multi-cloud, edge, cloud, hybrid-cloud and bare-metal Kubernetes clusters. It is a vendor-neutral extensible framework to build flat overlay networks across heterogeneous Kubernetes clusters. It enables and simplifies pod-to-pod communications for L3-L7 protocols across a fleet of clusters by using a construct called ‘Slice’. Each Slice can be associated with a set of clusters with varying topologies and can be associated with one or more namespaces in each cluster. The pods in the Slice namespaces can reach each other over the Slice specific flat overlay network. KubeSlice allows creating multiple Slices across clusters with each slice having a dedicated set of namespaces in each associated cluster. It enables easy segmentation and isolation of applications using slices. It allows namespace -sameness across the associated clusters in a slice. KubeSlice brings with it software-defined, highly-available and secure connections across clusters using VPN gateways. KubeSlice enables service discovery across the Slice using Service Exports and Imports in each cluster. A Slice associated namespace service running on a cluster can be exported and made available to all the other clusters namespaces associated with the Slice. SliceDNS in each cluster can be used for FQDN based inter-cluster service-service communications across the Slice. Slice DNS has service entries with overlay network IP addresses for service endpoints.

Slice flat overlay network is CNI agnostic, and it does not require non-conflicting pod subnets on the associated clusters.

KubeSlice integrates with service meshes like Istio to deploy slice Ingress/Egress gateways for east-west traffic across multi-cluster Istio deployments, by automating the creation of gateways and virtual services for cross cluster distribution of workloads.

This architectural prowess is vital for distributed applications across clusters, fostering data consistency, availability, and performance.

KubeSlice offers a unified service connectivity layer that enables easy segmentation and isolation of applications across multiple Kubernetes clusters. KubeSlice multi-cluster Kubernetes networking removes complexities of building and managing a service connectivity layer across multiple clusters. It further enables distributed application fabric through seamless data access and management. Users can craft data placement policies based on latency and data sovereignty and replicate data in optimal regions or clusters.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/kubeslice

Project repo URL in scope of application

https://github.com/kubeslice/kubeslice

Additional repos in scope of the application

https://github.com/orgs/kubeslice/repositories has all the related repos.

Website URL

https://kubeslice.io/

Roadmap

https://github.com/orgs/kubeslice/projects/4

Roadmap context

In our office hours and CNCF community channels, we openly discuss the Roadmap, gathering input and prioritizing items through collaborative discussions. Our approach is strongly oriented towards fostering a thriving ecosystem, and we actively seek opportunities for interoperability with CNCF projects and other open-source initiatives. This commitment helps us better address the interests and needs of our community.

Contributing Guide

://github.com/kubeslice/worker-httpsoperator/blob/master/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/kubeslice/worker-operator/blob/master/code_of_conduct.md

Adopters

No response

Contributing or Sponsoring Org

https://avesha.io/

Maintainers file

https://github.com/kubeslice/worker-operator/blob/master/MAINTAINERS.md

IP Policy

• [X] If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• [X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

By joining CNCF, we want to motivate more innovation and participation from the open-source community. Some significant values joining CNCF could bring to the project are:

Be vendor-neutral: KubeSlice can get a neutral home in CNCF, to facilitate further project development through a more diverse and neutral community.

Be more aware: leverage CNCF to promote the project and get more users and contributors through official events, mailing lists, blog posts, etc.

We also believe that KubeSlice could be an excellent addition to the existing CNCF landscape. KubeSlice is based on Kubernetes, and it is a significant attempt to tackle the challenges with applications specific multi-cluster networking across a fleet of clusters.

Benefit to the Landscape

As organizations move towards adopting or extending the use of Kubernetes clusters for their applications, they would inevitably have to deal with the complexities of building and managing a unified service connectivity layer for easy segmentation and isolation of applications across multiple clusters.

KubeSlice addresses these challenges by providing an extensible framework for creating and managing Slices where each Slice has its own flat overlay network and namespace associations for easy segmentation and isolation of applications across multiple clusters. Each pod in a Slice overlay network spanning across multiple clusters is uniquely addressable at L3. Hence, a pod talking to another pod in a remote cluster is oblivious of its location and would communicate with it as though it were running on the same cluster. Since the connectivity between pods is at L3, there is no need to provision L7 ingress/egress application gateways between clusters to enable pod-to-service or service-to-service communication. It also facilitates Service Discovery across the set of clusters by automatically exporting and importing service endpoints. KubeSlice not only enables applications that are based on L7 protocols, it also enables applications that are purely based on L4 protocols (TCP or UDP) to utilize multi-cluster topologies. KubeSlice does not have any restrictions on the CNI being used on the clusters. It is interoperable with any CNI, and it does not require the pod CIDR on the connecting clusters to be non-conflicting.

We believe KubeSlice would be a valuable addition to the CNCF landscape as the community navigates through the challenges of connecting applications across multiple clusters.

Cloud Native 'Fit'

KubeSlice is built as an extension to Kubernetes with Operators/Controllers and API extensions to build and manage Slices for applications connectivity across clusters. The Slice overlay network is built with cloud native network functions (CNFs). The state-based-management of Slices dramatically simplifies the multi-cluster connectivity orchestration and management, and improves the compatibility, scalability and configuration management of multi-cluster networking across heterogeneous Kubernetes clusters in edge, bare-metal or private/public cloud locations.

Cloud Native 'Integration'

KubeSlice uses CNCF sandbox project Network Service Mesh (NSM) for some of the Slice overlay network functions.

Cloud Native Overlap

N/A

Similar projects

N/A

Landscape

No

Business Product or Service to Project separation

Avesha’s KubeSlice enterprise product uses KubeSlice open-source as core, but the open source project roadmap and direction is driven by the needs of the community. This will continue to be true in the future. Avesha provides implementation & product enhancement services for enterprises which deviate from core open-source solutions.

Project presentations

No response

Project champions

No response

Additional information

No response

[TheFoxAtWork]

Please present to TAG - Network to provide additional awareness and understanding of what the project is and its scope with recommendation for align.

[mauilion]

Please present this project to tag network.

[pnavali]

Sure - will work with tag-network chairs to find a slot to present.

[pnavali]

Presented KubeSlice to TAG Network on 1/11. Thanks Nic Jackson @nicholasjackson, Lee Calcote @leecalcote and Lin Sun @istio for the opportunity to present it to the Network team and a good discussion. Presented slides are here. KubeSlice is built with cloud-native network functions and other CNCF sandbox projects (like NSM/Spire). It enables multi-cluster application networking and service connectivity with its Application Slices - with a slice specific flat overlay network across clusters, namespace associations and service connectivity across slice. We believe it aligns well with the TAG Network charter and look forward to the next steps.

[amye]

@leecalcote @linsun - does TAG network have a recommendation?

[linsun]

@amye ack - I'm consulting @nicholasjackson for his recommendation as he helped us run the last meeting on 1/11. Will circle back.

@pnavali please give me access to your slides - just sent a req in google docs. Thanks!

[pnavali]

@linsun - I have fixed the share settings on the doc - should be accessible to anyone with the link. Thanks. https://docs.google.com/presentation/d/1zU0_zCgRKG9IUSC2ad6MrUzd3treVaIO8zm2yFMMzBA/edit?usp=sharing

[linsun]

Hi @amye I have consulted @nicholasjackson and also gotten an update and demo from the KubeSlice team today in TAG-network meeting. We don't see any blocker for KubeSlide to be accepted as a CNCF incubation project. Both Nic and I found the project very interesting given our background of service mesh and networking, and have potential to integrate with various mesh products.

Nic wrote a great explanation: KubeSlice is a tool for Kubernetes with optional Service Mesh integration that allows you to distribute and connect services in your application securely across multiple Kubernetes clusters. For example, there are two teams in your organization. Team Frontend and Team Backend, each team manages a number of services and each team operates their own Kubernetes cluster. Team Backend would like to expose an API service securely to Team Frontend without exposing any other elements of the cluster. KubeSlice enables this by creating a slice, which is a logical partition of an application; this slice can then be exposed to an external cluster securely via the Slice VPN Gateways that run on each cluster. Since KubeSlice creates a custom DNS entry for the slice, all Team Frontend needs to do to call the service is to address it via the service DNS. KubeSlice handles the traffic routing to the Slice Gateway and then to the second cluster. Not only does this work between two clusters on the same VPC or network, but you can also use it on networks, vpcs, and even clouds.

One concern I have shared with the project is the lack of GitHub activities, there were a few months inactivity and no release towards 4Q 2023. The project maintainer mentioned they were working on a big feature thus skipped 1 release.

[pnavali]

Thank you @linsun and @nicholasjackson for a great feedback - Kubeslice team really appreciates it.

[nicholasjackson]

You are more than welcome, we are really looking forward to helping drive KubeSlice forward

[linsun]

Yep thank you @pnavali for presenting this twice to tag-network!! Great project!

[jberkus]

Existing project community files look fine.

If you get into Sandbox, you'll want to think about creating project governance for Kubeslice. But it's not required for acceptance.

[pnavali]

@jberkus sure will do - thanks.

[chira001]

Hi @amye I have consulted @nicholasjackson and also gotten an update and demo from the KubeSlice team today in TAG-network meeting. We don't see any blocker for KubeSlide to be accepted as a CNCF incubation project. Both Nic and I found the project very interesting given our background of service mesh and networking, and have potential to integrate with various mesh products.

Nic wrote a great explanation: KubeSlice is a tool for Kubernetes with optional Service Mesh integration that allows you to distribute and connect services in your application securely across multiple Kubernetes clusters. For example, there are two teams in your organization. Team Frontend and Team Backend, each team manages a number of services and each team operates their own Kubernetes cluster. Team Backend would like to expose an API service securely to Team Frontend without exposing any other elements of the cluster. KubeSlice enables this by creating a slice, which is a logical partition of an application; this slice can then be exposed to an external cluster securely via the Slice VPN Gateways that run on each cluster. Since KubeSlice creates a custom DNS entry for the slice, all Team Frontend needs to do to call the service is to address it via the service DNS. KubeSlice handles the traffic routing to the Slice Gateway and then to the second cluster. Not only does this work between two clusters on the same VPC or network, but you can also use it on networks, vpcs, and even clouds.

One concern I have shared with the project is the lack of GitHub activities, there were a few months inactivity and no release towards 4Q 2023. The project maintainer mentioned they were working on a big feature thus skipped 1 release.

@linsun - could I just clarify if we mean sandbox or incubation stage for the recommendation?

[amye]

Hi @amye I have consulted @nicholasjackson and also gotten an update and demo from the KubeSlice team today in TAG-network meeting. We don't see any blocker for KubeSlide to be accepted as a CNCF incubation project. Both Nic and I found the project very interesting given our background of service mesh and networking, and have potential to integrate with various mesh products. Nic wrote a great explanation: KubeSlice is a tool for Kubernetes with optional Service Mesh integration that allows you to distribute and connect services in your application securely across multiple Kubernetes clusters. For example, there are two teams in your organization. Team Frontend and Team Backend, each team manages a number of services and each team operates their own Kubernetes cluster. Team Backend would like to expose an API service securely to Team Frontend without exposing any other elements of the cluster. KubeSlice enables this by creating a slice, which is a logical partition of an application; this slice can then be exposed to an external cluster securely via the Slice VPN Gateways that run on each cluster. Since KubeSlice creates a custom DNS entry for the slice, all Team Frontend needs to do to call the service is to address it via the service DNS. KubeSlice handles the traffic routing to the Slice Gateway and then to the second cluster. Not only does this work between two clusters on the same VPC or network, but you can also use it on networks, vpcs, and even clouds. One concern I have shared with the project is the lack of GitHub activities, there were a few months inactivity and no release towards 4Q 2023. The project maintainer mentioned they were working on a big feature thus skipped 1 release.

@linsun - could I just clarify if we mean sandbox or incubation stage for the recommendation?

This is a sandbox application, that's the path forward here.

[linsun]

Hi @amye I have consulted @nicholasjackson and also gotten an update and demo from the KubeSlice team today in TAG-network meeting. We don't see any blocker for KubeSlide to be accepted as a CNCF incubation project. Both Nic and I found the project very interesting given our background of service mesh and networking, and have potential to integrate with various mesh products. Nic wrote a great explanation: KubeSlice is a tool for Kubernetes with optional Service Mesh integration that allows you to distribute and connect services in your application securely across multiple Kubernetes clusters. For example, there are two teams in your organization. Team Frontend and Team Backend, each team manages a number of services and each team operates their own Kubernetes cluster. Team Backend would like to expose an API service securely to Team Frontend without exposing any other elements of the cluster. KubeSlice enables this by creating a slice, which is a logical partition of an application; this slice can then be exposed to an external cluster securely via the Slice VPN Gateways that run on each cluster. Since KubeSlice creates a custom DNS entry for the slice, all Team Frontend needs to do to call the service is to address it via the service DNS. KubeSlice handles the traffic routing to the Slice Gateway and then to the second cluster. Not only does this work between two clusters on the same VPC or network, but you can also use it on networks, vpcs, and even clouds. One concern I have shared with the project is the lack of GitHub activities, there were a few months inactivity and no release towards 4Q 2023. The project maintainer mentioned they were working on a big feature thus skipped 1 release.

@linsun - could I just clarify if we mean sandbox or incubation stage for the recommendation?

This is a sandbox application, that's the path forward here.

Correct, only for sandbox stage.

[pnavali]

Quick KubeSlice project update:

Releases: We have done 3 releases since Jan: https://kubeslice.io/documentation/open-source/1.3.0/category/release-notes 1.2.0 - Jan 16 2024 1.2.1 - March 13 2024 1.3.0 - April 2 2024 Working on a release cadence of one or two releases per month.

Busy repo worker-operator pulse for March month: https://github.com/kubeslice/worker-operator/pulse/monthly Excluding merges, 9 authors have pushed 23 commits to master and 39 commits to all branches. On master, 107 files have changed and there have been [4,981 additions and 1,430 deletions].

We have added additional community contributors (working on it) and are looking to get more participation/visibility with CNCF sandbox approval.

Community development:

• We held KubeSlice open office hours event online on Feb 28th.
• Kubeslice demos at KubeCon Europe/Network TAG booth - hosted by TAG Network chair @nicholasjackson Thanks Nic!
• We presented KubeSlice at Docker Pune virtual meetup event (hosted by CNCF Ambassador) - with 36 in attendance
• We presented KubeSlice and held office open hours at Docker Pune in-person meetup event at Nutanix (hosted by CNCF Ambassador) - with around 60 in attendance
• We will be presenting KubeSlice at KCD Pune 2024 event on April 13th. CNCF supported; https://kcdpune.in/#

[cathyhongzhang]

Looks like a useful feature that can set up multiple virtual network domains for different tenants or different types of workloads through slices.

[castrojo]

/vote-sandbox

[git-vote[bot]]

Vote created

@castrojo has called for a vote on [Sandbox] KubeSlice (#62).

The members of the following teams have binding votes:

Team
@cncf/cncf-toc

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 7days. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[pnavali]

/check-vote

[git-vote[bot]]

Vote status

So far 36.36% of the users with binding vote are in favor (passing threshold: 66%).

Summary

In favor	Against	Abstain	Not voted
4	0	0	7

Binding votes (4)

User	Vote	Timestamp
rochaporto	In favor	2024-04-09 18:40:50.0 +00:00:00
TheFoxAtWork	In favor	2024-04-09 21:50:23.0 +00:00:00
cathyhongzhang	In favor	2024-04-09 16:11:52.0 +00:00:00
dims	In favor	2024-04-09 17:37:23.0 +00:00:00
@mauilion	Pending
@linsun	Pending
@dzolotusky	Pending
@kevin-wangzefeng	Pending
@nikhita	Pending
@kgamanji	Pending
@erinaboyd	Pending

Non-binding votes (38)

User	Vote	Timestamp
kunal-kushwaha	In favor	2024-04-09 20:43:49.0 +00:00:00
neutr0n420	In favor	2024-04-09 21:02:47.0 +00:00:00
jeevanjoseph	In favor	2024-04-09 21:32:46.0 +00:00:00
williamcaban	In favor	2024-04-09 22:28:03.0 +00:00:00
Rahul-D78	In favor	2024-04-10 1:42:22.0 +00:00:00
hanshal101	In favor	2024-04-10 1:53:20.0 +00:00:00
priyupadhyay	In favor	2024-04-10 2:31:35.0 +00:00:00
KRANTHI0918	In favor	2024-04-10 3:37:10.0 +00:00:00
KRANTHI1430	In favor	2024-04-10 3:37:37.0 +00:00:00
narmidm	In favor	2024-04-10 3:47:36.0 +00:00:00
PuranAdhikari	In favor	2024-04-10 4:10:42.0 +00:00:00
cheera270	In favor	2024-04-10 4:46:51.0 +00:00:00
saikotireddy	In favor	2024-04-10 4:51:53.0 +00:00:00
bharathbh	In favor	2024-04-10 4:52:15.0 +00:00:00
rissh	In favor	2024-04-10 4:58:34.0 +00:00:00
NishantSingh10	In favor	2024-04-10 5:51:15.0 +00:00:00
corneliu-calciu	In favor	2024-04-10 5:56:58.0 +00:00:00
tanmoysrt	In favor	2024-04-10 6:06:14.0 +00:00:00
Krishnapro	In favor	2024-04-10 6:10:32.0 +00:00:00
toshalkhawale	In favor	2024-04-10 6:13:31.0 +00:00:00
rohitBDeshmukh21	In favor	2024-04-10 6:15:22.0 +00:00:00
rahulii	In favor	2024-04-10 6:23:52.0 +00:00:00
rohitutekar123	In favor	2024-04-10 6:25:35.0 +00:00:00
sksaec	In favor	2024-04-10 6:59:20.0 +00:00:00
argadepp	In favor	2024-04-10 7:26:46.0 +00:00:00
Vivekgaddigi	In favor	2024-04-10 7:30:58.0 +00:00:00
Dheeraj-k8s	In favor	2024-04-10 7:37:43.0 +00:00:00
sudhiratavesha	In favor	2024-04-10 7:54:46.0 +00:00:00
Himan-Miku	In favor	2024-04-10 7:57:28.0 +00:00:00
sachinzac	In favor	2024-04-10 8:05:01.0 +00:00:00
yami-kami	In favor	2024-04-10 8:59:10.0 +00:00:00
mridulgain	In favor	2024-04-10 9:54:59.0 +00:00:00
testmail181202	In favor	2024-04-10 9:57:30.0 +00:00:00
veenamj-avesha	In favor	2024-04-10 10:26:43.0 +00:00:00
samuelneagu	In favor	2024-04-10 10:51:42.0 +00:00:00
uwagh	In favor	2024-04-10 11:22:25.0 +00:00:00
saiyam1814	In favor	2024-04-10 13:02:11.0 +00:00:00
rajavesha	In favor	2024-04-10 13:02:17.0 +00:00:00

[nicholasjackson]

/check-vote

[git-vote[bot]]

Vote status

So far 63.64% of the users with binding vote are in favor (passing threshold: 66%).

Summary

In favor	Against	Abstain	Not voted
7	0	0	4

Binding votes (7)

User	Vote	Timestamp
kevin-wangzefeng	In favor	2024-04-11 0:51:28.0 +00:00:00
TheFoxAtWork	In favor	2024-04-09 21:50:23.0 +00:00:00
dims	In favor	2024-04-09 17:37:23.0 +00:00:00
linsun	In favor	2024-04-11 10:30:45.0 +00:00:00
kgamanji	In favor	2024-04-10 16:17:23.0 +00:00:00
rochaporto	In favor	2024-04-09 18:40:50.0 +00:00:00
cathyhongzhang	In favor	2024-04-09 16:11:52.0 +00:00:00
@mauilion	Pending
@dzolotusky	Pending
@nikhita	Pending
@erinaboyd	Pending

Non-binding votes (53)

User	Vote	Timestamp
kunal-kushwaha	In favor	2024-04-09 20:43:49.0 +00:00:00
neutr0n420	In favor	2024-04-09 21:02:47.0 +00:00:00
jeevanjoseph	In favor	2024-04-09 21:32:46.0 +00:00:00
williamcaban	In favor	2024-04-09 22:28:03.0 +00:00:00
Rahul-D78	In favor	2024-04-10 1:42:22.0 +00:00:00
hanshal101	In favor	2024-04-10 1:53:20.0 +00:00:00
priyupadhyay	In favor	2024-04-10 2:31:35.0 +00:00:00
KRANTHI0918	In favor	2024-04-10 3:37:10.0 +00:00:00
KRANTHI1430	In favor	2024-04-10 3:37:37.0 +00:00:00
narmidm	In favor	2024-04-10 3:47:36.0 +00:00:00
PuranAdhikari	In favor	2024-04-10 4:10:42.0 +00:00:00
cheera270	In favor	2024-04-10 4:46:51.0 +00:00:00
saikotireddy	In favor	2024-04-10 4:51:53.0 +00:00:00
bharathbh	In favor	2024-04-10 4:52:15.0 +00:00:00
rissh	In favor	2024-04-10 4:58:34.0 +00:00:00
NishantSingh10	In favor	2024-04-10 5:51:15.0 +00:00:00
corneliu-calciu	In favor	2024-04-10 5:56:58.0 +00:00:00
tanmoysrt	In favor	2024-04-10 6:06:14.0 +00:00:00
Krishnapro	In favor	2024-04-10 6:10:32.0 +00:00:00
toshalkhawale	In favor	2024-04-10 6:13:31.0 +00:00:00
rohitBDeshmukh21	In favor	2024-04-10 6:15:22.0 +00:00:00
rahulii	In favor	2024-04-10 6:23:52.0 +00:00:00
rohitutekar123	In favor	2024-04-10 6:25:35.0 +00:00:00
sksaec	In favor	2024-04-10 6:59:20.0 +00:00:00
Vivekgaddigi	In favor	2024-04-10 7:30:58.0 +00:00:00
Dheeraj-k8s	In favor	2024-04-10 7:37:43.0 +00:00:00
sudhiratavesha	In favor	2024-04-10 7:54:46.0 +00:00:00
Himan-Miku	In favor	2024-04-10 7:57:28.0 +00:00:00
sachinzac	In favor	2024-04-10 8:05:01.0 +00:00:00
yami-kami	In favor	2024-04-10 8:59:10.0 +00:00:00
mridulgain	In favor	2024-04-10 9:54:59.0 +00:00:00
testmail181202	In favor	2024-04-10 9:57:30.0 +00:00:00
veenamj-avesha	In favor	2024-04-10 10:26:43.0 +00:00:00
samuelneagu	In favor	2024-04-10 10:51:42.0 +00:00:00
uwagh	In favor	2024-04-10 11:22:25.0 +00:00:00
saiyam1814	In favor	2024-04-10 13:02:11.0 +00:00:00
rajavesha	In favor	2024-04-10 13:02:17.0 +00:00:00
gourishbiradar	In favor	2024-04-10 13:37:58.0 +00:00:00
d7r-s4a-01	In favor	2024-04-10 14:23:50.0 +00:00:00
that-backend-guy	In favor	2024-04-10 14:24:30.0 +00:00:00
argadepp	In favor	2024-04-10 15:13:00.0 +00:00:00
nicholasjackson	In favor	2024-04-10 15:34:21.0 +00:00:00
wmariuss	In favor	2024-04-10 16:10:38.0 +00:00:00
Naveen-Reddi	In favor	2024-04-10 16:26:42.0 +00:00:00
KRANTHI1403	In favor	2024-04-10 16:32:52.0 +00:00:00
Hithesh-16	In favor	2024-04-10 16:52:36.0 +00:00:00
joerober	In favor	2024-04-10 17:05:59.0 +00:00:00
rutu-k	In favor	2024-04-10 17:32:29.0 +00:00:00
vvmadduri	In favor	2024-04-10 17:39:30.0 +00:00:00
swghosh	In favor	2024-04-10 19:05:44.0 +00:00:00
frankpaolino	In favor	2024-04-11 3:30:35.0 +00:00:00
Manikanta-StickSecure	In favor	2024-04-11 4:45:51.0 +00:00:00
FireAnt121	In favor	2024-04-11 13:08:22.0 +00:00:00

[pnavali]

/check-vote

[git-vote[bot]]

Votes can only be checked once a day.

[git-vote[bot]]

Vote closed

The vote passed! 🎉

81.82% of the users with binding vote were in favor (passing threshold: 66%).

Summary

In favor	Against	Abstain	Not voted
9	0	0	2

Binding votes (9)

User	Vote	Timestamp
@TheFoxAtWork	In favor	2024-04-09 21:50:23.0 +00:00:00
@cathyhongzhang	In favor	2024-04-09 16:11:52.0 +00:00:00
@linsun	In favor	2024-04-11 10:30:45.0 +00:00:00
@erinaboyd	In favor	2024-04-11 19:55:22.0 +00:00:00
@kevin-wangzefeng	In favor	2024-04-11 0:51:28.0 +00:00:00
@rochaporto	In favor	2024-04-09 18:40:50.0 +00:00:00
@dims	In favor	2024-04-09 17:37:23.0 +00:00:00
@nikhita	In favor	2024-04-12 9:29:23.0 +00:00:00
@kgamanji	In favor	2024-04-10 16:17:23.0 +00:00:00

Non-binding votes (56)

User	Vote	Timestamp
@kunal-kushwaha	In favor	2024-04-09 20:43:49.0 +00:00:00
@neutr0n420	In favor	2024-04-09 21:02:47.0 +00:00:00
@jeevanjoseph	In favor	2024-04-09 21:32:46.0 +00:00:00
@williamcaban	In favor	2024-04-09 22:28:03.0 +00:00:00
@Rahul-D78	In favor	2024-04-10 1:42:22.0 +00:00:00
@hanshal101	In favor	2024-04-10 1:53:20.0 +00:00:00
@priyupadhyay	In favor	2024-04-10 2:31:35.0 +00:00:00
@KRANTHI0918	In favor	2024-04-10 3:37:10.0 +00:00:00
@KRANTHI1430	In favor	2024-04-10 3:37:37.0 +00:00:00
@narmidm	In favor	2024-04-10 3:47:36.0 +00:00:00
@PuranAdhikari	In favor	2024-04-10 4:10:42.0 +00:00:00
@cheera270	In favor	2024-04-10 4:46:51.0 +00:00:00
@saikotireddy	In favor	2024-04-10 4:51:53.0 +00:00:00
@bharathbh	In favor	2024-04-10 4:52:15.0 +00:00:00
@rissh	In favor	2024-04-10 4:58:34.0 +00:00:00
@NishantSingh10	In favor	2024-04-10 5:51:15.0 +00:00:00
@corneliu-calciu	In favor	2024-04-10 5:56:58.0 +00:00:00
@tanmoysrt	In favor	2024-04-10 6:06:14.0 +00:00:00
@Krishnapro	In favor	2024-04-10 6:10:32.0 +00:00:00
@toshalkhawale	In favor	2024-04-10 6:13:31.0 +00:00:00
@rohitBDeshmukh21	In favor	2024-04-10 6:15:22.0 +00:00:00
@rahulii	In favor	2024-04-10 6:23:52.0 +00:00:00
@rohitutekar123	In favor	2024-04-10 6:25:35.0 +00:00:00
@sksaec	In favor	2024-04-10 6:59:20.0 +00:00:00
@Vivekgaddigi	In favor	2024-04-10 7:30:58.0 +00:00:00
@sudhiratavesha	In favor	2024-04-10 7:54:46.0 +00:00:00
@Himan-Miku	In favor	2024-04-10 7:57:28.0 +00:00:00
@sachinzac	In favor	2024-04-10 8:05:01.0 +00:00:00
@yami-kami	In favor	2024-04-10 8:59:10.0 +00:00:00
@mridulgain	In favor	2024-04-10 9:54:59.0 +00:00:00
@testmail181202	In favor	2024-04-10 9:57:30.0 +00:00:00
@veenamj-avesha	In favor	2024-04-10 10:26:43.0 +00:00:00
@samuelneagu	In favor	2024-04-10 10:51:42.0 +00:00:00
@uwagh	In favor	2024-04-10 11:22:25.0 +00:00:00
@saiyam1814	In favor	2024-04-10 13:02:11.0 +00:00:00
@rajavesha	In favor	2024-04-10 13:02:17.0 +00:00:00
@gourishbiradar	In favor	2024-04-10 13:37:58.0 +00:00:00
@d7r-s4a-01	In favor	2024-04-10 14:23:50.0 +00:00:00
@that-backend-guy	In favor	2024-04-10 14:24:30.0 +00:00:00
@argadepp	In favor	2024-04-10 15:13:00.0 +00:00:00
@nicholasjackson	In favor	2024-04-10 15:34:21.0 +00:00:00
@wmariuss	In favor	2024-04-10 16:10:38.0 +00:00:00
@Naveen-Reddi	In favor	2024-04-10 16:26:42.0 +00:00:00
@KRANTHI1403	In favor	2024-04-10 16:32:52.0 +00:00:00
@Hithesh-16	In favor	2024-04-10 16:52:36.0 +00:00:00
@joerober	In favor	2024-04-10 17:05:59.0 +00:00:00
@rutu-k	In favor	2024-04-10 17:32:29.0 +00:00:00
@vvmadduri	In favor	2024-04-10 17:39:30.0 +00:00:00
@swghosh	In favor	2024-04-10 19:05:44.0 +00:00:00
@frankpaolino	In favor	2024-04-11 3:30:35.0 +00:00:00
@Manikanta-StickSecure	In favor	2024-04-11 4:45:51.0 +00:00:00
@FireAnt121	In favor	2024-04-11 13:08:22.0 +00:00:00
@Dheeraj-k8s	In favor	2024-04-11 19:27:18.0 +00:00:00
@katragadda	In favor	2024-04-11 20:21:34.0 +00:00:00
@bhood4	In favor	2024-04-12 0:37:24.0 +00:00:00
@skrantz2000	In favor	2024-04-12 7:02:01.0 +00:00:00

[jeefy]

Heya @pnavali!

Welcome aboard! We're very excited to get you onboarded as a CNCF sandbox project! Here's the link to your onboarding checklist: https://github.com/cncf/sandbox/issues/190

That issue is where you can communicate any questions or concerns you might have. Please don't hesitate to reach out!

[pnavali]

Hello @jeefy - Thank you! We are looking forward to be onboarded - will take a look at the checklist/tasks and will reach out on cncf/sandbox#190.

[mrbobbytables]

With the onboarding issue open at: https://github.com/cncf/sandbox/issues/190 I'm going to go ahead and close this out. 👍

Thanks!