hey Metaflow folks, think I know the answer alread...
# ask-metaflow
f
hey Metaflow folks, think I know the answer already from perusing the metaflow service repo a bit but wanted to ask the experts: is it correct to say that in the metaflow data model there's no concept of version for deployed flows?
1
a
there is - every run keeps track of the version of the flow (including the code package - if available)
the references are in the metadata table
f
hey Savin! yep so my q is a bit of a different angle possibly, but looking at the metadata service a bit more looks like deployment isn't specifically in the data model. say you have a flow named MyCoolFlow , you deploy it on argo wf and then add a parameter and deploy it once more. Is this captured somewhere in the data model / argo wf labels annotations etc?
the only id, flow_id, is the MyCoolFlow ; is that right?
a
conceptually - we capture the full code package that makes the workflow template reproducible. argo wf by itself doesn't offer versions for workflowtemplates out of the box.
f
yeah thats at the run level though, specifically thinking at the flow level. In the case above, if a deployment was made adding a parameter we'd have a breaking change for services interacting w that deployed flow
a
yeah in those scenarios - using metaflow's notion of
@project / --branch
would be a better fit
f
yeah - branch would work but its then on the user to increment / handle versioning for these kinds of breaking changes
a
with breaking changes - it is usually better to have two different explicit versions be live at the some point so that downstream consumers can better test their changes
adding a layer that piggy backs on top of
--branch
to introduce versioning semantics should be easily doable
f
yeah, having supported fairly large teams of data scientists with different levels of technical knowhow the branch approach isn't too viable hah. Thinking about it a bit more seems appropriate to build ontop of labels. Imagine a CICD use-case; having versioning baked in vs manually using branches would allow you to easily rollback etc
thanks Savin! super helpful, gave me some things to think about
a
awesome! as of today - project and branch makes there way to argo wf both in the name and and as labels for all k8s resources associated with the wf. additionally, all metaflow objects are namespaced on projects and branches - so building a layer on top of them would be the best bet to guarantee isolation