2022 April 19 - 22: OIMT Virtual Face-to-Face

The March 2022 date for v1.6 will be changed. Come back on Friday. Will identify stuffs to be focused on in the next 6 month.

Task 65 Streaming

oimt2022.ND.002_ControllerStreaming.pptx (verson 1) was presented.

Look at the content of the stream and the stream reception, not just the source of the stream.

Slide 2 (Stream source - the send part)

• Nigel noted that
  • The association to the green classes are not navigable so the streaming model is decoupled from the main model, 
  • The information flow is from ExposureContext to TransmitFilter to ... to controlPort as illustrated by the big red arrow.
  • Focus now at the StreamLog and StreamHandler
  • Stored information (being streamed): The entity classes specifies LogRecordBody - the content of the stream
  • Conveyed information: Could convey multiple StreamLogRecord instance as a lump. 
• KL: Don't see the LogRecordHeader. Is it not of interested? 
  • Nigel Davis 05 May 2022 To put LogRecordHeader back in the Stream diagrams
• KL: Suggested to provide the brief definition of the classes in the diagram (as comments) to help understanding of the model
  • Nigel Davis 05 May 2022 To provide brief definition of the classes visible in the Stream diagrams. Could change the names if they are ambiguous. 
• CH: The entry class to the aggregate is the root. Use Aggregate terminology on the slides.
  • Nigel Davis05 May 2022 Emphasize in the slides and in the model that the whole aggregate is streamed and not just the aggregate root class.
  • Nigel Davis 05 May 2022 Emphasize that the shown entity classes (Equipment, PC, etc.) in the diagram are just examples, not exhaustive. 
• Nigel noted the other aspect - get the missing records.
  • The pipeline ensures awareness of any missing streamed records. 
    • Nigel Davis 05 May 2022 To cover getting lost records. The intention is the pipeline ensures the full integrity solution. Such as using the sequence number mechanism.
  • The clients can control re-connecting to the stream from the point where they last got the good record from the stream. 
  • CH: Just like the sequence number so can identify any missing (monotonic)
  • ND: This is the key behavior of the "pipeline"
  • MB: The Log Records are immutable. 
    • Nigel Davis 05 May 2022 To describe that the Log Records are immutable 
  • CH: Idempotent. If you ask the same record the second time, you get the same record.
    • Nigel Davis 05 May 2022  To describe that the Log Record usage should be idempotent
  • MB: Can the client ask for a specific record that the client thought was missing, e.g., record #71?
    • ND: Yes for some types of log. For a compacted log the record may be gone as a result of the compaction process. For compacted logs it is expected that the client is aligning a view with the real solution to achieve eventual consistency and hence is aiming to receive the entire log. So the client would not ask for a record specifically, but would essentially ask for the next relevant record after the record successfully received last.
  • This version of the core streaming model is intentionally open-ended on strategy. The aim is to produce a number of examples that show how the solution pattern can be used for various different specific solutions.
  • TAPI is more specific, but the essential log mechanism is intentionally equally flexible.
  • Under normal communications conditions where there is no bandwidth issue and the recipient is keeping up with the sender, the sender sends all events for everything grouped by the ConstraintDomain feeding the ExposureContext. It may be sent on a number of separate streams.
  • Under stress, where perhaps the comms has gone down for a while or the client platform is under performing, such that some form of recovery is required, the sender sends only records that will allow the client to achieve eventual consistency (removing "noise").

Side 3 (Clarifications - stream source)

• Two update mechanisms: "whole entity on change" or "change only". Both to maintain the integrity.
• CH: The update should be the aggregate, rather than the whole entity.
• ND: This was the intention and is what the TAPI solution does. 
  • Nigel Davis 05 May 2022Adjust "whole entity" to "whole aggregate". 
  • Nigel Davis 05 May 2022Reword "changed properties" to "changed leaves". State the structure and identify the leaves that have changes. Conditional leaf mechanism. No leaf should be mandatory.
