I'm still trying to work out why I have issues starting meetings using the ASF bot. In the mean time, we had a brief meeting earlier today. Here is the transcript:
kishoreg sandeep, i think it will help if you walk us through entire flow 14:06 osgigeek sure 14:06 kishoreg https://cwiki.apache.org/confluence/display/HELIX/API+Redesign+-+Progress 14:07 kishoreg lets use this wiki as starting point. thanks kanak for putting this up 14:07 osgigeek so one think on the wiki which is needs to be called out is what is Model for Helix 14:08 kishoreg correct 14:08 osgigeek that is what I was trying to grasp in that mail by asking questions 14:08 kishoreg yes, thats a good question. we shud finalize that 14:08 osgigeek So like I said a model is the minimum set of entities which help solve a given problem 14:08 osgigeek So lets ask ourselves what problem are we solving 14:08 sj__ has joined (451c9581@gateway/web/freenode/ip.69.28.149.129) 14:08 osgigeek IMO we are trying to solve the problem of cluster definintion, lifecycle management and resource allocation 14:09 osgigeek resource allocation across the cluster 14:09 osgigeek allocation or distribution 14:09 kishoreg correct, but slightly more than resource allocation 14:09 kishoreg resource state assignment 14:09 osgigeek ok so lets add that to our problem statement 14:10 osgigeek i.e. Helix attempt to solve cluster definition, lifecycle management and resource state assignment across the cluster 14:10 osgigeek so then the question is what should constitute a model which solves this problem 14:10 kishoreg what is cluster definition? 14:10 osgigeek the way someone goes about defining a cluster, how many nodes, what resources to allocate, how to partition 14:11 kishoreg ok 14:11 kishoreg lifecycle management ? 14:11 kishoreg start and stop of nodes? 14:11 osgigeek correct, start and stop of cluster, adding nodes or dynamically adding nodes 14:12 osgigeek So then what are the core entities which come to mind 14:13 kishoreg ok 14:13 osgigeek Cluster, Partition, Resource, Members (Participant, etc) 14:13 kishoreg right 14:13 osgigeek I think so far and I can be swayed 14:13 osgigeek that State Machines and Transitions are addendums 14:14 kishoreg agree, i think the question is of State 14:14 osgigeek meaning its an additional layer on top of the model 14:14 kishoreg thats one way to go about it. that they are attributes of the model 14:14 osgigeek The way I would try to make the distinction is if you were to build any clustering system do we need State Machines ? 14:14 osgigeek ok so lets look at State 14:14 kishoreg you definitely need it, 14:15 osgigeek Any entity should have a state 14:15 osgigeek lets figure State first then go to State Machine 14:15 kishoreg you can do it without a state but then you are making implicit assumptions 14:15 osgigeek right correct 14:15 kishoreg yes, any entity can have a state 14:15 osgigeek so I could have a Cluster which is say ACTIVE as soon as I create it 14:15 kishoreg for now we only have state for partition 14:16 osgigeek I could have RESOURCES which are AVAILABLE as soon as I add them 14:16 osgigeek there are implicit states 14:16 kishoreg correct 14:16 kishoreg same with participant 14:16 osgigeek but we can still accomplish clustering with those implicit states 14:16 osgigeek not a very flexible one albeit 14:16 osgigeek nor a very sophisticated one 14:16 kishoreg yes, but i would make them explicit 14:17 kishoreg much easier to reason about 14:17 osgigeek you mean State Machine and Transition or State? 14:17 osgigeek Like we said each entity should have State 14:18 osgigeek so that seems like an attribute on the entities in the model 14:18 osgigeek Then we have State machine which acts on entities and performs state transitions 14:18 kishoreg yes, 14:18 kishoreg agree 14:18 osgigeek without the core model the state machine makes little sense 14:18 osgigeek state of what? transitions on what 14:18 osgigeek which is why I was thinking of it as a layer on top of model 14:19 osgigeek so it might very well be model.statemachine 14:19 osgigeek dont get me wrong 14:19 osgigeek but an extension 14:19 sj__ Having a state model allows you to a have a correct global view of the system 14:19 osgigeek not the core model 14:19 kishoreg osgigeek: that is swaroop another Helix committer 14:19 osgigeek Hi swaroop 14:20 osgigeek nice to e-meet you :) 14:20 sj__ hello btw :-) 14:20 sj__ same here 14:20 kishoreg he knows a lot of internals of Helix 14:20 osgigeek so going back your point, I disagree a bit … having a state model gives a predictable view not necessarily a correct global view 14:21 osgigeek for correct global view the system has to synchronize across all nodes etc 14:21 kishoreg lets take concrete examples 14:21 sj__ by making constraints explicit, you have a chance of converging towards stated ideal state through only legal paths 14:21 sj__ without relying on participants making local decisions 14:21 osgigeek sj__: correct which is why I said predictable 14:22 osgigeek so its a definition which is adhered to 14:22 kishoreg sandeep, you should walk through ur solution end to end 14:22 osgigeek and respected 14:22 kishoreg without interuption from us 14:22 kishoreg and then we will pitch in 14:22 osgigeek So I am thinking we define a model (Cluster, Resource, Partition, Member) 14:22 kishoreg continue from statemachine is a layer on top 14:22 osgigeek then we define a layer on the resources 14:23 osgigeek State machine 14:23 kishoreg ok 14:23 osgigeek State machines act on entities 14:23 osgigeek State Machines have transitions 14:24 osgigeek We will have APIs for defining the models i.e. allow APIs to define the cluster and how it is assembled 14:24 osgigeek Those APIs only define the models and create the core layer, it puts all the ingredients to make a cluster 14:25 osgigeek Then APIs which apply State Machines to each of those entities 14:25 osgigeek We should have APIs which allow events for transitions 14:25 osgigeek so that listeners can be registered 14:26 osgigeek So there is an eventing layer which is a pub-sub model 14:26 osgigeek There will be APIs to query the state of any of the model entities 14:26 kishoreg makes sense 14:26 osgigeek These APIs provide view into what happened when I applied the state model to any of the entities 14:27 osgigeek The query APIs will give the view of the system while it is transitioning 14:27 osgigeek or once all is setup then the resting state of the system 14:27 osgigeek resting state of not just the entire system but more like each entity 14:28 osgigeek The same API which allows defining the assembly of the cluster 14:28 osgigeek then allows users to apply deltas 14:28 osgigeek realignments to the state 14:28 osgigeek these APIs would take rules 14:28 osgigeek So we need a set of classes for rules 14:28 kishoreg yep, i remember vinayak defining something very similar 14:29 osgigeek The rules are either defined during creation or even after creation 14:29 kishoreg we pretty have the same model 14:29 kishoreg we have eventing layer that defines all the events 14:30 kishoreg so controller is just an implementation that handles all the events 14:30 osgigeek yes sorry part of this is me not knowing all the internals and part of this is me doing a layered approach 14:30 kishoreg its designed exactly the way you described 14:30 kishoreg what we have done is mixed model and attributes 14:31 osgigeek right 14:31 kishoreg there is not clear line between the two 14:31 osgigeek that is what I was trying to cleanup 14:31 osgigeek clear the layers 14:31 kishoreg make sense 14:31 osgigeek everything in model should be core 14:31 osgigeek then model.events 14:31 osgigeek then model.statemachine 14:31 osgigeek and so on 14:31 kishoreg but here is the question 14:31 osgigeek sure 14:31 kishoreg how will you model attributes 14:31 kishoreg lets say state and transitions are attributes 14:32 kishoreg we have lot of other attributes like config etc 14:32 osgigeek So I think of state as an attribute on the model entities 14:32 kishoreg how do we define events now 14:32 osgigeek A state machine is a concrete object which acts on an entity 14:32 kishoreg will it be resourceChange Event 14:32 kishoreg or will it be resourceStateChange event 14:32 osgigeek Transitions are triggered off events and move entities across states 14:32 kishoreg resourceConfigChange event 14:33 osgigeek So we have two sets of events here 14:33 osgigeek (1) which makes transition (2) which is resulted because of transition 14:33 osgigeek So resourceConfigChange should cause state transition 14:33 osgigeek resourceStateChange is triggered as a result of that transition 14:34 osgigeek The latter acts as auditable log 14:34 osgigeek if we register listeners which keep track of the transitions 14:35 osgigeek does that make sense? 14:35 kishoreg let me parse that 14:35 osgigeek sure 14:36 osgigeek To supplement and maybe this can help 14:36 osgigeek Think of all changes an Admin makes to be an event on the model 14:36 osgigeek on the core model 14:36 osgigeek That change should trigger a state change, could be remaining in same state or going to a new state 14:37 osgigeek The advantage of an event model it supports both synchronous and asynchronous patterns, we choose how to apply the event 14:37 kishoreg lets say we have X models (cluster, node, resource, partition) and for each model we have Y attributes 14:37 sj__ Kishore, Sandeep - I'm finding it a bit hard to reason about pros/cons. Taking a concrete example would help 14:38 kishoreg sj__, will formulize it soon 14:38 kishoreg its not too different from what we have 14:38 kishoreg sandeep is making the definition crisp 14:38 kishoreg some coming back to X models and Y attributes 14:39 kishoreg will we define X*Y events ? 14:39 osgigeek No we dont have to 14:39 osgigeek We can do something like AttributeChangeEvent(Attribute) 14:39 kishoreg only X listeners ? 14:39 osgigeek Do we have attribute types? 14:40 kishoreg we dont have the concept of attribute now 14:40 osgigeek I am trying to figure what do listeners register to listen for, attributes with a certain scope 14:40 osgigeek ? 14:40 kishoreg thats what we will define shud every one get convinced :) 14:41 kishoreg listeners need to know that an attribute changed 14:41 kishoreg attribute value change 14:41 kanakb also attribute creation/removal 14:41 kishoreg correct, was about to say that 14:41 osgigeek yes but all listeners dont need to know that a specific attribute changed, they should be able to express interest level 14:41 osgigeek right 14:41 kishoreg correct 14:41 osgigeek I dont know enough to say what that level would be 14:42 osgigeek let me give an example 14:42 kishoreg its all possible combinations 14:42 kishoreg especially controller 14:42 osgigeek so controller is interested in all events 14:42 kishoreg participants only need to know of transitions 14:42 osgigeek it can discard events if its not applicable 14:42 osgigeek right 14:42 osgigeek there you go 14:42 osgigeek so we will have TransitionEvent 14:42 kishoreg ok 14:42 osgigeek and Participants should only subscribe to those 14:43 osgigeek they can look at the Event data and decide if they care or not to act 14:43 kanakb participants may also care if their configuration changes 14:43 kishoreg so do roles subscribe to events? 14:43 kanakb especially if it's a user config 14:43 kishoreg yes 14:43 osgigeek what is a role again, sorry lost track of it 14:43 kanakb participant, spectator, controller, admin 14:44 kanakb i believe i added a table on the wiki page 14:44 kanakb defining the role and purpose 14:44 osgigeek yes 14:44 osgigeek so yes roles should subscribe to events 14:44 osgigeek infact event-types 14:44 osgigeek bear with me 14:44 osgigeek event-type == (StateTransitionEvent, ConfigurationChangeEvent) 14:44 osgigeek event == a concrete realization of the event 14:45 osgigeek analogy is class -> instance 14:45 osgigeek event-type -> event 14:46 osgigeek Each event should identify the data it carries so listeners can rely on the data being present. Data is what happened when this event occured 14:46 kishoreg will they be defined at every granularity ? 14:46 osgigeek give me an example of what you mean by granularity 14:46 kishoreg granulairty is resource, partition, 14:46 kishoreg etc 14:47 kishoreg statetransitionevent will it be defined at resource, partition and cluster 14:47 kishoreg or only applicable to a partition 14:47 osgigeek If those entities need to have state transition event then yes, if not we keep it only for partition 14:48 osgigeek I think resource has state transtions 14:48 osgigeek does it not? 14:48 kishoreg no, resource does not have state transitions 14:48 kishoreg ok 14:48 osgigeek ok then it wont generate such an event 14:49 osgigeek Just a heads up I have to head into a meeting at 3 14:49 osgigeek so I have 10 mins 14:49 kanakb no problem 14:49 osgigeek but is this all making sense? 14:50 kanakb somewhat 14:50 osgigeek :) 14:50 osgigeek a somewhat from you is a good start kanakb 14:50 kanakb so i think what we need to address is that 14:50 kanakb some events only make sense at a subset of scopes and are only needed by a subset of roles 14:51 kishoreg yes, 14:51 kanakb and some events might be appropriate everywhere 14:51 kishoreg we can look at the listeners we have 14:51 kishoreg we have one listener for each type 14:51 kishoreg each event* type 14:51 osgigeek If we create a event hieararchy 14:51 osgigeek then listeners can latch on to any level I imagine 14:52 kishoreg yeah, that should be fine 14:52 kishoreg need to be careful about the attributes 14:52 kishoreg some attributes are applicable to all model classes and some are not 14:53 osgigeek Are they all well defined attributes or they are dynamic? 14:53 kishoreg shud be well defined 14:53 osgigeek which is why we can put the applicable to all in a base Model object 14:53 kishoreg and then we have everything else 14:53 kishoreg like idealstate, currentstate, externalview, statemodeldefinition etc 14:54 kishoreg alerts, controller attributes 14:54 osgigeek Alerts are not core model IMO 14:54 kishoreg i think our model is fixed 14:54 kishoreg cluster, resource, node, partition 14:54 osgigeek yes 14:54 osgigeek good 14:55 osgigeek happy to hear that 14:55 kishoreg we now need to fix the attributes 14:55 kishoreg and what shud we call everything else that dont fit in attributes 14:55 osgigeek I think the word 'node' had some problems in the past 14:55 osgigeek so I had offered 'member' 14:55 kishoreg member is fine 14:56 kanakb there's one more wrinkle: how to we distinguish config attributes from runtime attributes 14:56 kishoreg i have used it in the past 14:56 osgigeek ok sorry guys I have to bow out, need to make it to the next meeting 14:56 kanakb ok no problem 14:56 osgigeek I will come back online after 14:56 sj__ I'm a bit hesitant to call state model an attribute of one entity. We won't be able to capture conditional transitions nicely 14:57 osgigeek So I think of State as an attribute, State Model is a separate object in itself encompassing transitions 14:57 osgigeek so I wont say state model is an attribute of entity
