[Sandbox] Cozystack #87
Comments
|
You might want to amend this, there are several non-CNCF projects listed 😂 |
|
Well, that's actually true. I just double checked the information, and I found that:
I have to check the information better. Thank you for pointing this out. |
|
Hey there 👋 I just prepared a blog-posts about Cozystack for kubernetes.io: |
|
@amye this should probably be tagged for TAG App Delivery (and WG Platforms) too. Thanks! |
|
Please ignore the status change above; that was caused by my mistouch while accessing the website on my mobile browser. |
|
@lianmakesthings - Does TAG App Delivery have a recommendation for this project? |
|
Hi all, I was checking our notes and couldn't find a reference to cozystack. Was this project ever presented to the TAG App Delivery? If yes, would you be able to share the date? |
|
@lianmakesthings |
|
I just found tomorrow will be TAG App Delivery - General Meeting. Is that correct place for making presentation? |
|
Hi @kvaps Here is the link to tomorrow's meeting: https://zoom-lfx.platform.linuxfoundation.org/meeting/98590236563?password=b0335b64-4162-4499-bb61-ff2c7dec2724 Please let me know if you have any more questions. Otherwise, see you tomorrow! |
|
For transparency I would just like to mention that I will be working on reviewing this project for TAG App Delivery. We will have Cozystack on our August 7th meeting, and potentially at the next Platforms WG meeting as well. |
|
TAG Contributor strategy has reviewed this project and found the following:
This review is for the TOC’s information only. Sandbox projects are not required to have full governance or contributor documentation. |
|
Question, unrelated to the TAG-CS review: given that Talos Linux did not become part of the CNCF, would you still be contributing the talos-bootstrap repository? |
Yes, we're going to add this functionality into Talm configuration manager We like Talos Linux and are happy to use it for our customers. But we don't want to be dependent on Talos Linux alone, we want to support various distributions as well. The main value of the product is to provide ready-to-use automation bundles for bootstraping Kubernetes configuration, we provide bundles which can be used in hosted Kubernetes clusters for example: |
|
As about contributors documentation, it's slightly oudated. We'll fix it soon. We have more contributors and weekly meetings established with 4-7 person's visiting them every time. All of them from various companies and countries https://youtube.com/playlist?list=PLEIgpkcPkMHaXqndo8iMMLS64p4sBkHPg&si=DOJ7mjA9MSEhJBYS |
|
Hello again @kvaps, sorry for the late post here. A couple of follow-up questions after the TAG presentation. Good variation across the board here, as I purposely choose questions that expands on what I learned from your presentation.
|
|
Hi @roberthstrand, thank you for your questions,
The core value of the Cozystack is to provide ready configuration for all the system and user components. Thanks to Kubernetes all the components of the platform are standartized and unified. Thanks to Talos Linux the system configuration is fully atomic and managed by single YAML file format. In another words we just removed the OS layer operations to avoid system bugs and human mistakes by strict APIs of Kubernetes and Talos Linux. There are some bundles prepared to install on existing Kubernetes clusters. As about development Cozystack includes many amazing open-source technologies, one of our moto: Collaborate, not compete We are proud of our community and closely interact with projects around it. Thus if a feature being developed for the platform could be useful to a upstream project, it should be contributed to upstream project, rather than being implemented within the platform. We contribute a lot into such projects as Kubernetes, KubeVirt, Cilium, LINSTOR, FluxCD, SeaweedFS, kube-ovn and so on.
All system components are automatically updated with the installation of a new release. For user-facing services, we do not perform automatic upgrades yet. However, we inform users that an upgrade is available. We allow users to perform updates via the Dashboard, API, or using the GitOps approach.
Cozystack covers entrie infrastructure stack:
Layer 1: We don't strictly depend on Talos Linux, but highly recomend it to use. We still provide the oportunity to install Cozystack on different distros. But in this case we don't gurantee that everything will work as expected. Because in this case we can't be sure that system has correct kernel and all the modules enabled (especially DRBD and ZFS) Layer 2: Consists of system components delivered by FluxCD
Layer 3: Consists of system components delivered by FluxCD
Layer 4 User-defined applications can be created via both Cozystack Dashboard (based on kubeapps project) or direcrly in Kubernetes API, and are still managed by FluxCD. Helm is used to pack all the required YAML-manifests for the operators and provide user a single format for ordering managed services. Thanks to Helm it is easy to extend platform by adding external Helm repository and provide the Helm charts in the same format.
In the input we are expecting bare-metal servers, with no OS installed. In the output user gets the interface where they can order managed servcices from their hardware. Such services are:
All of them are configured to use preconfigured monitoring stack witch is backed by Grafana and Victoria Metrics.
|
|
Summary of the key considerations. For more details, see the review document. Community and GrowthThe project is primarily maintained by representatives from Ænix, but there are various contributors from other organizations. The project is relatively new, being around for less than a year, but has already managed to get a healthy number of contributors, GitHub stars and is starting to get some adopters. The project has been presented at several conferences, including KCD Czech & Slovak. There is a channel on the Kubernetes slack, closely followed up by the maintainers, and they host a weekly community meeting. Release Process, Issues and Testing InfrastructureCozystack aims to have 1-3 feature releases per month, in addition to path releases when necessary. The project follows semantic versioning, but has no automation for release and testing running yet. There are pull requests covering this, but nothing that has been merged and is in use. Project ChallengesThe balance between flexibility and opinionated comes to mind. The project should aim to simplify, but not at the cost of flexibility. How can one make sure the various aspects of the platform stack are modular and interchangeable? Key Feedback to the Project:There are some low hanging fruits one could tackle, like adding workflows for release automation and testing. Currently, only one maintainer is set as codeowner, so there is a single point of failure if something happens. After this moves over to a project specific GitHub organization, the governance structure needs to be updated. I would like to see more documentation in regards to how one can add more services to the project or how to change out the services that come with the project now. It makes sense to allow various platform teams to use Cozystack in a way that fits their organizations needs. TAG Recommendation to TOC:I think the project shows great promise. I have personally worked on creating a similar project, and I know how hard it is to create something that takes into account all the variables of a platform that builds platforms. Cozystack has solved a lot of these issues pretty elegantly, while still keeping simplicity and ease of use in mind. There is a lot to do when it comes to procedure and governance. After my interactions with the maintainers, I think these changes can be done quickly, and as this is an interesting project there will definitely be many interested potential contributors and maintainers ready to join if it gets accepted as a sandbox project. In general, I would recommend for the project to be accepted for sandbox. The few issues I have with the project should be easy fixes, and I think they will find a lot of traction as a sandbox project going forward. |
|
Hi Folks! Thank you for your interest in applying for CNCF sandbox! The TOC has reviewed your application today, and would recommend you to apply for a later date as a CNCF incubation project. We would love you to address the following concerns being discussed in the meeting:
Thanks much! |
|
Thanks again for the discussion in the platforms WG (Video attached here for reference) I know we ran out of time, but one question I have on this proposal is the lack of any cloud native overlaps. I am surprised to see that as I think there are a number of projects that also try to install packages per an operators config. For example, I think Otomi, KubeFirst and others seem to be in similar places but CNCF member companies and not projects so no conflict, just curious about the differentiations in a crowded space. Thanks! |
|
Hi @linsun, thank you for your response. As a self-bootstrapped project, we were hoping that CNCF could help us address these shortcomings :)
Is there a recording publicly available? We would like to review it to better understand the topics discussed. This would help us work in this direction and get better to improve our next application.
What do you mean by that? Is it possible to apply directly for a CNCF Incubation project without going through the Sandbox? Or will our application be considered later in the CNCF Sandbox? What further steps would you recommend? |
|
Hi @abangser, thank you for publishing the video. It was great to attend today's Platforms WG meeting.
As for your question, these projects are designed to provide ready configurations for Kubernetes, with their main focus being Kubernetes distribution. We don't see them as competition because our primary focus is on providing managed services. Our users may not be familiar with Kubernetes to run the services they need. We use Kubernetes solely as an engine to run all the necessary components for them. We can compete with solutions such as:
Currently, CNCF does not have a project that would solve service-providers needs and provide ready managed services backed for them. |
|
Also I want to add that solutions like Nutanix also could be recognised like a competitors to Cozystack. |
Yes, recording will be published, I will post a link here. And yes, you can apply directly for incubation without going through sandbox. Istio project did that, for example. |
|
Hi @kvaps - the recording from yesterday's meeting is out - https://www.youtube.com/watch?v=dFqDK3YtdEA, which should provide you more context of the discussion and some of the concerns the TOC has. I believe your project is somewhere in the middle of the recording. As far as further steps, I would recommend you focus on the concerns raised by the TOC members and drive more adoptions for your project. Some resources you may find useful: HTH! |
|
@linsun Hi! Thanks for the clarifications. Just one question. Is it correct understanding that we should implement some processes and address the concerns before we will proceed? Or could we go "as is"? |
|
Closing this application in favor of a future application to sandbox once the following items are completed:
|
github-project-automation
bot
moved this from 🏗 Upcoming
to ✅ Done
in Sandbox Application Board
Application contact emails
[email protected], [email protected], [email protected]
Project Summary
Cozystack is an open-source PaaS platform and framework for building clouds
Project Description
With Cozystack, you can transform your bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
You can use Cozystack to build your own cloud or to provide a cost-effective development environments.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/aenix-io
Project repo URL in scope of application
https://github.com/aenix-io/cozystack
Additional repos in scope of the application
https://github.com/aenix-io/talos-bootstrap/
Website URL
https://cozystack.io/
Roadmap
https://github.com/orgs/aenix-io/projects/2
Roadmap context
No response
Contributing Guide
https://github.com/aenix-io/cozystack/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/aenix-io/cozystack/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/aenix-io/cozystack/blob/main/ADOPTERS.md
Contributing or Sponsoring Org
https://aenix.io/
Maintainers file
https://github.com/aenix-io/cozystack/blob/main/MAINTAINERS.md
IP Policy
Trademark and accounts
Why CNCF?
We're startup and group of entusiasts which decided to go by the way of standardization.
Our platform is based on many other CNCF projects and provides a turn-key solution which is easy to install and use.
We want to keep this standardization as much as possible, we believe that open-source is the only way to achieve this.
Being a CNCF member, will allow us to show people our intention to remain standard and always free.
We adopt Kubernetes, Talos Linux, KubeVirt, Kamaji, FluxCD, Cluster API, Cert-Manager, Piraeus, Kube-OVN, Cilium, MetalLB, among others. We contribute a lot to these projects. We are keen to collaborate closely with them.
It would be nice to join a common ecosystem build by CNCF.
Since we self-bootstrapped we have no any profit yet, we need a help with promotion and various opportunities like both and lighting talks on KubeCon to let the people know about our project and attact the sponsors and external contributors.
Benefit to the Landscape
One of our motos: "Collaborate, not compete"
We are proud of our community and closely interact with projects around it. Thus if a feature being developed for the platform could be useful to a upstream project, it should be contributed to upstream project, rather than being implemented within the platform.
Being a CNCF member will help users of other CNCF projects with adoption of their technologies as they could provide a ready product and real-world example how it can be used.
Also we can organize a people to make a beatiful things together, for example etcd-operator is one of this community-driven project
#91
Cloud Native 'Fit'
We believe that our project will help various cloud-providers to build their infrastructure based on modern cloud-native principles.
The project goal is that you can manage your bare-metal infrastracture using cloud native approaches:
Cloud Native 'Integration'
We use a lot of CNCF projects and build a single ecosystem around them:
Talos Linux
Using Talos Linux as the base layer for the platform allows to strictly limit the technology stack and make the system stable as a rock.
Talos Linux has no moving parts, no traditional package manager, no file structure, and no ability to run anything except Kubernetes containers. The base layer of the platform includes the latest version of the kernel, all the necessary kernel modules, container runtime and a Kubernetes-like API for interacting with the system.
Updating the system is done by rewriting the image “as is” entirely onto the hard drive.
Kubernetes and etcd
Kubernetes has already become a kind of de facto standard for managing server workloads.
Our platform is Kubernetes-based and provides managed Kubernetes service that allows you to create full-featured Kubernetes clusters on demand. For each cluster, a separate managed control-plane and virtual compute nodes are created.
The control-plane is powered by Kamaji project and separate etcd cluster for backend. We utilize Cluster API for spawnging tenant Kubernetes clusters.
KubeVirt
KubeVirt is a project started by global industry leaders with a common vision to unify Kubernetes and a desire to introduce it to the world of virtualization. KubeVirt extends the capabilities of Kubernetes by providing convenient abstractions for launching and managing virtual machines, as well the all related entities such as snapshots, presets, virtual volumes, and more.
Helm and FluxCD
Each package in the platform consists of a set of YAML files combined into Helm chart. Therefore, anyone with some familiarity with Kubernetes primitives can modify or expand the platform. Delivery of packages to the system is handled by FluxCD, a well-known and widely used tool in the community.
FluxCD is the main system used to build distribution. FluxCD is used for three different cases:
Kube-OVN
Kube-OVN is a free implementation of virtual network fabric for Kubernetes based on Open vSwitch technology. With OVN, you get a robust and functional virtual network that ensures reliable isolation between tenants and provides floating addresses for virtual machines.
This enables seamless integration with other clusters and customer network services.
Cilium
Utilizing Cilium in conjunction with OVN enables the most efficient and flexible network policies, along with a productive services network in Kubernetes, leveraging an offloaded Linux network stack featuring the cutting-edge eBPF technology.
MetalLB
MetalLB is the default load balancer for Cozystack; with its help, the services obtain public addresses that are accessible from outside the cluster network.
Piraeus
DRBD is the fastest replication block storage running right in the Linux kernel. When DRBD only deals with data replication, time-tested technologies such as LVM or ZFS are used for securely store the data. The DRBD kernel module is included in the mainline Linux kernel and has been used to build fault-tolerant systems for over a decade.
DRBD is managed by LINSTOR privided by piraeus-operator. It provides an orchestation system integrated to Kubernetes which provides the management layer for creating virtual volumes based on DRBD.
Kubeapps
While the primary goal of the platform is to provide a beautiful API, it also has a dashboard for deploying applications, this dashboard is based on Kubeapps. It facilitates a quick dive into the platform and provides a visual demonstration of its capabilities.
The Web UI facilitates a quick dive into the platform and provides a visual demonstration of its capabilities.
CloudNativePG
Nowadays PostgreSQL is the most popular relational database. Its platform-side implementation involves a self-healing replicated cluster, managed with the increasingly popular CloudNativePG operator within the community.
Strimzi
Strimzi provides a way to run an Apache Kafka® cluster on Kubernetes or OpenShift in various deployment configurations. See our website for more details about the project.
Cloud Native Overlap
No response
Similar projects
VMware Tanzu
VMware Tanzu is a proprietary solution for creating Kubernetes clusters.
Our platform, however, is fully based on open-source and free technologies.
Additionally, to launch control planes, you don't need separate VMs, and we offer more services.
Rancher
Rancher can offer similar functionality but operates within its own ecosystem, offering a different value proposition.
While Rancher is more of a Kubernetes distribution, Cozystack is akin to a cloud platform.
Landscape
No, we just started :)
Business Product or Service to Project separation
Cozystack is a free project which is more likely a tool developed for our needs.
Ænix supervises the development and provides paid support. This paid support includes all types of assistance, including consultations, development of missing features, design, assistance with installation, and integration.
Project presentations
presentation: https://www.slideshare.net/slideshows/cozystack-free-paas-platform-and-framework-for-building-clouds/266662388
video: https://www.youtube.com/watch?v=24i9wIsJHGE
Project champions
Additional information
No response
The text was updated successfully, but these errors were encountered: