16:00:29 #startmeeting containers 16:00:30 Meeting started Tue Nov 8 16:00:29 2016 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:34 The meeting name has been set to 'containers' 16:00:38 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-11-08_1600_UTC Our Agenda 16:00:42 #topic Roll Call 16:00:45 Adrian Otto 16:00:48 Jaycen Grant 16:00:48 Spyros Trigazis 0/ 16:00:50 o/ 16:01:03 o/ 16:01:20 Yatin Karel 0/ 16:03:13 o/ 16:03:13 hello strigazi jvgrant__ Drago and hongbin and yatin 16:03:37 #topic Announcements 16:03:51 1) We have an open proposal for new core reviewers: 16:03:51 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106889.html New Core Reviewers 16:04:07 so far it has shown unanimous consent 16:04:30 o/ 16:04:31 I expect to conclude that vote this week 16:04:38 hello stn2 16:04:59 2) Reminder: we agreed that there will be no team meeting on 2016-11-22. 16:05:13 #topic Review Action Items 16:05:27 I have this marked as none, but I'm going to check that to be sure (one moment) 16:06:03 1) ACTION: adrian_otto to mark our agenda such that the 2016-11-22 meeting will be planned as cancelled. (Status: COMPLETE) 16:06:19 #topic Blueprints/Bugs/Reviews/Ideas 16:06:37 We have an essential blueprint 16:06:53 When will it be added to the agenda? 16:06:58 Two 16:07:27 one sec 16:07:29 ok, there he is 16:07:29 1) #link https://review.openstack.org/389835 Add cluster driver encapsulation spec (randallburt) 16:07:39 sorry. internet problems 16:07:41 randallburt: would you like to address this one? 16:08:23 sure, so Hongbin has argued for a change in spec and more community input. So we're bringing it up here to get people's opinions largely focused around the StateSynchronizer 16:08:51 hongbin: would you like to clarify? 16:09:07 adrian_otto: for this one, i would respectfully request you to remove your +2 first, since there is no consensus to merge this patch so far 16:09:13 adrian_otto: hi 16:09:33 we don't need consensus for me to vote on a proposal 16:09:42 ok 16:09:42 hongbin: why? your -2 will prevent it being merged. Folks use the voting mechanism to express their opinions. 16:09:51 tht's what we are doing now, we are having a discussion 16:10:17 it is unnormally to vote a +2 without a consensus 16:10:23 that is my feeling 16:10:26 hongbin: no it isn't 16:10:42 +A requires a clear intent from the stakeholders 16:10:45 +2 does not 16:10:56 then, this argument is not going to end 16:11:11 wait a moment. 16:11:33 I think we need to table this discussion, and revisit it after we have an intent to resolve the matter 16:11:54 but this is no way to open a community discussion about a new feature 16:11:59 hongbin: yes it is. compromise goes both ways. What I suggest is that everyone here go to the spec and weigh in. Please let us know what you prefer and the majority opinion wins 16:12:36 this needs a ML discussion, since obviously, there are not too much attendees in the meeting 16:12:55 hongbin: fine. I'll also post to the ML asking for feedback. 16:13:04 Hongbin, with respect, take a moment 16:13:14 I've read all the comments on the thread 16:13:27 you have a concern that we are trying to address 16:13:32 and you are here now 16:13:51 Meta-arguments aside, I would like the spec to provide a way to fully decouple Heat. I am less concerned about where exactly the line is drawn on the driver interface right now, since it will change over time as we get a better idea of how the driver interface should really look. 16:13:53 so let's explore the nature of the disagreement, and see if we can find a suitable way to address it 16:14:14 Drago +1 16:14:36 Drago +1 16:15:03 Drago: however, the interface is formally defined, and it is debatable. 16:15:05 i think both portions are important. Ton had a good point in the comments that though related to this spec the interface discussion is well beyond it 16:15:52 I would say put whatever we agreed on this spec and proceed, remove what we disagreed on and discuss it in a separated spec 16:16:00 hongbin: It is, but it is defined by a spec, which can be superseded by further specs. If it were set in stone forever, I would not have the same opinion. 16:16:25 I disagree, the interface is the meat of the spec and should be agreed upon. 16:16:35 Drago: then, the interface should not include anything that is questionable 16:16:37 Drago: exactly 16:16:51 so let's take a step back for a moment and cover some basics 16:17:09 is there any reason we should not produce a way for heat to be decoupled from drivers? 16:17:27 if not, can we express an agreement about the intent of this work? 16:17:45 what is the agreement? 16:18:03 hongbin: that we decouple heat from the drivers 16:18:15 yes 16:18:16 ok, i agree 16:18:16 regardless of details 16:18:27 ok, so we agree on that. 16:18:36 +1 16:18:37 adrian_otto: +1 for going through this point-by-point 16:18:39 +1 16:18:42 +1 16:18:52 +1 16:18:57 next, I'd like us to spend a moment to think about how we approach change in our community 16:19:07 first I will share my own philosophy 16:19:17 and we can discuss it as a team 16:19:44 I think that Magnum should be iteratively improved over time in small increments with efforts to continually improve 16:20:04 this includes merging improvements that are only part of a larger effort 16:20:38 as leaders in our community, we need to provide clarity as to what our long term vision is for the project, and work to agree on what that vision is 16:20:59 and our team should keep that vision in mind as we work together to advance toward that vision 16:21:09 in general, I ask one question about every patch I review: 16:21:12 that might apply to implementation, however, i am not sure about the spec. It is ok to put everything in the spec, although the implenetation can take place step by step 16:21:27 "Is this advancing us toward our vision, or is it setting us back?" 16:21:50 (pausing to respond about specs) 16:22:00 a spec is a way to articulate a plan 16:22:23 and we make them in order to improve the design of our contributions before they are implemented 16:22:44 however, a spec has to be correct and get general consensus from community 16:22:46 I'd like to see discussion on specs to be highly collaborative 16:22:55 hongbin: while i agree in general that specs should be closer to that end vision, they are iterative too. Even on this spec i'm not sure we can come up with a true goal interface when we probably don't completely understand what we need yet 16:22:57 removing the intent kinda neuters the spec IMO, but I'll remove them if they are seen as a barrier. Its kicking cans though. 16:23:11 Specs are influenced by implementation and real-world experience 16:23:21 Drago: +1 16:23:39 jvgrant__: ok, i understand that. however, a spec should not have something that is questionable. that is my point 16:24:02 hongbin: why should a spec be perfect? 16:24:07 right. so I can remove the interface definitions from the spec, but we'll just be back here again when patches start landing 16:24:23 hongbin: but specs details the usecase, scenarios and implentation details. the specs might be discussed 16:24:44 adrian_otto: a spec might not be perfect, but should not have something that is *questionable* 16:24:45 hongbin: agreed, but that is when we need to discuss that point(which is being done) and find out if we have an answer. Ideally we find it, but if not it is ok to realize it will have to iterate in the future. 16:24:51 spec might not be a perfect one but it can be improved with various thoughts 16:24:55 rather we come to consensus now rather than argue patches for more weeks. 16:25:12 and consensus means "everyone can live with it" not "everyone loves it". 16:25:20 jvgrant__: agree 16:25:27 so how about this... 16:25:50 the spec is essentially saying, let's take what we do now, and move it one step closer to being decoupled. 16:26:15 and hongbin, you are suggesting that the spec should detail an ideal implementation of a driver interface 16:26:23 adrian_otto: disagree, the spec define a driver interface which is brand new 16:26:30 actually, this will decouple us. what it won't do is predict how the interface may be refined in the future 16:26:30 I think randallburt's intent is to mirror exactly what happens now as a first step 16:26:54 hongbin: its not brand new. its almost completely empty classes and moving existing code around 16:27:12 the spec is mirror a heat driver implementation into a generic interface, that is my opinion 16:27:14 hongbin: its essentially formalizing what the Magnum code does right now today. 16:27:30 hongbin: that's correct. 16:27:46 then, it is againest to goal to decouple from heat? 16:28:16 hongbin: but it encapsulates all the Heat-specific parts and gets things like stack calls out of Magnum and into the driver with minimal disruption or changes to tested code 16:28:23 from the spec, what i saw is that the interface is not generic enough. it is biased to a certain implementation 16:28:42 hongbin: then you misunderstood the spec 16:28:47 on the subject of state synchronization, it mirrors how magnum currently works 16:28:53 ^^ 16:29:06 yes, it mirrors an implementation details 16:29:12 and we may design a superior way to address state syncronization 16:29:15 hongbin: generically 16:29:16 which should not be formally defined in a interface 16:29:30 that is what i understood from the spec. It was keeping things the same, but now framing everything in a way that decouples heat. It seems like a good step. It does highlight the point that the driver interface needs some attention and i think that will happen as we get real implementations that don't use heat. As we get requirements the driver interface will improve. 16:29:39 but I'm not convinced we need to design that innovation as part of this initial effort 16:29:44 jvgrant__: +1 16:29:48 maybe my question is why you have to put a poller to an interface. what are the benefis you get 16:29:55 hongbin: its not a poller 16:30:47 hongbin: its a class that the driver exposes that knows how to synchronize orchestration state with cluster state. Nothing is in the spec that dictates *how* the driver does that 16:31:01 jvgrant__: well, but what are on the interface and what are not is a different story 16:31:19 now Magnum may not handle that class in the most efficient way yet, but that's a refinement when real-world implementations of other drivers emerge 16:32:06 hongbin: why is it important to you to try to solve the state synchronization challenge now? 16:32:21 back to my question, why the statesynchronizer has to be formally defined in an interface? that is my whole point. 16:32:51 hongbin: because it currently makes sense and mimics the current logic and thereby reduces disruption 16:32:58 what is the alternative? Pushing that into each driver? 16:33:00 I think that we will be dissatisfied on whatever interface we come up with once its implemented, and have to iterate on it regardless. So, my vote is for the spec to outline a refactoring of the functionality that magnum already has and use the additional clarity to guide the better interface in the next spec. 16:33:14 Drago +1 16:33:20 my whole concern is if we puts something that is questionable in the interface (like state synchronizer), after everyone implements it, it is hard to remove later 16:33:42 the right first step is to include a minimum amount of methods in the interface 16:33:50 If we do what randallburt has proposed, the logic for how state is actually synchronized will be within Magnum. If we leave such a mechanism out of the driver interface, then it needs to be individually solved in each driver. 16:33:52 then, adding something later if it turns out to be 16:34:18 adrian_otto: s/how/when 16:34:21 adrian_otto: what is the problem to let each drive to solve it individually 16:34:39 adrian_otto: I think you might mean, the driver cannot solve it if it's within Magnum 16:34:58 because we end up with a system with a higher level of complexity, and less consistent implementation overall. 16:34:59 hongbin: the driver solves "how" to synchronize state. Magnum decides "when" 16:35:03 adrian_otto: in addition, putting the proposed spec didn't solve the problem, it just restrict it to be solved in a way 16:35:26 hongbin: that's demonstrably untrue 16:35:41 adrian_otto: disagree, the implementation are the same, the different is whether to implement the interface or not 16:35:42 hongbin: I think you're solving a different problem 16:35:54 Drago: yes, that's what I'm trying to convey. 16:36:58 hongbin: so to be clear, you'd rather not see a class or method that explicitly asks the driver to synchronize state and leave it up to the driver implementation to do that whenever and however it sees fit? 16:37:15 until now, i don't see a valid rational to enforce everyone to solve the state synchronizing problem in the same interface 16:37:34 hongbin: and if so, then by what mechanism can Magnum guarantee or ensure that the cluster state reflects reality? 16:38:14 this is up to the driver 16:38:28 hongbin: because if we are to achieve our goal, then Magnum can have no special knowledge of the underlying orchestration mechanism. 16:38:52 hongbin: so that leaves Magnum with no guarantee the state matches reality? 16:38:53 I worry that leaving state syncronization totally up to the driver will lead to race conditions between Magnum and drivers. 16:39:01 ^^ 16:39:06 that is the goal i think: magnum should not assume any knowledge of the underlying orchestration system 16:39:38 adrian_otto: could you give an example? 16:39:38 Magnum needs a way to check that state is not in a change-in-progress time period. 16:39:52 hongbin: and this spec does ensure that but it also requires drivers to implement orchestration-specific logic that allows magnum to request state synchronization 16:39:53 so if you allow magnum to tell the driver "sync state now" 16:40:19 and it has confidence that state is in sync after that action, then we address the risk of the race condition. 16:40:39 what race condition in particular? 16:40:46 exactly. Which I am sure is the rational behind the current implementation. Polling is immaterial 16:40:57 Is there any reason that poll_and_check cannot call a method provided by the driver? Because it sounds like the argument really comes down to the driver providing a class that has a poll_and_check method or a method that the current poll_and_check can call 16:41:03 hongbin: Magnum trying to do something to a cluster when its doing something else 16:41:21 hongbin: if you punt that to the driver, other drivers become a lot more complex out of the box 16:41:27 Example: prevent magnum from modifying a cluster that's in the process of being deleted. 16:41:46 or modifying a cluster that's already being modified in a conflicting way 16:42:15 leaving the result in an indeterminate state afterward 16:42:37 adrian_otto: why magnum need to modify a cluster that is in process state? 16:42:46 adrian_otto: is it a user to modify a cluster? 16:42:54 hongbin: seriously? 16:43:14 what magnum does is just execute what users are requesting 16:43:31 say you have two users on the same team who act on the same cluster 16:43:41 one does not know what the other has asked for 16:43:41 hongbin: of course it does, but there are states in which Magnum will refuse to do so because the state of the cluster precludes it. 16:44:10 hongbin: if Magnum doesn't have confidence in said state, then what's the point? 16:44:19 adrian_otto: ok, then how the state synchronizer can solve this problem? 16:44:50 hongbin: it makes sure that the cluster state matches the *real* state of the underlying orchestration 16:45:16 adrian_otto: and why the problem cannot be solved in an alternative way? 16:45:27 think of it like calling sync() on a filesystem to commit changes to the disk 16:45:35 hongbin: the synchronizer class only implements *how* to map orch state to cluster state. Magnum decides *when* it needs to ensure that matches. 16:45:38 I'm sure it can be solved ina variety of ways 16:45:51 let's use the current technique as the first one we try 16:46:02 and explore others when we have a reason to 16:46:10 adrian_otto +1 16:46:12 adrian_otto: yes, i believe it can be solved in many ways as well. then why the state synchronizer is the best way to solve it? 16:46:49 +1 "use the current technique as the first one we try" 16:46:51 the problem is after the state sysnchronize get in, it suggests to solve the problem in a particular way 16:46:56 it is dangous 16:47:18 hongbin: only in how you interpret it. It does not, in fact, advocate any strategy whatsoever 16:47:20 if we have an alternative that is viable, then we should add it to the spec and flesh it out. So far i haven't seen a complete alternative suggested that solves the concerns mentioned 16:47:27 ok, so I'm glad we had this discussion. I have additional clarity now on why you have concerns, hongbin. We should revisit this in our IRC channel and continue to work through the issue together. 16:47:45 I do not think decoupling from heat should be gated on magnum supporting an additional state synchronization mechanism 16:47:59 sure, we need more discussion on this 16:48:23 but I ask this of everyone on the team: 16:48:26 I wholeheartedly disagree. It sounds like everyone here agrees on a path forward except for 1 person 16:48:32 adrian_otto, hongbin: +1 Decouple heat, for state sync should wait for further discussion 16:49:02 sorry, I know I'm new here but this is not consensus. Its bike shedding and obstruction. 16:49:02 should see other proposol on state sync and then decide 16:49:03 I want us to get to the bottom of *why* we disagree, and not march into a deadlock before we reach an agreement 16:49:46 hongbin: would you be willing to make a concrete proposal for another approach? 16:50:09 and consider the input from our team to decide on the right first steps? 16:50:54 adrian_otto: i would argue the problem is not about alternative approach, it is about why magnum is biased on certain approach 16:50:57 that may help illustrate how we can do this better 16:51:41 if magnum is biased on certain approach, that is fine. but we need to know why we biased on this approach 16:51:58 Currently Magnum is biased on using Heat too 16:52:17 Drago: but we agreed on decoupling from heat right? 16:52:19 ok, do you have availability to revisit this today in #openstack-containers? 16:52:27 ^ hongbin 16:52:42 adrian_otto: i can 16:52:47 thanks so much 16:53:03 our next agenda item is Ocata Blueprints 16:53:04 hongbin: My point is that Magnum is biased on multiple things, and we would like to focus on one in this spec. 16:53:17 we are currently in "Blueprints/Bugs/Reviews/Ideas" 16:53:19 5 min 16:53:24 Drago: then, remove the poller :) 16:53:38 its. not. a. poller. 16:53:42 are there other BP's that the team would like to discuss 16:53:58 if not, we'll advance to Ocata Blueprints 16:54:10 #topic Ocata Blueprints 16:54:18 Which additional blueprints would we like to target for this release? 16:54:27 I have one... 16:55:00 https://blueprints.launchpad.net/magnum/+spec/template-versioning 16:55:20 which is needed by the nodegroup and update blueprints 16:55:40 https://blueprints.launchpad.net/magnum/+spec/flatten-attributes 16:55:40 nit: s/update/upgrade :) 16:55:56 sorry upgrade :) 16:56:05 These two blueprints have specs that are no longer WIP. Please give feedback/vote on them 16:56:32 I have one https://blueprints.launchpad.net/magnum/+spec/docker-authz-plugin 16:57:26 jvgrant__: directionally approved https://blueprints.launchpad.net/magnum/+spec/template-versioning for ocata 16:58:32 Drago: https://blueprints.launchpad.net/magnum/+spec/flatten-attributes directionally approved for ocata 16:58:40 The flatten attributes one would get work done for this at the same time: https://blueprints.launchpad.net/magnum/+spec/rename-id-parameter-names 16:58:45 adrian_otto: Thanks 16:58:52 vijendar: we have an alternate approach for that that I will discuss with you 16:58:56 swatson https://review.openstack.org/395012 16:58:59 (auth plugin) 16:59:12 adrian_otto: ok 16:59:26 #topic Open Discussion 16:59:30 1 minute remaining, sorry for that 17:00:03 Our next meeting will be Tuesday, November 15 at 1600 UTC. 17:00:14 thanks for your attendance, and I look forward to follow-up discussion. 17:00:18 #endmeeting