• CH: Need to ensure consistency when applying the changes (e.g., input and output ports of LTP)

Slide 4 (Stream sink - the receive part)

• CH: StreamBuffer --> ReceiverBuffer
  • Nigel Davis 05 May 2022Consider relabel the classes, e.g., StreamBuffer as ReceiveBuffer (note that this was partially done later in the week).
• CH: Refactor - a grouping class to group the transmit classes, another grouping class to group the receive classes.
  • Nigel Davis 05 May 2022Refactor the sketch, such as, to have another green class that bring the ReceiveFilter and TransmitFilter together and relieve the ExposureContext some of the works. 
• ND: Need a model for the ExposureContext to choose a stream and advertise the available streams. TAPI has that model already.
  • An action was taken to do this, but Nigel subsequently realized that the model already covered everything necessary in this areas (as presented lated in the week).
• MB: Need to unfold the diagram to show the client side and the server side independently
• MB: The type of information the server streams to the client is very different from the type of information the cilent to the server.
• ND: The client can stream request. It could also makes request.
• KL: The role of a peer-end may change based on the transaction.
• ND: To prune the diagram into two. One for the transmitter and another one for the receiver.
  • Nigel Davis: To prune the diagram into two. One for the transmitter/provider view and another one for the receiver view. With ppt slides to show the flows (note that this was done for the presentation later in the week)

Due to lack of time, the remaining slides will be covered in the Thursday Overflow session

Note: oimt2022.ND.002_ControllerStreaming.pptx Versions 2 and 3 were posted after the session. Version will be used in the Thursday overflow session (Thu3.2).

Task 78 Controller zero-trust hardening

Stephen presented oimt2022.SS-MB.001-TR512-A.15.docx, which contains further mark-up on top of the document that was liaised to OIMT from ITU-T SG15 Q12 & Q14 on 2022-03-22 that contains SG15's questions, comments, and suggested edits to the OIMT early draft of TR-512.A.15 (Controller Lifecycle and Security). As noted at the beginning of the marked up, the feedback addresses the entity relationships of service, agent, and client, but does not develop the issue of compute and storage resources. The issue of the controlling entity for links between server contexts or controllers is not addressed. Commonalities with ITU-T Recommendation G.7716 (draft) are not explored but the issue is raised in section 5.2.1.

NOTE: In the marked-up document, the main section numbers have dropped by 1 as compared to the original liaised draft.

Stephen went through the feedback.

• Section 2.2 Management Control Architecture (section 3.2 of the original draft)
  • Figure 3-1. Could put the yellow triangles (common MC components) in the middle "Other MC Systems" too.
    • Stephen Shew 26 May 2022  To seek permission from ITU-T for ONF to re-use Figure 3-1 (which is from Figure 6-1 of G.7701) and Figure 3-1.1 (which is from Figure 6-2 of G.7702).
• Fig. 3-3
  • While the figure was not modified, there are a lot comments provided in the marked-up text below the figure.
  • "... A service context is n:1 with an exposure context". The n is not multiple views. The n means n instances of a call. Nested client contexts. As the concept described in the SDN architecture TR-521. Related to one customer (client). Suggest to read TR-521. The question is do we want to represent it or not. If not, why not.
  • Note the comment (bullets) on the RDB.
• Section 2.4 Controller in context - deployment assumptions
  • Section 2.4.1
    • The suggested client assumptions should be non-contentious. Were also asked in the liaison text.
    • The "Agent" concept was also taken from TR-521.
• 3 Building a Controller (i.e., Section 4 of the original draft)
  • 3.1  Platform creation (network administration)
    • Memory is mentioned. 
  • 3.2 Assign network resources (network administration)
    • Noted the imbedded question regarding Link. The later diagram (end of the section) shows "link". What is that link in scope of?
  • 3.3 Configure server contexts (controller admin)
    • In the figure, what context/view are those links in?
• The following slides
  • It will be good to turn the slides into text.
  • ND: Didn't have enough time to do that. Will do in the next pass.
