---
# System prepended metadata

title: 'SearchPlatform changes:'

---

just follow up on what we talked about:

# SearchPlatform changes:

### Overview
- needs to be able to send a new field `environments`
    - optional field, can be non-exist.
    - meaning platform-manager needs to know:
        - which shop has multiple environment
        - how each environment should be processed
    - Say if we maintain 2 environments for `prodvery`, platform-manager will need to additionally send
        ```
        {
          "environments": [
            {
              "environment_id": "20190712",
              "configuration": {}
            },
            {
              "environment_id": "20190812",
              "configuration": {}
            }
          ]
        }
        ```
        where `configuration` will be picked up by catalog-service.
    - each job is still treated the same as it used to (one job to catalog-service, expects one callback).
        
### Design
TBD by Sam, requirement is we should be able to update `environments` of each store dynamically.

### Potential problems
- if some `environment configuration` contain values that catalog-service cannot process, jobs will fail.
    - Currently we expect the information to be put in manually and we just need to be careful.
- `environment configuration` might have conflicts with other modules within catalog-service (for example, strategy, or elastic_search_host).
    - We leave it for catalog-service to resolve such conflicts, and trust catalog-service to make the right decisions (meaning environment configuration will overwrite everything else)

        
# CatalogService changes:

### Overview
- needs a JobSpliter, splits one job with multiple environments to multiple jobs, each can be picked up by a seperate worker
    - a splited job will be treated as normal jobs, except for:
        - do not do callbacks on each individual splited job
        - will viewed aggregately on monitoring 
- needs to be able to send callback for splited jobs properly
- needs a configuration merger, that merges store_configuration with environment_configuration, for each splitted job.

### Design
TBD by Tony, should not change the way anything works currently

### Potential Problems
- it will be harder to mock production update requests manually, because configuration information is further split.
    - GSD keeps:
        - store -> `es_client:9200/index_alias`
        - store -> strategy
    - platform-manager keeps:
        - store -> environments -> environment configuration
    - catalog-service keeps:
        - base configuration
        - store customized configuration
        - strategy customized configuration
- some optimization could be done, which are not fully considered yet

