4. Resource version is not guaranteed to be an integer Big gotcha.. our datatable for storing resourceVersion was using unsigned integer.
Thanks for the insight On Tue, 22 Nov 2016 at 02:48 Clayton Coleman <[email protected]> wrote: The original guarantees we provided were that 1. Resource version is guaranteed to be unique (as a string) across all instances returned by a LIST or WATCH. * this does not mean that the value for each is going to be a unique, increasing integer - if we add sharding in the future the resource version might be "shard1:34986534" 2. Resource version is guaranteed to be different if the object changes 3. Resource version is not guaranteed to be unique across resource types or different clusters 4. Resource version is not guaranteed to be an integer 5. Resource version is not guaranteed to increment (likely, just not guaranteed) 6. Resource version of an object, given to WATCH, is guaranteed to show changes that occur after the version you saw (after the resource version) If you have to cheat, expect that it may be broken in the future (especially if we end up doing sharding) On Wed, Nov 9, 2016 at 5:38 PM, Andrew Lau <[email protected]> wrote: Cluster wide or per namespace? Using the case scenario of watching every project quota across the entire cluster. On Thu, 10 Nov 2016 at 09:34 Jordan Liggitt <[email protected]> wrote: Not guaranteed unique across resource types > On Nov 9, 2016, at 1:58 PM, Andrew Lau <[email protected]> wrote: > > Is the resourceVersion unique across the whole cluster or just for the particular resource? > _______________________________________________ > users mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users _______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
