You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tags applied to catalogs or submanifests help us target groupings of computers, but it would be more dynamic and faster for testing or limited rollouts to be able to target one person or one computer
The text was updated successfully, but these errors were encountered:
Introducing the targeting of principal users and serial numbers breaks the caching layer. The cache keys are just variations of the combination of tags. A machine with the same combination of tags will get the cached resources. This works as long as the number of tags is orders of magnitude lower that the number of machines. If we have to reflect the principal user or the serial number in the cache key, we could as well remove the cache.
We can actually address this with conditional items/installable conditions, for both the serial number or primary user use cases, so we don't need special handling above and beyond what we have at this time.
(The convenience for testing and ability to custom-cater a product/version to a specific user/machine was the goals I had in mind, since we'd be capturing many more versions of apps (like e.g. Zoom) than we deploy, and we can facilitate immediate testing by having an approach to fulfilling the request for one user or one machine ready.) The idea of using conditional items/installable conditions above can be the docs for now.
Tags applied to catalogs or submanifests help us target groupings of computers, but it would be more dynamic and faster for testing or limited rollouts to be able to target one person or one computer
The text was updated successfully, but these errors were encountered: