16:00:02 #startmeeting containers 16:00:08 Meeting started Tue Aug 9 16:00:02 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:08 #topic Roll Call 16:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:11 The meeting name has been set to 'containers' 16:00:24 Spyros Trigazis 16:00:26 o/ 16:00:29 Jaycen Grant 16:00:38 murali allada 16:00:42 Ton Ngo 16:00:48 hi all 16:00:55 Michal Jura 16:01:02 Hieu LE o/ 16:01:09 Madhuri Kumari 16:01:15 Thanks for joining the meeting strigazi vipulnayyar jvgrant muralia tonanhngo mjura hieulq_ mkrai 16:01:19 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-08-09_1600_UTC Today's agenda 16:01:20 o/ 16:01:25 Anything needs to be added to the agenda? 16:01:53 #topic Announcements 16:02:02 I have no announcement, anyone else has? 16:02:05 We have https://hub.docker.com/r/openstackmagnum/ 16:02:11 nice 16:02:24 +1 16:03:04 hongbin egor and adrian are also owners 16:03:22 I didn't have anyone's else username or email 16:03:22 Vaguely here, got a concurrent meeting. 16:03:29 +1 16:03:47 Thanks strigazi for acquiring this account 16:04:12 If anyone else want to own this repo, feel free to ping strigazi offline 16:04:23 #topic Review Action Items 16:04:26 None 16:04:32 #topic Essential Blueprints Review 16:04:38 1. Support baremetal container clusters (strigazi) 16:04:43 #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support 16:04:47 strigazi: ^^ 16:04:52 k8s-atomic is ready be merged 16:05:05 yuanting did great job 16:05:20 I helped but he deserves most of the credit 16:05:34 I meant yunaying 16:05:49 Testing swarn, it looks in good shape 16:05:58 that's all 16:06:01 Hi Strigazi, do you have any plan to enable dc/os or mesos, swarm on baremetal 16:06:10 mesos is next 16:06:17 then coreos 16:06:28 and then i'd love to add DC/OS 16:06:29 The DC/OS is not even on VM yet 16:06:40 any help is welcome 16:07:05 hongbin: what do you mean? 16:07:05 I think Jay is working on DC/OS 16:07:06 Thanks strigazi 16:07:27 Thank you for update, STrigazi 16:07:31 eghobo: We have a BP to support DC/OS, but it is not implemented yet 16:07:40 got it 16:07:57 #link https://blueprints.launchpad.net/magnum/+spec/mesos-dcos 16:08:04 2. Magnum User Guide for Cloud Operator (tango) 16:08:10 #link https://blueprints.launchpad.net/magnum/+spec/user-guide 16:08:16 tonanhngo: ^^ 16:08:20 Not much to update this week. The Bay section was merged. Next I will do a round of update 16:08:40 I added some notes on the whiteboard 16:08:51 to pick up on comments from Ricardo and Spyros that I missed, along with new changes and features 16:09:08 Thanks Spyros 16:09:26 That's all I have 16:09:37 Thanks tonanhngo 16:09:52 3. COE Bay Drivers (jamie_h, muralia) 16:09:59 #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers 16:10:01 muralia: ^^ 16:10:26 I've made some more progress on this. I've moved all the stack creation, update and deletion methods to the common driver folder. 16:10:46 im in the process of changing the entry points to load each drivers driver.py file 16:10:57 instead of the template_def.py file 16:11:30 i'll continue working on that and will have a patch soon 16:12:37 You finished? 16:12:43 yes, done 16:12:48 Thanks muralia 16:13:03 #topic Kuryr Integration Update (tango) 16:13:12 tonanhngo: ^^ 16:13:38 The Kuryr team did not have a meeting again last night, it seems the person from Japan is not available to host 16:14:01 I think they will move the meeting time back to the morning slot for the other folks to join 16:14:32 The Kuryr docker image is still not working, I saw several attempts to rebuild it but they failed 16:14:43 apparently the code refactor is not completed. 16:15:07 I went back to the pre-refactor code to build my own Kuryr image 16:15:19 got that working 16:15:33 tonanhngo: Do you think Kuryr is stable enough to be integrated? 16:15:46 So with that, we do have Kuryr working with our Swarm bay 16:16:08 The code for libnetwork is stable, it's just the refactoring 16:16:17 ok 16:16:19 to accomodate the new CNI code 16:16:37 It looks their refactoring breaks 16:17:07 Yeah, the pieces are just not in place completely yet 16:17:20 so for us, we can just use the older version 16:17:37 until they are done with refactoring 16:17:43 sound good 16:17:48 So now with the prototyping done, I will start the patches 16:18:11 I will put 2 images on the openstackmagnum account 16:18:42 The Kuryr old image and the OVS agent image, for Fedora Atomic 16:19:08 That's all I have for now 16:19:16 Thanks tonanhngo 16:19:29 #topic Other blueprints/Bugs/Reviews/Ideas 16:19:34 1. Midcycle summarize 16:19:40 #link https://etherpad.openstack.org/p/magnum-newton-midcycle-topics 16:20:08 Broken link 16:20:09 https://etherpad.openstack.org/p/magnum-newton-midcycle-topics-restored-998 16:20:13 Since some people was not able to attend the midcycle, I want to take this chance to update all of you 16:20:40 Thanks Drago 16:20:50 There are several important decisions in the midcycle 16:21:01 1. Rename bay to cluster 16:21:11 and rename baymodel to clustermodel 16:21:29 Did we open a blueprint on this yet? 16:21:33 https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster 16:21:44 The old term "bay" and "baymodel" will still be valid for a while but deprecated 16:22:05 Eventually, the old terms will be removed 16:22:24 2. Introduce the concept of "node-group" 16:22:43 A cluster will have 2 node-group": master and minion 16:23:12 Should we write a spec on this? since it's a major change. 16:23:12 But users can add more node-groups to a cluster later 16:23:21 https://blueprints.launchpad.net/magnum/+spec/nodegroups 16:23:32 See the blueprint for a link to the spec 16:23:39 Thanks Drago 16:23:41 I am currently drafting it with jvgrant 16:24:19 The bay to cluster renaming and the adding of node-group are the most important decisions 16:24:40 There are several other decisions, which could be found in the etherpad above 16:24:55 So far, any question/concern for the midcycle decisions? 16:25:08 is it an addition or a new api version? 16:25:28 Hi, these 2 bps seems to big change. Do you have any plan or schedule on when to complete them? 16:25:52 considering that it might impact the implementation of other features 16:26:00 rochaporto: cluster will be introduced in v1, node-group might be introduced in v2 (I guess) 16:26:08 +1 16:26:11 +1 16:26:27 garyduan: ASAP 16:26:44 garyduan: Those two BPs should have the most priority 16:26:49 the bay to cluster change will be done in steps, i should have a patch out today for the new cluster api 16:27:01 they will use the same backend as the bay api's 16:27:22 jvgrant: it's a patch in the client? 16:27:53 strigazi: doing the magnum-api first then the client, so i can use the new api's in the client 16:28:12 so bay to cluster renaming makes it to newton, but not nodegroups? 16:28:12 We should stage the patches to avoid disruption. 16:28:47 if jvgrant's patch is only additions it's ok 16:28:47 We do have users trying out Magnum, so it may create confusion 16:29:03 rochaporto: yes, will not be part of the newton release. 16:29:16 it will appear to be additions for users in v1 16:29:32 all previous commands will continue to work as well 16:29:36 I think it's ok 16:30:27 Any further concern/question? 16:30:42 feature freeze is aug 29th? 16:31:12 rochaporto: I think we have a bit flexiable about the feature freeze date 16:31:29 I will discuss with the team about when is the best date to freeze 16:31:37 sounds good 16:31:42 It sounds that nodegroup features will be implemented in next release. Is it correct? 16:31:50 yes 16:32:20 I think you can start the implementation in this release, if nothing is blocking 16:32:43 However, get everything done in this release is almost impossible 16:33:41 OK. Advance topic 16:33:52 2. Enable usage of test account files by default (vipulnayyar) 16:33:59 #link https://bugs.launchpad.net/magnum/+bug/1610186 16:33:59 Launchpad bug 1610186 in Magnum "Use accounts.yaml file as default method to create users for functional tests" [Low,Triaged] - Assigned to Vipul Nayyar (vipulnayyar) 16:34:04 vipulnayyar: ^^ 16:34:10 So, wanted to work on making use of accounts.yaml file default for functional testing. Especially for tests where tenant sharing is required. I'd suggest to have a read up on the bug description if you haven't already. Just wanted to parade this around to get suggestions, if any or some caveats to keep in mind. 16:35:32 Did any other project have similar issues? 16:36:08 Can you describe a little the refactoring? 16:37:06 We use dynamic_credentials in functional tests generated by Tempest. All the users created have separate dynamic tenants. 16:37:29 For tests requiring users in same tenant, we need to use accounts.yaml file. 16:37:55 Ryt now use_dynamic_credentials is used as true implicitly 16:38:06 We need to use it as explicitly false. 16:38:35 AS for refactoring, we just need to add pass a force_tenant_isolation parameter as True to Tempest credentials creation api 16:38:58 Is that the recommended approach for Tempest? 16:39:24 Based on the Tempest doc and api that I read, I believe it is the right approach. 16:39:39 link? 16:39:43 But couldn't find any recommended approacj 16:39:43 to the doc 16:40:35 http://docs.openstack.org/developer/tempest/configuration.html#credential-provider-mechanisms 16:41:03 Maybe we should ask someone from the Tempest team to help review. 16:41:53 vipulnayyar: In which case, you would need the users from the tenant (which dynamic credential is not statisfied)? 16:41:53 Sure 16:42:12 So it's addint pre-provisioned credentials? 16:42:18 So it's adding pre-provisioned credentials? 16:42:19 vipulnayyar: FOr example, which test cases you want to add? 16:42:24 I need it for bay deletion test by different users under same tenant 16:42:36 I see 16:43:08 The pre-provisioned creds would only be used for tests we require. For rest, we can pass tenant isolation parameter to Tempest cred creation api 16:43:40 which would use dynamic credentials as always 16:44:04 OK. For me, it sounds reasonable approach 16:44:12 I'll ask about this on Tempest, also 16:44:34 Thanks vipulnayyar 16:44:38 +1, they would have more expertise than us here 16:44:51 3. Add OpenSUSE to Magnum (Michal Jura) 16:44:51 update the ticket with more information, when you ask 16:45:01 #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/100833.html 16:45:32 mjura: ^^ 16:45:43 we talked about this already with strigazi 16:45:56 I'm going to move this change to contrib/drivers 16:46:14 and adopt changes from comments which I've got already 16:46:24 thank you for code-review 16:46:29 mjura: do you plan to support this driver for the long term? 16:46:45 tonanhngo: yes, this is our idea 16:46:54 mjura: +1. once the driver becomes stable, we'll move it to /drivers. 16:47:01 tomorrow I have also meeting with SUSE engineers 16:47:13 from containers team 16:47:36 we would like to support it for long term as other OpenStack components 16:47:45 +1 16:47:56 we did already demo about openSUSE driver and Magnum 16:48:07 everything works fine 16:48:10 I think it's good to have a contrib driver, it will help us develop the dynamic mechanism for bay drivers 16:48:33 yes, I'm happy to help with it 16:48:43 muralia: is there a mechanism for users to pick up contrib drivers? 16:48:59 (to load the driver) 16:49:02 yes, we'll need to just add an entry point 16:49:28 muralia: if somebody would like to add new driver 16:49:37 he has to add it to entry points 16:49:45 Maybe we should add that details to the user guide, if it's not there yet. 16:50:04 and adding this to magnum.conf to enabled_definitions is not enough 16:50:14 yes, i'll update the user guide. mjura, lets chat once I submit my patch. this will be a good opportunity to test it. 16:50:33 mjura: it didn't work? 16:50:51 muralia: is this patch already submited 16:50:55 not yet 16:51:02 strigazi: entry_points has to be updated too 16:51:11 magnum.conf is not enough 16:51:18 ok 16:51:24 I will include this in README file 16:51:42 about installation 16:51:51 until tomorrow I will upload new patchset 16:51:57 cool 16:52:00 and I will be gone for one week 16:52:10 so, no worries I will be back :) 16:52:13 also cool 16:52:48 mjura: Thanks for your interest to contribute the driver to Magnum. I am looking for the new driver. 16:53:03 #topic Open Discussion 16:53:03 I thank you to everybody 16:53:11 for support and comments 16:53:14 Make the test coverage job voting (Spyros Trigazis) 16:53:21 When a change decreases the test coverage we should not merge it. If we want to increase our test coverage we should stop adding code that decreases it. 16:53:24 yes, I'm big fan of Magnum and k8s 16:53:36 thoughts? 16:53:53 do other projects do this too? 16:53:58 yes 16:54:02 rally 16:54:11 gophercloud 16:54:40 haven't checked for others 16:54:45 What about template changes? 16:54:46 but I think makes sense 16:54:58 I mean python code 16:55:23 I would like the same policy for templates too, but one step at a time 16:55:56 What if there is a major change and the patches are broken up into small pieces? 16:56:27 The tests should be broken in pieces as well 16:56:54 When you write a function you also write a test function 16:57:33 are we ready to make the job voting right away? or do we need to refactor and add more tests before we enable voting? 16:57:54 I can modify the current job to report 16:58:04 ok. 16:58:05 when the coverage decreases and then decide 16:58:14 i like that 16:58:23 Does the coverage test point to the function that fails the coverage? 16:58:44 not sure what you mean, time is up 16:58:52 2 minutes 16:59:03 Ton, can you elaborate 16:59:13 we can follow up on the other channel 16:59:17 ok 16:59:39 Thanks to the Rackspace team for hosting the midcycle, it was very productive in my opinion 16:59:47 +1 16:59:48 Thanks 16:59:51 it was great meeting all of you. 17:00:14 All, thanking for joining the meeting. 17:00:17 +1 17:00:17 #endmeeting