Oded Messer

@efiop @skshetry - is anyone looking at this? Looks like a small fix, needed to put order in telemetry across products, but no real response here for a long time...

@efiop unifying telemetry into a package reusable by other products seems great ... 😄 BUT Currently DVC uses internal logic - Why would this functional change be blocked by someone...

@skshetry To your concerns about transparency and user trust - we should make https://github.com/iterative/iterative-telemetry public (see: https://github.com/iterative/iterative-telemetry/issues/30), I don't think that it warrants the duplication personally Today this package doesn't...

@ www.iguazio.com we ended up creating helm charts for mpi-operator ourselves, which is not ideal 😄

Once we get some mileage on our mpi operator chart we'll go ahead and submit to helm incubator

@terrytangyuan - Sorry for the delay, have a look: https://github.com/kubeflow/mpi-operator/pull/167 We're still using mpioperator 0.2.0 so that's battle tested. I'll do a sanity with installing a newer version as well...

@0x2b3bfa0 @DavidGOrtega Why not have both in a consistent, explicit manner - 2 separate fields: `startup_script` and `startup_script_base64` . If both fields are non-`""` it will fail (no guessing!)

Yeah (obviously 😬 ) but not sure I follow what are you suggesting wrt the choice of whether to expect file contents encoded or not (meaning: from the user). b64...

@0x2b3bfa0 - due to [this](https://github.com/iterative/terraform-provider-iterative/issues/91#issuecomment-886892321) I suggest to think whether it's beneficial to drop the b64 encoded field support. Hence the suggestion to have both co-exist. I can think of...

With the risk of repeating the point a bit 😄 Agreed the `bas64decode` function exists and things can be decoded in various places and achieved either way. The point I'm...