16:00:03 #startmeeting containers 16:00:04 Meeting started Tue May 10 16:00:03 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:08 The meeting name has been set to 'containers' 16:00:10 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-05-10_1600_UTC Today's agenda 16:00:16 #topic Roll Call 16:00:20 Hi 16:00:22 Spyros Trigazis 16:00:25 o/ 16:00:26 Ton Ngo 16:00:27 o/ 16:00:28 o/ 16:00:31 o/ 16:00:32 o/ 16:01:11 o/ 16:01:21 Adrian Otto 16:01:35 Thanks for joining the meeting sheel strigazi madhuri tango__ spn dane_leblanc_ bradjones jamie_h juggler adrian_otto 16:01:58 #topic Announcements 16:02:06 #link http://lists.openstack.org/pipermail/openstack-announce/2016-May/001103.html python-magnumclient 2.1.0 release 16:02:19 This is the first release based on request 16:02:34 Any comment? 16:02:57 #topic Review Action Items 16:03:00 None 16:03:08 #topic Essential Blueprints Review 16:03:14 1. Support baremetal container clusters 16:03:20 #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support 16:03:36 For this blueprint, the original assignee is Kennan 16:04:02 However, I received an email from him that he is not able to own it anymore 16:04:13 Therefore, we need a new owner for this one 16:04:41 This is a very important feature for Magnum (most people want to run containers on baremetals) 16:04:50 If nobody want to take it, I will take it 16:04:59 I'd like to help, but unfortunately have commitments until end of June. 16:05:11 I will help also, it's important for us 16:05:11 dane_leblanc_: ack 16:05:22 I 'll help too 16:05:24 hongbin: Ì can work with you and help 16:05:25 Can help part time for now 16:05:46 Thanks all 16:05:49 maybe you can list the TODO and people can jump in 16:05:56 +1 16:06:05 Let's find an owner 16:06:19 The owner should coordinate efforts from other contributors 16:06:27 Who want to own that BP? 16:06:51 (note: owner don't have to do the job, but coordinate the efforts) 16:07:07 I have many bp already, but I can try 16:07:21 strigazi: thx 16:07:33 strigazi: I will assign it to you 16:07:41 ok 16:07:45 strigazi: Again, you don't have to be the one who do the work 16:07:55 ack 16:08:07 strigazi: I think tango__ spn dane_leblanc_ will interest to help out 16:08:10 strigazi: I can help 16:08:19 spn: thx 16:08:26 spn: thx 16:08:34 Any further comment for this BP? 16:08:54 2. Magnum User Guide for Cloud Operator (tango) 16:09:00 #link https://blueprints.launchpad.net/magnum/+spec/user-guide 16:09:08 tango__: status? 16:09:22 I resumed working on this after a pause for the Summit, currently working on the storage section 16:09:32 I added a place holder for bay driver 16:10:11 will start writing it as outlined in the spec for now, so we have something to update as we proceed with the implementation 16:10:41 The other sections in the guide will cover the supported bay drivers: Kubernetes, Swarm, Mesos 16:10:53 tango: I think this can actually help the implementation 16:11:08 I would expect new bay drivers to have their doc to supplement the guide 16:11:09 yes 16:11:44 I will also start consolidating other docs into the guide, like TLS, ... 16:12:07 tango__: thx 16:12:12 As usual, any help from the team is welcome 16:12:32 tango__: In particular, which part you need help from the team? 16:12:53 The BP list some of the sections that has no content yet 16:12:59 tango__: ack 16:13:05 for instance, HA 16:13:07 The documentation team told me that we can publish under docs.openstack with no details on that, but I have a contact 16:13:36 Sounds good, I will follow up with you 16:13:43 ok 16:13:52 Any other question for Ton? 16:13:58 is this spec separate from API documentation? 16:14:30 I think API doc should be separate, since it's for a different audience 16:14:31 I think it is separated 16:14:40 ok 16:14:48 There is a WIP patch for leveraging Swagger for API docs 16:15:00 #link https://review.openstack.org/#/c/303235/ 16:15:10 Sync with yuanying if you interest 16:15:23 3. COE Bay Drivers (Jamie Hannaford) 16:15:41 jamie_h: any update? 16:16:01 #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers 16:16:14 i've been busy last week, but hope to restart things tomorrow 16:16:25 there's been a lot of feedback, which i almost entirely agree with. i have a few questions though 16:16:35 o/ 16:16:41 wangqun_: hey 16:16:50 hi 16:16:53 jamie_h: Yes, I think the spec is almost ready 16:17:03 should the spec dictate what lives inside the version.py manifest file? its structure etc 16:17:09 or leave that up to the implementor 16:17:28 jamie_h: I think it is up to you 16:17:40 jamie_h: I think the spec don't have to address all the details 16:17:58 We can go back and update the spec also as needed 16:18:01 jamie_h: So, just outline the design is good enough for me 16:18:04 ok, sounds good 16:18:28 Any question for jamie_h regarding the Bay driver BP? 16:19:06 4. Create a magnum installation guide (strigazi) 16:19:24 The proposed spec https://review.openstack.org/#/c/301284/ to move Big Tent projects from the install guide to repos owned by project teams has been merged. A new spec for the install-guide has been created for Newton https://review.openstack.org/#/c/310588/. The intention is to move from "one install-guide to rule them all" to installation tutorials, many, or a few. For example, debian con 16:19:27 #link https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide 16:19:30 tent (with debconf https://wiki.debian.org/debconf) will be moved in a separate tutorial. Additionally, quite a few people in the design summit were in favor of installation instructions from source. 16:20:00 In https://review.openstack.org/#/c/310588/, a template will be created, which can be followed by project teams. Magnum will have installation instructions in its repo and that content will be published in docs.openstack.org. The exact publishing location for Big Tent projects hasn't been determinted, yet. 16:20:31 We can start by adding my WIP in our repo 16:20:49 strigazi: Yes, that would be great 16:20:50 Which is done and tested for rdo and ubuntu 16:21:04 Do you think we should have a spec? 16:21:04 +1. I have been trying it out on Ubuntu 16:21:33 Thing might change, since the documentation team makes changes 16:21:46 strigazi: I don't think we need a spec for writing the doc 16:21:46 s/thing/things 16:22:27 We can have two, one for packaged installations and one from source 16:22:51 since magnum is under active development from source makes sense 16:23:09 WFM 16:23:13 I agree that we don't need a spec for this. 16:23:39 Yes, just get everything landed in the fastest way 16:23:45 ok 16:23:48 let's just resubmit the doc for merge under the magnum source tree 16:24:19 I'll remove obs and debian 16:24:40 strigazi: thx. Any other comments regarding to the installation guide BP? 16:24:47 is there a problem with the debian packaging? 16:25:03 I haven't tested it 16:25:18 debconf is a lot diffrent 16:25:37 It looks other projects don't have debian in their documentations 16:25:37 I makes things easier thow if you know what you're doing 16:26:36 Any other comments? 16:26:37 We can point debian users to the packages and to the install from source, until we are ready 16:26:37 If we have guidance and it's just not tested for debian, I suggest including it and marking it as untested. 16:26:51 ok 16:27:29 OK. Let's advance topic 16:27:30 the more installation options operators have, the more adoption we are likely to see. As folks try it, they can let us know what works and what doesn't 16:27:47 #topic Magnum UI Subteam Update (bradjones) 16:28:14 bradjones: any update from the UI subteam? 16:28:20 both shu & I have been on vacation since summit so nothing new 16:28:32 hoping some of the new bps will get picked up this week 16:28:38 so should be more next week 16:28:47 bradjones: Thanks Brad 16:28:53 Any question for Brad? 16:29:22 #topic Other blueprints/Bugs/Reviews/Ideas 16:29:27 1. Review Magnum mission statement 16:29:33 #link https://review.openstack.org/#/c/311476/ The proposal 16:29:54 It looks the patch has a lot of +1 already 16:30:08 If you have comments, now is the last minutes 16:30:20 2. Add an option to turn on Keystone authentication for k8s bay 16:30:28 #link https://blueprints.launchpad.net/magnum/+spec/keystone-for-k8s-bay 16:30:56 This is a proposal to add support for additional auth machnism for k8s 16:31:12 There is a use case from Horizon plugin to leverage it 16:31:41 The idea is to turn on the Keystone support for kubernetes, which is already in updstream 16:32:09 Any comments for this proposal? 16:32:35 Do you think if it is the right direction? 16:32:50 Good to have more integration with OpenStack services 16:33:02 tango__: +1 16:33:06 +1 16:33:08 wait a sec 16:33:08 +1 16:33:11 this is one of the value Magnum brings 16:33:14 what are you proposing exactly? 16:33:19 Yes it is good idea to integrate Keystone 16:33:33 to change the default configuration of K8s to use keystone for user auth instead of TLS certs? 16:33:38 adrian_otto: Add an option to turn on Keystone auth in k8s 16:33:52 adrian_otto: The default is still TLS 16:34:31 I think the option is fine. The default should be the prevailing way k8s users normally interact with k8s clusters, which is using TLS for auth. 16:34:32 There is a link in the BP to the feature in Kubernetes 16:35:13 The BP has nothing to do with the default configuration 16:35:21 It is about adding an alternative option 16:35:21 We should avoid a situation where k8s users have to set up their environments differently in order to use a k8s bay on Magnum, versus how they would use k8s elsewhere. 16:35:51 adrian_otto: If we decided to integrate with Kuryr, this is already the case 16:36:05 that's different 16:36:22 adrian_otto: Could you elaborate? 16:36:48 because you can interact with the docker API regardless if we use kuryr 16:37:03 OK. That is true 16:37:14 if you make it so that my usual k8s client enfironment is incompatible with using k8s on openstack, that would be a bad user experience. 16:37:52 I might or might not agree, but that has nothing to do with the BP 16:37:57 so I recognize that's not what has been proposed, but I wanted to offer my input of where we should be careful 16:38:27 OK. THen I will approve the BP if there is no objection from others 16:38:42 Any opposing point of view? 16:39:11 Approved 16:39:24 3. Add labels help text in magnumclient 16:39:36 #link https://review.openstack.org/#/c/307631/ 16:39:42 #link https://review.openstack.org/#/c/307642/ 16:40:18 wangqun: You are the one who proposed those patches? 16:40:34 yes 16:40:51 These patches have -2 from Tom 16:40:59 So I bring it to the team meeting 16:41:03 I want to add the label help because its paraments is so many. 16:41:20 wangqun: Could you elaborate more? 16:41:43 wangqun: (more details for others to catch up the context) 16:42:13 Yes 16:43:43 I want to add the labels help and it will be easy to introduce the paramenter for users 16:44:01 Yes 16:44:04 Now the mesos flags has been added so many value. 16:44:26 I think it's good to have more explanation to help the user. It's true that label is for general use so it's difficult to know what's supported. 16:44:34 The issue is how to organize the help message 16:45:03 The help message have to be in the CLI if we decided to give it 16:45:04 +1 16:45:06 to make it easy for the users to find what they need 16:45:28 I find the nova has the example https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/shell.py#L487 16:45:29 Looks like in the patch, it will all be under label, which may be too much 16:45:36 Here is the objection from @Tom 16:45:59 He argued that help text in CLI might be outdated if it is under maintain 16:46:06 Therefore, he gave a -2 16:46:35 So, there is two opposing poiint of view 16:46:52 #1 Put help text to CLI to make it close to end users 16:47:23 #2 Don't put detailed help text to CLI to make it easer to maintain 16:47:48 What are your opinions between these two point of views? 16:48:26 comments? 16:48:46 Or you want to discuss it in the ML? 16:48:55 If the keky point is to make it easier to maintain, we can have it in the CLI and organize in a way to make it easy to maintain 16:49:04 without having to update master 16:49:35 tango__: maybe let the CLI to retrieve help text from server 16:49:47 Going back to the doc is not very convenient 16:49:54 although it should be documented as well 16:50:21 Maybe put it in magnum.conf ? 16:50:34 tango__: magnumclient don't have access to magnu.conf 16:50:47 through a call to the server 16:50:58 tango__: Yes, that is an option 16:51:08 Anyway, we can discuss the implementation 16:51:16 Yes it is a option 16:51:17 I added a patch to get parameters from server https://review.openstack.org/#/c/303235/ 16:51:29 Let's discuss it further in ML 16:51:36 but we don't have to choose one or the other 16:51:41 it can be both 16:51:50 #action hongbin start a ML to discuss the CLI help text documentation 16:52:05 #topic Open Discussion 16:52:41 hongbin: when we are going to start on higgins? 16:52:51 hongbin: is there any defined roadmap for same? 16:53:24 sheel: It can be started as long as the repo was created 16:53:31 #link https://review.openstack.org/#/c/313935/ 16:53:55 hongbin: yes i am aware of it being one of the reviewers :) 16:54:00 sheel: Once the patch go through, the repo will be created. Then, it can be started 16:54:25 hongbin: nice.. any roadmap defined for same like which fucntionalities specifically to move etc 16:54:39 sheel: Not yet. That needs to be discussed 16:54:39 hongbin: will be helpful to track the work 16:54:48 hongbin: ohk... 16:54:59 sheel: BTW, this is a Magnum meeting. This is a bit out of topic :) 16:55:00 hongbin: so any plan for discussion in coming days/weeks? 16:55:16 hongbin: sorry for asking too many questions but curious to start work on it... 16:55:18 sheel: I will start a ML to schedule a meeting 16:55:44 hongbin: sounds good.. 16:55:55 thanks 16:56:00 np 16:56:57 Anyone else has a topic to discuss? 16:57:41 If not, let's wrap up 16:58:14 Thanks everyone for joining the meeting 16:58:20 #endmeeting