Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add sig-api charter #296

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

add sig-api charter #296

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions sig-api/charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# SIG API

Weekly meetings on Wednesdays at 13:00 UTC.
https://docs.google.com/document/d/1LCLt5k9x1yISZE_0SxGb5hcU3Q0pzDqRfIMEffgqlnk/edit?usp=sharing

## Scope
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While sig-compute will focus on the node level aspects, Sig-api will need to be responsible for the kubevirt control plane components and deployment such as virt-api, virt-conrtoller, and virt-operator.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I see it, the scope is not about a specific logic or features content, but on how to expose them for usage through the API in a safe and stable manner.

Could you be specific and point out which of the items listed here requires rephrasing, removing or which items are missing?

At the moment, I see that all of the items are described in a supportive manner. I mean, trying to provide means to write safe and stable APIs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let me second @EdDev .

IIUIC - and how I would support it - SIG API is exclusively about guarding our public APIs (everything in CRDs)., and not about their implementation.

It is to ensure that we have

  • good API patterns
  • avoid repeating API mistakes
  • achieve more consistency between APIs
  • ensure proper life-cycling of APIs (incl FGs).

Thus I am in favor of scoping SIG API in that way.

@vladikr so far I'm seeing the components that you had mentioned still to be in the domain of sig compute.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fabiand I don't think that sig-compute knows about this responsibility.
If you look at Sig API Machinery, the focus there is on everything that affects the control plane.

I see very little value and a risk for a bottleneck in a sig that is only responsible for writing APIs without the knowledge and responsibility of how these APIs affect the rest of the components.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladikr , this proposal is not related to api-machinery, it is related to the API governance subproject of sig-architecture.
It is actually a portion of that subproject, as it only focused on the API part.

I see very little value and a risk for a bottleneck in a sig that is only responsible for writing APIs without the knowledge and responsibility of how these APIs affect the rest of the components.

The SIG is not responsable to write APIs, it is responsible to provide guidance and protect the project API, keeping it safe in terms of comparability, dependability and consistency.

IMO the project reached a size that makes it hard for all maintainers/approvers to consider all API concerns and avoid conflict of interest with other concerns (functionality, code quality, delivery due time).

I would expect the SIG-API to evaluate an API change and seek/ask for several alternatives before it is being accepted.
This may be considered a bottleneck, although this charter is not hinting anything about enforcing at this stage. I think it makes sense to be very careful when introducing API changes at this stage, it should be much harder than before, with more discussions taking place.
I think we are not yet in a good position today, although awareness has increased.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me +1 about the scope

This sig is not implementing APIs, it's rather focused on establishing standards around it - as described below.

Implementing, and maintaining APIs is still up to the other SIG (whoever is providing it), and the machinery is currently owned by sig compute (IIUIC) - but this is separate from this proposed sig.

Btw - one takeaway could be @EdDev @alaypatel07 to call this sig sig-api-governance.

* Define and drive graceful, forward and backward compatible API changes in within KubeVirt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You do not want to "Define … API changes".

Can we reword this? Maybe you want to say that you want to support the community in doing "graceful, fwd and etc changes?"

* Develop and maintain an API change contribution guide
* Document and maintain best practices guide for API changes in KubeVirt
* Raise awareness about the importance of thinking through API changes
* Build tooling to for automated detection of compatibility breaks
* Provide inputs via PRR to all the api-facing changes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

define PRR



## Roles and Organization Management

This sig follows the Roles and Organization Management outlined in [OWNER_ALIASES](https://github.com/kubevirt/kubevirt/blob/main/OWNERS_ALIASES)
file.

SIG chairs:
* EdDev
* alaypatel07
22 changes: 22 additions & 0 deletions sigs.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,28 @@ sigs:
url: https://zoom.us/j/3205945033
archive_url: https://docs.google.com/document/d/1d_b2o05FfBG37VwlC2Z1ZArnT9-_AEJoQTe7iKaQZ6I/edit?usp=sharing
recordings_url: https://www.youtube.com/channel/UC2FH36TbZizw25pVT1P3C3g
- dir: sig-api
name: KubeVirt API SIG
mission_statement: |
Define and drive graceful, forward and backward compatible API changes in within KubeVirt
label: kubevirt-community
leadership:
chairs:
- github: EdDev
name: "Edward Haas"
company: Red Hat
- github: alaypatel07
name: "Alay Patel"
company: Nvidia
meetings:
- description: KubeVirt API Meeting
day: Wednesday
time: "13:00"
tz: UTC
frequency: weekly
url: https://zoom.us/j/94066461783
archive_url: https://docs.google.com/document/d/1LCLt5k9x1yISZE_0SxGb5hcU3Q0pzDqRfIMEffgqlnk/edit?usp=sharing
recordings_url: https://www.youtube.com/channel/UC2FH36TbZizw25pVT1P3C3g
contact:
slack: kubevirt-dev
mailing_list: https://groups.google.com/forum/#!forum/kubevirt-dev
Expand Down