You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**What this PR does / why we need it**:
**Which issue(s) this PR fixes**:
Fixes #
**Special notes for your reviewer**:
**Release note**:
<!-- Write your release note:
1. Enter your release note in the below block.
2. If no release note is required, just write "NONE" within the block.
Format of block header: <category> <target_group>
Possible values:
- category: breaking|feature|bugfix|doc|other
- target_group: user|operator|developer|dependency
-->
```feature user
```
---------
Co-authored-by: Uwe Krueger <uwe.krueger@sap.com>
Copy file name to clipboardExpand all lines: README.md
+37-38Lines changed: 37 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,15 +8,15 @@ Its focus is to describe versioned sets of artifacts and to assign globally uniq
8
8
9
9
OCM provides a common language usable by tools to talk about software artifacts, regardless of the technologies and the processes working on them. Tool specific metadata, like deployment descriptions, are handled as own, typed artifacts. This enables the provisioning of content-agnostic tools: for example, transporting software between environments, signing and verification, providing compliance data, etc.
10
10
11
-
11
+
12
12
13
13
The following chapters provide a formal description of the format to describe software artifacts and a storage layer to persist those and make them available from remote.
* 2.6.1.[Blob Representation Format for Resource Types](doc/02-processing/04-digest.md#blob-representation-format-for-resource-types)
67
68
* 2.6.2.[Interaction of Local Blobs, Access Methods, Uploaders and Media Types](doc/02-processing/04-digest.md#interaction-of-local-blobs-access-methods-uploaders-and-media-types)
* 3.2.[Abstract Operations defined by the Open Component Model](doc/03-persistence/01-operations.md#abstract-operations-defined-by-the-open-component-model)
* 4.6.[Storage Backend (file-based): Common Transport Format (CTF)](doc/04-extensions/03-files.md#storage-backend-file-based-common-transport-format-ctf)
Copy file name to clipboardExpand all lines: doc/01-model/01-model.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -98,9 +98,11 @@ A formal specification must describe any repository that can be used to store co
98
98
99
99
Such a specification is usable by a language binding to gain access to this repository.
100
100
In a concrete environment all those repositories are usable, for which an
101
-
implementation of the [abstract model operations](../03-operations/README.md) exists.
101
+
implementation of the [abstract model operations](../03-persistence/01-operations.md) exists.
102
102
103
-
A repository specification has a type, the *Repository Type* used to identify the required [mapping](../04-persistence/01-mappings.md) and the information required to identity a concrete repository instance.
103
+
A repository specification has a type, the *Repository Type*
104
+
used to identify the required [mapping](../03-persistence/02-mappings.md)
105
+
and the information required to identity a concrete repository instance.
104
106
105
107
There are two kinds of types:
106
108
@@ -112,7 +114,7 @@ There are two kinds of types:
112
114
[A-Z][a-zA-Z0-9]*
113
115
```
114
116
115
-
The defined types with their meaning and format can be found in [a later chapter](../04-persistence/README.md)
117
+
The defined types with their meaning and format can be found in [a later chapter](../04-extensions/03-storage-backends/README.md)
Copy file name to clipboardExpand all lines: doc/01-model/02-elements-toplevel.md
+43-17Lines changed: 43 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,11 @@
1
1
2
2
# Model Elements
3
3
4
-
The following section describes how a component (version) is specified in more detail. Please note that this section intends to give an overview and explain the principal elements and their structure. It is not a complete specification. See the [schemas](https://github.com/open-component-model/ocm/tree/main/resources) for a full definition.
4
+
The following section describes how a component (version) is specified in more detail.
5
+
Please note that this section intends to give an overview and explain the principal
6
+
elements and their structure. It is not a complete specification.
7
+
See the [schemas](https://github.com/open-component-model/ocm/tree/main/resources)
8
+
for a full definition.
5
9
6
10
## Components and Component Versions
7
11
@@ -36,7 +40,8 @@ Those attributes are described by formal fields in the component descriptor:
36
40
37
41
-**`type`** (required) *string*
38
42
39
-
The type of an artifact specifies the logical interpretation of an artifact and is independent of its concrete technical representation.
43
+
The type of an artifact specifies the logical interpretation of an artifact
44
+
and is independent of its concrete technical representation.
40
45
41
46
-**`labels`** (optional) *[]Label*
42
47
@@ -47,11 +52,17 @@ Those attributes are described by formal fields in the component descriptor:
47
52
48
53
### Artifact Types
49
54
50
-
The formal type of an artifact uniquely specifies the logical interpretation of an artifact and its kind, independent of its concrete technical representation.
55
+
The formal type of an artifact uniquely specifies the logical interpretation of an artifact and its kind,
56
+
independent of its concrete technical representation.
51
57
52
-
If there are different possible technical representations, the access specification determines the concrete format given by a media type used for the returned blob.
58
+
If there are different possible technical representations,
59
+
the access specification determines the concrete format given by a media type used for the returned blob.
53
60
54
-
For example, a helm chart (type `helmChart`) can be represented as OCI artifact or helm chart archive. Nevertheless, the technical meaning is the same. In both cases the artifact (resource)`type` will be `helmChart`. The acess specification however will be different. In the first case it will refer to the helm-chart archive. In the second case the access type will be `ociArtifact`.
61
+
For example, a helm chart (type `helmChart`) can be represented as OCI artifact
62
+
or helm chart archive. Nevertheless, the technical meaning is the same.
63
+
In both cases the artifact (resource)`type` will be `helmChart`.
64
+
The acess specification however will be different. In the first case it will refer to the helm-chart archive.
65
+
In the second case the access method type will be `ociArtifact`.
55
66
56
67
```yaml
57
68
...
@@ -78,7 +89,7 @@ For example, a helm chart (type `helmChart`) can be represented as OCI artifact
The access type `ociArtifact` however is also used for container images:
92
+
The access method type `ociArtifact` however is also used for container images:
82
93
83
94
```yaml
84
95
...
@@ -92,15 +103,20 @@ resources:
92
103
imageReference: bitnami/mariadb:10.11.2
93
104
```
94
105
95
-
The resource type `ociImage` now describes an object that can be used as a container image. So, the technical representation in both cases will be an OCI image manifest. The semantics how these objects can be used are completely different. This is expressed by the `type` of the artifact.
106
+
The resource type `ociImage` now describes an object that can be used as a container image.
107
+
So, the technical representation in both cases will be an OCI image manifest.
108
+
The semantics how these objects can be used are completely different.
109
+
This is expressed by the `type` of the artifact.
96
110
97
-
An artifact's kind and logical interpretation is encoded into a simple string. The artifact type must be globally unique. OCM defines a naming scheme to guarantee this uniqueness.
111
+
An artifact's kind and logical interpretation is encoded into a simple string.
112
+
The artifact type must be globally unique. OCM defines a naming scheme to guarantee this uniqueness.
98
113
99
114
There are two kinds of types:
100
115
101
116
- Centrally defined type names managed by the OCM organization
102
117
103
-
These types use flat names following a camel case scheme with the first character in lower case, for example `ociArtifact`.
118
+
These types use flat names following a camel case scheme with the first character
119
+
in lower case, for example `ociArtifact`.
104
120
105
121
Their format is described by the following regular expression:
106
122
@@ -110,16 +126,26 @@ There are two kinds of types:
110
126
111
127
- Vendor specific types
112
128
113
-
Any organization may define dedicated types on their own. Nevertheless, the meaning of those types must be defined. There may be multiple such types provided by different organizations with the same meaning. Organizations should share and reuse such types instead of introducing new type names.
129
+
Any organization may define dedicated types on their own.
130
+
Nevertheless, the meaning of those types must be defined.
131
+
There may be multiple such types provided by different organizations with the same meaning.
132
+
Organizations should share and reuse such types instead of introducing new type names.
114
133
115
-
To support a unique namespace for those type names vendor specific types MUST follow a hierarchical naming scheme based on DNS domain names. Every type name has to be preceded by a DNS domain owned by the providing organization, like `landscaper.gardener.cloud/blueprint`. The local type must follow the above rules for centrally defined type names
116
-
and is appended, separated by a slash (`/`).
134
+
To support a unique namespace for those type names vendor specific types
135
+
MUST follow a hierarchical naming scheme based on DNS domain names.
136
+
Every type name has to be preceded by a DNS domain owned by the providing organization,
137
+
like `landscaper.gardener.cloud/blueprint`. The local type must follow the above rules
138
+
for centrally defined type names and is appended, separated by a slash (`/`).
117
139
118
140
So, the complete pattern looks as follows:
119
141
120
142
```
121
143
<DNSdomainname>/[a-z][a-zA-Z0-9]*
122
144
```
145
+
146
+
[Artifact Types](../01-model/07-extensions.md#artifact-types) are an extension point within the OCM model.
147
+
All existing artifact types are listed [here](../04-extensions/01-artifact-types/README.md).
148
+
123
149
## Sources
124
150
125
151
A *Source* is an artifact which describes the sources that were used to generate one or more of the resources. Source elements do not have specific additional formal attributes.
@@ -161,7 +187,7 @@ A resource uses the following additional formal fields:
161
187
Indicates whether the entity providing a component is also the provider of the resource ('local') or whether the
162
188
resource is provided by a separate entity ('external'). This may be useful to determine whether the entity responsible
163
189
for the component is also responsible for the resource.
164
-
This property is purely informational and completely unrelated to the access type.
190
+
This property is purely informational and completely unrelated to the access method type.
165
191
166
192
-**`digest`** (optional) *Digest Info*
167
193
@@ -198,13 +224,13 @@ Example:
198
224
type: ociArtefact
199
225
```
200
226
201
-
The full list of resource types is [here](03-extensible-values.md#resource-types).
227
+
The full list of resource types is [here](../04-extensions/01-artifact-types/README.md).
202
228
203
229
## References
204
230
205
231
A component version may refer to other component versions by adding a *reference* to the component version.
206
232
207
-
An *reference* does not habe a blob but it has:
233
+
A *reference* does not have a blob but it has:
208
234
209
235
- an *Identity* in the context of the component version
210
236
- a set of labels
@@ -246,6 +272,6 @@ Example:
246
272
```
247
273
248
274
249
-
# Model Summary
275
+
## Summary
250
276
251
-
The OCM model describes component versions. A component version is stored in a component repository and consists of sources, resources and references. The component version itself as well as each resource, source and reference has an identity. Only sources and resources have content and therefore an access specification and an optional digest. All elements can have labels.
277
+
The OCM model describes component versions. A component version is stored in a component repository and consists of sources, resources and references. The component version itself as well as each resource, source and reference has an identity. Only sources and resources have content and therefore an access specification and an optional digest. All elements can have labels.
0 commit comments