GithubHelp home page GithubHelp logo

community's Introduction

Community

Welcome to the KubeVirt Community repo! Here you will find all things community, including our membership policy, project governance, charters for our SIGs (Special Interest Groups), upcoming events, and more.

If you're looking for the main code base, you can find it at kubevirt/kubevirt.

And check out kubevirt/sig-release for all release-related information, such as our schedule, support matrix, or our roadmap

Get Started

Check out the KubeVirt user guide for all of our documentation, including architecture, getting started, managing virtual machines and your KubeVirt cluster, release notes, and debugging.

You can also find our contributor guide with resources for code and non-code contributions for beginners and those looking to contribute features and run a test cluster.

Socializing

If you've had enough of code and want to speak to people, then you have plenty of options:

community's People

Contributors

aburdenthehand avatar alicefr avatar alonakaplan avatar codificat avatar davidvossel avatar dhiller avatar eddev avatar fabiand avatar fgimenez avatar iholder101 avatar iranzo avatar jberkus avatar jean-edouard avatar jparrill avatar lyarwood avatar machadovilaca avatar maiqueb avatar mazzystr avatar mhenriks avatar nunnatsa avatar ormergi avatar phoracek avatar prnaraya avatar ptrnull avatar ramlavi avatar rmohr avatar rthallisey avatar scollier avatar stu-gott avatar suomiy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

community's Issues

Community member req

Mark DeNeve has reqs web statistics for his blog post.

He would also like a brief statement from the project to help with a promotion

Host kubevirt-test-vm repository in kubevirt org

Hi,

as discussed in the community meeting yesterday, I'm opening an issue here to discuss if we want to host the work I did in KubeVirt org.
The repository kubevirt-test-vm is a small golang program that helps the users to create test VMs and containers for running fio tests. The repository is self-contained, so it already has a containerdisk based on Fedora with all the needed tooling. The fio tests are containerized, and we deploy the same image directly in a container on the cluster or inside the VM.

I'd like to move the repository under KubeVirt org to have a better visibility and have the chance to use KubeVirt CI.

I have already raised the questions in kubevirt-devel and you can see there more details.

Consolidate community documentation to this repo

We have many repos with different versions of welcome, contributing, and style guides. I would like for all of the these pages to be moved this following hierarchy to follow suit with CNCF/Kubernetes ....

kubevirt/community:
  - contributors:
      - README.md: https://github.com/kubernetes/community/tree/master/contributors/devel/README.md
      - CONTRIBUTING.md
      - example_subproject: https://github.com/kubernetes/community/tree/master/contributors/devel/sig-api-machinery
          RELEASES.md
          STLYE_GUIDE.md
          etc       
      - guides: https://github.com/kubernetes/community/tree/master/contributors/guide
        - automation.md: https://github.com/kubernetes/community/blob/master/contributors/devel/automation.md
        - first_contribution.md: https://github.com/kubernetes/community/blob/master/contributors/guide/first-contribution.md
        - owners.md: https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md

The repo page gets a stub page (example: kubernetes/apimachinary/CONTRIBUTING.md )

A secondary object is to sync these pages to the user-guide appendix

Need community membership policy document

Per email to kubevirt-devel from [email protected]

Lately we've been thinking about the diversity of our project maintainers. It's easy to notice that a lot of emails come from one domain. When our project was in its infancy, that was understandable and sort of made sense. However, I'd like to think we've grown past that. We are starting to see more names on our community calls, and an ever growing number of followers on various platforms such as GitHub, Twitter or Slack. With that in mind, a topic I'd like to discuss during tomorrow's community meeting is the establishment of a documented process by which community members can get involved and become maintainers or co-owners of the KubeVirt project.

As a follow on to that, it's worth also discussing the different ways people interested in the project might be able to get involved. Some areas of responsibility might include:
 * Moderating a public GitHub issue scrub
 * Building the Community Meeting weekly agenda
 * Slack presence -- to answer questions of other community members
 * Leading or contributing towards our effort to get KubeVirt to V1
 
