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
* Implement catalog switching proposal
- implements catalog switching proposal
See https://github.com/operator-framework/enhancements/blob/master/enhancements/automatic-catalog-switching-annotations.md
- picks up v0.10.3
- change sed command in copy_crds.sh to be posix compliant
The command + in sed is non-portable. The posix compliant version of
this command is {1,}
This change allows this script to run on a mac too (which uses BSD sed)
See https://riptutorial.com/sed/topic/9436/bsd-macos-sed-vs--gnu-sed-vs--the-posix-sed-specification
Note: GVK was implemented but disabled due to security concerns.
Future versions will address these concerns
Signed-off-by: John Hunkins <[email protected]>
* Address review comments from ecordell
- reorganize imports
- change logging common case to debug
Signed-off-by: John Hunkins <[email protected]>
* removed all watcher related code
- this is the commit that should be reviewed later
when it comes time to re-enable the GVK code
Signed-off-by: John Hunkins <[email protected]>
* update vendor to remove dynamic lister code
Signed-off-by: John Hunkins <[email protected]>
* fix incorrect names and improper error usage
- fix names that don't match Golang convention
- fix misspelled package name
- return nil for sync function casting
Signed-off-by: John Hunkins <[email protected]>
* change code block organization and add mutex
Signed-off-by: John Hunkins <[email protected]>
* remove all traces of GVK template feature
- clean up every instance of the GVK templating feature
- add last minute change for RWMutex instead of Mutex
- this is the second commit that should be reviewed later
when it comes time to re-enable the GVK code
Signed-off-by: John Hunkins <[email protected]>
* return status update errors and adjust logging
Signed-off-by: John Hunkins <[email protected]>
* address review comments
- update logging for clarity
- clean up code blocks
- refactor catalogsource helper functions:
- remove mutex
- remove two step get/update* in preference to update* even though
this may result in more "the object has been modified" errors
- rename helper functions to clarify usage
- clarify the update helper function docs
Signed-off-by: John Hunkins <[email protected]>
Copy file name to clipboardexpand all lines: deploy/chart/crds/0000_50_olm_00-catalogsources.crd.yaml
+47
Original file line number
Diff line number
Diff line change
@@ -106,6 +106,53 @@ spec:
106
106
status:
107
107
type: object
108
108
properties:
109
+
conditions:
110
+
description: Represents the state of a CatalogSource. Note that Message and Reason represent the original status information, which may be migrated to be conditions based in the future. Any new features introduced will use conditions.
111
+
type: array
112
+
items:
113
+
description: "Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: \"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"` \n // other fields }"
114
+
type: object
115
+
required:
116
+
- lastTransitionTime
117
+
- message
118
+
- reason
119
+
- status
120
+
- type
121
+
properties:
122
+
lastTransitionTime:
123
+
description: lastTransitionTime is the last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
124
+
type: string
125
+
format: date-time
126
+
message:
127
+
description: message is a human readable message indicating details about the transition. This may be an empty string.
128
+
type: string
129
+
maxLength: 32768
130
+
observedGeneration:
131
+
description: observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance.
132
+
type: integer
133
+
format: int64
134
+
minimum: 0
135
+
reason:
136
+
description: reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty.
137
+
type: string
138
+
maxLength: 1024
139
+
minLength: 1
140
+
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
141
+
status:
142
+
description: status of the condition, one of True, False, Unknown.
143
+
type: string
144
+
enum:
145
+
- "True"
146
+
- "False"
147
+
- Unknown
148
+
type:
149
+
description: type of condition in CamelCase or in foo.example.com/CamelCase. --- Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be useful (see .node.status.conditions), the ability to deconflict is important. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
0 commit comments