Have multiple targets per service

[GBrawl]

Description of feature

A service should be able to have multiple infrastructure targets, with our current stack-instance model this is not possible, so we'll have to change it.

Purpose of this new feature

Be able to have multiple infrastructure targets

Additional information

We should not take the first one here and take every possible target:

https://github.com/stacklio/stackl/blob/master/stackl/application/handler/stack_handler.py#L52

The current format is like this:

category: items
deleted: false
name: stack-instance
services:
  windows_2019:
    infrastructure_target: aws.brussels.eu-west
    provisioning_parameters:
      key: value
      win_domains:
      - domain_name: nubera.local
        state: domain
    secrets:
      password: PASS
      user: USER
type: stack_instance

We could change it to this:

category: items
deleted: false
name: stack-instance
services:
  windows_2019:
    aws.ireland.eu-west1:
      provisioning_parameters:
        key: value
        win_domains:
          state: domain
      secrets:
        password: PASS
        user: USER
    aws.ireland.eu-west2:
      provisioning_parameters:
        key: value
        win_domains:
          state: domain
      secrets:
        password: PASS
        user: USER
type: stack_instance

[SvenAkk]

This issue is invalid or should be rephrased.

According to the design, a Stack Instance represents a running application (an instantiated stack).
As such, it should not have multiple targets per service. The terminology 'target' is also wrong in this case. For a stack instance, the target is actually a host.

A Stack Template however should have a list of potential placement solutions, i.e., all the suitable targets for a certain service deployment. In this case, the term 'target' does apply, since it is a potential candidate for hosting the service.

Does this makes sense? I've marked the issue invalid for now since I am open to discussion about this in case we would need to change it. Otherwise, we can close this issue.

Addendum: this is unrelated to how we should pick a solution from a ST for creating a SI, which is another topic.

[GBrawl]

How are we going to solve deploying a service HA available then? In the simplest example where we want two VM's on different targets (infrastructure targets in this case, not hosts) for example? Is this something we don't want in Stackl?

[SvenAkk]

We do and after we had talked about it, I made a design proposal and said I did so, but you understandably probably forgot it amidst the other stuff ;-). It is described in the Google Doc OPA Integration ("Services with replicas → service groups")
See there for an example but basically:
"""
Services that should be duplicated are specified to do so in the SAT by the replica policy. This is dealt with in a specific stage between the basic_service_to_target_map and the resulting basic_application_placement_solution_sets which is then further filtered.
""