VLroyrenn
08/10/2022, 9:14 PMprefect deployment build
handles uploading the flow (and apparently the rest of the CWD?) to remote storage. If deployment build
is meant to be used to create a "YAML manifest [...] build artifact", why does it also handle the uploading? If changes are made to the flow script(s), should the manifest be rebuilt (given it's the same step that handles the uploading)? If manifests are meant to be recreated from scratch whenever the flow is updated, doesn't that make manual edits to any parts of the manifest not specified in the CLI args too easy to overwrite (and invite users to just create one-liner shell scripts to not have to re-type these every time)? Or shouldn't it be apply that handles uploading the flow to storage while also notifying the Orion server about the change? Would deployment apply
overwrite the changes in configuration made in the UI, making it preferable that deployment files be the main source of truth for things like scheduling and flow description?
I'm looking at this from the point of view of a user who's looking to (at least initially) deploy Orion as-is, with no docker images and the flow files on... an SMB share, most likely, or maybe some FTP server . Ideally I would just have the flows be pulled from a local git server (which seems to me like a no-brainer if all the flows are going to be versioned anyway) and use commit IDs instead of manual version numbers, but I would probably run into issues using the experimental fsspec git backend as a remote FS. Maybe these procedures all make sense when working with Docker and K8s, but the documentation mostly skims over the "lifecycle of flow and/or deployment updates", so to speak, so I'm not really sure what to do with these, and deployments are a pretty big step to get to havinng scheduled execution of flows.
So, to make things short, how is one supposed to go about updating deployments and deployed flows?Anna Geller
08/10/2022, 9:42 PM