If you have any other ideas, please feel free to bring them up on this email thread or during the call!

Here's a draft proposal for what our maintainership procedures could look like:

https://docs.google.com/document/d/1sviYdFC5gXIRhc8M1nFOb1aDzyS-fmao9JjzSzdORTQ/edit#
https://docs.google.com/document/d/1N9SflndMOh9H7POvEMR__KWV--fi0e7OoTO76YcqAFs/edit

Review and update CONTRIBUTING guide

KubeVirt CONTRIBUTING guides are scattered and haven't been reviewed in quiet a while.

Let's do a deep review and side-by-side comparison to CNCF/Kubernetes's CONTRIBUTING document. Link is here.

Please follow their established hierarchy when organizing the pages.

Existing documents can be deprecated with community approval

  • check in with RH OSPO (project sponsor)
  • mention in community meeting
  • send email to dev mailing list
  • respond to comments
  • let bake for at least 30 days

KubeCon 2022 NA conference

KubeCon 2022 North America

CPF: link
Status: Submitted

Proposal to present KubeCon 2022 NA

Presenter: @marceloamaral
Presenter: @rthallisey

General Topic Idea Ryan and I want to present the journey in the SIG Scalability of how we analyzed and improved KubeVirt's performance at scale, including the testing tools we have developed.

Title

How KubeVirt Bootstrapped Our Own Performance Infrastructure

Description

Kubernetes has extensive performance and scale testing infrastructure, but how many other cloud native projects do? Performance testing is not widely adopted because of its infrastructure, metric definition, and tooling complexity. This often leads to bad experiences for users.
KubeVirt certainly didn't have anything when we launched the project, so we formed the Performance and Scale SIG and built our own. Today, that framework allows us to verify expected system behaviors under various load conditions and prevent unexpected regressions.
This talk will share our journey in KubeVirt through our performance testing framework, defining key metrics, creating performance tests, and deeply analyzing the results. We will discuss the challenges we face using Prometheus, and finally, we will conclude the talk with a guideline on how to bootstrap your own performance infrastructure for your project.

Migrate KubeVirt shared cal to the CNCF account

Currently the cal shared on the community page (link) is a cal owned by the Red Hat org. This is going to harm incubation due diligence and so it needs to be migrated to the correct account.

Events need to be migrated to the CNCF account
The CNCF account calendar needs to be made publically viewable
The kubevirt.io/community page needs to be updated to link to the correct cal

Move community repo contents to kubevirt.github.io website

Some contents in kubevirt this repository would get more visibility if stored in the 'community' section of the main website instead of this repo.

Some things that may require community visibility outside of regular website could be kept here, but others like:

  • Logos
  • Code of conduct
  • Material overview
  • Events

Could make better use and visibility on the website

KubeVirt Summit 2022

Planning

  • Decide format (in-person vs virtual)
    • Format will be virtual due to many reasons
  • Platform:
  • Send email to the mailing list
  • Discuss at Community Meeting
  • Finalize date
  • blah

Running

  • blah

KubeCon 2021 NA conference

Proposal to present KubeCon 2021 NA

CFP: link

Status: Submitted, waiting on review

Presenter @vladikr

General Topic Idea Declarative API to configure and assign v/GPUs to VMs with KubeVirt

Title: Declarative API to configure and assign v/GPUs to VMs with KubeVirt

Pay pobox

Pobox has invoiced on July 3. They're ready to be paid.

KVM Forum

Proposal to present KVM Forum

CFP: link

Status: Submitted, waiting on review

Presenter @vladikr

General Topic Idea Declarative API to configure and assign v/GPUs to VMs with KubeVirt

Title: Declarative API to configure and assign v/GPUs to VMs with KubeVirt

designs: PV Storage for VMs -

PR #5 is concerned about adding PV based disk to VMs.

There are two issues:

  1. libvirtd and qemu both need access to the volume (and contained file) in the same path.
  2. The file needs to be initialized

