22:01:13 #startmeeting containers 22:01:14 Meeting started Tue Feb 10 22:01:13 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:17 The meeting name has been set to 'containers' 22:01:19 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-02-10_2200_UTC Our Agenda 22:01:23 #topic Roll Call 22:01:27 Adrian Otto 22:01:40 Andrew Melton 22:01:40 o/ steak here 22:01:49 wkharold 22:01:56 o/ 22:01:59 OTSUKA Yuanying 22:02:09 o/ 22:02:18 good morning Yuanying 22:02:40 Thomas Maddox 22:02:43 o/ 22:03:00 and hello apmelton sdake wkharold pradk rpothier and thomasem 22:03:05 howdy 22:03:36 Sorry I missed last week's. Was knee deep in a production issue. 22:03:48 thomasem: np. We have a lot on the agenda today, so let's get started… 22:03:54 Hongbin Lu 22:04:02 hi hongbin 22:04:10 #topic Announcements 22:04:14 (1) adrian_otto will be away on 2015-02-17 and 2015-02-24 for our 1600 UTC meeting. Our pro-tem chair will be sdake for these two meetings. 22:04:30 the week after that is our Midcycle meetup 22:04:34 yar 22:04:36 should we hold an IRC meeting or not? 22:04:53 I marked the calendar as no meeting for 2015-03-03 22:04:57 during the midcycle? I'd say no 22:05:24 yeah, we will be in the team IRC channel during the midcycle 22:05:33 but I don't think we need the IRC meeting. 22:05:42 (2) The Magnum Midcycle Meetup will be on 2015-03-02 and 2015-03-03. 22:05:50 #link https://wiki.openstack.org/wiki/Magnum/Midcycle Magnum Midcycle 22:05:56 (more on this later) 22:06:13 (3) Please welcome @madhuri to our team as a full-time contributor. She is joining the Magnum team from NEC and works with yuanying in Japan. 22:06:26 Welcome! 22:06:27 it's 07:06 in Japan right now 22:06:55 so maybe we will see her a bit later 22:07:05 She can not connect this channnel because some error 22:07:34 She is trying to connect now 22:07:45 ok, we can come back to it a bit later. 22:08:01 but I will say that I'm really pumped to see the team growing. 22:08:10 yar :) 22:08:15 #topic Review Action Items 22:08:26 we had two 22:08:32 (1) adrian_otto to follow up with yuanying about ironic-heat-template 22:08:46 I was able to discuss this with yuanying-alt breifly 22:08:57 Implementation Status is slow due to lack of familiarity with pxe/ironic/image-building. Support from other Stackers desired. 22:09:17 if you can help with this, let's arrange for you and yuanying-alt to work together 22:09:45 Now, I can boot ironic instance (kube minion) 22:09:57 but there is some problems 22:10:32 Please see my patch https://review.openstack.org/#/c/154437/ 22:11:59 that's all 22:12:02 sdake: is this something you think you might be able to help with? 22:12:16 overloaded atm 22:12:22 I handed it off to yuanying in teh first place 22:12:27 aha 22:13:06 ok, so feel free to discuss on the ML 22:13:16 maybe we can pull in others who can help 22:13:29 our next action item was: 22:13:33 (2) adrian_otto to initiate an ML thread for discussion of native Docker scheduling support for Magnum 22:13:44 #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056273.html ML Thread about Magnum Scheduling 22:13:58 that thread got numerous replies 22:14:12 diga: yt? 22:14:30 it's like 02:15 where he lives 22:15:00 so, I managed not to subscribe to the ML somehow ... 22:15:11 at any rate, we did discuss the topic, and most of us semed happt to pursue a point solution for the native docker backend 22:15:31 real quick, what would integrating swarm provide that k8s doesnt? 22:15:45 while aiming for a generic scheduler option to leverage Gantt when it reaches suitable matuity 22:16:25 wkharold: the difference is that we would not expect to be interacting with a docker backend in the k8s case 22:16:37 whereas we would in the case of the native docker backend 22:16:56 k8s is built on/for Docker, no? 22:17:10 k8s has it's own REST API 22:17:21 and tha's what our k8s backend interacts with 22:18:18 it would not make sense to surface the Docker API on an individual node of a k8s cluster 22:18:34 where that would make sense if you are using Magnum to get a single container running on a docker host 22:18:35 not sure why it matters whether backend talks k8s or Docker API 22:18:49 magnum clients see neither 22:19:01 it's still Docker at the end of the day 22:19:06 actually, we discussed surfacing the native API endpoints 22:19:24 to allow for existing tooling to interact with the container using the native API 22:19:54 existing tooling? 22:19:57 so you would Use Magnum as the control plane, but you might put the container into different backend states by interacting directly with it's API 22:20:12 say you wanted to use cAdvisor or something 22:20:36 and that -something- were integrated with the container API 22:20:56 we want to provide a control surface abstraction to get the container entity 22:21:05 I think in some cases, for VIF for example, we need to not surface the native api for k8s 22:21:22 but you might select a different backend handler depending on what you want Magnum to link you to from that. 22:21:32 the Docker API is always there 22:21:41 even k8s or not 22:21:53 but you may be unable to reach it 22:22:15 say for example if k8s sets up a TLS token keypair 22:22:25 and the client token is held by k8s 22:22:31 it can talk to docker, but other clients can not. 22:22:53 the k8s tls token problem can be solved by an api addtion to retrieve the client's keypair 22:22:57 if you use a native docker backend, we could make the client key part of the OCNtainer resource 22:23:08 does it do that? Docker would have to be a participant in that scheme 22:23:35 it does not yet, but these are examples of some of the points of differentiation between the two backends 22:24:02 let's park this to revisit in open discussion 22:24:08 sure 22:24:19 that concludes action itmes 22:24:23 #topic Administrative 22:24:33 Reviews to include links to "Implements blueprint BLUEPRINT" or "Closes-Bug: #NNNN" on the last line of the commit message. 22:24:43 Rationale: This allows for more accurate tracking of our progress in each release to be included in our release notes. 22:24:48 +1 22:24:50 NOTE: The bug does not need to be previously approved to be linked to a review. 22:24:54 +1 for better commit logs 22:25:15 +1 22:25:26 if you find reviews that link to neither a BP or a bug ticket, please vote -1 and direct the committer to add one 22:25:41 also, I have routinely commented on commit messages 22:25:56 ideally the commit message will answer the question about "Why are we doing this?" 22:26:18 "Who cares?" 22:26:23 the commit log is the most important point of the changei mo :) 22:26:29 so we are getting better at that 22:26:36 sdake: agreed 22:26:55 a really good commit message signals to me that your patch is well reasoned 22:27:03 even in cases where you have a 1 line patch 22:27:06 that can be gamed ;-) 22:27:11 I'd still like to see a sensible commit message 22:27:15 sorry for late 22:27:21 hey jay 22:27:26 hey sdake 22:27:33 I'm trusting this team not to play games 22:27:44 welcome Jay 22:27:55 thx ;) 22:28:02 ok, any more discussion on the Administrative topic? 22:28:13 launchpad admin 22:28:14 the last change we made in this area was a policy to require unit tests 22:28:17 see stuff in discussion 22:28:21 what is the trigger to approved 22:28:39 I will comb through those 22:28:51 most of them have estimates now 22:29:06 if discussion has happened, and dispute is absent, then I will approve as long as there is enough detail in the BP to actually work against it 22:29:30 thanks to all of you who added estimates. 22:29:38 we will get to this in Task Review 22:29:50 #topic Release Schedule Discussion 22:29:58 Next planned release date is 2015-02-16 is there value in aligning our release date with our Midcycle meetup? 22:30:21 keep in mind that we can release as often as we want 22:30:25 as in pushing 2-16 back to just before 3-2? 22:30:42 or releasing 2-16 then quickly again before/after the mid cycle? 22:31:30 my question is if we should push out a release date 22:31:34 i think just push out a week 22:31:57 we do have 25+ open bugs, several of them are Criticals 22:31:57 +1 22:32:11 adrian_otto: that's a good point 22:32:13 so I'd like to see us draw down the critical list a lot 22:32:17 +1 to push out 22:32:24 some bp also under development 22:32:45 +1 fine with me 22:32:48 That would make the proposed release date Feb 23 22:32:49 I see no reason to not push back the date, so +1 from me 22:33:15 +1 22:33:26 ok I will record that as a #agreed 22:33:50 #agreed our next target date to tag a release is 2015-02-23 22:34:29 if you have a moment, I'd like us all to find a bug in the queue that has Assignee set to None, and take it. 22:34:37 or take a few 22:35:13 I will revisit that in a moment as well. 22:35:26 but now, I'd like to welcome our new team member madhuri__ 22:35:45 Hi all! 22:35:50 welcome madhuri__ 22:35:54 welcome 22:35:55 howdy 22:35:55 madhuri__: welcome to eh Magnum team!! 22:36:00 Thank you! 22:36:02 welcome madhuri_ 22:36:02 welcome! 22:36:23 I am happy to join this team. 22:36:34 madhuri__: have you worked on other OpenStack projects before, or will this be your first? 22:36:37 welcome! 22:37:00 Yes. I have worked on swift. 22:37:13 sweet! 22:37:14 I'd argue this isn't a bug: https://bugs.launchpad.net/magnum/+bug/1405356 22:37:14 Launchpad bug 1405356 in Magnum "Tech Debt: Fix endpoint configuration on docker handler" [High,Triaged] 22:37:39 ok, so your learning curve will be much easier with Gerrit and such 22:37:48 More of an improvement. Right? 22:38:08 Yes. I am familiar with it. 22:38:51 let's cover the Midcycle for a moment 22:38:55 #topic Mid-Cycle Meetup 22:39:08 If you can attend, please RSVP: 22:39:10 #link https://www.eventbrite.com/e/magnum-midcycle-meetup-tickets-15673361446 Midcycle RSVP Tickets 22:39:17 if you can not attend, take no action 22:39:32 regardless, please review the agenda topics 22:39:33 #link https://etherpad.openstack.org/p/magnum-midcycle-topics Midcycle Agenda Items 22:39:49 adrian, I think someone does want to join remotely 22:40:16 yes, the next step in planning will be to get all the topics, and build a schedule for them 22:40:34 for remote attendees, what is the process? 22:40:38 if you want to join the discussion on one of the topics, please label it 22:40:40 how does it work? 22:40:46 and put an asterisk by your name if you are remote 22:41:00 and anchor that asterisk to the timezone you wnat to attend from 22:41:11 and I will see what I can do to allow remote participation 22:41:18 we have a room with a very good VC system in it 22:41:31 and I have held midcycles there before 22:41:49 Google Hangouts worked well, as well as projecting up the IRC channel 22:41:52 cool, might document how to connect for the midcycle then if we haveremotees 22:42:07 good idea 22:42:18 I will put that on the wiki page for the Midcycle linked above 22:42:28 cool thx 22:42:31 again for your convenience: 22:42:32 • #link https://wiki.openstack.org/wiki/Magnum/Midcycle Magnum Midcycle 22:42:51 I will plan to sponsor lunches for us 22:43:08 so if you have dietary constraints, please contact me individually 22:43:40 any other questions or concerns regarding the meetup? 22:44:00 #topic Blueprint/Task Review 22:44:08 #link https://blueprints.launchpad.net/magnum/milestone-2 M2 Blueprints 22:44:22 I will be advancing several of these from discussion to approved today 22:44:33 are there any that you think I should leave in discussion? 22:44:38 if so, LMK. 22:45:00 #link https://bugs.launchpad.net/magnum/+bug/1418719 replication controller created pods don't show up in pod-list output 22:45:00 Launchpad bug 1418719 in Magnum "replication controller created pods don't show up in pod-list output" [High,Triaged] 22:45:11 this bug struck me as important, but it has no owner 22:45:24 it might actually be a critical 22:45:35 what is m2-docs? 22:45:38 and it might actually be related to another open bug 22:45:46 yes, we did not put pod data in DB when creating with rc 22:45:51 all documentation work items for the upcoming rleease 22:46:25 re: 1418719 ... not clear that the DB is a good place for that info 22:46:25 jay-lau-513: so you are confirming that 1418719 is a unique defect? 22:46:53 adrian_otto yes 22:46:54 if the source of truth is in the rc resource, then we do not need to duplicate it 22:47:03 that will not be a high frequency request 22:47:05 just so 22:47:05 I'm also thinking if DB is a good place for such case 22:47:28 it will be difficult to keep it in sync 22:47:45 so we are short on time today, but I wanted to bird dog that particular bug. 22:47:46 better to talk to k8s or maybe etcd 22:48:06 We have ~15 bugs that have no owner assigned 22:48:17 #link https://bugs.launchpad.net/magnum/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=& 22:48:31 I have taken 1418719 22:48:40 so please adopt them as you find ones you can solve 22:49:06 any other work items that should be discussed as a team today? 22:49:32 #topic Open Discussion 22:51:03 wkharold did you have more questions about docker native backend? 22:51:20 I'd like to comment on that a little bit 22:51:27 I need to read thru the e-mail thread to get a full context 22:51:48 apmelton: you have the floor 22:52:09 the way I see it, providing the docker/kubernetes endpoint allows power users to continue to use their tools 22:53:30 I think that's pretty important in the container world 22:53:41 that would of course come with a "use at your own risk" warning 22:54:25 yes 22:54:38 apmelton: what are the tools that power users are using? 22:54:47 the docker cli 22:54:52 kube client 22:55:29 apmelton, I think we did have have the plan to support this, sdake please confirm 22:55:38 https://github.com/stackforge/magnum/blob/master/specs/containers-service.rst 22:55:50 whether we support it or not, users are going to do it 22:55:50 Take a look at use case 9 22:56:08 jay yup 22:56:10 confirmed 22:56:36 this is exposing the native ReST APIs via the bay 22:56:42 that can be shown via bay-show 22:56:53 right 22:56:57 yes 22:57:12 we would expect some different output depending on the backend 22:58:10 for example, I may want to emulate the behaviour of docker-machine when using the native docker backend 22:58:20 which would be different than what I expect for the k8s backend 22:58:39 we are approaching the end of our scheduled time for today's meeting 22:58:59 I'm happy to discuss further in #openstack-containers 22:59:32 Our next meeting is 2015-02-17 at 1600 UTC. 22:59:37 k 22:59:40 thanks everyone for attending today!! 22:59:44 bye everyone 22:59:48 #endmeeting