Newer
Older
.. _ingestion:
Data Ingestion
==============
This section details the data ingestion and later management in the VS.
Redis queues
------------
The central synchronization component in the VS is the redis key-value store.
It provides various queues, which are listened on by the services. For
operators it provides a high-level interface through wich data products can be
registered and managed.
Via the Redis, the ingestion can be triggered and observed. In order to
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
eventually start the preprocessing of a product, its path on the configured
object storage has to be pushed onto the ``preprocess_queue``, as will be
explained in detail in this chapter.
As the Redis store is not publicly accessible from outside of the stack. So to
interact with it, the operator has to run a command from one of the services.
Conveniently, the service running Redis also has the ``redis-cli`` tool
installed that lets users interact with the store.
When doing one off commands, it is maybe more convenient to execute it on a
running service. For this, the ``docker ps`` command can be used to select the
identifier of the running docker container of the redis service.
.. code-block:: bash
container_id=$(docker ps -qf "name=<stack-name>_redis")
With this identifier, a command can be issued:
.. code-block:: bash
docker exec -it $container_id redis-cli ...
When performing more than one command, it can be simpler to open a shell on the
service instead:
.. code-block:: bash
docker exec -it $container_id bash
As the container ID may change (for example when the replica is restarted) it
is better to retrieve it for every command instead of relying on a variable:
.. code-block:: bash
docker exec -it $(docker ps -qf "name=<stack-name>_redis")
For the sake of brevity, the next commands in this chaptere are using either of
the above techniques and will just print the final commands inside the redis
container.
.. note::
For the VS, only the ``List`` and ``Set`` `Redis data types
<https://redis.io/topics/data-types>`_ are really used. ``Sets`` are an
unordered collection of string elements. In VS it is used to denote that an
element is part of a particular group, e.g: being preprocessed, or having
failed registration.
``Lists`` are used as a task queue. It is possible to add items to eithre
end of the queue, but by convention items are pushed on the "left" and
popped from the "right" end of the list resulting in a last-in-first-out
(LIFO) queue. It is entirely possible to push elements to the "right" end
as-well, and an operator may want to do so in order to add an element to be
processed as soon as possible instead of waiting before all other elements
before it are processed.
The full list of available commands can be found for both `Lists
<https://redis.io/commands#list>`_ and `Sets
<https://redis.io/commands#set>`_.
For a more concrete example: the following command finds the container ID of
the redis service replica, and executes a ``redis-cli lpush`` command to add a
new path of an object to preprocess on the ``preprocess_queue``:
.. code-block:: bash
redis-cli lpush preprocess_queue "/data25/OA/PL00/1.0/00/urn:eop:DOVE:MULTISPECTRAL_4m:20180811_081455_1054_3be7/0001/PL00_DOV_MS_L3A_20180811T081455_20180811T081455_TOU_1234_3be7.DIMA.tar"
Usually, with a preprocessor service running and no other items in the
``preprocess_queue`` this value will be immediatly popped from the list and
processed. For the sake of demonstration this command would print the contents
of the ``preprocess_queue``:
.. code-block:: bash
$ redis-cli lrange preprocess_queue 0 -1
/data25/OA/PL00/1.0/00/urn:eop:DOVE:MULTISPECTRAL_4m:20180811_081455_1054_3be7/0001/PL00_DOV_MS_L3A_20180811T081455_20180811T081455_TOU_1234_3be7.DIMA.tar
Now that the product is beeing preprocessed, it should be visible in the
``preprocessing_set``. As the name indicates, this is using the ``Set``
datatype, thus requiring the ``SMEMBERS`` subcommand to list:
.. code-block:: bash
$ redis-cli smembers preprocessing_set 0 -1
/data25/OA/PL00/1.0/00/urn:eop:DOVE:MULTISPECTRAL_4m:20180811_081455_1054_3be7/0001/PL00_DOV_MS_L3A_20180811T081455_20180811T081455_TOU_1234_3be7.DIMA.tar
Once the preprocessing of the product is finished, the preprocessor will remove
the currently worked on path from the ``preprocessing_set`` and add it either
to the ``preprocess-success_set`` or the ``preprocess-failure_set`` depending
on whether the processing succeeded or not. They can be inspected using the
same ``SMEMBERS`` subcommand but either name as parameter.
Additionally, upon success, the preprocessor places the same product path on
the ``register_queue``, where it can be inspected with the following command.
.. code-block:: bash
$ redis-cli lrange register_queue 0 -1
/data25/OA/PL00/1.0/00/urn:eop:DOVE:MULTISPECTRAL_4m:20180811_081455_1054_3be7/0001/PL00_DOV_MS_L3A_20180811T081455_20180811T081455_TOU_1234_3be7.DIMA.tar
If an operator wants to trigger the re-registration of a product only the
product path needs to be pushed to this queue:
.. code-block:: bash
redis-cli lpush register_queue "/data25/OA/PL00/1.0/00/urn:eop:DOVE:MULTISPECTRAL_4m:20180811_081455_1054_3be7/0001/PL00_DOV_MS_L3A_20180811T081455_20180811T081455_TOU_1234_3be7.DIMA.tar"
Very similar to the preprocessing, during the registration the product path is
added to the ``registering_set``, afterwards the path is placed to either the
``register-success_set`` or ``register-failure_set``. Again, these queues or
sets can be inspected by the ``LRANGE`` or ``SMEMBERS`` subcommands.
Sometimes it is necessary to directly interact with the registrar/renderer. The
following section shows what tasks on the registrar can be accomplished.
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
.. warning::
This approach is not recommended for everyday use, as it circumvents the
Redis sets to track what products have been registered and where the
registration failed.
Preprocessing
~~~~~~~~~~~~~
In this section all command examples are assumed to be run from a running
preprocessor container. To open a shell on a preprocessor, the following
command can be used.
.. code-block:: bash
docker exec -it $(docker ps -qf "name=<stack-name>_preprocessor") bash
The preprocessor can be used in two modes. The first (and default mode when
used as a service) is to be run as a daemon: it listens to the Redis queue for
new items, which will be preprocessed one by one. The second mode is to run the
preprocessor in a "one-off" mode: instead of pulling an item from the queue,
it is passed as a command line argument, which is then processed normally.
.. code-block:: bash
python preprocessor.py ... TODO
In this mode, the item will not be placed in the resulting set
(``preprocessing_set``, ``preprocess-success_set``, and
``preprocess-failure_set``).
Registration Handling
~~~~~~~~~~~~~~~~~~~~~
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
For all intents and purposes in this section it is assumed, that the operator
is logged into a shell on the ``registrar`` service. This can be achieved via
the following command (assuming at least one registrar replica is running):
.. code-block:: bash
docker exec -it $(docker ps -qf "name=<stack-name>_registrar") bash
The contents of the shared registrar/renderer database can be managed using
the registrars instance ``manage.py`` script. For brevity, the following bash
alias is assumed:
.. code-block:: bash
alias manage.py='python3 ..../manage.py' # TODO
A collection is a grouping of earth observation products, accessible as a
single entity via various service endpoints. Depending on the configuration,
multiple collections are created when the service is set up. They can be listed
using the ``collection list`` command.
New collections can be created using the ``collection create`` command. This
can refer to a ``Collection Type``, which will restrict the collection in terms
of insertable products: only products of an allowed ``Product Type`` can be
added. Detailed information about the available Collection management commands
can be found in the `CLI documentation <https://docs.eoxserver.org/en/master/users/coverages.html#command-line-interfaces>`__.
Collections can be deleted, without affecting the contained products.
.. warning::
Since the other services have fixed configuration and depend on specific
collection, deleting said collections without a replacement can lead to
service disruptions.
In certain scenarios it may be useful, to add specific products to or exclude
them from a collection. For this, the Product identifier needs to be known. To
find out the Product identifier, either the OpenSearch on an existing
collection or the CLI command ``id list`` can be used.
When the identifier is obtained, the following management command inserts a
product into a collection:
.. code-block:: bash
manage.py collection insert <collection-id> <product-id>
Multiple products can be inserted in one pass by providing more than one
identifier.
The reverse command excludes a product from a collection:
.. code-block:: bash
manage.py collection exclude <collection-id> <product-id>
Again, multiple products can be excluded in a single call.