16:03:03 <adrian_otto> #startmeeting containers
16:03:04 <openstack> Meeting started Tue Jan 19 16:03:03 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:03:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:07 <openstack> The meeting name has been set to 'containers'
16:03:11 <adrian_otto> #lin https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-01-19_1600_UTC Our Agenda
16:03:15 <adrian_otto> #topic Roll Call
16:03:17 <adrian_otto> Adrian Otto
16:03:19 <madhuri> o/
16:03:24 <rods> o/
16:03:25 <wanghua> o/
16:03:26 <Tango> Ton Ngo
16:03:26 <houming> o/
16:03:26 <Kennan_> o/
16:03:27 <rpothier> o/
16:03:27 <bunting> o/
16:03:28 <HimanshuGarg> o/
16:03:30 <muralia> o/
16:03:33 <hongbin> o/
16:03:34 <sew1> o/
16:03:42 <wangqun> o/
16:03:45 <coreyob> o/
16:03:56 <eghobo> o/
16:04:08 <bradjones> o/
16:04:26 <adrian_otto> hello madhuri, rods, wanghua, Tango, houming, Kennan_, rpothier, bunting, HimanshuGarg, muralia, hongbin, sew1, wangqun, coreyob, eghobo, and bradjones
16:04:31 <juggler> o/
16:04:47 <adrian_otto> hello juggler
16:04:48 <thomasem> o/
16:04:49 <tcammann> hello
16:05:05 <juggler> hello all
16:05:09 <adrian_otto> hello thomasem and tcammann. Glad to have you all here. Let's begin.
16:05:15 <levi_b> o/
16:05:16 <thomasem> hihi
16:05:17 <adrian_otto> #topic Announcements
16:05:24 <adrian_otto> 1) Midcycle
16:05:39 <adrian_otto> we have selected dates. Feb 18-19, hosted by HP
16:05:46 <tcammann> HPE!
16:05:49 <adrian_otto> HPE
16:05:57 <adrian_otto> my apaologies for the abbreviation
16:06:08 <Kennan_> what's HPE?
16:06:18 <eghobo> is it in Sunnyvale?
16:06:27 <tcammann> :D We renamed to HPE, we split HP
16:06:44 <tcammann> Sunnyvale is the plan, I'm trying to book a room at the moment
16:06:53 <adrian_otto> tcammann and I will be working on the exact logistics, but please save the date.
16:07:07 <adrian_otto> I will email a reply to the date coordination thread indicating the selection
16:07:45 <adrian_otto> we will revisit topic selection soon
16:07:54 <adrian_otto> if you have a topic, keep it handy
16:08:21 <adrian_otto> any announcements from team members?
16:08:24 <ttx> adrian_otto: I had a request to align the release model to cycle-with-intermediary (since you want to do a "mitaka" release afaik)
16:08:29 <ttx> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html
16:08:43 <ttx> must be proposed this week at the latest
16:08:57 <ttx> so I figured I would give you a heads-up
16:08:59 <adrian_otto> ttx, yes, thanks. I need to get the review in to toggle that over, or if someone has already done it, I'm happy to cast a vote on it.
16:09:09 <ttx> nobody did it yet
16:09:09 <adrian_otto> we agreed as a team to proceed.
16:09:24 <adrian_otto> ok, I'll plan to wrap that up today.
16:09:28 <ttx> thx!
16:09:31 <adrian_otto> np!
16:09:45 <adrian_otto> ok, let's advance topics
16:09:53 <adrian_otto> #topic Review Action Items
16:10:02 <adrian_otto> 1) #link https://review.openstack.org/#/c/268852/ spec for trust (wanghua)
16:10:17 <adrian_otto> wanghua: status on this item?
16:10:42 <wanghua> I think we need a discussion about this bp
16:11:10 <wanghua> It is a feature needed by many bps
16:12:08 <wanghua> We need to make a decision
16:12:17 <adrian_otto> ok, that might require a bit more time than we have today. Our options are to begin my ML, and then follow up by IRC, or schedule a meeting dedicated to this topic. What are your thoughts on this?
16:13:02 <muralia> we should do a ML discussion. that gives me time to think about it and reply
16:13:27 <adrian_otto> seems there is already thoughtful discussion on that spec review
16:14:00 <adrian_otto> wanghua: what question would you like the team to answer?
16:14:10 <adrian_otto> is this a matter of how to implement?
16:14:18 <wanghua> yes
16:14:25 <adrian_otto> I don't see a controversy over whether this should be done or not
16:14:33 <coreyob> I do o/
16:14:50 <adrian_otto> ok, let's focus energy on the review comments, and get our respective POV's there for consideration
16:15:11 <adrian_otto> and I'm happy to put a follow-up into next week's agenda if we feel we need a discussion as well
16:15:15 <Kennan_> wanghua  do you want to replace access info (for example load balancer) to something else?
16:15:39 <Kennan_> I did not check that details, maybe need some time to review it
16:16:02 <adrian_otto> ok, so let's table this for today, and continue in the review comments, and in #openstack-containers
16:16:13 <adrian_otto> we'll get a good plan together.
16:16:23 <wanghua> ok
16:16:37 <adrian_otto> we are still in action item review. Next one is:
16:16:39 <adrian_otto> 2) #link https://review.openstack.org/#/c/265057/ spec for volume integration (Kennan)
16:16:49 <adrian_otto> Kennan_: remarks on this one?
16:16:56 <Kennan_> yes adrian_otto
16:17:13 <Kennan_> I have replied manye comments, but no new comments input, and no review progress yet
16:17:23 <Kennan_> s/manye/many
16:17:46 <Kennan_> I want to collect more inputs, and make sure we move that
16:17:54 <Kennan_> adrian_otto :)
16:17:55 <adrian_otto> I remember seeing a remark on this last night
16:18:13 <adrian_otto> about not needing a volume on the master node because it's not running a docker daemon
16:18:27 <Kennan_> no adrian_otto:
16:18:37 <Kennan_> it not same review items
16:18:42 <Kennan_> it seems another item
16:18:53 <Kennan_> it seems docker storage configruation
16:18:56 <adrian_otto> ok, so reviewers, please take a moment to review https://review.openstack.org/#/c/265057/ (myself included) at your earliest convenience
16:19:00 <Kennan_> not related with this one
16:19:10 <adrian_otto> ok, got it Kennan_, thanks.
16:19:19 <Kennan_> Thanks adrian_otto
16:19:51 <adrian_otto> ok, so the action items here are actually complete, and the reeust for both is for our reviewers to offer additional input on those reviews.
16:19:59 <adrian_otto> that concludes action item review.
16:20:49 <adrian_otto> the networking subteam is merging back into the main group again, so I will be dropping the subteam updates from the regular agenda going forward.
16:21:03 <adrian_otto> #topic Magnum UI Subteam Update (bradjones)
16:21:10 <bradjones> hi all
16:21:28 <bradjones> there is one last important bp which is still yet to merge
16:21:30 <bradjones> https://review.openstack.org/#/c/235620/
16:21:34 <juggler> hey bradjones
16:21:37 <bradjones> which is bay model create
16:21:57 <bradjones> there is a comment on current patch which between Shu & myself will be addressed shortly
16:22:08 <bradjones> will be great to get that merged as soon as new patch is out though
16:22:21 <bradjones> I'm going to spend a bit of time doing some bug management today too
16:22:23 <adrian_otto> that one ended up being a pretty big patch
16:22:26 <Tango> Looks great
16:22:38 <Kennan_> bradjones I would like to try that tomorrow if time is OK, good feature I think
16:22:50 <bradjones> as there are a few issues which have no movement on and look like they need fixing
16:22:59 <bradjones> Kennan_: great will try to get something out before then
16:22:59 <adrian_otto> thanks bradjones for all that work
16:23:33 <bradjones> adrian_otto: no worries, that's all from me
16:23:41 <adrian_otto> thanks bradjones
16:23:53 <adrian_otto> #topic Essential Blueprint Updates
16:24:24 <adrian_otto> #link https://blueprints.launchpad.net/magnum/mitaka Our Mitaka Blueprints
16:24:58 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/magnum-tempest (dimtruck)
16:25:23 <adrian_otto> dimtruck: how are we doing on this one?
16:25:35 <dimtruck> just documentation left
16:25:50 <dimtruck> there's one patch that's on hold due to the api tests now taking close to 2 hours
16:25:51 <adrian_otto> excellent.
16:25:55 <dimtruck> so ican't spin up another bay :(
16:26:06 <dimtruck> i'll have documentation done this week
16:26:18 <dimtruck> eghobo and thomasem helped me out with that already
16:26:27 <adrian_otto> I did notice that the Magnum API is really slow recently
16:26:47 <dimtruck> yup, that's b ecause bay tests are spinning up a bay...and that takes an extra 30 minutes
16:27:15 <dimtruck> we may potentially want to increate the test timeout for these from 2 hours to something longer
16:27:26 <dimtruck> like 150 or 180m
16:27:36 <adrian_otto> the bay create operation is taking much longer than I expect it to.. in the range of 20 seconds for what I expect should be subsecond time
16:27:36 <dimtruck> up to the team..
16:28:00 <dimtruck> do you mean bay model create?
16:28:24 <dimtruck> bay create takes ~18 minutes alone in spinning up swarm nodes and swarm manager
16:28:29 <adrian_otto> no, a bay create from an existing baymodel should return a 201 created right away, and it blocks for almost 20 seconds
16:28:36 <dimtruck> ahh
16:28:45 <adrian_otto> I thought it was my sest env, so I chucked it and set up a new one, and the same thing happened again
16:29:23 <dimtruck> i'll take a look...i've been more concentrating on getting the bay create time down and haven't looked at the actual api responses :(
16:29:29 <adrian_otto> maybe someone with performance profiling experience could have a look
16:29:29 <adrian_otto> or maybe there are some profiling tools for python that I could learn to use
16:29:33 <dimtruck> full bay create i meant
16:29:53 <adrian_otto> thanks dimtruck
16:30:27 <adrian_otto> I don't think we want to extend the time allowed to run the func tests, but see about ways to make them execute more quickly instead
16:30:37 <dimtruck> sounds good!
16:30:57 <adrian_otto> ok, next BP up for checkin is:
16:31:03 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/magnum-troubleshooting-guide (Tango)
16:31:11 <adrian_otto> Tango: any update?
16:31:38 <Tango> We have 2 sections being added. Thanks dimtruck and Tom
16:31:55 <Tango> 2 other in progress
16:32:25 <adrian_otto> de we have enought velocity on this, or should we plan to pull in more help from other team members?
16:32:46 <Tango> It would be good to get more help from the team
16:33:09 <Tango> so if anyone has expertise on debugging, please feel free to jump i
16:33:11 <Tango> in
16:33:22 <adrian_otto> ok, I am going to mark the BP as Slow Progress as a signal that we need more assistance on it.
16:33:40 <Tango> I set up the TODO list in the BP, please put your name on the section you would like to work on
16:33:57 <adrian_otto> we also have a related BP:
16:34:02 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/user-guide (Tango)
16:34:11 <adrian_otto> that's one of the others in progress you mentioned?
16:34:22 <Tango> Similarly, 2 are in progress, TLS and networking
16:34:35 <adrian_otto> ok
16:34:46 <Tango> Wonder if bradjones can help with Horizon
16:34:52 <adrian_otto> how should I mark the status of the user-guide BP?
16:35:10 <Tango> We can say Slow Progress also
16:36:08 <adrian_otto> ok, you go t it
16:37:08 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/resource-quota (vilobh)
16:37:33 <adrian_otto> vilobh is not in attendance today
16:38:12 <adrian_otto> A couple of days ago there was a revision to https://review.openstack.org/#/c/266662/
16:38:45 <adrian_otto> I'll plan to review that one as well, hopefully today.
16:39:06 <adrian_otto> next is:
16:39:26 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/mesos-functional-testing (eliqiao)
16:39:39 <adrian_otto> eliqiao: remarks on this one?
16:40:00 <hongbin> adrian_otto: I have followed up with eliqiao last week
16:40:12 <hongbin> adrian_otto: He mentioned that one is complete
16:40:18 <adrian_otto> oh, sweet!
16:40:20 <adrian_otto> I will mark it
16:40:33 <adrian_otto> oh, it already is. My mistake!
16:40:45 <adrian_otto> ok, that brings us to open discussion
16:40:50 <adrian_otto> #topic Open Discussion
16:41:55 <adrian_otto> maybe we have time to revisit the specs
16:44:14 <adrian_otto> or, I have a question
16:44:56 <adrian_otto> I have an opinion I'll be giving in an upcoming talk at the SCALE conference about why you might select one COE over another for a particular workload
16:45:43 <adrian_otto> if you were to give me your ideas on the top one or two reasons for picking Docker Swarm, Kubernetes, or Apache Mesos as your COE type, what are they?
16:46:26 <adrian_otto> I'm thinking Swarm for the freedom to really customize the app setup and deployment process, because you can use an imperative style.
16:46:42 <Tango> Another option is to run Kube and/or Swarm on top of Mesos
16:46:44 <adrian_otto> or that you are already familiar with the docker tools, and want to continue using those, plus the benefits of OpenStack
16:47:16 <adrian_otto> Tango: good point. In what circumstances would you prefer to do that?
16:47:51 <eghobo> adrian_otto: maybe we should talk about this topic during mid-cycle, i cannot type quick enough ;)
16:47:58 <adrian_otto> heh
16:47:59 <Tango> This allows fine grain resource sharing, so if you have workloads running on both Kube and Swarm, it would be helpful
16:48:57 <Kennan_> Tango: do you mean use mesos to schedule between kube and swarm?
16:49:24 <Tango> Right
16:49:25 <Tango> Kube is now available as a framework on Mesos, so there is interesting capability for managing the kube cluster
16:50:02 <adrian_otto> Tango: are you aware of anyone using that in a production capacity?
16:50:10 <adrian_otto> anyone I can ask about how that's working?
16:50:46 <Tango> It's too early for production use
16:50:53 <adrian_otto> ok
16:50:56 <Kennan_> It seems interesting. Would be helpful to have link for demo for that
16:51:00 <Tango> The kube framework is only a few months old
16:51:15 <adrian_otto> yeah, I'd love to learn more about it
16:51:23 <Tango> but it's an interesting possibility, we are looking into this
16:51:39 <Tango> might be a good topic for mid cycle
16:52:05 <Kennan_> adrian_otto:
16:52:10 <Kennan_> when you talked about this
16:52:11 <Kennan_> you can use an imperative style.
16:52:12 <Tango> For Magnum, we could consider deploying Kube and Swarm as framework on Mesos cluster
16:52:13 <adrian_otto> ok, I'll be sure to get that on the topi list
16:52:16 <Kennan_> what's that means ?
16:52:46 <adrian_otto> Kennan: as opposed to the declarative style used by Kubernetes in the YAML format kube file
16:53:19 <adrian_otto> instead of describing the output of the app setup, in an imerative style you would specify the explicit steps the system should follow during deployment.
16:53:35 <adrian_otto> so if you like declarative and want to use Swarm, you might select a tool like docker-compose
16:54:11 <adrian_otto> or if you prefer imperative you might just write a script that calls the docker client with a bunch of arguments that you orchestrate around yourself.
16:54:43 <Kennan_> OK
16:55:03 <Kennan_> I got it. so you mean swarm support both ways
16:55:09 <Kennan_> it is very flexible
16:55:17 <adrian_otto> Kubernetes gives a nice rich declarative style experience
16:55:17 <Kennan_> right ? adrian_otto
16:55:25 <adrian_otto> that's one of the sexy parts of it
16:56:09 <adrian_otto> but the deawback is that it requires a lot of code within the system itself to interpret the model provided by the user, and decide how to accomplish it
16:56:22 <adrian_otto> s/deawback/drawback/
16:56:42 <adrian_otto> ok, if you have more thoughts on this question, find me. I'd love to get your input.
16:56:58 <adrian_otto> we are coming close to the end of our scheduled time for today
16:57:19 <adrian_otto> hongbin: thanks so much for helping out last meeting as chair. I really appreciate it.
16:57:27 <hongbin> adrian_otto: np
16:58:21 <adrian_otto> Our next meeting is scheduled for 2016-01-26 at 1600 UTC. I look forward to seeing you all then!
16:58:26 <adrian_otto> thanks for attending today!
16:58:42 <juggler> thanks all
16:59:05 <adrian_otto> #endmeeting