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