On Fri, 19 Nov, 2021, 7:03 pm Ilan Ginzburg, <[email protected]> wrote:
> Is the request here for everybody to express again the concerns > already expressed in this email thread and not addressed? > I think the expectation now (after we've expressed our intention to reach a lazy consensus) is that if someone wants to block this SIP from adoption, then to put forward the objections. Sort of like a veto. > > I suggest instead the authors review the thread, match expressed > concerns with how the concern was addressed (or not addressed) and > provide an exhaustive list. > I've summarized most of the discussion in the SIP document. If you feel I could do a better job with it, please help me with areas of improvement. > > This proposal in its current form (data and overseer roles) doesn't > offer much that can't be reasonably achieved by other means. I'd find > much more value in making sure what is done now is a solid foundation > for the future. > Fair enough, I understand your perspective. Thanks for your feedback. > > Ilan > > On Thu, Nov 18, 2021 at 11:24 PM Noble Paul <[email protected]> wrote: > > > > After so many back and forth mails, I just can't say who has an > outstanding concern and if they are already addressed or not. I think the > Google doc would help us get clarity on that. Please take a moment to give > your inputs > > > > On Fri, Nov 19, 2021, 9:18 AM Ishan Chattopadhyaya < > [email protected]> wrote: > >> > >> Apologies, the vote hasn't passed formally and I was under some > confusion on the process. > >> > >> I'd like to proceed with a lazy consensus and proceed to the > implementation phase now. > >> > >> However, I would appreciate it if someone wants to bring out any > outstanding concerns about the SIP document. > >> > >> To facilitate in-line comments, here's a temporary Google Docs version > of this document. > >> > https://docs.google.com/document/d/1hijvM1WX9u2TOUdLEkFYVCofLeJlv2MRZqe-ncobJVw/edit?usp=sharing > >> (I shall copy changes back to confluence eventually) > >> > >> Thanks and apologies again regarding the confusion with the voting, > >> Regards, > >> Ishan > >> > >> On Thu, Nov 18, 2021 at 9:50 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >>> > >>> The SIP passed the voting phase. Thanks for all for the feedback and > insights. > >>> Looking forward to your collaboration and reviews as we implement this. > >>> > >>> On Thu, Nov 18, 2021 at 9:42 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >>>> > >>>> > It's fine if we don't provide any ability for runtime modification > of roles at this time but I'm leery of precluding it in the future. > >>>> > >>>> In future, the necessity for such a facility can dictate our course > of action. We cannot lay down rules cast in stone for functionality that we > can't foresee yet. > >>>> > >>>> On Thu, Nov 18, 2021 at 9:40 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >>>>> > >>>>> Thanks Jan, I added both those points to the SIP document in the > Notes section. > >>>>> > >>>>> On Thu, Nov 18, 2021 at 7:18 PM Jan Høydahl <[email protected]> > wrote: > >>>>>> > >>>>>> 18. nov. 2021 kl. 01:43 skrev Gus Heck <[email protected]>: > >>>>>> > >>>>>> > >>>>>> 2) Roles will not be checked by loading config from disk or caching > disk config in memory. (zk ONLY source of truth) > >>>>>> > >>>>>> > >>>>>> It sounds a bit backward for a local node to first parse > solr.node.roles, determine its local set of roles, then publish them to > Zookeeper, and then read back its own roles from ZK. > >>>>>> Code that only needs to determine "Do I have the XXX role?" or find > out "What roles do I have" should be able to fetch the (static) roles from > some roles utility class without consulting ZK. > >>>>>> Code that needs to check what nodes have a certain role (such as > placement) would obviously need ot consult ZK. > >>>>>> > >>>>>> Perhaps the SIP should also state some Non-goals or assertions such > as > >>>>>> * Roles are static and immutable (also in zk) for the entire life > cycle of a node > >>>>>> > >>>>>> I also think we should state that the bar for adding new roles > should be high so it is not abused as any other tag or label for any tiny > feature. It should be reserved for functionality that may benefit from a > dedicated set of nodes. That may be clear already, but you never know... > >>>>>> > >>>>>> Jan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
