Rationale Wanted

[kbruegge]

I would like to trigger a discussion about the current architecture of the shifthelper.
I'm not saying to change anything. I just think we need some more rationale on why these design decisions were made. We should collect more of these things. I think it might help with maintenance in the long term.

This is just the basic gist of what I understand to be basic structure of the whole thing:

Status

pycustos

a python lib that uses threads to perform checks for specific conditions or time intervals.

shifthelper

A program to check the status of the various subsystems of FACT.
In case one of these status reports is not within predefined bounds a predefined action is taken and a thing called Alert is produced.
All the threading and control flow logic is part of pycustos.

Some basic requirements include:

• shifter has to have a backchannel to the shifthelper -> instance must be accessible from the internet
• all alerts should be stored in a database.
• many many more.

shifthelper-webinterface

Currently the webinterface is running as a separate program. It communicates with the shifthelper instance via http requests. It does not necessarily need to run on the same machine as the shifthelper. There is some authentication stuff involved here as well. A user has to login to acknowledge alerts.

dockerization

The shifthelper instance is deployed using a docker container.

My Questions

Deployment

Let me quote wikipedia:

Docker is an open-source project that automates the deployment of Linux applications inside software containers.

Sounds good. Heres some more wikipedia:

Docker provides an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[6] Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as aufs and others[7] to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.[8]

Sounds to me like a great piece of software for two use cases:

1. The cloud. Many heterogenous computers. The user does not know the system details of the underlying machine and possibly shares it with other users.

2. Software which is hard to install. We deal with weird C,C++,Fortran software everyday which only compiles on very specific system/OS/compiler combinations.

My questions:

1. Are we planning to run the shifthelper in a coud computing environment?

2. I guess this is not true in case of the shifthelper right? Its pip installable right?

3. Whats the big advantage of using docker over other service controlling tools already built in to many OSes? (systemd comes to mind).

Webinterface

Separation of concerns is always good practice.

1. Due to the login/auth stuff the server providing the webinterface has to hold state. Which user is logged in currently. And on a lower level in some queue handling HTTP requests to communicate with the shifthelper.

2. We need to run and monitor two separate executables.

From what I understand the web interface could be provided by shifthelper as well. My question:

Whats the big advantage of this separation?

Hope you had a nice election day.
Make america great again.

[dneise]

I think this issue is really great and I totally support it. However, it is pretty large and I expect answers to become even larger (especially in case they are discussed).

In order to not be lost in a huge mess, how should we proceed?
Can we identify questions which can be asked and answered isolated from this issue, but still link to this issue in case people need context?

Once the questions are answered and this issue will be closed, it will be difficult to find the highly valuable information.

So what is the outcome of this issue? Is it maybe a document?

If so, we could start a document initially full of questions ... but to be filled with answers and work on it using the normal git approach, branching the document to answer a question and discuss the validity of the answer in the PR.