wave Hello I recently submitted a draft PR for `stow` that Flyte #flyte-deployment

:wave: Hello! I recently submitted a draft PR for ...

Terence Kent

09/19/2023, 2:06 PM

👋 Hello! I recently submitted a draft PR for

stow

that adds Azure AD support (flyteorg/stow/pull/9, related convo here). Part of the effort in shoring up that PR is testing the

stow

branch in a Flyte deployment. The changes are tested within the

stow

project, but being able to try it all together would be a nice early check. Is that something somebody here is interesting is trying out? Or, should I just follow the development guide.

David Espejo (he/him)

09/19/2023, 2:33 PM

That'd be neat for sure. I know @Gopal Vashishtha has some experience with it and other folks here are running on Azure Thanks @Terence Kent!

Terence Kent

09/19/2023, 4:32 PM

@David Espejo (he/him) - Cool! I should clarify though. My main interest in testing at this stage is really about using a custom a build of flyte that uses the

flyteorg/stow

branch I've setup. Even deploying that locally (not in Azure) and having it interact with azure storage accounts would be useful. If you (or anyone else) has an interest in doing that loop, I'd appreciate it! There is now a terraform module in my

flyteorg/stow

branch for setting up an Azure storage account for testing. If not, that's fine too! I just probably won't get around to sorting out a local build until late this week or next. Just a lot of other things to do 🙂.

Terence Kent

09/20/2023, 4:19 AM

Just a quick update here. I ended up putting together a local build of Flyte and swapping the

stow

implementation to use my local branch. The good news is that

stow

works just fine and the dependency upgrades appear to cause no issues in the

flyte

project. On startup, using either AD auth or a shared key, a container with the name specified under

storage.container

is correctly created. When running a workflow, some

flytesnacks/...

blobs are created, so that's clearly working. The bad news is that all my test workflows fail due to an exception in

flytekit

. I haven't chased this down yet, but the

ffspec

paths being created are rejected with the an error of:

Copy code

Must provide either a connection_string or account_name with credentials!!

The fsspec created looks like:

Copy code

<abfs://myflytetest/flytesnacks/development/VQMFYT6TQOXW63XGU3I2GO33IE======/scri>
pt_mode.tar.gz

Maybe somebody here already knows what this is. Otherwise, this will need to wait until I can walk through the python library to see what's going on.

Samhita Alla

09/20/2023, 6:07 AM

Some of our community members were able to resolve this issue you're seeing. Here's a thread: https://discuss.flyte.org/t/13904302/hello-back-with-more-azure-adventures-slightly-smiling-face-#229e5898-71f9-42a8-95ed-2a766495b915

Terence Kent

09/20/2023, 4:48 PM

@Samhita Alla I see! Thanks for pointing me to the right place. That situation is not great. It requires an easy-to-get-wrong auth config in each pod template. I'll first see if I can get things working using

AZURE_STORAGE_CONNECTION_STRING

and then see if there is an easier way to manage the required configs.

2 Views

Open in Slack

Previous Next