• 5 Control Service ... (i.e., section 6 of the original draft)
• 5.2 Multiple views
  • May be multiple agents. 
• 5.2.1 Building a client context.
  • Noted the references to ITU-T G.7716 that could be used/referenced for the next pass.
• 6 Security Consideration (section 7 of the original draft)
  • Noted that access control may be used by or implemented within call control in G.7701.

ND: What is our plan to proceed this?

• MB: ND & MB get together next week to propose additional text, come to closure.
• KL: Could target for an updated version to be published in v1.6
  • Editor's note: Later in the week it was concluded that this would not be in v1.6
• CH's chat: 
  • From 521
    and "A service context conceptually contains at least all of the attributes of a service as requested by the client, and server-specific information necessary to map service attributes into the realization of the service. Notifications, logs, and profiles may or may not be associated with a service. There is no implication that a given service be owned by any particular user login, but also no prohibition."
• ND: Client context has an error in wording. Will ensure the right definition.
  • Editor's note: ND had material to present later in the week but there was no time so this will be covered on a subsequent call.
• MB: Areas to address. May put some high level consideration (without try to resolve it now). 
  • Resolve the loop of server/client context;
  • The concern with Link between server context and server context of another controller;
  • Migration of resources from one controller to another one
  • ND noted that the controller could be conceptual and hence is not overloaded.
  • Split a server context (which has moves in it).
  • Aim is to present problem and any inspirations.

Next step:

• Nigel Davis Malcolm Betts 19 May 2022 Take this document as the base to start with. Work on it focusing on Link abstraction with LRMs etc. (and link between server contexts) and Service Context. Work through points above and comments in the document. Nigel to send invitation for Next Wednesday (Planned time 5-6 (April 27th) EST.) for ND/MB. Then bring rework back to the team for discussion and refinement.

Malcolm presented oimt2022.MB.001-control loop sketch.pptx

• Look at this at very high level, not details.
• Core control loop (continuous/fast) and other control loops that act on the target configuration (occasional/slow/"background").
• Independent but need coordination.
  • Aiming for basic structure and then add TOD etc.
• Control loops with control construct, Job/Task and PC
• Slide 4 Steady state control loop – including restoration
  
  • Job/task: Observation and Difference determination is ongoing; high level sketch of very complex processes
  • Need to prioritize actions etc.
• Slide 5 Add connection (and delete or modify)
  • Path computation request could be abstract (if required)
  • Refine target as the development of realization proceeds
  • Report "refined" target is part of the target configuration, not refine target
  • ND: These would be preferences (never at all costs). All things are constraint with weightings... the weighting often very "heavy"
• Slide 6 Network optimization
  • The first determine whether cost of change is warranted by value <change>
    • CH: calculate the cost of change and compare 
    • MB: Probably need AI or human intervention. 
    • SS: There are business implications
    • CH: Put the job in input queue and then to decide
    • MB: need to sequence changes and determine whether it is worth it and refine sequence and target ongoing
      • Once chosen then implement changes in chosen sequence
• Slide 7 Network expansion
  • MB: May run on totally external events
  • <Commit>: multi-dimensional complex decision to make
  • CH: Changes may be based on history
  • CH: Also complex moves where traffic is moving from one place to another
  • CH: Double loops - Intent loop and Implementation loop
  • MB: It became clearer once the loops were separate 
  • ND: Intertwined loops 
  • MB: How to model the interaction of the loops
  • CH: Need to take care of stability and damping
  • ND: Similar to any control loop problem with possibility of becoming unstable
  • ND: Noted that networks today do grow and migrate and recover from issues with people running them. It is clearly possible to achieve stability.
• Next step:
  • Agreed to park the document as it is at the moment. Focus on the architecture regarding controller, client/server contexts, decide on where the loops reside. Master controller focus on the intent loop and the other controllers on the implementation loop.
  • ND noted that there will not be one big controller with one set of loops, it will be split across multiple controllers
  • MB: We need to look at planned state and how that relates.

