New server

[SteBaum]

Discussion

This PR is a server started from scratch although it has been inspired by the previous one.

• Switched to python version 3.9 and newer depencies in pyproject.toml.
• The endpoints have been changed.
• The schemas are not identical.

Agreements

• [x] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004.
• [x] I hereby agree to grant TOSIT a copyright license to use my contributions.

[PaulFarault]

Please add tdp-lib as a dependency instead of a requirement if needed.

[SteBaum]

• Created a new endpoint for status which is equivalent to the tdp-lib tdp status show command.
• The add_pagination library automatically joins the 422 error each time we implement it in an endpoint.

[SteBaum]

Removed the methods put and patch in the endpoints services and components since their goal was to update the variables of the service/component and we have now a service/variables and component/variables endpoint. However I would like to have your opinion on that.

[PaulFarault]

• [x] add back the status edition endpoints (PUT /services/{service-id}, same on components)
• [x] most of the body schema that you provide should be transform to schema for query parameters
• [x] GET /services/{service-id} shouldn't return variables, only variables-url. Add a GET /services/{service-id}/variables for this purpose (same for component).
• [x] add a GET /services/{service-id}/schema
• [x] POST on variables should be converted to a PUT
• [x] GET /deployments/{deployment-id} shouldn't return operation text logs

[PaulFarault]

• [x] /api/v1/services/{service_id}/variables should return a dict with variables. No need for pagination.
• [x] /services/{service_id}/schema is called "Get Service Variables".
• [x] /services/{service_id}/components/{component_id}/status-history should return a list.
• [x] What is the use of /services/{service_id}/components/{component_id}/stales as service and components can be edited through their PUT endpoints. You should remove this one and add to_config, to_restart, running_version and configured_version as query parameters of PUT /api/v1/services/{service_id} and /api/v1/services/{service_id}/components/{component_id}. Also id, variables_url and schema_url shouldn't be editable.
• [x] /api/v1/deployments/{deployement_id} should return a dict.

• [ ] Please format the "Discussions" section of your README to make it easier to comment:

  • Split general REST discussions from our endpoints choices. Provide external sources for general REST discussions and eventually some Ambary / tdp server v0.1 refs for the second part.

  • Format each discussion as:

    - bias
    discussion

[PaulFarault]

• [x] /services/{service_id}/schema misses a response sample (null for now).

• [x] We may want to provide navigation url for "items" lists. For example in /api/v1/services.items, instead of returning:

  {
  "items": [
          "hdfs"
      ],
  "total": 1,
  ...
  }

  We could have:

    {
  "items": [
      {
          "id": "hdfs",
          "service_url": "http://.../api/v1/services/hdfs",
      }
      ],
  "total": 1,
  ...
  }

  Same for /api/v1/deployments/{deployement_id}.operations).

• [ ] GET /api/v1/services/{service_id} misses to_config and to_restart, also status is not needed here. It'll be handled by tdp_observability.

• [ ] What is host on GET /api/v1/services/{service_id}/components/{component_id}?

• [x] host should be a parameter on GET /api/v1/services/{service_id}/components/{component_id}/status-history.

• [x] POST /api/v1/deploy why is vars a query parameter?

• [x] I'm not sure why {Operationtype} appears in the path on GET api/v1/operations/{Operationtype} as it is a query parameter.

• [ ] POST /api/v1/plan/dag I'm not sure to understand the use of the options query parameter

• [x] Please check the response schema of the POST /api/v1/plan/... endpoints (will noop, depends_on, ... really needed? Also, it lacks deployment information as it's id).

• [ ] Would be nice to have GET / return a list of URL to all available GET endpoints.

I wonder if:

• we should merge status, services, components and validate groups to configurations.
• GET /deployments/status should be moved to GET /deploy as it is the endpoint that trigger the deploy action.

[SteBaum]

The response_schema for POST /api/v1/plan/... endpoints are almost identical to the result given by tdp-lib

[PaulFarault]

• [ ] I'm not sure if service_id should be returned by GET /api/v1/services/{service_id}/components/{component_id}.
• [ ] Why did you add /get-endpoints ?
• [ ] Response sample are wrong for plan endpoints (deployment is not executed for them, no time should be returned). Also, you can uses the same kind of object schema than for the lib (including an options object).

Also, we should list components available for a service somewhere.

[SteBaum]

The /get-endpoints is an endpoint which justs lists all available endpoints with the GET method

[SteBaum]

I have alos added a test framework which for now only has 3 simple tests, but we will work on that once we start implementing the endpoint functions