EESSI / compatibility-layer

Compatibility layer of the EESSI project

Home Page:https://eessi.github.io/docs/compatibility_layer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

installation procedure for /cvmfs/pilot.eessi-hpc.org/test/gentoo/2020

boegel opened this issue · comments

@bedroge @peterstol I think it makes sense to document how the Gentoo Prefix installation we have now at /cvmfs/pilot.eessi-hpc.org/test/gentoo/2020 came to be: which procedure was taken, which "version" of the bootstrap script was used (the one in #4, I presume), which customizations were made compared to upstream, which problems did we run into (ideally incl. link to upstream bug report or fix), etc.

Also, if any additional commands were run (like "emerge ..."), we should document them somewhere for future reference.
That can be done in here, by adding comments to this issue...

When we do another Prefix installation later (we will probably start over at some point during the pilot, but also for production later), we can use this issue as a reference of lessons learned...

Makes sense, but note that most of this information is also already included in the README, especially after we merge #4 (e.g. the changes that we made to the bootstrap script are included there).

@bedroge OK, but I think it makes more sense to document the hurdles we ran into in an issue rather than in the README.

The README should focus on things that are still relevant in the current state of things, the problems we ran into are fixed (but we may want to check later what we did). At some point the README will be cleaned up, and it'll be harder to find that info (since it will be hidden in in git history).

So my vote goes to just adding a comment here with the historical info that's now in the README, incl. pointers to the relevant Gentoo bugs or commits, and stripping it out of the README.

I'm just a little bit afraid that this issue is going to be one big mess with all different things we modified / ran into / etc. We could also make an admin page (either in the docs or in a github wiki?) that documents this in a bit more structured way?

@bedroge Given the current README and the work that has been done with Ansible, maybe this can be closed?

Yes, I agree. One thing that might be missing is the changes that we made to the bootstrap script? Or is that documented somewhere?

@bedroge We have a copy of the bootstrap script in the repo, so the git history is the documentation? ;)

Fine with me! :-)