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
Is your feature request related to a problem? Please describe.
When the DPA is configured to set velero arguments such as --log-level and --log-format=json it was expected that this would extend to node-agent daemonset and the pods belonging to the daemonset. It does not.
When the spec.configuration.velero.log-level or the fields in spec.configuration.velero.args is set the main velero deployment is updated. The node-agent daemonset, also running velero does not.
There are no fields on spec.configuration.nodeAgent to add these arguments. They are supported. We tried them by editing the node-agent deployment manually and successfully.
Describe the solution you'd like
The request is either that the field of spec.configuration.velero.log-level and spec.configuration.velero.args would also be mirrored to node-agent daemonset.
Alternative, add a similar log-level and args configuration object to the spec.confgiguration.nodeAgent specifically for the nodeAgent daemonset configuration.
Describe alternatives you've considered
If manually edited the daemonset and bringing down the replicas of the adp-operator to 0. This is quite awkward. Have to reset this every time we need a configuration change.
We've also considered editing the Velero code to do this already as a custom image.
Discussions in my organization has been unclear which is preferable, with applying existing Velero configuration fields to the node-agent would be preferred or a node-agent specific configuration.
I don't have a preference.
Additional context
The text was updated successfully, but these errors were encountered:
@msfrucht Thank you for creating this issue. The OADP engineering team is working on providing a solution to pass container arguments for velero/node-agent that the DPA does not have support for but velero does. Here is the on-going design: #1400
@shubham-pampattiwar Thank you, that will certainly work. Though I would prefer something more structured like spec.configuration.velero.args. But I understand this adds flexibility rather than having to update the CRD spec for each velero argument change.
+1 on this feature, we are also facing the same thing where we wanted more visibility on our nodeAgent pods, right now the suggested workaround still works temporarily
Is your feature request related to a problem? Please describe.
When the DPA is configured to set velero arguments such as --log-level and --log-format=json it was expected that this would extend to node-agent daemonset and the pods belonging to the daemonset. It does not.
When the spec.configuration.velero.log-level or the fields in spec.configuration.velero.args is set the main velero deployment is updated. The node-agent daemonset, also running velero does not.
There are no fields on spec.configuration.nodeAgent to add these arguments. They are supported. We tried them by editing the node-agent deployment manually and successfully.
Describe the solution you'd like
The request is either that the field of spec.configuration.velero.log-level and spec.configuration.velero.args would also be mirrored to node-agent daemonset.
Alternative, add a similar log-level and args configuration object to the spec.confgiguration.nodeAgent specifically for the nodeAgent daemonset configuration.
Describe alternatives you've considered
If manually edited the daemonset and bringing down the replicas of the adp-operator to 0. This is quite awkward. Have to reset this every time we need a configuration change.
We've also considered editing the Velero code to do this already as a custom image.
Discussions in my organization has been unclear which is preferable, with applying existing Velero configuration fields to the node-agent would be preferred or a node-agent specific configuration.
I don't have a preference.
Additional context
The text was updated successfully, but these errors were encountered: