So, this presentation is about reducing technical debt with reproducible shell workflows.
I believe the approach that we take with regard to documenting system is quite different
from most stocks that I've seen here today, and I believe that makes it actually even more
interesting, or at least I hope so.
I'm, well, we first introduce ourselves, maybe Collin, we can do this right to left.
Okay, so, in myself, I'm Collin Hav, an employee at 9, with Hugo, and a lot of people here,
with you, but that's software, and came here to participate to talk about this, and
you go, you can present yourself.
Yeah, I'm here with Collin, I'm in embedded software engineer at mine, I've been working
on mine for seven years now, and I've been working for several projects, for several projects
in Avionics, and one of the more recent projects was for Boeing, where Boeing asked us
to implement a new operating system, Linux operating system, using the built-in system for
the TALOS, the Raptor TALOS II hardware, Raptor TALOS II is, I would say, a very advanced
operating, it's a very performant machine, it's also very expensive, and we encountered
quite a few challenges when implementing this system.
There are two elements to this presentation, so the things, the software artifacts that
we implemented, and then a methodology that we used to implement those software and artifacts
basically to execute the project.
Boeing explicitly asked me to add that the Boeing work was for Raptor TALOS II, Linux power
and I operating system functionality, but that Boeing is also neutral on the workload concepts
and methodology used to carry out the project, which is the main focus of this presentation.
I have been in the main architect of the Neural Simulator called Genesis in computational
biology, and one of the main targets of this simulated was making improving the quality
of scientific publications, and some of you people may know that there's a serious problem
with the quality of many scientific publications, because the results are not reproducible.
So one of the main focus of one main focus of the Genesis Simulator was making these scientific
results reproducible, improving the transparency, and while doing this, we start to make
a distinction between two types of knowledge.
On one hand, there's the process knowledge that you develop while you're carrying out a project,
while you're doing your research, while you're implementing your software system.
In a second, there's the product knowledge, when you do your product delivery, you publish
yourself to it, there's the knowledge that you want to document functionality of the product
that you made, so that are the typical manuals, that are diagrams, using manuals, specification
manuals, and so on.
There's a different fundamental difference between these two types of knowledge.
Similarly, the product knowledge is implicitly consumed by the users, but the process knowledge
is never shown to the user, a user is never exposed to it, nevertheless, if you want
to continue to develop the product, if you want to evolve the product, you will require
that process knowledge.
This presentation has a strong focus on the process knowledge.
There are many good tools for product knowledge, process knowledge, I believe, is underestimated,
nevertheless, enormously important for software development.
So in the Genesis Simulator, we implemented tools that supported the delivery of both process
knowledge and product knowledge.
The product knowledge in a scientific context is quite simple, it's a scientific publication,
but the process knowledge is hardly documented.
As a consequence, results are not always reproducible, especially in embedded systems we face
a similar challenge, reproducing embedded software artifacts is not easy.
There are special build systems like build route, which I will show later on.
We developed several tools for the in the context of Genesis Simulator.
Vigilia has a focus on product knowledge, workflow, the workflow engine that we will present
over here as a focus on process knowledge.
These are open source software tools available from GitHub.
So I'm now going to do a very quick tour about the workflow engine, and especially a focus
on how exactly do you use it, how exactly what is it, how does document work flows.
So I'm going to go to a live demonstration, and maybe the first thing that I will
to hear is show workflow as executable.
So using the workflow engine, you'll implement several projects, or you can implement
several projects.
There's a full isolation between all the different projects.
If I list the projects available on my laptop, I see there's something like 10, quickly
go through a few of them, so there's the build route workflow.
In this case, workflow engine acts as a wrapper around the build route build system.
There is, for instance, over here, the mind workflow.
The mind workflow, that's a workflow engine configuration that assists me in the infrastructure
maintenance of the mind network.
This includes, for instance, the website of mind, where I sometimes do updates, mind workflow
captures, there is a configuration that captures the workflows that I employ when developing
that website.
And then for another example is a fleet miner workflow, fleet miner workflow is a configuration
that assists in the development of an internet of things simulation and maintenance management
system.
And in that case, the workflow engine orchestrates the behavior of many different IoT devices.
Connics into a dashboard, visualize their dynamics.
OK, so what I'm going to do now is I'm going to give a more concrete idea of how
everything works.
I'm quickly going to create a workflow project.
So I make a directory, CD into that directory, there we go, the directory is empty, of
course.
And then I start using the workflow engine.
As you see, I type a few letters, and I use bash completion, bash completion, is a main
element in exploring existing workflow configurations.
If I tap twice here, you see, I will have a project start.
Element, if I tap bash completion again sometimes, the bash completion is used as a kind
of guide for red type of arguments, a common workflow could expect.
In this case, the name of the workflow configuration that I'm about to create, there you
go, workflow engine gives me some additional instructions.
One of the elements here is that I want to install this workflow, making it globally
available on my laptop, there you go.
And from now on, I do have a false-them workflow with bash completion.
The project that I create is based on a template, template has a few examples.
One of these examples is a Python examples, and then Python commands.
So this is just a kind of toy example for you to start with your workflow project.
Just a comment here on terminology.
So you have the false-them workflow executable.
Then Python examples is what is referred to as the target, and Python commands is what
is referred to as the operation, working on that target.
If I execute this workflow, just a very simple toy like example, it echoes a few things to
the screen, if I ask for interactions, it will tell me what it would do if I execute that
workflow.
How do I add a new workflow?
Very simple.
As usual, we have bash completion to assist us to figure out how things work.
We have this operation workflow add.
I type bash completion to see what should be.
How should this work?
I need a target name.
Well, I'm just going to use the target name that I have over here, and an operation
name.
Let's call our new workflow operation one.
There we go.
Create a new workflow in file, and so let's see what's in this file.
So this file, that implements one workflow for the workflow configuration of false-them,
is a regular Python file.
You can import new Python libraries.
You can do anything that you can do with Python in this file.
It's a regular Python file.
And it implements this workflow Python example operation one.
So if I execute this workflow, nothing happens.
If we look at the implementation of this workflow, indeed, nothing happens.
For low and back to this file, this file implements three different Python functions.
So the implementation of the workflow itself, the configuration of the bash completions.
And then here at the end, you'll put the help page.
I'm slowly building towards documenting these workflows.
If we want to add commands to the workflow, we use, for instance, in this case, execute
commands, execute command array.
These are API calls into the workflow engine, and I'm slowly building up how this slowly
building up the complexity of the workflow that I'm about to implement.
So if I write this file, there we go, Python examples operation one.
Now suddenly this operation one workflow is not empty anymore.
The commands are executed, and I can obviously ask for the interactions, there we go.
So this all works nicely together.
With regard to the bash completion, if I tap twice, I get the bash completions.
They're not filled in yet.
How exactly does this work?
So let's add some more meaningful bash completions.
I'm going to choose the typical examples of food.
Say, food is an argument that could be added to this workflow.
After food, we don't expect any further completions.
The second possible argument is bar.
The bar argument could possibly be followed by a bar one,
which is then followed by nothing, and then possibly followed by a bar two argument,
which is followed by nothing.
So I hope I didn't make any typos.
If I go back to the workflow itself, and I tap completion,
there we go bar for the possible completions.
Food isn't followed by anything else.
Bar is followed by bar one or bar two.
If I just execute the workflow, it's still the same.
It's still echoing few commands.
Now there is one option that I would like to show here too.
At the top of the file, we can read the sentence rows are available
as a variable global rows.
And here we see row that's a row that is defined
in the false and configuration, and that can be added to
as an argument on option to these API functions.
So I'm first going to go back to false and workflow,
built in, and then show what rows are available.
If I tap twice here, built in row print,
I see there are several rows available,
and I'm just choose kind of arbitrary, the T-mix rows,
ask the print them.
There are two T-mix rows, one 14,
one 14-mix server.
And what these rows do, they start T-mix sessions,
such that you can execute commands in those T-mix sessions.
Then obviously you can attach a Qmoo engine or a different
or a serial console or something to this T-mix row.
To start the T-mix row, I first need to create,
created. So I start now two t-mux rows. I can attach or t-mux sessions. I can attach
to such a session.
Here we go.
There we go. This is the
Here up is I've a terminal attached to the t-mux session that I just started.
What I can now do
is I can
have some of these commands executed in the t-mux session.
By the time syntax requires me to first declare this variable
global rows and then I define a variable t-mux row equals
t-mux rows.
I have the thing for a moment. I think the name was t-mux device.
Okay, and then here I add the option row equals t-mux row.
t-mux row.
There we go. I write this file.
I then ask again for the interactions.
Python examples operation when interactions
there we go. And we see that the workflow engine would now echo Python
command 1 to the local console and echo these other commands
to the t-mux session. So if I execute this, there we go. Python
command 1 is echoed here in the local console.
And if I go switch to the t-mux session, then I see that Python
command 2, Python command 3 are echoed in that session.
Now, so far these are all toy-like examples just echoing.
Obviously, you can imagine that you attach this to a QMO instance,
that you start to do things with QMO through the telnet port or through an
SSH. This is all possible. It's just about defining the right
rows and combining these things in the right way.
If indeed, we kind of functionally scale up and we look again
at what projects were available over here, then we see that we do have a
tallos to workflow. So this brings us back to the project that we have been
doing for Boeing. And if I then ask for all the workflows of tallos
to, you see that we implemented many different workflows while
executing this project. I'm quickly going to show a few examples
regarding to source code. So the source code of that we,
so if I use a source code target, workflow engine again wraps around
if I ask completion for a configure, what you see over here,
all the different and a difficult fix available for this
particle of source code. We implemented some. This is the tool chain,
so you've got type O with tab completion. So what you see is that the workflow engine
dynamically finds the right difficulties, automatically generates completion,
so there are no type of possible over here. If I just
configure, then you see how the workflow engine exactly wraps around
the build-through build system, it sets the right
environment variables, changes to the right directory and so on.
So now if I would start to build itself like this, I'm not going to
execute this because it's going to take a long time, but then the
build commands would be started to build the tool chain that we need
for the operating for building the operating system for that all of
us to. And this brings us much closer to the real work.
Okay, so I will present quickly the way I've been using
workflow engine to support for go during the development
of a driver of a modification for the driver for the BCM 155719.
And how I use the workflow engine to quickly get on board and
do stuff and accelerate my workflow while keeping it documented.
So a bit of context first, we will need a bit of support to enable the
cross-compilation of this BCM firmware to the target architecture of
PowerPC 64 began then, began then a bit unusual, so there was a lot of
hurdles, we can re-galing that. And so my first step was to just set up the dev
environment, usually it would be done with a Docker container or maybe a giant
batch script or via stuff, but this time it was done with the workflow engine, so
I originally knew I would introduce me to workflow engine very well, yeah.
So I could just pull the workflow configuration, install it, and see what was
available to me to reproduce a basic build. And actually, like a few
hours, I was able to have a native build, which is a good first step for my work.
But the basic, the native build is not what I wanted, I wanted to cross-compile,
so how would I do that? Well, I will be very quickly clear because I have much time
and that assist route, which is basically a way to, to avoid
linking against the native libraries, which would be a program for cross-compiling code.
And I used the deviant and the bootstrap to easily pull full Linux
route system, deviant route system in this case, my computer for the right
architecture. And so that was done for the assist route building, so I could put that into
workflow, so that you could use it and discover it later, and ask me question and
note it. And I generally need to set them really big and long commands over Slack,
as I'm also sorry. And yeah. So next step, I need to fix some problems with the CMake
tool chain of the firmware. Once again very quick, the project builds some of its
build tools in the project, which are there, which if you cross-compile them, then you cross-compile
the build tools, which is not good because you need them to build. So I had to modularize this
CMake system to enable to fix the problems. I also had a bit of an issue with the linker,
would not do some stuff for this architecture, which was sold by pulling and compiling a
specific linker, which brings me to this schematic, where each square is basically a workflow.
I don't need to send a giant bass strip in a pull request. I just have five more workflow
then you go and try iterate and give it feedback on. And later, I can just reuse these workflows
to re-dive into the work that we had done for this really easily in a few comments.
Yeah. Yeah. You go, I give you the flow. Okay. Yeah. That's fine. So what in the end comes out
of this is that we can build a manual for this NICDAR hit. Okay. And so in this case the workflow engine
has produced a PDF document of all the work that Colleen has done. It has an introduction,
you see the same diagram that Colleen just showed, and it has all the work flows,
enumerated, and with all the documentation for how to do the cross compilation of this NIC firmware.
Okay. So all these tools are available. All the repositories that we use are available from
our GitLab repository or our GitLab pages of mind. Now I quickly would like to end with this diagram.
I see at the end already as a smile and he knows how much effort I put in this diagram.
So I showed the workflow engine as a simple wrapper around build route. I've shown the workflow
engine for infrastructure maintenance. I've explained about fleet-minded as a software component
integration system. And I believe with the growing landscape of open source software components,
the technical depth that emerges from the integration, hopefully the useful integration of
some of these software components will greatly increase. And I believe there will be a greater
need for components such as or systems such as the workflow engine to document this technical
and to address that problem. That's it. Thank you.
Is it done for questions? The recording automatically cut off, but if there are any questions,
this is the final top of the day. Now it's your text.
Mark, the workflow configuration is putting a Git repository that can be published to GitHub or GitLab
or whatever medium you want. And then the workflow engine has built in workflows to re-estantiate
that's configuration as a useful configuration. So to make it available on our machine.
Yeah, that's a very good question.
Well, the workflow engine is not a build tool. That's one. I believe all these software
components that we see on the screen now, they have their own dedicated purpose. They're very
good at it. And the workflow engine just wants to integrate them. That's one part of the answer.
The other part of the answer is for us, if you compare to Ansible, there are a few distinguishing
factors. The workflow engine is directly programmable in Python, which I believe, where I believe,
I'm not that familiar with Ansible. I must say, but I believe Ansible has its own external
type of language. Then another, and I believe more important,
difference is that the workflow engine has a focus on documentation and knowledge sharing.
While Ansible is actually a configuration tool. So that's a very
principal's difference. And that's also the reason why we can automatically generate PDF documents
from these workflows. I didn't show that much about that. I apologize for that. But that's definitely
not the purpose of Ansible. The workflow engine executes the code. Yes. So in that sense, you also have
the element that these hell of pages and the code, the workflows themselves are very close to each
other. So it's easy to keep them synchronized. What questions? Okay. Thank you very much.