
Key: |
QB-3767
|
Type: |
New Feature
|
Status: |
Resolved
|
Resolution: |
Fixed
|
Priority: |
Major
|
Assignee: |
Robin Shen
|
Reporter: |
J.R. Mash
|
Votes: |
0
|
Watchers: |
0
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 27/Jul/21 02:30 AM
Updated: 28/Feb/22 12:43 PM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
12.0.0
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
I have recently begun testing QuickBuild's Kubernetes and Cloud Profile features with our environment, but our use-case presents some challenges.
- imagePullPolicy: This defaults to 'IfNotPresent' and cannot be overridden, so using tags like '1.5' or 'latest' may not pull the latest associated image.
- imagePullSecrets: This cannot be specified.
- automountServiceAccountToken: This value cannot be specified.
- serviceAccountName: This value cannot be specified, which means only the 'default' service account for the namespace to be used.
I can envision other values that might be useful to specify (container environment variables and volumes, for instance), making it advantageous to allow users to specify a spec file to be used with the cloud profile. In lieu of that, perhaps a key->value type input control that allows for specific properties associated with the main classes (V1Container, V1PodSpec) may suffice.
I think our use case is a bit more complex than the average, so feel free to reach out if you have any questions or would like any more info on our situation.
|
Description
|
I have recently begun testing QuickBuild's Kubernetes and Cloud Profile features with our environment, but our use-case presents some challenges.
- imagePullPolicy: This defaults to 'IfNotPresent' and cannot be overridden, so using tags like '1.5' or 'latest' may not pull the latest associated image.
- imagePullSecrets: This cannot be specified.
- automountServiceAccountToken: This value cannot be specified.
- serviceAccountName: This value cannot be specified, which means only the 'default' service account for the namespace to be used.
I can envision other values that might be useful to specify (container environment variables and volumes, for instance), making it advantageous to allow users to specify a spec file to be used with the cloud profile. In lieu of that, perhaps a key->value type input control that allows for specific properties associated with the main classes (V1Container, V1PodSpec) may suffice.
I think our use case is a bit more complex than the average, so feel free to reach out if you have any questions or would like any more info on our situation. |
Show » |
There are no comments yet on this issue.
|
|