Hi Enrique, If we have two instances and one goes down, let's say a k8n POD, it does not mean that the user has voluntary has un-deployed the workflow. Instead, this is a "temporal" situation the k8s will automatically recover as soon as possible. We are not going to mark the ProcessDefiintion as "unavialable" at this point.
"availabilty" in the context of the proposal mean "user don't want to work with that workflow anymore", it was just "removed" from the "available" list. So, we mark a ProcessDefiniton definition as "unavailable" (undeployed) when the user voluntary decides to undeploy that process definition from the system. The SonataFlow operator knows that, and it's responsible for sending the corresponding event to the DI at that point. On 2024/07/04 09:59:00 Enrique Gonzalez Martinez wrote: > Hi walter, this won't give you the data you are aiming for. > > If you have two instances and one goes down the state will be set as not > available unless you compute something in the data index so at least you > will need more information or duplicate lines. This is unlikely to be the > responsibility of the data index. > > El jue, 4 jul 2024, 11:28, Walter Medvedeo <[email protected]> escribió: > > > Hi, the idea is to introduce the requirement/concept first, and summarize > > the impact on the information registered in the DI as much as possible. > > > > And thus, very summarized, the proposal is to include one more filed in > > the ProcessDefinitions information registered by the DI, that will let us > > know if a given definition is still "available" to create instances. > > > > That is a requirement we have from SonataFlow users. > > > > > > On 2024/07/03 20:50:20 Jason Porter wrote: > > > I am not exactly sure what the proposal is here. I see a bunch of > > background info for this new feature, but I don't see an actual proposal. > > > > > > On 2024/07/03 15:06:21 Walter Medvedeo wrote: > > > > Hello Guys, > > > > > > > > > > > > Let me share some requirement we have. > > > > > > > > > > > > Right now, as part of the ProcessDefinition information we store in the > > > > Data Index, we record for example the processId and the serviceURL. > > > > > > > > That information is good for users to know, for instance, which are the > > > > existing ProcessDefitnions, and, based on that information, they can > > for > > > > example start a new process instance by concatenating the serviceURL + > > “/” > > > > + processId. > > > > > > > > In the context of a SonataFlow Operator driven setups, users need to > > know > > > > if a ProcessDefinition is still “available”. > > > > > > > > For example, users can deploy a WF, use it for some time, and then, > > decide > > > > to un-deploy it. From this point, no more instances of that workflow > > can be > > > > created. The user has just decided to remove that deployment from the > > > > ecosystem. > > > > > > > > However, in the data-index, that definition is still recorded. And > > users > > > > want to keep it there, since they want to keep consistent information > > about > > > > the already executed instances etc. (The intention is to not introduce > > any > > > > information deleting procedure at the DI, etc.) > > > > > > > > On the other hand, users need a way to filter which definitions are > > still > > > > “available” by using the standard graphql api. > > > > > > > > What we are evaluating is to include a “status” field in the > > > > ProcessDefinitions, with the values available/unavailable, and, that > > will > > > > be updated as usual via ClouldEvents. In the case of SonataFlow, those > > > > events will be produced by the operator, which governs the > > > > deployment/undeployment, etc. Other setups might just ignore that > > field. > > > > > > > > Note: we are looking for a very minimalist approach that lets us > > record > > > > the situation, and facilitate SonataFlow users to query that situation > > by > > > > using the standard Graphql api. > > > > > > > > This is not any sort of more elaborated clustering > > > > management/monitoring/etc. solution. > > > > > > > > Independently of fine grained details about the event to introduce, > > which > > > > carries more or less the information we are already sending in the > > other DI > > > > events. > > > > > > > > From the point of view of let’s say non SonataFlow setups, do you guys > > see > > > > any objections? > > > > > > > > Regards, > > > > > > > > Walter. > > > > ResponderReenviar > > > > Añadir reacción > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
