Thanks for adding that :) and Thanks to Nobel for translating my ravings :). Sorry about the acronym. Amusingly I had to look up gish gallop to understand what you meant :) I can assure you that I will never gish gallop you or anyone on the list, and I find such techniques repugnant. If I'm not making sense, I'm likely covering ground too fast, skipping things that are in my head but not yours, expressing too many tangents (when I start nesting parentheses this is (usually) a sign I'm wandering too much), or I am simply mistaken about something. Always feel free to ask me to explain!
-Gus On Sun, Nov 21, 2021 at 12:17 AM Ishan Chattopadhyaya < [email protected]> wrote: > Added both your suggestions to Google Docs for inline commenting and the > SIP document at confluence. Thanks for the feedback. > > On Sun, Nov 21, 2021 at 10:28 AM Ishan Chattopadhyaya < > [email protected]> wrote: > >> I'll add the lifecycle details to the document as well. >> >> On Sun, 21 Nov, 2021, 9:08 am Ishan Chattopadhyaya, < >> [email protected]> wrote: >> >>> Hi Gus, >>> Thanks for bringing it up again. Initially, I wasn't clear what you >>> meant and mistook them for gish gallop. >>> >>> These were the things I am/was confused about (Noble explained it to me >>> what you mean): >>> - adherence to DRY via zk >>> - runtime config info should come from zk >>> - add dynamic features >>> - same interaction patterns for consulting config values. >>> >>> Now, after Noble's help, I think I understand your motivations. >>> - DRY = Don't Repeat Yourself ;-) >>> - You're suggesting that we have a standard way to have role specific >>> configurations (in ZK), so that a new role added later can access the >>> configurations in a standard way >>> >>> This is a very good suggestion, and makes complete sense now. This was >>> definitely a missing piece! >>> >>> Here's a proposal to address that (adding it to Google Docs: >>> https://docs.google.com/document/d/1hijvM1WX9u2TOUdLEkFYVCofLeJlv2MRZqe-ncobJVw/edit >>> ): >>> - Per Role ZNode >>> - Every role's ZNode to hold configuration data (this is the key >>> addition that you're asking for, IIUC) >>> - Children of role ZNodes to be list of ephemeral solr nodes >>> >>> We can iterate over this on the Google Docs (internal representation ZK >>> section) with inline commenting if we need to. >>> >>> Please let us know how that sounds. >>> Regards, >>> Ishan >>> >>> >>> >>> On Sun, Nov 21, 2021 at 4:49 AM Gus Heck <[email protected]> wrote: >>> >>>> It is difficult to track everything in this thread for sure. >>>> Specifically, I don't feel my email of Wed, Nov 17, 7:43 PM (EST) has been >>>> addressed or responded to except for one difference of opinion with Jan on >>>> whether or not we should prohibit the notion of any role ever changing at >>>> runtime. >>>> >>>> Note that I made a specific proposal for an addition to the sip, >>>> regarding start up lifecycle and adherence to DRY via zk, in the (probably >>>> not clearly expressed) hope that we can move to a general overall >>>> application principle that at runtime config info should come from zk. If >>>> we follow such a principle, we will always be in a position to add dynamic >>>> features without significant rework, and all code could hopefully reuse the >>>> same interaction patterns for consulting config values. >>>> >>>> Neither item is addressed in the SIP currently. >>>> >>>> Also I had put that out there as a single item so it could be focused >>>> on (simplifying the discussion I hope), and depending on how discussion >>>> proceeds, I may have other follow on items. >>>> >>>> -Gus >>>> >>>> On Sat, Nov 20, 2021 at 8:45 AM Ishan Chattopadhyaya < >>>> [email protected]> wrote: >>>> >>>>> >>>>> 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] >>>>>> >>>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> http://www.the111shift.com (play) >>>> >>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
