When using the

flyte-binary

helm chart is there a way to specify which project's you'd like automatically defined? I'm looking for something like

initialProjects

from the

flyte-core

helm chart

cc @Yee /@jeev

hmm perhaps this could be simply read from configuration? https://github.com/flyteorg/flyte/blob/507a466077883bd2c34677c928ac277be7be9c28/cmd/single/start.go#L68

it wasn’t ported because i think it was an extra init container in the other chart, and we just wanted to avoid that.

maybe we can just make it a config?

we can i suppose.

true

not against it, just a bit concerned about config bloat

This config? https://docs.flyte.org/en/latest/deployment/configuration/generated/flyteadmin_config.html

helm config

got it 👍🏼

flyte admin config is more easily managed i feel

From my perspective, being able to update our helm values.yaml and pass values into the admin_config has been quite nice.

right

like the cfg.Admin block here

yeah right?

that’s what i was thinking too. then some plumbing from helm values into the configmap?

yeah

@Mike Ossareh up to you

I'm happy to take a look at it. It gives me a good reason to better familiarize myself with your configmap.

awesome

is flytestdlib/config just a light wrapper over pflag?

yeah

If I create an issue to track this; can one of you assign it to me?

yup

👍🏼

thank you

@jeev & @Yee I (finally!!) got around to implementing this. https://github.com/flyteorg/flyte/pull/3631 I'm not sure where is best to document this change; I'm happy to do so, but I'll need a pointer to where best to put those docs.

oh nice thanks.

@Mike Ossareh looks like the PR is close and just needs some final touches :)

hey @jeev 👋🏼

@Mike Ossareh: still seeing the version changes, but that probably needs

make helm

as far as the helm chart key goes: do we even need it? or can we just expose directly under the

configuration

key? im not super opinionated on this. will defer to you and @Yee. everything else lgtm! thanks for the valuable contribution!

@jeev good spot with the `make helm`; I forgot that. I’ve run it and the version changes have bumped. re: the configuration key. You’re suggesting: •

configuration.admin

•

configuration.propeller

•

configuration.dataCatalog

instead of

configuration.flyte-binary.[admin,propeller,dataCatalog]

. I’m fine with this personally; it’s sort of the same thing from my POV 🙂 so I’m happy to do whatever you and @Yee suggest I do.

no strong opinions from me. i was suggesting that because all of configuration is technically already for

flyte-binary

@jeev / @Yee here’s a diff that demonstrates the suggestion above: https://github.com/ossareh/flyte/pull/1/files some things to consider: 1.

000-core.yaml

already has a top level

admin

entry 2. the args for

flyte-binary

are in a

Section

called

flyte

a. we either change

cmd/single/config.go

to use a different section name b. or we accept that 000-core.yaml cannot have a top level

admin

key and we put the flyte-binary args under

flyte:

in the ConfgMap. If the diff above is acceptable, I’ll cherry pick the commit onto the existing PR in the flyte repo - the PR above is just for demonstration purposes.

i like that last one.

yea feel free!

OK; I'll migrate the commit over to the main PR branch and then ping y'all here when it's pushed.