Skip to content
Open
Changes from all commits
Commits
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
66 changes: 66 additions & 0 deletions sig-standardization/20251002.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
## 2025-10-02

### Participants

<!-- GitHub handles preferred -->
- @depressiveRobot
- @garloff
- @matfechner

### Pending action items

- _AI @mbuechse_: implement decisions from 2025-09-18 regarding communication of relaxed requirements
- _AI @garloff_: blog article about `os_purpose` scs-0102 and reference in implementation notes

### SCS-0007 Integrator exceptions

sponsor: @depressiveRobot

- worries
- too many requests for exceptions may undermine the quality perception of integrator certification
- some Gestalters had problems to vote due to assessment of references or don’t know requesting organization
- no clear criteria how to rate exception references (hard checkable facts)
- opinions
- standards vs. flexibility
- customers expect standards to be fulfilled
- flexibility to allow (new) companies to qualify and be able to acquire customers requesting SCS compatibility (chicken-egg problem)
- fact-checked reasoning
- exceptions should be based on hard checkable facts
- exceptions should be time-limited
- supplement already states, that exceptions should be eliminated until re-certification
- prevent exceptions from becoming a risk to trust
- many suggestions on lowering initial requirements
- alternative entry level certificate like "Incubator" or "Bronze" status
- defined process with strict criteria to ensure quality and transparency
- roadmap on how exceptions will be eliminated
- counteract potential social pressure
- proposal
- make requirements more generic for the first year
- allow companies with relevant experience (like OpenStack) to qualify while they work towards full SCS compliance
- inputs of this meeting
- integrators should always work towards building SCS-compatible clouds
- entry level certification only once
- allow companies that don't want to offer an own public cloud (criteria c) to get certification
- how do we want to handle joint references? (e.g. two or more companies have jointly set up SCS clouds or manage them together)

### Add larger memory flavors

sponsor: @mbuechse

- PR [standards#938](https://github.com/SovereignCloudStack/standards/pull/938) now ready for review
- Q: do we need that many flavors, or can we drop those with root disk?
- suggestion to drop those with root disk
- recommend meaningful and uniform disk sizes as explanation in the standard
- AI: @garloff will create a proposal/draft

### Create v2 of scs-0102-image-metadata

sponsor: @mbuechse

- draft PR [standards#988](https://github.com/SovereignCloudStack/standards/pull/988)
- makes `os_purpose` mandatory
- removes naming convention
- while we're at it, what else do we want to change?
- open question how fast we want to make this mandatory
- maybe tie such things in the future to SCS releases
- _AI @depressiveRobot_ will ask all providers whether a prompt activation of the new requirements is feasible for them in short term in order to stay compliant