16:00:13 <hongbin> #startmeeting containers
16:00:14 <openstack> Meeting started Tue Apr 12 16:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <openstack> The meeting name has been set to 'containers'
16:00:21 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-04-12_1600_UTC Today's agenda
16:00:25 <hongbin> #topic Roll Call
16:00:29 <strigazi> o/ Spyros Trigazis
16:00:31 <muralia_> o/
16:00:34 <juggler> o/
16:00:34 <spn> o/
16:00:36 <wwangqun> o/
16:00:38 <tango> Ton Ngo
16:00:44 <madhuri> o/
16:00:52 <rpothier> o/
16:00:54 <eghobo> o/
16:01:00 <rochaporto> o/
16:01:03 <dane_leblanc> o/
16:01:11 <adrian_otto> Adrian Otto
16:01:29 <askb> o/
16:01:48 <hongbin> Thanks for joining the meeting strigazi muralia_ juggler spn wwangqun tango madhuri rpothier eghobo rochaporto dane_leblanc adrian_otto askb
16:01:55 <hongbin> #topic Announcements
16:02:01 <hongbin> 1. Welcome Eli Qiao to the Magnum core team
16:02:06 <redrobot> o/
16:02:19 <hongbin> eliqiao: welcome
16:02:23 <madhuri> Welcome Eli :)
16:02:30 <tango> Welcome Eli !
16:02:36 <hongbin> 2. TLS feature is not functional right now. We are working hard to fix the problem
16:02:42 <hongbin> #link https://bugs.launchpad.net/magnum/+bug/1568427 The bug report
16:02:43 <openstack> Launchpad bug 1568427 in Magnum "Add subjectAltName back to CSR config" [Critical,Triaged]
16:02:48 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091889.html ML discussion
16:02:57 <juggler> congratulations eliqiao!!
16:03:09 <askb> congrats eliqiao
16:03:14 <hongbin> Basically, the TLS feature is not functioning right now if you pulled the lastest commit
16:03:34 <hongbin> The reason is that there are two depending module are conflicting each other
16:03:42 <hongbin> We are working hard to resolve the issue
16:04:05 <hongbin> For now, I would suggest to disable TLS for development and testing
16:04:17 <hongbin> Any comment for that?
16:05:07 <hongbin> Let me know anytime if there is a concern
16:05:10 <hongbin> #topic Review Action Items
16:05:16 <hongbin> 1. hongbin confirm with OpenStack BoD about the legal implications of DCOS
16:05:22 <hongbin> #link http://lists.openstack.org/pipermail/foundation/2016-April/002326.html An email was sent to OpenStack BoD
16:05:48 <hongbin> Based on the response so far, Magnum contributors are not able to distribute DCOS
16:06:02 <hongbin> Unless MesosSpere gave us premission
16:06:30 <hongbin> The details can be found in the ML provided above
16:06:39 <hongbin> Any comment for that?
16:07:10 <hongbin> 2. hongbin started an ML to discuss adding Chronos to mesos bay
16:07:17 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091835.html
16:07:37 <hongbin> Above is the ML of the discussion
16:07:45 <adrian_otto> the DCOS license is a non starter
16:08:19 <hongbin> adrian_otto: Yes, I believe we are not able to work on that direction until we have the issue resolved
16:08:21 <adrian_otto> because of the way OpenStack is redistributed my numerous parties.
16:09:20 <hongbin> OK. Back to the discussion of adding Chronos to Mesos bay, we have a session for discussing it further later
16:09:33 <hongbin> #topic Plan for design summit topics
16:09:39 <hongbin> #link https://etherpad.openstack.org/p/magnum-newton-design-summit-topics Etherpad collaborating topics for Magnum Newton design summit
16:10:21 <hongbin> In the etherpad, I draft the schedule for 9 sessions.
16:10:44 <hongbin> I would pause for a few minutes for reading the schedule
16:11:07 <hongbin> I am happy to revise it if it doesn't work well
16:11:53 <hongbin> In addition, there is a workroom session, which doesn't have a topic yet
16:12:13 <hongbin> I am thinking of a topic for that session. Just let me know if you have one
16:12:35 <adrian_otto> for the first session on the list (2016-04-27 09:00 - 09:40, Discuss bay driver design) I suggest having written proposal(s) to review prior to that discussion. Otherwise it will not be enough time.
16:12:57 <tango> There is a spec
16:12:57 <muralia_> there is a blueprint being reviewed right now for that
16:13:13 <muralia_> everyone should look at it and add comments
16:13:16 <adrian_otto> are there alternate approaches to that, I mean?
16:13:30 <adrian_otto> what is the discussion about, or is it actually a design session?
16:13:53 <tango> we can pull out from the spec items that need team discussion
16:13:57 <hongbin> I believe we will discuss the proposed spc
16:14:02 <hongbin> s/spc/spec/
16:14:24 <adrian_otto> link to it from the etherpad
16:14:40 <tango> +1
16:14:53 <adrian_otto> So it's "Review Bay Driver Design Spec"
16:14:55 <hongbin> I haven't created the etherpad for each session yet. Will do
16:15:26 <hongbin> sure
16:15:50 <hongbin> Any further comment for the design summit?
16:16:05 <muralia_> looks like all of friday is free
16:16:27 <hongbin> Yes, Friday will discuss what is left over
16:16:48 <rochaporto> on the lifecycle one, the monitoring part is for magnum/bays or for the containers themselves? would be interesting to hear how people are doing monitoring of containers and if there's a common solution we could integrate
16:17:07 <tango> I have a conflict with the session on bay driver
16:17:27 <tango> I can just add my input on the spec review
16:17:47 <hongbin> tango: I can swap the session if you want to attend that one
16:18:27 <tango> I will follow up later
16:18:38 <hongbin> rochaporto: I believe the monitoring is not the focus of that session
16:19:18 <spn> whois
16:19:34 <hongbin> OK. Let's advance topics
16:19:50 <hongbin> Feel free to ping me after for the design summit schedule
16:19:59 <hongbin> #topic Essential Blueprints Review
16:20:06 <hongbin> SKIP until we identify a list of essential blueprints for Newton
16:20:12 <hongbin> #link https://blueprints.launchpad.net/magnum/newton List of blueprints for Newton so far
16:20:20 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:20:27 <hongbin> 1. Re-confirm an AGREED in our last meeting
16:20:33 <hongbin> AGREED: Magnum will leverage Keystone as alternative authentication machnism for k8s (hongbin, 16:49:50)
16:20:55 <hongbin> For summary, in our last meeting, we discussed how to decouple from Barbican
16:21:13 <hongbin> And we reached a AGREED
16:21:34 <hongbin> The agreement seems to be leveraging Keystone as alternative authentication machnism
16:21:50 <hongbin> However, I found  some team members think the different way
16:22:04 <hongbin> (That is after the meeting)
16:22:30 <adrian_otto> storing TLS credentials in keystone instead of Barbican would work regardless of which COE.
16:22:35 <hongbin> In particular, adrian_otto thinks the *keystone approach* we agreed on is to leverage the Keystone /credential API
16:22:49 <adrian_otto> integrating k8s with keystone still leaves the problem unsolved for other COEs
16:23:02 <hongbin> Therefore, I want to re-confirm the AGREED again
16:23:23 <hongbin> adrian_otto: Other COEs can follow the similar approach I believe
16:23:52 <hongbin> adrian_otto: The the /credential proposal, the biggest problem is the disagreement from the Keystone team
16:24:09 <adrian_otto> that assumes that each COE has a pluggable auth scheme that's compatible with Keystone auth
16:24:17 <mvelten> I don't get it, is there a way to store unrelated credentials (like certs) inside Keystone ? or the plan is to integrate keystone auth inside k8s ?
16:24:31 <adrian_otto> yes, please link to the blueprint for the reference
16:24:53 <hongbin> Anyone have the link of the BP?
16:25:01 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store
16:25:06 <mvelten> thx
16:25:24 <adrian_otto> it makes reference to the Keystone credentials store:
16:25:27 <adrian_otto> #link http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#credentials-v3-credentials
16:25:57 <tango> Keystone is an alternative with its own implication, not a replacement, so as long as we document it well, we leave the choice to the users.
16:26:17 <hongbin> tango: ++
16:26:37 <mvelten> Why does the keystone guys object ? according to the linked doc this is exactly our use case ^^
16:26:43 <madhuri> hongbin: What is the disagreement from Keystone team?
16:26:59 <adrian_otto> the motivation here is to allow a cloud operator to deploy multiple magnum conductor instances without depending on Barbican for cert storage.
16:27:07 <hongbin> madhuri: mvelten The Keystone team disagreed on another proposal, not this one
16:27:17 <mvelten> oh ok
16:27:20 <hongbin> OK. Let me clarify
16:27:25 <hongbin> There are two proposal
16:27:26 <adrian_otto> madhuri: the caution was that the credential store does not use encryption to persist the artifact.
16:27:34 <adrian_otto> so you have to do that client side
16:27:46 <hongbin> 1. Leverage Keystone /credential endpoint to store credentials (disagreed by Keystone team)
16:27:47 <adrian_otto> which is called for in the BP
16:28:05 <hongbin> 2. Integrate COEs with Keystone for authenticaiton (what we agreed on)
16:28:24 <adrian_otto> it was not disagreed. If you read carefully they are saying that Barbican is the right place for that, which we are already doing.
16:28:39 <rochaporto> another alternative (which could replace the 'local' one) would be to put them (encrypted) in the magnum db?
16:29:07 <hongbin> rochaporto: Yes, that is also another option
16:29:23 <adrian_otto> rochaporto: yes, that's functionally equivalent to what is currently proposed in the BP
16:29:27 <mvelten> why 1 is disagreed ? the doc even clearly state the cert case
16:29:36 <rochaporto> that would work fine for anyone wanting to try it out (even with multiple controllers), and leave barbican for later
16:29:46 <hongbin> mvelten: I don't know, Keystone team disagreed on the ML
16:29:54 <adrian_otto> read what they wrote.
16:30:05 <mvelten> ok thx will look
16:30:33 <adrian_otto> the fundamental concern is that credential storage is a solved problem in barbican
16:30:33 <hongbin> adrian_otto: If we want to go with #1, we should get an agreement from Keystone team first
16:30:44 <adrian_otto> that's not necessary
16:30:49 <hongbin> adrian_otto: Otherwise, I don't think we should puesue it further
16:31:05 <mvelten> any objection for storing inside the db ? any drawback ?
16:31:57 <adrian_otto> mvelten: operators may have already fortified their keystone environment, but not put the same level of rigor into their magnum environment.
16:32:50 <adrian_otto> hongbin: what are you afraid of? That the credential store will be deprecated in future Keytone versions?
16:33:10 <adrian_otto> by then Barbican adoption should be at the point where this is a total non-issue.
16:33:26 <hongbin> adrian_otto: It is not good to go with a solution that another team disagreed on
16:33:37 <adrian_otto> I think you misunderstood the feedback
16:33:54 <hongbin> adrian_otto: OK, I am happy to re-confirm their feedback
16:34:17 <hongbin> adrian_otto: Could I send a ML to Keystone for clarification?
16:34:18 <adrian_otto> it has to do with the idea that we are even seeking a Barbican alternative
16:34:30 <adrian_otto> which is not a keystone team decision
16:34:34 <tango> We can reconfirm with them:  if we do #1, will they disavow us?
16:34:45 <muralia_> Does keystone v2 support credential storage? Can operators that still use v2 use this feature?
16:35:07 <adrian_otto> muralia_: no, this was introduced in v3
16:36:40 <adrian_otto> this is the exact use case that the keystone credential store was designed for.
16:37:00 <adrian_otto> as long as we are not storing them in plaintext, it's an appropriate fit.
16:37:22 <hongbin> #action hongbin sent a ML to collect opinions from general OpenStack community (including Keystone team) for option #1
16:37:27 <madhuri> Why did they do it when there is barbican for such use case?
16:37:31 <hongbin> Let's push the discussion to ML
16:37:58 <adrian_otto> madhuri: it pre-dates Barbican. It's been there since the Grizzly release.
16:38:00 <mvelten> Since the goal would be to drive magnum usage for people unwilling to deploy Barbican I would vote DB so it also covers people not using v3
16:38:01 <mvelten> ok
16:38:28 <madhuri> mvelten: User has this choice also
16:38:45 <hongbin> 2. Enhance Mesos bay to a DCOS bay (Jay Lau)
16:38:51 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090437.html Discussion in ML
16:38:57 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/mesos-dcos The blueprint
16:39:47 <hongbin> In the ML, there are 3 options mentioned
16:40:21 <hongbin> 1. Directly add Chronos to Mesos bay
16:40:35 <hongbin> 2. Support a configuration hook for users to add Chronos
16:40:55 <hongbin> 3. Separate mesos into two bay type: one for marathon, another for Chronos
16:41:01 <adrian_otto> it sounds like the idea for DCOS and the idea for Chronos have been conflated. What did I miss?
16:41:29 <hongbin> adrian_otto: Chronos is totally open source, DCOS is different
16:42:02 <adrian_otto> I suggest that https://blueprints.launchpad.net/magnum/+spec/mesos-dcos not be approved, due to licensing problems with DCOS.
16:42:21 <adrian_otto> A new blueprint should be started for adding a Chronos framework
16:42:26 <hongbin> No, I haven't approved that one
16:42:40 <hongbin> sure
16:42:59 <tango> +1, for clarity between the two issues
16:43:26 <hongbin> Back to the three options, Kai Qiang, Ton, Adrain mentioned they preferred option #2 in the ML
16:43:38 <hongbin> Egor preferred option #1
16:43:50 <hongbin> I preferred option #1 but OK with option #2
16:44:22 <tango> I have been working on Kube and Swarm framework, and would like to add these as options for Mesos bay.  This is our main use case.
16:44:29 <adrian_otto> As I understand this, the approach depends on the intended use case. If you want Chronos as a plugin to Marathon, or as a framework in Marathon.
16:44:33 <hongbin> #action hongbin created another BP for adding Chronos to mesos
16:44:44 <adrian_otto> I don't have clarity on which users have asked for.
16:45:17 <mvelten> I would be in favor to implement 1 now (mainly because nearly everybody does chronos+marathon), and think about how to abstract Mesos frameworks installation in a second part.
16:45:18 <adrian_otto> s/framework in Marathon/framework in Mesos/
16:46:21 <mvelten> for the standalone chronos vs chronos on top of Marathon no preference for me
16:46:22 <adrian_otto> mvelten: what evidence can we cite that indicates that chronos+marathon is the most common use of Mesos?
16:47:06 <adrian_otto> it might make sense to ask in the context of the Mesos community what we should aim for.
16:48:00 <eghobo> adrian_otto: https://mesosphere.github.io/marathon/
16:49:08 <adrian_otto> excerpt from the link above "Marathon is a powerful way to run other Mesos frameworks: in this case, https://github.com/mesos/chronos."
16:49:11 <eghobo> even Mesosphere folks recommend it, also for user it doesn't matter at all (the same ui/rest interface), it's less headache for operatrors
16:49:24 <adrian_otto> that's the POV I was considering when indicating my preference for #2.
16:49:47 <eghobo> Marathon cannot run "cron" like jobs
16:50:08 <mvelten> I have no source, but if you want to launch batch jobs and not only long running services you need both. Chronos on top of Marathon is fine but I would still deploy it by default.
16:50:24 <eghobo> but for example Aurora can and user use just Aurora
16:50:45 <adrian_otto> ok, so they are not expected to ever conflict with eachother, because they are commonly used together.
16:51:32 <eghobo> mvelten: if you doing just ETL you can use just Chronos
16:51:32 <mvelten> eghobo: +1 I would also be fine with replacing both with Aurora
16:51:43 <adrian_otto> my concern is not to burden the Magnum dev team with a significant system integration chore each time a new version of Chronos or Marathon is released.
16:52:02 <eghobo> adrian_otto: i deployed it this way, last week. so far so good
16:52:36 <adrian_otto> eghobo: using Chronos run by Marathon?
16:53:03 <eghobo> adrian_otto: yes
16:53:06 <adrian_otto> ok
16:53:16 <hongbin> OK, could we reach an agreement in this topic?
16:53:42 <hongbin> Or we need a vote?
16:53:59 <tango> It sounds like if we do #1, eventually we will need #2 anyway?
16:54:31 <hongbin> OK. This is controveral topic. Let's have a vote
16:54:41 <hongbin> #startvote
16:54:41 <openstack> Unable to parse vote topic and options.
16:55:15 <tango> We don't have all the team members here
16:55:17 <adrian_otto> seems to me that using Marathon to run Chronos will cause it to be more resilient than running it directly on Mesos
16:55:24 <hongbin> #startvote Choose an option to add chronos to mesos bay? option 1, option 2
16:55:25 <openstack> Begin voting on: Choose an option to add chronos to mesos bay? Valid vote options are option, 1, option, 2.
16:55:26 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
16:55:27 <mvelten> I still don know what to vote :) I am for 1 now but 2 ultimately
16:55:36 <hongbin> #vote option 1
16:55:37 <openstack> hongbin: option 1 is not a valid option. Valid options are option, 1, option, 2.
16:55:43 <hongbin> #vote 1
16:56:32 <mvelten> #vote 1
16:56:35 <hongbin> mvelten: We voted for what to do for now (1 or 2)
16:57:00 <hongbin> Everyone can vote, but I will count the vote from core team (others for reference)
16:57:11 <adrian_otto> I have not heard counter arguments to using Marathon to run Chronos.
16:57:20 <adrian_otto> so I think a vote is premature
16:57:42 <hongbin> adrian_otto: I can push the vote to the next meeting if you want
16:57:55 <adrian_otto> I move that we table this
16:58:02 <hongbin> #endvote
16:58:03 <openstack> Voted on "Choose an option to add chronos to mesos bay?" Results are
16:58:04 <muralia_> yes please.
16:58:05 <openstack> 1 (2): hongbin, mvelten
16:58:20 <hongbin> #topic Open Discussion
17:00:11 <hongbin> Time up. Thanks all for joining hte meeting
17:00:17 <hongbin> #endmeeting