Task 69 Job/Task (and Task 5 & 57?)

ND presented from oimt2021.ND.005_OAM.pptx

Building on previous work oimt2021.ND.005_OAM.pptx and discussing the latest updates (version 3) focusing on the task aspect.

OAM model MEG/MEP/MIP

ND summarized the tentative agreement. There were no objections. The items noted in the slides can be considered as agreements.

• Need to close off on mapping of OAM concepts to the ONF CIM - FC/LTP to MEG/MEP & MIP and if any model enhancements are required.
  • There were no objections to the interpretation in the slides
  • Document will sketch TP contents and show NCM first and then pull out bits to show various degenerate TP forms.

• Nigel Davis Andrea Mazzini 05 May 2022 Discuss how to progress the OAM work.
• Nigel Davis Andrea Mazzini 26 May 2022 Review first draft of skeleton OAM document and determine whether content can be partitioned between AM and ND. Aim for 1.6 release.
• Nigel Davis 09 Jun 2022 Provide a skeleton document as described in oimt2021.ND.005_OAM.pptx that sets out the rationale for use of existing FC and LTP to represent OAM entities. Note that the action "Nigel Davis  17 Mar 2022 Early draft of OAM document using existing model and explaining key features that enable it to be used for OAM, then projecting this model towards a TAPI-like solution. Action item from 2021-09-23 OIMT Meeting notes" is covered by this action.

Job/Task

Note that CH pointed to an example of a new workflow engine - Kestra: a Scalable Open-Source Orchestration and Scheduling Platform https://www.infoq.com/news/2022/03/kestra-orchestration-platform/

ND went through basic observation on a task linking the task to intent and outcome. An outcome can be ongoing/continuous, periodic, one-off/instantaneous etc.

Need to consider the trigger of a task.

CH: The terminology in this space is messy, there are no clear definitions.

ND: So we need to have some clean terminology that we use.

AM: There is a target configuration. The task is a composition of activities working on a target.

ND: Using Outcome for the target configuration where this may be complex and changing. 

AM: related to MB diagrams and a hierarchy/arrangement of target configurations. It is intertwined. Task is also for use case.

ND: As task is an activity that may lead to another activity.

AM: Noted the control loop is a task.

ND: The control loop is a task and there is control of control.

AM: There is a continuum

ND: The terminology is relative. We need to right statements of relativity. We need to tease apart the problem to get to a terminology set that is stable and usable

CH: Suggested that a task is not ongoing and workflow is longer lived.

MB: Not sure if that is true. Think about network configuration. The entity that is observing for differences is ongoing.

CH: Emphasized the challenge of terminology.

ND: The terminology needs to be fractal and relative.

CH: Kestra is a good example. Try to make the tasks small and reusable within a workflow. You need to start with something Atomic.

ND: Atomic is a problem... An atom is not atomic.

ND: I have not tried to tackle the definitions yet. 

CH: All the workflows seem to have similar concepts. In the abstract, fractals are OK, but we need something implementable

ND: Well, actually in the core, we need to get the patterns right, we try to describe the problem space in the core. We do not implement the core directly (other than wireless), we refactor, e.g., in TAPI.

ND: Using the term Task here as all words have a problem. 

ND: Discussed results, intermediate results, 

ND: All functions (Tasks) have some flow through. Can control the flow. Can apply variable resources. Any function (Task) is constrained by an encompassing definition and It can be further constrained. E.g., Path Computation function is constrained to computed paths but any paths, so for it to do something useful it needs constraints (the topology, the specific ends etc.).

AM: Generic pattern in the core is fine but need more concrete consideration on atomic and composition. We have an implementation of a management interface. There appears to be a practical definition of "atomic" operations. There is a need to put together these atomic things into useful overall activities (use cases).

ND: Agreed with an implementation pitch that enables understanding. Human terminology enables implementation (even if the machines do not need it).

Discussion on abstraction of control and a control hierarchy. Atomic in the context at a moment.

CH: Cannot afford to make it too complex.

ND: Component-System is not complex. It is overly simple.

CH: Offered to show Kestra. 

ND: Agreed, but concluded first.

AM: This looks like a use case. 

ND: Yes, but artificial boundaries are a problem.

ND: Trying to pull out the common pattern. We can then refactor it in different concepts. 

MB: Agreed with the general challenge and that we need to identify the pattern.

Editor's note: The challenge is terminology.

ND: Brief discussion on the Intent Task diagram.

• Nigel Davis 12 May 2022 Work a definition set for the "Task" space accounting for the fractal nature and the Component-System pattern aspect. Deal with "triggers" (events etc.), constraints etc.
• Nigel Davis 12 May 2022 Set out some meaningful examples an interaction of "Tasks" to achieve some relevant outcome (e.g., service creation, restoration...). Note that the action "Nigel Davis   14 Apr 2022 To study the boundaries of Job/Task, ControlConstruct, PC, CASC (algorithmic). Consider path computation as an example. Action item from 2020 OIMT Virtual Face to Face - Week of April 13" should be covered by this action.
• Nigel Davis 12 May 2022 Provide a mapping from "Task" terminology to other terminology sets (e.g., Use Case, Workflow...)

CH: Kestra

CH: Walked through Kestra definitions (the screen shot below is from publicly available Kestra documentation).

ND: General definition of Task with specializations.

ND: Isn't a Task realizable by a subordinate Flow?

ND: Fractals bend away but there is a sweet spot of several levels.

CH: Indicated that the simple definitions help.

MB: Provided an example of recursive tasks Path Computation is a Task from the "create a connection" perspective, but Path Computation is itself formed from flows.

CH: Lots of implementations out there and all have similar concepts and definitions.

Task 37 Spec re-work

Building on previous work (using updated version of oimt2021.ND.004_Specification.pptx (version 4) considering slides 30 to end).

Schema discussion.

• Slide 31 Layer stack
  • G.709 OTN layer stack as example
  • Challenge: Standard is not machine interpretable
  • Need to have a machine interpretable specification of the subset of the standard properties (capability, option, mapping, ....) that one has implemented on that port on that version of that type of hardware. 
  • Will look into what the specification structure need to be
  • LN (25:35): Will combinatorial aspects of options be covered? 
  • ND: Yes. 
    • Nigel Davis 19 May 2022 Cover combinatorial rule for layer protocol options. "And" & "Or" in spec language.
• Slide 32 General principles 
  • Broad definition > recursively narrowing
  • Jsonized coding for single value leaf. Not to repeat in next level narrowing
  • (added: x is omitted as it is fixed in the previous level)
• Slide 33 Further considerations
• Slide 34 Considering nested definition
  • Default stuff is not re-stated.
• Slide 14 Extraction from spec showing examples
  • The definition types are intertwined.
• Simplified spec 
  • To get to a lightweight simplified spec for LTP.
    • Nigel Davis 19 May 2022Take the spec model, prune out the stuff that are not relevant to simple layer hierarchy, look at how to apply the general principles (slide 32) notation to the stack of layers & rules, write it in the context of the original spec structure. Note that the action "Nigel Davis  14 Apr 2022To prune out the unneeded stuff from the current Spec document so that to show the Yang "when" and "must" of the Occurrence pattern. Action item from 2021 Sep 07-10 : OIMT Virtual Face-to-Face" is covered by this action.
    • Nigel Davis 19 May 2022Construct simple spec example using layer hierarchy model for the OTN payload structure, try longhand form, correct number of occurrence set, based on some specific ports. Code it in JSON form of YANG. Note that the action "Nigel Davis  10 Mar 2022Lay out the spec model with sufficient occurrence pattern of equipment in it. Relate UML to Yang. Action item from 2021 Sep 07-10 : OIMT Virtual Face-to-Face" is superseded by this action.
  • MB: Write it in a structural language form is a right approach. Close to YANG but don't be constrained by YANG.
  • ND: Tried this in raw YANG and found it not possible to construct.
  • ND: Will keep Martin S in the loop.

