What To Do Before Configuring prosEO

This page contains information on the steps recommended before starting to configure a mission in prosEO.

Deployment Considerations

There are many different deployment configurations possible for prosEO. The Deployment Guide describes some of them. However before planning a prosEO deployment, a few initial questions need to be answered:

• Deployment in the Cloud or on-site? With a public Cloud deployment, the advantages of e.g. a managed infrastructure or a managed Kubernetes environments may be leveraged, but on the other hand for continual operations a Cloud environment may not be the most cost-effective approach.
• Location of the Docker registry? A Docker registry is required, where all images for the prosEO Control Instance as well as for all processors running on the Processing Facilities can be accessed. A placement in a publicly accessible DMZ will be required for Cloud deployments, whereas for on-site deployments a placement in a secure internal network segment is feasible.
• Sizing: Actually due to the flexibility of (private or public) Cloud-based application systems, sizing is not so much a technical issue as a business issue. Weighing the cost of a deployment in a public Cloud against an on-site deployment requires some understanding of the needed processing power, the data storage requirements (both permanent and transient), and especially the external data transfer volumes (both incoming and outgoing).

Further details on the deployment of a prosEO instance can be found in the Deployment Guide.

Agreeing on Mission Conventions

For the mission configuration itself, some basic conventions are required to be set up beforehand in order to streamline the configuration process:

• Input and output product classes: The names of the product classes (or in some other terminology "product types") for the intended output products as well as for the input and auxiliary products need to be fixed, as these are important for the interface to the processors operated by prosEO. The processors will receive so-called Job Order files, and within these the input and output product "file types" will be referenced by their product class names. If the processors have special requirements as to how these product "file types" must be named, these requirements must be taken into consideration when choosing product class names.
• Processor class names and processor versions: As with product class names the choice of processor class names or version identifiers is not entirely free. The processor class name and processor version will also be forwarded to the processor in the Job Order file, hence they should correspond to the processor name and version expected by the processor.
• Product file naming: A suitable product file naming convention should be agreed early on in the project. prosEO's Production Planner component will generate output product file names for the Job Order file, and a common naming scheme simplifies the configuration of the instructions for file name generation. While it is possible to define different file naming schemes for each product class, it is advisable to cover as many product classes as possible with the default file naming scheme configured for the whole mission.
• Product parameters: prosEO intentionally only defines a limited set of (mandatory) attributes for products. However this will most probably not fulfil the information requirements of any concrete satellite mission, therefore it is possible to add an arbitrary amount of "product parameters" with arbitrary names to each and every product file. The parameters used might even vary between products of the same product class – but this is strongly discouraged for maintainability reasons (it may however happen as parameter sets evolve over time). It is recommended to define a common set of product parameters before integration of the processor (i.e. development of their Wrapper classes) starts, because these parameters need to be extracted from the product files and updated in the metadata database by the processor-specific Wrapper classes.

For more information on how to configure a mission please read:

• Creating and Configuring a Mission
• Writing and Integrating Data Processors

Security Considerations

Some considerations regarding information security are related to the setup of the infrastructure (firewalling, proxying etc.) and are discussed in the Deployment Guide. But on top of these some security configuration at the user level is possible and required. prosEO uses a role-based access control (RBAC) model to separate user areas of concern. This model has two dimensions:

• Functional dimension: Users (or rather user groups) can be assigned privileges to access certain functions of the prosEO application systems, e.g. reading data vs. updating, or restricting access to processing orders, to configuration parameters or to certain user or programming interfaces.
• Data dimension: There are two flavours of usere separation by data accessed in prosEO. One separation takes place at the mission level. prosEO is a multi-mission system, but each mission is fully separated from each other mission with the single (intentional) exception that they all may see and use the same Processing Facilities. All privileges are granted per user or user group and per mission. So a user with manager privileges for one mission may not even be able to login to another mission. The second separation aspect is at the level of products visible on the interfaces (user or programming interfaces). Each product class has a "visibility" associated with it, which may be "PUBLIC", "RESTRICTED" or "INTERNAL", and each of these visibility levels requires a different privilege to access the products of any given class.

These two dimensions of user privilege configuration require some advance planning to ensure a well-balanced set of permissions throughout the system. Further information on this topic including a sample user group setup can be found in Using the Role-based Access Model.