| 2017-09-27 18:38:29 |
Robie Basak |
bug |
|
|
added bug |
| 2017-09-27 18:38:41 |
Robie Basak |
bug |
|
|
added subscriber Scott Moser |
| 2017-09-27 18:39:11 |
Robie Basak |
bug |
|
|
added subscriber Christopher Townsend |
| 2017-09-27 18:41:00 |
Robie Basak |
description |
The correct way to query simplestreams for a particular thing is:
1. Filter for what you want that should narrow it down. This returns a list.
2. Choose from what you got back to get a single thing. This returns a single thing.
It is incorrect to assume that the output from step 1 is always a single item. This assumption can break in the future when we publish more things that match your filters.
The general form of this problem applies to the general domain of publishing images in a future-proof way, rather than something that only applies to simplestreams.
A hypothetical example:
Many users like that Ubuntu images are "brown", but there is an increasingly growing set of different users who would like Ubuntu images to be "green". Ubuntu decides to cater for this different set of users by now shipping to sets of Ubuntu images, both "brown" and "green".
We would expect to publish the metadata for this using a new key "color" whose value would be either "brown" or "green".
Existing programs that make the incorrect assumption above will immediately break, since they weren't filtering for "color". They used to get one image; now they get two.
A real example:
We hit this with Juju and the publication of HWE images.
To solve this problem, I propose that we publish a new key called "priority", which will be an unsigned integer between 0 and (2^32)-1.
Client programs should then implement step 2 above by sorting by priority from lowest to highest and then returning the first (lowest) entry.
To implement this, just publish every thing with a priority of 1 (it doesn't actually matter). This allows clients to implement this behaviour now. We only need to worry about publishing different priorities as part of a future task when adding a new image dimension. |
The correct way to query simplestreams for a particular thing is:
1. Filter for what you want that should narrow it down. This returns a list.
2. Choose from what you got back to get a single thing. This returns a single thing.
It is incorrect to assume that the output from step 1 is always a single item. This assumption can break in the future when we publish more things that match your filters.
The general form of this problem applies to the general domain of publishing images in a future-proof way, rather than something that only applies to simplestreams.
A hypothetical example:
Many users like that Ubuntu images are "brown", but there is an increasingly growing set of different users who would like Ubuntu images to be "green". Ubuntu decides to cater for this different set of users by now shipping to sets of Ubuntu images, both "brown" and "green".
We would expect to publish the metadata for this using a new key "color" whose value would be either "brown" or "green".
Existing programs that make the incorrect assumption above will immediately break, since they weren't filtering for "color". They used to get one image; now they get two.
A real example:
We hit this with Juju and the publication of HWE images.
Proposed solution:
To solve this problem, I propose that we publish a new key called "priority", which will be an unsigned integer between 0 and (2^32)-1 (inclusive).
Client programs should then implement step 2 above by sorting by priority from lowest to highest and then returning the first (lowest) entry.
Proposed implementation:
To implement this, just publish every thing with a priority of 1 (it doesn't actually matter). This allows clients to implement this behaviour now. We only need to worry about publishing different priorities as part of a future task when adding a new image dimension. |
|
| 2017-11-06 14:15:00 |
Scott Moser |
simplestreams: status |
New |
Confirmed |
|
| 2017-11-06 14:15:03 |
Scott Moser |
simplestreams: importance |
Undecided |
Medium |
|
| 2018-05-10 16:13:15 |
Robie Basak |
bug |
|
|
added subscriber Steve Langasek |
| 2018-05-10 16:16:52 |
Robie Basak |
description |
The correct way to query simplestreams for a particular thing is:
1. Filter for what you want that should narrow it down. This returns a list.
2. Choose from what you got back to get a single thing. This returns a single thing.
It is incorrect to assume that the output from step 1 is always a single item. This assumption can break in the future when we publish more things that match your filters.
The general form of this problem applies to the general domain of publishing images in a future-proof way, rather than something that only applies to simplestreams.
A hypothetical example:
Many users like that Ubuntu images are "brown", but there is an increasingly growing set of different users who would like Ubuntu images to be "green". Ubuntu decides to cater for this different set of users by now shipping to sets of Ubuntu images, both "brown" and "green".
We would expect to publish the metadata for this using a new key "color" whose value would be either "brown" or "green".
Existing programs that make the incorrect assumption above will immediately break, since they weren't filtering for "color". They used to get one image; now they get two.
A real example:
We hit this with Juju and the publication of HWE images.
Proposed solution:
To solve this problem, I propose that we publish a new key called "priority", which will be an unsigned integer between 0 and (2^32)-1 (inclusive).
Client programs should then implement step 2 above by sorting by priority from lowest to highest and then returning the first (lowest) entry.
Proposed implementation:
To implement this, just publish every thing with a priority of 1 (it doesn't actually matter). This allows clients to implement this behaviour now. We only need to worry about publishing different priorities as part of a future task when adding a new image dimension. |
The correct way to query simplestreams for a particular thing is:
1. Filter for what you want that should narrow it down. This returns a list.
2. Choose from what you got back to get a single thing. This returns a single thing.
It is incorrect to assume that the output from step 1 is always a single item. This assumption can break in the future when we publish more things that match your filters.
The general form of this problem applies to the general domain of publishing images in a future-proof way, rather than something that only applies to simplestreams.
A hypothetical example:
Many users like that Ubuntu images are "brown", but there is an increasingly growing set of different users who would like Ubuntu images to be "green". Ubuntu decides to cater for this different set of users by now shipping two sets of Ubuntu images, both "brown" and "green".
We would expect to publish the metadata for this using a new key "color" whose value would be either "brown" or "green".
Existing programs that make the incorrect assumption above will immediately break, since they weren't filtering for "color". They used to get one image; now they get two.
A real example:
We hit this with Juju and the publication of HWE images.
Proposed solution:
To solve this problem, I propose that we publish a new key called "priority", which will be an unsigned integer between 0 and (2^32)-1 (inclusive).
Client programs should then implement step 2 above by sorting by priority from lowest to highest and then returning the first (lowest) entry.
Proposed implementation:
To implement this, just publish every thing with a priority of 1 (it doesn't actually matter). This allows clients to implement this behaviour now. We only need to worry about publishing different priorities as part of a future task when adding a new image dimension. |
|