Task 5 Streaming (using updated version of oimt2022.ND.002_ControllerStreaming.pptx (version 3)):

• Continuation from Tue 1.1b discussion.
• Diagram broken into two parts to show client and provider
  • New slides in version 3 of the deck: 2, 7-13, 
• Consider the request portion of the diagram (which was not discussed on Tuesday)
• Walk-through of stream interaction (slides 8-12) 
  • Client asks provider via get (not shown) which streams are available via appropriate control port. Provider presents available stream details.
    • Showing a particular CD.
    • The client needs to know where/how the provider can be connected to.
      • Nigel Davis 05 May 2022 Step-0 of stream interaction. The client needs to know where/how the provider can be connected to.
  • Stream logs are running and being populated with current state and change.
    
    • Note that ViewMapping is not shown.
  • Client connects to stream and stream starts.
  • Client receives a new FC and populates its appropriate CD
    
    • ViewMapping is not shown
  • Client receives various records and maps to views etc.
  • Note that All the entity artifacts should be aggregate
    • Nigel Davis 05 May 2022Should emphasize that all the entity artifacts (FC etc.) in the streaming slides should be aggregates.
      • MB: The artifacts in the aggregate should be consistent.
    • Nigel Davis 05 May 2022 Should note that there will be temporary unresolvable references due to asynchronous processing of streams etc. 
• Request Constructor Sketch (slides 14, 15)
  • Haven't done: How does one determines the needed details for constructing the Get/Post/Put/Patch request.  
    • Nigel Davis 05 May 2022 Lay out the details of constructing request (Get/Post/Put/Patch).
• Controller in hierarchy (Slide-16)

Task 64 Aggregates (using updated version of oimt2022.ND.004_ComponentPort.pptx (version 3)):

• Continuation from Tue 1.1b discussion.
• Updated version of Nigel's slides that attempts to account for the partial precision of the reference and the necessary detail of the reference to a specific type of subordinate part etc.
• Slide-4 Scope considerations.
• Slide-5 Potential conclusion
  • All association ends are in terms of constraint
• Slide-2 Considering Aggregates and components
  • Both have unexposed internal parts, weakly exposed parts.
  • An aggregate has only one facet. A component has multiple distinct facets.
  • Aggregate is not strongly focused on flow.
• Slide-8
  • Two key observations
    • Need to have the notion of a port so that we can reference in it, not a specific one (port).
    • For more specific one, it is in terms of constraint and not the actual ID.  
• MB: What to do next?
• ND: Need to know how to reference thing by constraint.
• MB: Keep in mind that the constraint could point you to one port.
• Discussion will continue on Friday

Task 73 Temporal expression 

Augmentation focused or subclass focused.

Using oimt2022.ND.001_TemporalExpression.pptx.

Discussion: To decision whether to use the subclassing form

• ND Proposal: Use augmentation to bring in different capabilities as opposed to subclassing
• Alternative: Use subclassing form; 
  • Reason of concern: combinatorial in subclassing
• Example (slide-14)
• ND preference: Augmentation form. Cannot see distinction rather than style, why augmentation form won't support the example, did the one in Fowler

• CH: Instance example to prove. Will find the example and look at it. 
  • Chris Hartley05 May 2022  validate augmentation approach to temporal expression against Chris' example to find out whether the augmentation can support the example or not. Yes or no.
    
  • Nigel Davis 16 Jun 2022  Construct draft Temporal Expression document. Note that the action "Nigel Davis  10 Mar 2022 Draft temporal expression document" is covered by this action.

Task 64 Aggregates 

• Continuation from Thu 3.2 overflow discussion.

(rough notes following... to be completed)

• Fowler considers communication between the software entities of the management solution whereas our consideration is the flow between the managed entities. This may be a key distinction.
• The component is opaque, so it does not expose the internal parts but does express the behavior of how the component appears.
• Component has 2 views:
  • external: express to the outside world what it does. This is the transfer function. What it does and not how it does it.
  • internal: describe the supporting functionality
