The more I think about this issue the more I think the Solr-Operator shouldn't be changing CR objects. My understanding of this is that the operator takes it's direction from the CR object and not the other way around. So for the operator to write back to a CR object, even with equivalent values, breaks that contract.
I'll create an issue for this so we can discuss how to handle this. Joel Bernstein http://joelsolr.blogspot.com/ On Tue, Nov 23, 2021 at 1:13 PM Joel Bernstein <joels...@gmail.com> wrote: > A little more testing has shown that the cpu value is only reformatted if > it's a multiple of 1000. > > I'm not sure if the solr-operator can control this or if this part of the > go operator framework. But if it's controllable ideally we would probably > not reformat the cpu. > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > > On Tue, Nov 23, 2021 at 12:14 PM Joel Bernstein <joels...@gmail.com> > wrote: > >> As part of the collections operator we are working on we need to compare >> the value of the collection's cpu resource with the value of the underlying >> SolrCloud cpu resource. What we found is that the SolrCloud cpu resource is >> being formatted by the Solr operator which makes it tricky to do this >> comparison. I believe it's using the following go function to format the >> cpu value. I just wanted to confirm that if we port this logic to java >> we'll be able make this comparison. >> >> // NewMilliQuantity returns a new Quantity representing the given >> // value * 1/1000 in the given format. Note that BinarySI formatting >> // will round fractional values, and will be changed to DecimalSI for >> // values x where (-1 < x < 1) && (x != 0). >> func NewMilliQuantity(value int64, format Format) *Quantity { >> return &Quantity{ >> i: int64Amount{value: value, scale: -3}, >> Format: format, >> } >> } >> >> >> >> >> >> Joel Bernstein >> http://joelsolr.blogspot.com/ >> >
