Add os_purpose field. #970
Conversation
Also add a link to OpenStack specs for os_distro and explain why we need it. This is patch 1 from several. It adds this os_purpose field as *recommended*. As it does not break certification, this can be done in the existing v1 of the scs-0102 standard. I suggest we discuss this one first until we are aligned. In parallel, I'd like to prepare a blog article that serves as user guide how to select images in a portable way without relying on the name. We can reference it in tne implementation notes. We should also enhance the image-manager input to carry this field soon. In a future patch, we create a v2 of scs-0102 which *requires* the os_purpose field. The naming in scs-0102 is already a recommendation only, so that can remain. scs-0104 will need a new version then, as it does use the recommended names as mandatory for the mandatory images. Signed-off-by: Kurt Garloff <[email protected]>
garloff
added
the
work in progress
garloff
added
the
standards
Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Kurt Garloff <[email protected]>
From today's SIG Std/Cert: Only the tuple (os_distro, os_version, architecture) should be unique for os_purpose=generic. Signed-off-by: Kurt Garloff <[email protected]>
As per today's SIG Std/Cert discussion, these terms may be too generic to be useful. So let's instruct providers to use `custom` for now and hope they will talk to use to request new purposes. Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Kurt Garloff <[email protected]>
| The following values are allowed | ||
|
|
||
| | `os_purpose` value | Intention | | ||
| |--------------------|-----------------------------------------------------------| | ||
| | `generic` | A general purpose image, (mostly) vanilla from upstream | | ||
| | `minimal` | A much more barebones general purpose image | | ||
| | `capinode` | Node image built for cluster-API | | ||
| | `gpu` | Image with GPU drivers e.g. for HPC or AI | | ||
| | `custom` | None of the above | | ||
|
|
||
| Note that no other values are currently allowed and `custom` should be used in case | ||
| of doubt. Talk to the SCS standardization bodies if you'd like to see this list extended which is | ||
| likely the case if you fall back to `custom`. | ||
|
|
||
| The usage of standardized `os_distro`, `os_version`, `architecture`, and `os_purpose` help cloud users to create | ||
| automation that works across clouds without requiring image names to be standardized. Only | ||
| one visible public image with `os_purpose` = `generic` and the same settings for `os_distro`, | ||
| `os_version` and `architecture` should be active on any given cloud. | ||
| The link to the OpenStack specs and the recommended `os_purpose` was added to version 1.1 of | ||
| this standard; a new version 2 of the standard that requires `os_purpose` will be created later. |
There was a problem hiding this comment.
It might make sense to indent this, so that it belongs to the os_purpose itemization item.
Signed-off-by: Kurt Garloff <[email protected]>
| automation that works across clouds without requiring image names to be standardized. Only | ||
| one visible public image with `os_purpose` = `generic` and the same settings for `os_distro`, | ||
| `os_version` and `architecture` should be active on any given cloud. |
There was a problem hiding this comment.
Comprehension question: what is meant by "be active" in this context? The text already speaks of visible public image, so I would presume it either exists or it doesn't?
There was a problem hiding this comment.
Feel free to word this "should exist" if you find "should be active" confusing. For me it's the same.
(There are several ways to make an image inactive. Setting os_hidden='True'. Marking it as visibility=community. We don't prescribe any of these. As both basically affect visibility, the idea of deactivation and removing from visibility possibly being different is currently not true -- I would not exclude the possibility of a future mechanism to deactivate in ways that may not be well characterized by "hiding", although I don't expect it. I felt that the wording as chosen is a safe choice. But it has confused you, so it wasn't.)
There was a problem hiding this comment.
I suppose when I set os_hidden=True then it's no longer visible, and when I set visibility=community then it's no longer public, so the word 'active' to me suggested that there would be a third way, but I didn't know what this might be. I'm afraid I'm a reviewer who is quite easily confused ;)
| The link to the OpenStack specs and the recommended `os_purpose` was added to version 1.1 of | ||
| this standard; a new version 2 of the standard that requires `os_purpose` will be created later. |
There was a problem hiding this comment.
I would not repeat the version history here, but I would warn people that we intend to turn the recommendation into a requirement soon.
| The link to the OpenStack specs and the recommended `os_purpose` was added to version 1.1 of | |
| this standard; a new version 2 of the standard that requires `os_purpose` will be created later. | |
| Note: Expect this field to become mandatory in v2 of this standard sooner rather than later. |
There was a problem hiding this comment.
In your suggested wording, the words "this field" lack context.
My understanding of creating a minor revision was that we make the changes within the minor revision visible to non git-pros, thus my mini-changelog. Idea being that a reader can understand why her cloud suddenly gets a warning from the compliance checks without reading git history on the standard or the tool nor even being aware that we do minor revisions if they are non-breaking ...
My vote is for keeping a mini-changelog, but I have no strong opinion here.
There was a problem hiding this comment.
The context is that this whole part is indented below the bullet point for precisely the field in question, no?
| @@ -244,4 +278,13 @@ A boolean property that is not present is considered to be `false`. | |||
|
|
|||
| The script `image-md-check.py` retrieves the | |||
| image list from a configured cloud and checks each image for the | |||
| completeness and consistency of mandatory properties. | |||
| completeness and consistency of mandatory properties. See the | |||
| [Corresponding Implemetation and Testing Notes](https://docs.scs.community/standards/scs-0102-w1-image-metadata-implementation-testing) | |||
There was a problem hiding this comment.
I'm actually wondering whether the whole section (Conformance Tests) should be removed...
There was a problem hiding this comment.
(or at least its entire contents replaced by a link to the notes)
There was a problem hiding this comment.
This section predates the existence of the Implementation and Testing notes.
I did a minimal change by adding the pointer.
But probably after double-checking that we don't lose any valuable information, we can better drop the whole section, agreed.
Co-authored-by: Matthias Büchse <[email protected]> Signed-off-by: Kurt Garloff <[email protected]>
Signed-off-by: Marvin Frommhold <[email protected]>
Also add a link to OpenStack specs for os_distro and explain why we need it.
This is patch 1 from several. It adds this os_purpose field as recommended. As it does not break certification, this can be done in the existing v1 of the scs-0102 standard. I suggest we discuss this one first until we are aligned. In parallel, I'd like to prepare a blog article that serves as user guide how to select images in a portable way without relying on the name. We can reference it in the implementation notes. We should also enhance the image-manager input to carry this field soon and create test cases.
In a future patch, we create a v2 of scs-0102 which requires the os_purpose field. The naming in scs-0102 is already a recommendation only, so that can remain. scs-0104 will need a new version then, as it does use the recommended names as mandatory for the mandatory images.