The problem with 1 is that libvirtd and qemu expect the same path in their namespace. But their mount namespace is different than the pods mount namespace.
A possible solution is to expose the pod informations in the virt-handler to allow it to share enough informations about it to allow libvirt/qemu to use the attached volumes.

  1. is actually implicitly solved if 1. is getting fixed. The reasons that libvirtd needs access to the referenced disk file is that it does a few checks, and creates the file if necessary.

Create policy for field deprecation

[@kwiesmueller ] Discuss featureGates (and deprecation)
Create issue for deprecation policy
13 listed in featuregates.go… not all may be used

Please create policy in this repo. We can then link to it.

Linux Foundation / KubeCon / CloudNativeCon EU

Epic Goal

  • Linux Foundation / KubeCon / CloudNativeCon EU is offering an Office Hours feature to KubeCon/CloudNativeCon on May 4-7,2021. Project Kubevirt should run office hours sessions.

Why is this important?

  • It's important for KubeVirt to have a presence at Kubernetes and cloud oriented cons.

Scenarios

  • Kubevirt should have a canned demo by this time. It should not be any extra back end work to gather material. Team will just run the Office Hours booth.

Checklist

  • Survey
  • Prepare material
  • Practise
  • Run office hours

Adjust main branch to use respectful language

/kind enhancement

What happened:
Current standard of this repos main branch name master is not respectful to some contributors and/or users of KubeVirt

What you expected to happen:
Please adjust the main branch name to main.

Anything else we need to know?:

  • Repo admin privledges will be necessary. Please coordinate with @mazzystr
  • Ensure repo config enforcement in CI/Prow is adjusted

Achieve gold medal with Linux Foundation CII Best Practices Program

Project page: https://bestpractices.coreinfrastructure.org/en/projects/2805

The Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify, at no cost, by using this web application to explain how they follow each best practice. The CII Best Practices Badge is inspired by the many badges available to projects on GitHub. Consumers of the badge can quickly assess which FLOSS projects are following best practices and as a result are more likely to produce higher-quality secure software.

More details at ... https://bestpractices.coreinfrastructure.org/en

KubeVirt has stagnated on it's trek toward a gold medal. Let's get things moving again.

All Things Open conference

All Things Open 2021

ATO Call for Papers - link
ATO Talk Topics - link
TIPS for getting proposal accepted - https://opensource.com/article/20/5/tips-conference-proposals

Proposal to present at ATO2021

Organizer: @mazzystr
Presenter: @stu-gott

Use Raspberry Pi 4 hardware to build Kubernetes / Rancher K3S multinode cluster with KubeVirt layered on. Apply mixed workloads to the cluster.

Demonstrate running mixed workloads.

Set up

Hardware

ARM64 - 4 core / 8 GiB mem

Intel

Storage

  • SSD / NVME
  • SATA

Networking

  • 1 gig-e internet is preferred....broadband ok
  • Wireguard mesh
  • Flannel sdn

Software

Kubernetes

Application workload

Meeting information

Topic: All Things Open 2021
Time: Apr 29, 2021 07:00 Pacific Time (US and Canada)

Join Zoom Meeting
https://zoom.us/j/3205945033

Publish video to YouTube channel

Federico Gimenez provided a video describing KubeVirt CI infrastructure. Please upload to KubeVirt YouTube channel

Title: KubeVirt CI Infrastrcture Overview

Description: Brief overview of the infrastructure we use to run KubeVirt CI jobs, how it has changed over the last few months and the short/medium term improvements we are working on. Includes a small demo about our usage of Bazel gitops rules to manage components on CI/CD pipelines

Community manager needed

It is with both sadness and excitement that I have to inform the community that I have resigned my position with IBM/Red Hat and with that my position as KubeVirt community organizer. My last day with IBM/Red Hat will be Nov 29. I have accepted a position at NASA Goddard Space Agency to assist in building and maintaining climate research supercomputers.

This is a great opportunity to get involved with the project. I thought the position was fun. I got to do some coding and got to do a lot of talking to people both publicly and through back channels. See pull/154 for a list of responsibilities. It is unclear if Red Hat is going to fund another position.

KubeCon 2021 NA conference

KubeCon 2021 North America

CFP: link

Status: Submitted, waiting on review

Proposal to present KubeCon 2021 NA

Presenter: @rthallisey
Presenter: @davidvossel

General Topic Idea Ryan and I want to present the journey of how we measured and improved KubeVirt's performance at scale. This will include details into how we approached scale testing along with how we profiled the distributed system to evaluate and improve performance.

Title: 1000s of VMs and beyond: KubeVirt performance and scale

Abstract:

Our goal is to scale KubeVirt to new levels and measure its performance and efficiency; here’s our journey to 1000s of VMs:

In this session we will uncover the tools and methodologies we used to visualize, measure, and identify KubeVirt performance bottlenecks and improve them. We'll outline how we collected baseline performance metrics under load and how changing certain code paths impacted baseline performance. From our learnings, we hope you’ll come away with an understanding of what patterns can help improve performance in your own Kubernetes controllers as well as an understanding of how to approach profiling a distributed control plane.

Community survey

The KubeVirt community would like to create a survey for users to get a better gauge on various aspects of the project.

Develop survey here

Promote KubeVirt to a CNCF incubating project

/kind enhancement

Per Josh Berckus in Red Hat OSPO (Open Source Program Office) it is time to begin the process to get project KubeVirt promoted to an incubating project under the CNCF.

CNCF Technical Oversight Committee (TOC) Due Diligence doc is here

Where to start

  • make sure you're clear on the TOC Principles, the project proposal process, the graduation criteria and desired cloud native properties are. The project sponsor (a member of the TOC) should have assisted in crafting the proposal to explain why it's a good fit for the CNCF. If anything's unclear to you, reach out to the project sponsor or, failing that, the TOC mailing list for advice.
  • make sure you've read, in detail, the relevant project proposal, This will usually be in the form of an open pull request. Consider holding off on commenting on the PR until you've completed the next three steps.
  • take a look at some previous submissions (both successful and unsuccessful) to help calibrate your expectations.
  • Verify that all of the basic project proposal requirements have been provided.
  • do as much reading up as you need to (and consult with experts in the specific field) in order to familiarize yourself with the technology landscape in the immediate vicinity of the project (and don't only use the proposal and that project's documentation as a guide in this regard).
  • at this point you should have a very clear technical idea of what exactly the project actually does and does not do, roughly how it compares with and differs from similar projects in it's technology area, and/or a set of unanswered questions in those regards.
  • go through the graduation criteria and for each item, decide for yourself whether or not you have enough info to make a strong, informed call on that item.
    ** If so, write it down, with motivation.
    ** If not, jot down what information you feel you're missing.
    ** Also take note of what unanswered questions the community might have posted in the PR review that you consider to be critically important.

Some example questions that will ideally need clear answers

Most of these should be covered in the project proposal document. The due diligence exercise involves validating any claims made there, verifying adequate coverage of the topics, and possibly summarizing the detail where necessary.
Technical

  • An architectural, design and feature overview should be available. (example, example)
  • What are the primary target cloud-native use cases?
  • Which of those:
    ** Can be accomplished now.
    ** Can be accomplished with reasonable additional effort (and are ideally already on the project roadmap).
    ** Are in-scope but beyond the current roadmap.
    ** Are out of scope.
  • What are the current performance, scalability and resource consumption bounds of the software? Have these been explicitly tested? Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)?
  • What exactly are the failure modes? Are they well understood? Have they been tested? Do they form part of continuous integration testing? Are they appropriate given the intended usage (e.g. cluster-wide shared services need to fail gracefully etc)?
  • What trade-offs have been made regarding performance, scalability, complexity, reliability, security etc? Are these trade-offs explicit or implicit? Why? Are they appropriate given the intended usage? Are they user-tunable?
  • What are the most important holes? No High-Availability? No flow control? Inadequate integration points?
  • Code quality. Does it look good, bad or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form. Are there explicit coding guidelines for the project?
  • Dependencies. What external dependencies exist, do they seem justified?
  • What is the release model? Versioning scheme? Evidence of stability or otherwise of past stable released versions?
  • What is the CI/CD status? Do explicit code coverage metrics exist? If not, what is the subjective adequacy of automated testing? Do different levels of tests exist (e.g. unit, integration, interface, end-to-end), or is there only partial coverage in this regard? Why?
  • What licensing restrictions apply? Again, CNCF staff will handle the full legal due diligence.
  • What are the recommended operational models? Specifically, how is it operated in a cloud-native environment, such as on Kubernetes?

Project

The key high-level questions that the voting TOC members will be looking to have answered are (from the graduation criteria):

  • Do we believe this is a growing, thriving project with committed contributors?
  • Is it aligned with CNCF's values and mission?
  • Do we believe it could eventually meet the graduation criteria?
  • Should it start at the sandbox level or incubation level?

Some details that might inform the above include:

  • Does the project have a sound, documented process for source control, issue tracking, release management etc.
  • Does it have a documented process for adding committers?
  • Does it have a documented governance model of any kind?
  • Does it have committers from multiple organizations?
  • Does it have a code of conduct?
  • Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of it's dependencies compatible with their usage and CNCF policies? CNCF staff will handle the full legal due diligence.
  • What is the general quality of informal communication around the project (slack, github issues, PR reviews, technical blog posts, etc)?
  • How much time does the core team commit to the project?
  • How big is the team? Who funds them? Why? How much? For how long?
  • Who are the clear leaders? Are there any areas lacking clear leadership? Testing? Release? Documentation? These roles sometimes go unfilled.
    What is the rate of ongoing contributions to the project (typically in the form of merged commits).

Users / See #110

  • Who uses the project? Get a few in-depth references from 2-4 of them who actually know and understand it.
  • What do real users consider to be it's strengths and weaknesses? Any concrete examples of these?
  • Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed?

Contributor experience

Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc.

  • Is it easy to contribute to the project as an external contributor? If not, what are the main obstacles?
  • Are there any especially difficult personalities to deal with? How is this done? Is it a problem?
  • Getting interviews with 2-3 external contributors is advisable for DD process, both from the community and technical perspective. It can help to identify technical depth in areas like extensibility, API design and general code architecture.
  • For more in-depth review of the contributor experience, consulting with sig-contributor-strategy is always a good idea.

Context

  • What is the origin and history of the project?
  • Where does it fit in the market and technical ecosystem?
  • Is it growing or shrinking in that space? Is that space growing or shrinking?
  • How necessary is it? What do people who don't use this project do? Why exactly is that not adequate, and in what situations?
  • Clearly compare and contrast with peers in this space. A summary matrix often helps. Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others. Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner. Be suspicious if there appears to be one.

Other advice

  • Bring in other people (e.g. from your company) who might be more familiar with a particular area than you are, to assist where needed. Even if you know the area, additional perspectives from experts are usually valuable.
  • Conduct as much of the investigation in public as is practical. For example, favor explicit comments on the submission PR over private emails, phone calls etc. By all means conduct whatever communication might be necessary to do a thorough job, but always try to summarize these discussions in the PR so that others can follow along.
  • Explicitly disclose any vested interest or potential conflict of interest that you, the project sponsor, the project champion, or any of the reviewers have in the project. If this creates any significant concerns regarding impartiality, its usually best for those parties to recuse themselves from the submission and it's evaluation.
  • Fact-check where necessary. If an answer you get to a question doesn't smell right, check the underlying data, or get a second/third... opinion.

Bug manager needed

Bug scrub is starting to take 15-30 mins out of community calls. It is time to split out to a separate call with a person in charge of bug management.

Reqs for this should be easy

  • Add bug manager to org file
  • Run bug scrub meeting. See the last 30 mins of any video on the YouTube channel.
  • Send bug report periodically to the mailing list.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.