Problem
It is not always clear which fleet configuration properties are relevant for cloud fleets and which are relevant for SSH fleets.
This leads users to compose configurations with both cloud and SSH properties.
type: fleet
# SSH properties
ssh_config:
user: "user"
identity_file: /home/user/.ssh/dstack
hosts:
- 127.0.0.1
port: 2261
# Cloud properties
resources:
cpu: 7
memory: 10GB
disk: 15GBIn that case dstack provisions an SSH fleet and ignores the cloud properties silently, which is highly likely to cause misunderstandings. Example:
it completely ignored declared resource request with CPU 7, 10GB RAM and 15GB Volume
Solution
Validate fleet configurations and show errors if cloud and SSH properties are mixed.
Implementation note
This can be implemented by adding validators on top of the existing configuration structure or by rethinking the configuration structure, e.g. moving cloud and SSH properties to different mappings or even introducing different configuration (sub)types for cloud and SSH fleets.
Problem
It is not always clear which fleet configuration properties are relevant for cloud fleets and which are relevant for SSH fleets.
This leads users to compose configurations with both cloud and SSH properties.
In that case
dstackprovisions an SSH fleet and ignores the cloud properties silently, which is highly likely to cause misunderstandings. Example:Solution
Validate fleet configurations and show errors if cloud and SSH properties are mixed.
Implementation note
This can be implemented by adding validators on top of the existing configuration structure or by rethinking the configuration structure, e.g. moving cloud and SSH properties to different mappings or even introducing different configuration (sub)types for cloud and SSH fleets.