Inconsistent paths between native and docker installations #89

Closed podhrmic closed 3 years ago

In GitLab by @zutshi on Oct 17, 2020, 13:43

We ran into this when one of the notebook was using a path to the toml files. Because the path is different for native and docker env, it will work in only one of the env. We can resolve this either by

making the paths uniform
~~localizing and placing the notebooks with the example systems. This was ruled out in one of the eng. meetings.~~

Yes, the docker launch pathway is ./run-csaf.sh -j -d $PWD/examples/f16, where $PWD/examples/f16 becomes csaf-system. @podhrmic and @bauer-matthews may have input here.

Ref: https://gitlab-ext.galois.com/assuredautonomy/csaf_architecture/-/merge_requests/54#note_63779

In GitLab by @podhrmic on Oct 19, 2020, 14:45

Yes, I am aware of this. Currently, we don't officially support running the notebooks natively, precisely because of this issue. Before tackling this, I would like to understand if we need to run the notebooks natively - our original idea was to support only docker. Is that not working for our collaborators? @zutshi you probably have the most experience working with them - what do you think?

In GitLab by @zutshi on Oct 19, 2020, 17:52

Well, I thought this was a simple issue to resolve. But maybe not. Some thoughts....

If this issue is hard to resolve, the first step would be to just explicitly mention this in the README
From the outside, it looks like a simple naming issue, but the way you explained it, looks to be a more involved issue. This is concerning because ideally there shouldn't be any difference between native and docker distributions which can affect portability of code between them.
My understanding was that we were using Docker to demo and not that we don't support native installation and development. In fact, that just seems weird. It is OK as long as our customer is only DARPA, but not if others start actively developing it.
As far as subs are concerned, I don't know how many are comfortable with docker. Docker is awesome for deployment but development requires some learning curve. Given the late start on integration and the tight time lines, I just want them to integrate their tools. They can then start porting them to Docker, instead of porting their development environment on Docker.

In GitLab by @bauer-matthews on Oct 20, 2020, 05:46

Do I understand correctly that the difference here is the launch path for the run script? If so, I think it might be a strong statement to say we don't support native development. And there shouldn't be any code portability issues, other than the run script args. I also think there is a difference between doing native development of CSAF vs. doing development of a single component and using docker to run a simulation.

Here is maybe another approach. We have an environment variable called CSAF_HOME (or something similar). And we anchor directory paths from there. We could also try to auto-set this where appropriate.

In GitLab by @podhrmic on Oct 20, 2020, 17:46

If this issue is hard to resolve, the first step would be to just explicitly mention this in the README

Let's do that, I would rather not spend much time on this.

Matt's CSAF_HOME idea could work, lets look into it more if we have time after addressing other issues.

For added color - the idea is that we support primarily Docker as a way of running CSAF because that is easy and you don't need to install any dependencies. You can develop/debug with Docker as you please, it just takes a bit of extra setup and I should add it to the README. You also can develop/debug natively, but we don't want to say we support it, because of the extra work - so in that case, it is up to you to resolve the paths etc. you need. In reality, you need to change only one line in the notebook, so not a big deal.

In GitLab by @podhrmic on Oct 28, 2020, 08:33

mentioned in commit 85abde042c232f82b251ae987ea2943b724d56bb

GaloisInc / csaf

Inconsistent paths between native and docker installations #89