Hey, here is the February release!
Thank you all for the feedback on the January meeting. We improved the documentation, improved our cli and made various other contributions!
Release Content
In this release, we focused our efforts on:
- Implemented a new data model.
- Implemented css/template customisation.
- Integrated react in our search page.
- Refactored our cli, making it easier to setup things.
- Integrated S3 extension thanks to your contributions!
- Deployed a new documentation site!
And we fixed various bugs as usual.
What do you need to do?
Try out the release and see if the above features work by following the new InvenioRDM documentation from the beginning (from scratch). This documentation site replaces the previous wiki.
Leave all feedback as comments to this thread using the template below.
## Bugs
## What worked well
## What didn't work well
## Wishes for documentation
1 Like
Bugs
no bugs.
What worked well
The CLI worked great, didn’t give any trouble.
really liked the search page with react.
thumbs up 
for the documentation site
What worked well
So far I have tested the installation process and the preview and I did not find any issue.
Wishes for documentation
I think in new documentation looks clean. I would add some reference information for users, concerning this items:
The user working on this install should now the implication of running this command.
sudo usermod --append --groups docker $USER
Concerning this information:
We usually deploy the RDM in machines that have around 8GB of RAM and at least 4 cores. InvenioRDM can certainly run (for demo purposes) with less, just take into account that you are going to be running between 4 and 8 containers (among them an Elasticsearch container, which is quite demanding).
Probably will need more context, note that will be different if you run invenio with all services installed locally as opposed to running invenio and outsourcing the services, like elasticsearch.
In some cases it is better to specify or suggest the amount of resources needed for development instance, but clearly advise users that a production instances layout ( cpu, memory) will depend in the forecasted data requirements of each instance and institution …
Installation
The new installation method is quite clean, however in a production environment it will be important for admins to be able customize UI_PORT, API_PORT, certificates … so probably a note of advance configuration would need to be created as a part of the installation.
Continuing with testing following documentation from Develop to (including Extensions)
What worked well
All of it I could run a smooth installation. I like the way the invenio-cli is developed to handle different stages in the installation! Nice work.
What didn’t work well
All work well for me!
Wishes for documentation
So if pipenv will be use through the documentation then it should be then specified since the beginning in the section where the installation of the Invenio-cli is done?
In the extension part, cookiercutter creates a default custom-module/views.py file, should be noted in the guide that. The user would need to modified the views.py file to match the documentation so it could quickly look evaluate the example. This is pretty much done in other examples.
Thanks for the feedback!
Our usage of pipenv in invenio-cli should be an implementation detail for the user. That is to say, invenio-cli can be installed using any regular python package installation tool. It uses pipenv under the covers, but doesn’t require installation of invenio-cli via pipenv to be clear. Clarify if I missed the point on that remark 
.
PORT and so on configuration
Indeed. This month we are working on the deployment aspect of the project and we’ll make sure to document these things. This will illustrate the deployment contexts even better.
The user working on this install should now the implication of running this command.
sudo usermod --append --groups docker $USER
What implications would you add here? (apart from the current user now being part of the docker group)
thanks,
Probably users executing this type of command would need to consider security restrictions based on intuitional policy…
Ok, I gave a basic test of the S3 documentation and install using Minion. I was able to upload a file and store it using the Minio S3 bucket, checksums match after upload and downloading the file independently.
There was a typo? in the instructions when referring to the Minion UI I was not able to use the secure endpoint (https://localhost[:9000]/minio) but the http://localhost:9000/minio to create the bucket.
Hi @cfgamboa! Good news, and thanks for testing the S3 implementation!
We will change that part in the docs. My idea on the [] was to specify that the port is optional (terminal CLI style), because it kind of depends on how Minio is deployed (like people could specify another port in the docker-compose files. But I understand it was not specified, will change it, thanks for the test means a lot!
Pablo
@lnielsen here is some screenshots, after successfully changing the theme using the docs.
2 Likes
Hey @mb-wali! That looks very nice! Thanks a lot for your feedback, means really a lot to us!
1 Like
