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
The image-builder binary is used on a client and producer side. For both usage scenarios the tool uses the same configuration file. The producer usage scenario will happen in ado only. The configuration relevant for producer scenario should be maintained together with oci-image-builder.
The configuration relevant for client scenario should be maintained in a location globally accessible.
The client must get the current config on each run from this global location.
The client must have possibility to accept values as flags to override central config and use values from flags for test purpose.
The configuration used by client must be stored in a system which doesn't block requests from client due to hard rate limits.
Preferred storage for a configuration is artifact registry storing other types of artifacts. The artifact registry is already accepted public storage for artifacts produced by kyma teams. Alternativelly a GCP bucket storage can be used if artifact registry is not usable for our scenario.
Reason
The image-builder client will be used in multiple locations where some usage will run image-builder container directly. We need to prepare for such scenario where we will not control steps for providing proper config for the image-builder client.
The text was updated successfully, but these errors were encountered:
Description
The image-builder binary is used on a client and producer side. For both usage scenarios the tool uses the same configuration file. The producer usage scenario will happen in ado only. The configuration relevant for producer scenario should be maintained together with oci-image-builder.
The configuration relevant for client scenario should be maintained in a location globally accessible.
The client must get the current config on each run from this global location.
The client must have possibility to accept values as flags to override central config and use values from flags for test purpose.
The configuration used by client must be stored in a system which doesn't block requests from client due to hard rate limits.
Preferred storage for a configuration is artifact registry storing other types of artifacts. The artifact registry is already accepted public storage for artifacts produced by kyma teams. Alternativelly a GCP bucket storage can be used if artifact registry is not usable for our scenario.
Reason
The image-builder client will be used in multiple locations where some usage will run image-builder container directly. We need to prepare for such scenario where we will not control steps for providing proper config for the image-builder client.
The text was updated successfully, but these errors were encountered: