|
4 | 4 | Configuration |
5 | 5 | ************* |
6 | 6 |
|
| 7 | +Configuring a run with S3 data |
| 8 | +------------------------------ |
7 | 9 |
|
| 10 | +As a standalone application, PyActiveStorage does not need any configuration, data being |
| 11 | +supplied directly to the ``Active`` class; however, some configuration is still needed to be |
| 12 | +able to access an S3 bucket. |
| 13 | + |
| 14 | +For an example, suppose we are trying to access a file ``ch330a.pc19790301-def.nc`` on CEDA-JASMIN's S3 storage, |
| 15 | +for which one needs to supply ``Active`` the ``storage_options`` dictionary: |
| 16 | + |
| 17 | +.. code-block:: bash |
| 18 | +
|
| 19 | + storage_options = { |
| 20 | + 'key': "key.string", |
| 21 | + 'secret': "sercret.string", |
| 22 | + 'client_kwargs': {'endpoint_url': "https://uor-aces-o.s3-ext.jc.rl.ac.uk"}, |
| 23 | + } |
| 24 | +
|
| 25 | +where ``key.string`` and ``secret.string`` are the key and secret strings needed to access the ``S3_BUCKET`` S3 bucket. Then, |
| 26 | +the call to ``Active`` is: |
| 27 | + |
| 28 | +.. code-block:: bash |
| 29 | +
|
| 30 | + active = Active("S3_BUCKET/ch330a.pc19790301-def.nc", ncvar='UM_m01s16i202_vn1106', |
| 31 | + storage_options=storage_options, |
| 32 | + active_storage_url="https://reductionist.jasmin.ac.uk/") |
| 33 | +
|
| 34 | +Note that the `<https://reductionist.jasmin.ac.uk/>`_ specified here is the Reductionist server deployed |
| 35 | +on CEDA-JASMIN. |
| 36 | + |
| 37 | +Configuring a Reductionist deployment |
| 38 | +------------------------------------- |
| 39 | + |
| 40 | +A few points on how to deploy `Reductionist <https://github.com/stackhpc/reductionist-rs>`_ on a Rocky9 cloud machine: |
| 41 | + |
| 42 | +* 99% of the deployment documentation is found in `Reductionist's nice deployment instructions <https://stackhpc.github.io/reductionist-rs/deployment/>`_ |
| 43 | +* there are a few caveats specific to a pristine Rocky9 (and other distros) deployment though: |
| 44 | +* (n00b step) always have a system ``pip`` by installing it with: ``python -m ensurepip --upgrade`` |
| 45 | +* system Python executable is ``python3`` - you can, of course, ``ln -s`` it to ``python``, or, better, run Ansible pointing it to the correct system Python3: |
| 46 | + |
| 47 | +.. code-block:: bash |
| 48 | +
|
| 49 | + ansible-playbook -i reductionist-rs/deployment/inventory reductionist-rs/deployment/site.yml -e 'ansible_python_interpreter=/usr/bin/python3' |
| 50 | +
|
| 51 | +* that call *may result* (as in our case) in an error: |
| 52 | + |
| 53 | +.. code-block:: bash |
| 54 | +
|
| 55 | + TASK [Ensure step RPM is installed] **************************************************************************************************** |
| 56 | + fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to validate GPG signature for step-cli-0.24.4-1.x86_64: Package step-cli_0.24.4_amd643z16ickc.rpm is not signed"} |
| 57 | +
|
| 58 | +that's because, in our case, we missed the ``step-cli`` package, and a ``dfn`` install is not well liked by the system (it's not ``mamba`` business); |
| 59 | +that gets sorted out via `Step's install docs <https://smallstep.com/docs/step-cli/installation>`_: |
| 60 | + |
| 61 | +.. code-block:: bash |
| 62 | +
|
| 63 | + wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm |
| 64 | + sudo rpm -i step-cli_amd64.rpm |
0 commit comments