16:01:20 #startmeeting containers 16:01:21 Meeting started Tue Aug 16 16:01:20 2016 UTC and is due to finish in 60 minutes. The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:26 The meeting name has been set to 'containers' 16:01:27 #topic Roll Call 16:01:28 o/ 16:01:29 o/ 16:01:31 Ton Ngo 16:01:35 O/ 16:01:38 Jaycen Grant 16:01:43 o/ 16:01:53 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-08-16_1600_UTC Today's agenda 16:02:08 ugh, o/ 16:02:19 Thanks for joining the meeting Drago1 swatson__ tonanhngo hieulq jvgrant_ eghobo 16:02:42 #topic Announcements 16:02:56 I have no announcement. Anyone else has? 16:03:17 #topic Review Action Items 16:03:25 None 16:03:31 #topic Essential Blueprints Review 16:03:37 1. Support baremetal container clusters (strigazi) 16:03:43 #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support 16:03:57 Spyros is on vacation so I update you on behalf 16:04:03 (Spyros) Fedora-k8s baremetal is merged 16:04:08 (Spyros) I'll investigate if it's possible to maintain the VM and BM versions with the same entrypoint and therefore the same driver. 16:04:14 (Spyros) But, as discussed with Muralia, we proceed keeping in mind that since the BM version has its own definition will be a separate driver. 16:04:31 That's all 16:04:58 Any question / comment? 16:05:24 2. Magnum User Guide for Cloud Operator (tango) 16:05:30 #link https://blueprints.launchpad.net/magnum/+spec/user-guide 16:05:35 tonanhngo: ^^ 16:05:39 I made a round of update, it has been merged. 16:05:44 Thanks everyone for the quick review 16:06:03 I talked to wangqun about continuing her doc on explaining labels 16:06:15 I will pick up her patch and merge with the user guide 16:06:34 Next I will write the section on Scaling 16:06:53 one question for the team: we have a simple implementation now, which I will cover 16:07:08 we also have had a much discussion on this subject. 16:07:39 I am thinking about summarizing these discussion in the user guide as well, to share the current thinking, although it's not implemented 16:07:54 Does this sound OK? 16:08:00 About scaling? 16:08:04 right 16:08:10 auto scaling, to be exact 16:08:29 oh, that is different from scaling 16:08:56 Can you elaborate? 16:09:05 is that better suited for a work in progress spec that could be referenced from user guide? I don't think the user guide should have non-implemented feature discussion 16:09:23 tonanhngo: When you talked about scaling, I thought you menned manually scaling (not auto) 16:09:44 OK, that's fair. I will leave it out then. 16:10:03 I can just mention that autoscaling is under discussion 16:10:09 Also, keep in mind that there is no consensus on auto-scaling so far (as far as I can remember) 16:10:32 True, we discussed some possible direction 16:10:52 Other than that, that's all I have for now 16:11:06 tonanhngo: Thanks Ton 16:11:28 tonanhngo: For the autoscaling, I think the first step is to drive consensus first 16:11:50 tonanhngo: Maybe you can use the ML or a design summit session 16:11:51 Yes, there are several different approaches. 16:12:02 That's a good idea. 16:12:10 ok 16:12:37 Any other question / comment ? 16:13:05 3. COE Bay Drivers (jamie_h, muralia) 16:13:10 #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers 16:13:21 It looks muralia is not here 16:13:50 Drago1: Do you know the status of this BP? 16:14:15 hongbin: Murali went on vacation Thursday, so probably not much has changed since the last meeting 16:14:28 Drago1: ack 16:14:47 Then, let's skip this topic today 16:15:08 #topic Kuryr Integration Update (tango) 16:15:14 tonanhngo: ^^ 16:15:28 I attended the Kuryr meeting yesterday 16:15:46 The code refactor for kuryr-lib is technically done 16:16:04 but they still have to update their functional tests and devstack script to use it 16:16:12 So the code remains to be validated 16:16:38 They do change their services a little, so this will impact our integration 16:17:22 They do recognize it's taking a long time, so they are trying hard to wrap this up 16:17:22 It looks we are not able to integrate with Kuryr at this cycle 16:17:38 We do have a dependency on them 16:17:54 ok 16:18:25 I think by the summit, we should have all the patches working, but unless they turn around quickly, it may not make into the release 16:18:49 ok 16:18:56 Let's see how is everything going 16:19:02 They are breaking out the REST/RPC server from the current libnetwork driver and running it separately 16:19:33 From our side, I continue with the code patches, expecting to make changes as needed 16:19:48 ok 16:19:50 I pushed to Docker Hub 2 images for our use 16:20:00 and have been testing against these 16:20:15 tonanhngo: From the dependency point of view, what exactly we needs to depends on Kuryr 16:20:35 tonanhngo: Needs to enable Kuryr in our devstack? or just needs to pull their docker image? 16:21:25 I think we need 2 things: their new updated Kuryr Docker image, and their new REST/RPC server code 16:22:05 ok 16:22:10 We will pull their Docker image to run on each Swarm node, and have their server running somewhere (devstack) to respond to requests 16:22:25 tonanhngo: the image is something they are working on, or something that already exists that we need to try? 16:22:32 The remaining parts should be the same as they are now 16:23:18 There is an image that I rebuilt from their code before the refactoring, but that image has both the Swarm libnetwork code and the server code together 16:23:43 So that works for now from the user perspective, but it's different from their new code 16:24:25 We can make reasonable progress for now, while their new code comes together 16:25:10 Anyway, they are making a serious effort to wrap up, so I think maybe another week or 2 16:25:39 That's all for now 16:25:49 Thanks tonanhngo 16:26:16 #topic Other blueprints/Bugs/Reviews/Ideas 16:26:22 1. Use common tooling for generating API docs 16:26:28 #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/101380.html API status report 16:26:34 #link https://review.openstack.org/#/c/317368/ A proposed patch 16:26:48 I can summarize the topic a bit 16:27:16 At the ML above, I saw Magnum was excluded from teh common navigation of OpenStack API reference 16:27:37 So, I am searching for our API patch 16:27:45 Which is the second link 16:28:20 The patch above proposed to use Swagger to generate the API docs 16:28:38 However, it looks Swagger is imcompatible with OpenStack API reference for now 16:29:08 That means if we continue to use Swagger, we are still excluded from teh OpenStack official API reference 16:29:15 That is my concern 16:30:15 What should we use? 16:30:38 The API doc team recommanded another tool 16:30:44 Let' me find the link 16:31:11 #link http://docs.openstack.org/contributor-guide/api-guides.html 16:31:49 Sorry. More specific link 16:31:51 #link http://docs.openstack.org/contributor-guide/api-guides.html#how-to-document-your-openstack-api-service 16:32:24 I saw all other projects followed this link to generate the API doc 16:32:39 Should we rework the current patch with Swagger to use this approach? 16:33:12 I find this amusing because six months ago they told us to use Swagger. 16:33:14 tonanhngo: I think the swagger patch is OK for long term, but we needs another patch for short-term 16:33:21 adrian_otto: +1 16:33:42 I thought swagger is a good approach also 16:33:50 From hongbin's link (next section) : "If your project already has WADL files, they are migrated to Swagger files with every commit to the api-site repository" 16:34:07 … "However, some APIs cannot be described with Swagger" 16:34:10 in fact, I think that advice actaully came from the same individual who is now pushing a different direction. 16:34:47 Maybe they had a change of heart when they realized not all APIs "can be described with Swagger" 16:35:46 I pinged the API doc team about this 16:36:07 From their response, it looks they want to keep the swagger patch as experiental 16:36:15 So then do we need a two-pronged approach: short term and long term? 16:36:34 the good news is that we don't have an extensive API. 16:36:52 tonanhngo: That is my understanding of the suggestion from API doc team 16:37:33 I would like to know the shortcomings of swagger, so if anyone has links or wants to talk offline, let me know 16:38:36 The main problem for Swagger is that it cannot be integrated well with other OpenStack docs 16:39:24 There are other shortcomings as well I believe 16:39:38 which was mentioned in a ML but I couldn't find it now 16:40:39 Then we should open a blueprint with the details mentioned here and start working on the OpenStack API approach 16:40:57 tonanhngo: +1 16:41:27 Others, what do you think? 16:42:03 tonanhngo: +1 16:42:15 We need to conform with whatever the prevailing format is. 16:42:36 It would be nice if the requirements were really clear. 16:43:06 so if we can digest them and put them into terms we can all totally get, then that would be a worthwhile effort. 16:43:31 I think a blueprint is a good place for that, so +1 16:44:00 ok. Then, let's create a BP for that 16:44:33 #action hongbin create a BP for API docs 16:45:06 Let's work on the BP after it has been created 16:45:15 Any other question? comment? 16:45:39 #topic Open Discussion 16:45:51 quick update on bay to cluster 16:45:57 there are 3 code reviews out 16:46:30 close to pushing on api and doc 16:46:36 https://review.openstack.org/#/c/353726/ 16:46:52 https://review.openstack.org/#/c/354404/ 16:46:59 https://review.openstack.org/#/c/354436/ 16:47:08 is there any thought given on magnum services in active-active-active(HA)? 16:47:29 most of my time right now is spent merging all the changes that are coming in from other reviews 16:47:38 so if we could get those reviewed a pushed that would be great 16:47:39 rajiv__: will discuss that later 16:48:07 next meeting? 16:48:12 jvgrant_: OK. I will try to priority the review on taht 16:48:13 it also appears that our functional tests are over the timeout for jenkins, is there a way to up this timeout? 16:48:50 jvgrant_: We can increase the timeout, but I don't think it will help 16:49:23 jvgrant_: how about the python client? 16:49:24 hongbin: with the cluster commands we are basically doubling our time on the api tests 16:49:28 jvgrant_: It looks there are some unknown issue that blocked the bootstrap of some nodes at the gate 16:50:02 jvgrant_: I see 16:50:14 hongbin: client is the 3rd review and is getting close as well 16:50:45 jvgrant: i've seen the tests make it under 2 hours, but also see them take over that. 16:51:23 jvgrant_: I believe there is a parameter to set teh bay creation timeout 16:51:54 hongbin: on average the current api tests take 1 hour 10 minutes to 1 hour 40, so adding the new cluster commands makes it go over 2 hours 16:52:31 jvgrant_: If it goes over, I am ok to remove the bay tests 16:52:51 hongbin: i can at least simplify the larger ones for bay 16:53:33 hongbin: i'll try that and see if it will stay under 2 hours. i don't think we really want 3 hour api tests on each patch 16:53:51 jvgrant_: ack 16:54:58 jvgrant_: Another question for you. Do you mind to add the bay to cluster renaming BP to the meeting agenda 16:55:17 jvgrant_: That means you are expected to report status of this BP every week 16:55:31 hongbin: yes, please do. I think we should track this 16:55:38 jvgrant_: Thanks 16:56:13 #action hongbin add rename-bay-to-cluster BP to teh meeting agenda 16:56:19 Thanks jvgrant_ 16:56:29 rajiv__: your turn 16:56:53 is there any discussion on a/a/a/? 16:57:11 or we have to discuss and drive it. 16:57:23 Can you elaborate? 16:57:46 I mean, what if we want magnum services in active active active state 16:58:00 is there any challenges? 16:58:14 has this been taken care off in existing code? 16:59:05 Do you mean you want to run multiple magnum-api / magnum-conductor? 16:59:12 yes 16:59:18 It should work 16:59:50 We faced issue with other component after failover, so i was curious to know 17:00:04 whether magnum has been tested for this or not? 17:00:11 rajiv__: please report a bug for that 17:00:20 SOrry, time is over 17:00:21 ok 17:00:29 All. thanks for joining the meeting 17:00:32 #endmeeting