Todo list for AP portal

[MauriceHendrix]

• [x] understand how to start the components & run them together
• [x] decide whether the current jenkins setup on cardiac.nottingham is useful and needs to be kept
• [x] find and move relevant bits from gef work on docker-hub & bitbucket
• [x] split the various components into their own repository?
• [x] create tests using github actions for various components (where possible)
• [x] catch up with security PRs
• [x] redevelop client-direct?
• [x] UI improvements asked for by gary
• [x] ApPredict version info
• [x] Using cmake in dockers

[mirams]

It has been a while, so I could do with a refresher course on what tech/repos the existing portal uses, why ApNimbus-cloud-tech will help and what/where all that is, and what we need to do to get ApNimbus up to the capabilities of the existing one before we swap over!

Have we written all that down somewhere? That would be a good start

[MauriceHendrix]

It has been a while, so I could do with a refresher course on what tech/repos the existing portal uses,

I think it's Java servlets, the "new" client-direct is angular but Gef has always insited it needed replacing.

why ApNimbus-cloud-tech will help

In theory at least it will be easier to deploy somewhere else and it would be possible to deploy multiple instances of the simulation running software making it scale better under lots of use.

and what/where all that is, and what we need to do to get ApNimbus up to the capabilities of the existing one before we swap over!

It's on github, with docker images pushed to docker hub as far as I understand. As far as I understand it's all working except for the client-direct (web front-end). Unfortunately I never quite got to the bottom of what is and isn't in there, something we need to look at once we managed to actually get it running.

Have we written all that down somewhere? That would be a good start

There is a reasonable amount of documentation already https://ap-nimbus.readthedocs.io/en/latest/ bu there are some gaps in my knowledge & understanding most notably on the deployment side of things

[flawmop]

It has been a while, so I could do with a refresher course on what tech/repos the existing portal uses,

I think it's Java servlets, the "new" client-direct is angular but Gef has always insited it needed replacing.

Yeah, all the "legacy" portal is mainly Java, Maven (for building Java bits), MySQL. It invokes ApPredict either natively or via Docker/Singularity. It's separated into components (client or client-direct, business, dose-response, and app) which talk web services to each other.

why ApNimbus-cloud-tech will help

In theory at least it will be easier to deploy somewhere else and it would be possible to deploy multiple instances of the simulation running software making it scale better under lots of use.

ApNimbus jumps on board the cloud, kubernetes, REST and container bandwagons which now seem almost ubiquitous. Having said that - ApNimbus in its current form was really just a working proof-of-concept to see if we could get a ApPredict using cloud/k8s/container. It's tested ok although we never got to try out the scalability side of things using the kubernetes. It'll probably also help ongoing development in a research environment if you use something other than Java!

and what/where all that is, and what we need to do to get ApNimbus up to the capabilities of the existing one before we swap over!

It's on github, with docker images pushed to docker hub as far as I understand. As far as I understand it's all working except for the client-direct (web front-end). Unfortunately I never quite got to the bottom of what is and isn't in there, something we need to look at once we managed to actually get it running.

As mentioned earlier; the current incarnation is a proof-of-concept to test the ideas. Some aspects should be stable (e.g. the ApPredict invocation and monitoring), but other aspects need a lot of improvement. For example, the Angular UI needs replacing or significantly updating; the Mongo data store is almost an off-the-shelf implementation and would probably need a much better design. The kubernetes configuration needs a lot more attention to get it to do what we'd want it to do regarding stability and scaling and CI/CD. The ApNimbus environment also hasn't got any security/authn/authz/automated pIC50 input value element built into it yet, and purposely it has no "business" logic processing - it's just a run-lots-of-ApPredicts application.

Have we written all that down somewhere? That would be a good start

There is a reasonable amount of documentation already https://ap-nimbus.readthedocs.io/en/latest/ bu there are some gaps in my knowledge & understanding most notably on the deployment side of things

[MauriceHendrix]

by the way @flawmop am I right in thinking that the legacy portal doesn't use docker in any way?

[flawmop]

It can do a little bit. app-manager can run dockerised ApPredict, e.g. appredict-no-emulators or appredict-with-emulators, directly - see stuff in https://bitbucket.org/gef_work/ap_predict_online/src/master/app-manager/tools/

[MauriceHendrix]

It can do a little bit. app-manager can run dockerised ApPredict, e.g. appredict-no-emulators or appredict-with-emulators, directly - see stuff in https://bitbucket.org/gef_work/ap_predict_online/src/master/app-manager/tools/

eeuhmm .. ok but is it at the moment? I'm trying to clean up the list of docker images on cardiac.nottingham not sure if I can get rid of these:

REPOSITORY                                  TAG                 IMAGE ID       CREATED         SIZE
chaste-image                                latest              289bb0e7e731   9 months ago    2.78GB
chaste                                      latest              289bb0e7e731   9 months ago    2.78G
datastore                                   latest              e254ce5162dc   23 months ago   77MB
postgres                                    alpine              5239fade3a90   2 years ago     71.9MB
ruby                                        2.4.5               a14928bdfa34   2 years ago     873MB
registry                                    2                   f32a97de94e1   2 years ago     25.8MB

[flawmop]

It might be but can't remember - you'll need to see what prepare.sh is being symlinked to locally. If it's symlinked to prepare_docker.sh then Docker.sh would contain the docker image being run. If it's symlinked to prepare_localfs.sh then it's a locally built ApPredict being run.

You could run a simulation in legacy portal and watch the processes to see if a container or a local ApPredict is started.

I don't think chaste-image and chaste were anything to do with me, and the other stuff looks like stuff that would probably be downloaded by docker again if any were ever run. I wouldn't get rid of registry though - it may be being used to store local images - although whether that's still usable because of the recent failure to run to due to use of an insecure local registry I'm not sure.

[flawmop]

This seems to be completed, so closing.