• There is a relationship between what the component does and how it does it.
• What a component does can be represented in terms of components. How it does it can be represented in terms of components. But the components in the expression of what it does and those in the expression of how it does it are not the same.
• Can see and set properties on the expression of what the component does. The management control system can clearly see and set values on the exposed component description of what the component does.
• There is an information flow missing (missing a green arrow from Agg to Agg) that is the same place as (2a)
  • Nigel Davis 26 May 2022 add missing information flow corresponding to (2a) in Agg/Component diagram
• The port is the same as the FcPort.
  • Like a hole in the wall.
• The green arrows represent flows and are at different levels of abstraction
  • At one extreme end there are ways in but I don't care which etc. and at the other there are specific ports associated.
  • Different port types can be referenced (it's a port, it's a type of port, its from a group of ports)
  • Arrow direction not information flow direction
    • If it was, then there are many bidirectional bindings that would cause a highly coupled model
• Other relationships are not related to flows (related properties)
  • Rules and properties.
  • Rules must be able to relate to exposed properties, regardless of their depth. Related to policy
• The association direction relates to relative lifecycle relationship.
  • FcPort references LTP and not the reverse as LTP can meaningfully exist independent of the FC but the FC is not meaningful independent of LTPs 
    • The LTP may be abstract end (building etc.)
• The port should have an address relative to the root where that address is in terms of the root and a sequence of (perhaps just one) local ids.
• Delegating root stereotype may solve the port issue
  • Nigel Davis 26 May 2022 Apply delegating root stereo type to ports in the model and prepare brief refactoring of LTP port applying the delegating root.

OAM (slides 14, 15 and 16 of oimt2021.ND.005_OAM.pptx (version 4))

• Continuation from Wed 2.2 discussion.
• Slide-15: Brief assessment of Kestra in context of Core Task
  • A brief assessment of Kestra and further explanation of Task emphasizing that Task can be any size
  • CH: Kestra are separating flow from Task
  • Separate orchestration of flow and doing the Task
  • CH noted that a task could trigger a workflow
• Slide-16
  • ND: Cannot see why a task cannot have work flow inside it where each workflow is composed of tasks where these tasks can have workflows.

• • CH showed previously submitted work.

• • CH emphasized that a task may trigger a workflow.
  • Discussion on task and workflow split
  • Discussed the need for clear definitions.
  • MB noted that we need to apply the component-system pattern where we describe the task in terms of a workflow of tasks and implement a task in terms of the a workflow of tasks.
  • ND agreed.
  • CH noted that with the right abstraction the orchestration realization can be relatively simple.
  • ND noted that a task is described by an apparent arrangement of tasks and is realized by an arrangement of tasks
  • CH suggested that it is like a DB transaction with respect to atomicity
  • ND: A task may not be atomic. It may have multiple outputs some of which may be fail etc. There is no need for rollback, etc.
  • Delegated complexity with complex description.
• Actions
  • Nigel Davis 12 May 2022 Definitions of task using Component-System principles (explaining the distinction) and show clear boundaries. Say what a task is and what not. Define recursion. Emphasize reuse. Place orchestration on a figure.
  • Nigel Davis 12 May 2022 How the orchestrator interprets complex tasks with intermediate outputs with loops etc.
  • Nigel Davis 12 May 2022 Example of a complex task description in terms of an abstract workflow with intermediate output and loops etc.

Service Context - to cover in future

• Continuation from Wed 2.1 discussion.
• Concerns with terminology and definitions in TR521
  • MB: Need the ExposureContext and ConstraintDomain in the ServerContext.

Bubble chart updated. oimt2022.KL.001__OIMT-task-bubble-chart.pptx (Version 2)

• Nigel DavisHing-Kam Lam  28 Apr 2022 Dedicated meetings planned for:
  • Equipment model
  • Job/Task