Bug #1517
closedOrder dependent, ambiguous YAML in multi-detect.
Description
Both the tenants and mappings section of multi-detect contain problematic YAML.
For tenants we have:
1. multi-detect: 2. tenants: 3. - tenant: 4. id: 1 5. yaml: somefile.yaml
It is unclear if the "tenant" on line 2 is supposed to be a key with an empty value, or be the parent of "id" and "yaml", which would actually look like:
1. multi-detect: 2. tenants: 3. - tenant: 4. id: 1 5. yaml: somefile.yaml
It is also order dependent, for example the following will fail:
1. multi-detect: 2. tenants: 3. - id: 1 4 tenant: 5. yaml: somefile.yaml
Despite being equivalent when it comes to YAML.
Question: Is the "tenant" keyword necessary here? Could we not just have:
1. multi-detect: 2. tenants: 3. - id: 1 4. yaml: somefile.yaml
Since it is expected that each item in the sequence should be a tenant. Or is the plan to have multiple kinds of tenants? In which case we should probably have a "type" field denoting the type of tenant.
The mappings fields has all the same issues. As the "selector" tells us what the mappings are selecting on, we could probably get by with:
multi-detect: selector: vlan mappings: - vlan-id: 1000 tenant-id: 1
Then when processing the list of mappings, fail if vlan-id is not found. Similarly if a future subnet selector was added, we would fail when handling the list of mappings if a subnet keyword wasn't present. Such a change would make the YAML order independent.
Updated by Victor Julien over 9 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 3.0RC1
Updated by Victor Julien about 9 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100