Skip to content

Specify what presence of an image means - #1260

Merged
mbuechse merged 1 commit into
mainfrom
issue/1259a
Aug 31, 2026
Merged

mbuechse merged 1 commit into
mainfrom
issue/1259a

Conversation

@mbuechse

Copy link
Copy Markdown
Contributor

No description provided.

@mbuechse

Copy link
Copy Markdown
Contributor Author

Note: This has to be debated in SIG Std/Cert, particularly the case of visibility=community.
I presume @berendt will want this, but I'm not sure this finds consensus.

@toothstone

Copy link
Copy Markdown
Contributor

@mbuechse Could you please elaborate/confirm that this change only aligns the canonical texts with the existing compliance checks. Since I see no diff in Tests I assume so, but I think it would be good to have it explicitly spelled out.

@berendt

berendt commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Visibility of community < public. Fine for me the add this. I don't like the public visibility and prefer community over public.

@mbuechse

Copy link
Copy Markdown
Contributor Author

@toothstone I can confirm that:

c.add_function('images', lambda c: [img for img in c.conn.list_images(show_all=True) if img.visibility in ('public', 'community')])

However, in my mind, it's more important that the standard makes sense. This is v2, which is still a draft, so we can and should discuss in the SIG what makes most sense.

@depressiveRobot

Copy link
Copy Markdown
Contributor

Is something else to do here based on the discussion in the SIG on 2026-08-06 or can this be merged?

@garloff garloff left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

From my perspective, this is good to go.

  • Operators can provide images as public (preferrable) or as community images.
  • Only those are considered by the standard.
  • This means that creating a customer-specific image (private) or one that is shared from one customer to another are neither subject to these rules nor can they be used to fulfill the mandatory list ...

There is a separate discussion on filtering out snapshots.

@toothstone toothstone left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Aligns the text with the de-facto tests, so I'm very glad to see this happen!

Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
@mbuechse
mbuechse merged commit 3975eb1 into main Aug 31, 2026
8 checks passed
@mbuechse
mbuechse deleted the issue/1259a branch August 31, 2026 07:56
@toothstone

Copy link
Copy Markdown
Contributor

As a follow up @mbuechse , don't we need a similar clarification on SCS-0102? I just managed to fail the compliance check due to a user-supplied image with "community" visibility, which of course lacks some mandatory metadata. The (non-binding) "motivation" section implies that SCS-0102 is intended to only apply to CSP-provided images, but the tech specs don't explain how those are recognized - the test code does img.visibility in ('public', 'community').

@mbuechse

Copy link
Copy Markdown
Contributor Author

@toothstone Interesting question. The compliance tests would usually be run on a more-or-less 'pristine' project, so not 'tainted' by such things as user-supplied images. However, we should still answer the question whether it's acceptable that users can so easily interfere with these guarantees -- not necessarily breaking any automation, but who knows?

@toothstone

Copy link
Copy Markdown
Contributor

I think as a first step it would be good to clarify in SCS-0102 that "provided" images are defined as having img.visibility in ('public', 'community'), and maybe add some note to the implementation supplement that this is known to cause false negatives for user-provided community images.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants