16:00:29 <adrian_otto> #startmeeting containers
16:00:30 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:34 <openstack> The meeting name has been set to 'containers'
16:00:38 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-11-08_1600_UTC Our Agenda
16:00:42 <adrian_otto> #topic Roll Call
16:00:45 <adrian_otto> Adrian Otto
16:00:48 <jvgrant__> Jaycen Grant
16:00:48 <strigazi> Spyros Trigazis 0/
16:00:50 <Drago> o/
16:01:03 <hongbin> o/
16:01:20 <yatin_> Yatin Karel 0/
16:03:13 <GheRivero> o/
16:03:13 <adrian_otto> hello strigazi jvgrant__ Drago and hongbin and yatin
16:03:37 <adrian_otto> #topic Announcements
16:03:51 <adrian_otto> 1) We have an open proposal for new core reviewers:
16:03:51 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106889.html New Core Reviewers
16:04:07 <adrian_otto> so far it has shown unanimous consent
16:04:30 <stn2> o/
16:04:31 <adrian_otto> I expect to conclude that vote this week
16:04:38 <adrian_otto> hello stn2
16:04:59 <adrian_otto> 2) Reminder: we agreed that there will be no team meeting on 2016-11-22.
16:05:13 <adrian_otto> #topic Review Action Items
16:05:27 <adrian_otto> I have this marked as none, but I'm going to check that to be sure (one moment)
16:06:03 <adrian_otto> 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 <adrian_otto> #topic Blueprints/Bugs/Reviews/Ideas
16:06:37 <Drago> We have an essential blueprint
16:06:53 <Drago> When will it be added to the agenda?
16:06:58 <strigazi> Two
16:07:27 <adrian_otto> one sec
16:07:29 <adrian_otto> ok, there he is
16:07:29 <adrian_otto> 1) #link https://review.openstack.org/389835 Add cluster driver encapsulation spec (randallburt)
16:07:39 <randallburt> sorry. internet problems
16:07:41 <adrian_otto> randallburt: would you like to address this one?
16:08:23 <randallburt> 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 <randallburt> hongbin: would you like to clarify?
16:09:07 <hongbin> 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 <stn2> adrian_otto: hi
16:09:33 <adrian_otto> we don't need consensus for me to vote on a proposal
16:09:42 <hongbin> ok
16:09:42 <randallburt> hongbin:  why? your -2 will prevent it being merged. Folks use the voting mechanism to express their opinions.
16:09:51 <adrian_otto> tht's what we are doing now, we are having a discussion
16:10:17 <hongbin> it is unnormally to vote a +2 without a consensus
16:10:23 <hongbin> that is my feeling
16:10:26 <randallburt> hongbin:  no it isn't
16:10:42 <adrian_otto> +A requires a clear intent from the stakeholders
16:10:45 <adrian_otto> +2 does not
16:10:56 <hongbin> then, this argument is not going to end
16:11:11 <adrian_otto> wait a moment.
16:11:33 <adrian_otto> I think we need to table this discussion, and revisit it after we have an intent to resolve the matter
16:11:54 <adrian_otto> but this is no way to open a community discussion about a new feature
16:11:59 <randallburt> 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 <hongbin> this needs a ML discussion, since obviously, there are not too much attendees in the meeting
16:12:55 <randallburt> hongbin:  fine. I'll also post to the ML asking for feedback.
16:13:04 <adrian_otto> Hongbin, with respect, take a moment
16:13:14 <adrian_otto> I've read all the comments on the thread
16:13:27 <adrian_otto> you have a concern that we are trying to address
16:13:32 <adrian_otto> and you are here now
16:13:51 <Drago> 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 <adrian_otto> so let's explore the nature of the disagreement, and see if we can find a suitable way to address it
16:14:14 <jvgrant__> Drago +1
16:14:36 <swatson> Drago +1
16:15:03 <hongbin> Drago: however, the interface is formally defined, and it is debatable.
16:15:05 <jvgrant__> 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 <hongbin> 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 <Drago> 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 <randallburt> I disagree, the interface is the meat of the spec and should be agreed upon.
16:16:35 <hongbin> Drago: then, the interface should not include anything that is questionable
16:16:37 <randallburt> Drago:  exactly
16:16:51 <adrian_otto> so let's take a step back for a moment and cover some basics
16:17:09 <adrian_otto> is there any reason we should not produce a way for heat to be decoupled from drivers?
16:17:27 <adrian_otto> if not, can we express an agreement about the intent of this work?
16:17:45 <hongbin> what is the agreement?
16:18:03 <randallburt> hongbin:  that we decouple heat from the drivers
16:18:15 <adrian_otto> yes
16:18:16 <hongbin> ok, i agree
16:18:16 <randallburt> regardless of details
16:18:27 <adrian_otto> ok, so we agree on that.
16:18:36 <strigazi> +1
16:18:37 <Drago> adrian_otto: +1 for going through this point-by-point
16:18:39 <jvgrant__> +1
16:18:42 <Drago> +1
16:18:52 <swatson> +1
16:18:57 <adrian_otto> next, I'd like us to spend a moment to think about how we approach change in our community
16:19:07 <adrian_otto> first I will share my own philosophy
16:19:17 <adrian_otto> and we can discuss it as a team
16:19:44 <adrian_otto> I think that Magnum should be iteratively improved over time in small increments with efforts to continually improve
16:20:04 <adrian_otto> this includes merging improvements that are only part of a larger effort
16:20:38 <adrian_otto> 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 <adrian_otto> and our team should keep that vision in mind as we work together to advance toward that vision
16:21:09 <adrian_otto> in general, I ask one question about every patch I review:
16:21:12 <hongbin> 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 <adrian_otto> "Is this advancing us toward our vision, or is it setting us back?"
16:21:50 <adrian_otto> (pausing to respond about specs)
16:22:00 <adrian_otto> a spec is a way to articulate a plan
16:22:23 <adrian_otto> and we make them in order to improve the design of our contributions before they are implemented
16:22:44 <hongbin> however, a spec has to be correct and get general consensus from community
16:22:46 <adrian_otto> I'd like to see discussion on specs to be highly collaborative
16:22:55 <jvgrant__> 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 <randallburt> 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 <Drago> Specs are influenced by implementation and real-world experience
16:23:21 <jvgrant__> Drago: +1
16:23:39 <hongbin> jvgrant__: ok, i understand that. however, a spec should not have something that is questionable. that is my point
16:24:02 <adrian_otto> hongbin: why should a spec be perfect?
16:24:07 <randallburt> 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 <stn2> hongbin: but specs details the usecase, scenarios and implentation details. the specs might be discussed
16:24:44 <hongbin> adrian_otto: a spec might not be perfect, but should not have something that is *questionable*
16:24:45 <jvgrant__> 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 <stn2> spec might not be a perfect one but it can be improved with various thoughts
16:24:55 <randallburt> rather we come to consensus now rather than argue patches for more weeks.
16:25:12 <randallburt> and consensus means "everyone can live with it" not "everyone loves it".
16:25:20 <hongbin> jvgrant__: agree
16:25:27 <adrian_otto> so how about this...
16:25:50 <adrian_otto> the spec is essentially saying, let's take what we do now, and move it one step closer to being decoupled.
16:26:15 <adrian_otto> and hongbin, you are suggesting that the spec should detail an ideal implementation of a driver interface
16:26:23 <hongbin> adrian_otto: disagree, the spec define a driver interface which is brand new
16:26:30 <randallburt> actually, this will decouple us. what it won't do is predict how the interface may be refined in the future
16:26:30 <adrian_otto> I think randallburt's intent is to mirror exactly what happens now as a first step
16:26:54 <randallburt> hongbin:  its not brand new. its almost completely empty classes and moving existing code around
16:27:12 <hongbin> the spec is mirror a heat driver implementation into a generic interface, that is my opinion
16:27:14 <randallburt> hongbin:  its essentially formalizing what the Magnum code does right now today.
16:27:30 <randallburt> hongbin:  that's correct.
16:27:46 <hongbin> then, it is againest to goal to decouple from heat?
16:28:16 <randallburt> 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 <hongbin> from the spec, what i saw is that the interface is not generic enough. it is biased to a certain implementation
16:28:42 <randallburt> hongbin:  then you misunderstood the spec
16:28:47 <adrian_otto> on the subject of state synchronization, it mirrors how magnum currently works
16:28:53 <randallburt> ^^
16:29:06 <hongbin> yes, it mirrors an implementation details
16:29:12 <adrian_otto> and we may design a superior way to address state syncronization
16:29:15 <randallburt> hongbin:  generically
16:29:16 <hongbin> which should not be formally defined in a interface
16:29:30 <jvgrant__> 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 <adrian_otto> but I'm not convinced we need to design that innovation as part of this initial effort
16:29:44 <randallburt> jvgrant__:  +1
16:29:48 <hongbin> maybe my question is why you have to put a poller to an interface. what are the benefis you get
16:29:55 <randallburt> hongbin:  its not a poller
16:30:47 <randallburt> 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 <hongbin> jvgrant__: well, but what are on the interface and what are not is a different story
16:31:19 <randallburt> 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 <adrian_otto> hongbin: why is it important to you to try to solve the state synchronization challenge now?
16:32:21 <hongbin> back to my question, why the statesynchronizer has to be formally defined in an interface? that is my whole point.
16:32:51 <randallburt> hongbin:  because it currently makes sense and mimics the current logic and thereby reduces disruption
16:32:58 <jvgrant__> what is the alternative? Pushing that into each driver?
16:33:00 <Drago> 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 <swatson> Drago +1
16:33:20 <hongbin> 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 <hongbin> the right first step is to include a minimum amount of methods in the interface
16:33:50 <adrian_otto> 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 <hongbin> then, adding something later if it turns out to be
16:34:18 <randallburt> adrian_otto:  s/how/when
16:34:21 <hongbin> adrian_otto: what is the problem to let each drive to solve it individually
16:34:39 <Drago> adrian_otto: I think you might mean, the driver cannot solve it if it's within Magnum
16:34:58 <adrian_otto> because we end up with a system with a higher level of complexity, and less consistent implementation overall.
16:34:59 <randallburt> hongbin:  the driver solves "how" to synchronize state. Magnum decides "when"
16:35:03 <hongbin> 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 <randallburt> hongbin:  that's demonstrably untrue
16:35:41 <hongbin> adrian_otto: disagree, the implementation are the same, the different is whether to implement the interface or not
16:35:42 <randallburt> hongbin:  I think you're solving a different problem
16:35:54 <adrian_otto> Drago: yes, that's what I'm trying to convey.
16:36:58 <randallburt> 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 <hongbin> 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 <randallburt> hongbin:  and if so, then by what mechanism can Magnum guarantee or ensure that the cluster state reflects reality?
16:38:14 <hongbin> this is up to the driver
16:38:28 <randallburt> hongbin:  because if we are to achieve our goal, then Magnum can have no special knowledge of the underlying orchestration mechanism.
16:38:52 <randallburt> hongbin:  so that leaves Magnum with no guarantee the state matches reality?
16:38:53 <adrian_otto> I worry that leaving state syncronization totally up to the driver will lead to race conditions between Magnum and drivers.
16:39:01 <randallburt> ^^
16:39:06 <hongbin> that is the goal i think: magnum should not assume any knowledge of the underlying orchestration system
16:39:38 <hongbin> adrian_otto: could you give an example?
16:39:38 <adrian_otto> Magnum needs a way to check that state is not in a change-in-progress time period.
16:39:52 <randallburt> 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 <adrian_otto> so if you allow magnum to tell the driver "sync state now"
16:40:19 <adrian_otto> and it has confidence that state is in sync after that action, then we address the risk of the race condition.
16:40:39 <hongbin> what race condition in particular?
16:40:46 <randallburt> exactly. Which I am sure is the rational behind the current implementation. Polling is immaterial
16:40:57 <Drago> 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 <randallburt> hongbin:  Magnum trying to do something to a cluster when its doing something else
16:41:21 <randallburt> hongbin:  if you punt that to the driver, other drivers become a lot more complex out of the box
16:41:27 <adrian_otto> Example: prevent magnum from modifying a cluster that's in the process of being deleted.
16:41:46 <adrian_otto> or modifying a cluster that's already being modified in a conflicting way
16:42:15 <adrian_otto> leaving the result in an indeterminate state afterward
16:42:37 <hongbin> adrian_otto: why magnum need to modify a cluster that is in process state?
16:42:46 <hongbin> adrian_otto: is it a user to modify a cluster?
16:42:54 <randallburt> hongbin:  seriously?
16:43:14 <hongbin> what magnum does is just execute what users are requesting
16:43:31 <adrian_otto> say you have two users on the same team who act on the same cluster
16:43:41 <adrian_otto> one does not know what the other has asked for
16:43:41 <randallburt> 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 <randallburt> hongbin:  if Magnum doesn't have confidence in said state, then what's the point?
16:44:19 <hongbin> adrian_otto: ok, then how the state synchronizer can solve this problem?
16:44:50 <randallburt> hongbin:  it makes sure that the cluster state matches the *real* state of the underlying orchestration
16:45:16 <hongbin> adrian_otto: and why the problem cannot be solved in an alternative way?
16:45:27 <adrian_otto> think of it like calling sync() on a filesystem to commit changes to the disk
16:45:35 <randallburt> 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 <adrian_otto> I'm sure it can be solved ina variety of ways
16:45:51 <adrian_otto> let's use the current technique as the first one we try
16:46:02 <adrian_otto> and explore others when we have a reason to
16:46:10 <swatson> adrian_otto +1
16:46:12 <hongbin> 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 <Drago> +1 "use the current technique as the first one we try"
16:46:51 <hongbin> the problem is after the state sysnchronize get in, it suggests to solve the problem in a particular way
16:46:56 <hongbin> it is dangous
16:47:18 <randallburt> hongbin:  only in how you interpret it. It does not, in fact, advocate any strategy whatsoever
16:47:20 <jvgrant__> 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 <adrian_otto> 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 <Drago> I do not think decoupling from heat should be gated on magnum supporting an additional state synchronization mechanism
16:47:59 <hongbin> sure, we need more discussion on this
16:48:23 <adrian_otto> but I ask this of everyone on the team:
16:48:26 <randallburt> I wholeheartedly disagree. It sounds like everyone here agrees on a path forward except for 1 person
16:48:32 <yatin_> adrian_otto, hongbin: +1 Decouple heat, for state sync should wait for further discussion
16:49:02 <randallburt> sorry, I know I'm new here but this is not consensus. Its bike shedding and obstruction.
16:49:02 <yatin_> should see other proposol on state sync and then decide
16:49:03 <adrian_otto> 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 <adrian_otto> hongbin: would you be willing to make a concrete proposal for another approach?
16:50:09 <adrian_otto> and consider the input from our team to decide on the right first steps?
16:50:54 <hongbin> 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 <adrian_otto> that may help illustrate how we can do this better
16:51:41 <hongbin> if magnum is biased on certain approach, that is fine. but we need to know why we biased on this approach
16:51:58 <Drago> Currently Magnum is biased on using Heat too
16:52:17 <hongbin> Drago: but we agreed on decoupling from heat right?
16:52:19 <adrian_otto> ok, do you have availability to revisit this today in #openstack-containers?
16:52:27 <adrian_otto> ^ hongbin
16:52:42 <hongbin> adrian_otto: i can
16:52:47 <adrian_otto> thanks so much
16:53:03 <adrian_otto> our next agenda item is Ocata Blueprints
16:53:04 <Drago> 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 <adrian_otto> we are currently in "Blueprints/Bugs/Reviews/Ideas"
16:53:19 <randallburt> 5 min
16:53:24 <hongbin> Drago: then, remove the poller :)
16:53:38 <randallburt> its. not. a. poller.
16:53:42 <adrian_otto> are there other BP's that the team would like to discuss
16:53:58 <adrian_otto> if not, we'll advance to Ocata Blueprints
16:54:10 <adrian_otto> #topic Ocata Blueprints
16:54:18 <adrian_otto> Which additional blueprints would we like to target for this release?
16:54:27 <adrian_otto> I have one...
16:55:00 <jvgrant__> https://blueprints.launchpad.net/magnum/+spec/template-versioning
16:55:20 <jvgrant__> which is needed by the nodegroup and update blueprints
16:55:40 <Drago> https://blueprints.launchpad.net/magnum/+spec/flatten-attributes
16:55:40 <strigazi> nit: s/update/upgrade :)
16:55:56 <jvgrant__> sorry upgrade :)
16:56:05 <Drago> These two blueprints have specs that are no longer WIP. Please give feedback/vote on them
16:56:32 <vijendar> I have one https://blueprints.launchpad.net/magnum/+spec/docker-authz-plugin
16:57:26 <adrian_otto> jvgrant__: directionally approved https://blueprints.launchpad.net/magnum/+spec/template-versioning for ocata
16:58:32 <adrian_otto> Drago: https://blueprints.launchpad.net/magnum/+spec/flatten-attributes directionally approved for ocata
16:58:40 <swatson> 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 <Drago> adrian_otto: Thanks
16:58:52 <adrian_otto> vijendar: we have an alternate approach for that that I will discuss with you
16:58:56 <strigazi> swatson https://review.openstack.org/395012
16:58:59 <adrian_otto> (auth plugin)
16:59:12 <vijendar> adrian_otto: ok
16:59:26 <adrian_otto> #topic Open Discussion
16:59:30 <adrian_otto> 1 minute remaining, sorry for that
17:00:03 <adrian_otto> Our next meeting will be Tuesday, November 15 at 1600 UTC.
17:00:14 <adrian_otto> thanks for your attendance, and I look forward to follow-up discussion.
17:00:18 <adrian_otto> #endmeeting