09:00:45 <yuval> #startmeeting karbor
09:00:46 <openstack> Meeting started Tue Dec 20 09:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is yuval. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:50 <openstack> The meeting name has been set to 'karbor'
09:01:04 <yuval> Hello everybody, and welcome to Karbor's weekly meeting
09:01:11 <chenying> hi
09:01:15 <edisonxiang> hi
09:01:16 <leon_wang> hi
09:01:26 <yuval> saggi will not be here today
09:02:01 <yuval> zhonghua: here?
09:02:08 <zhonghua> hi
09:02:21 <chenying> yinwei said that she will come later.
09:02:21 <yuval> zengchen: zhangshuai: ?
09:02:32 <zengchen> yuval:i am here.
09:02:41 <zengchen> yuval:how are you.
09:02:51 <yuval> zengchen: fine, thanks :)
09:03:11 <yuval> alright
09:03:30 <yuval> #topic Make fullstack tests voting
09:03:48 <yuval> Over the last 2 weeks we had 3 bugs affecting our fullstack tests
09:04:10 <yuval> 1) xenial virtualenv issue 2) gitattributes issue 3) devstack+heat issue
09:04:38 <chenying> you mean that change the voting status of fullstack tests?
09:04:49 <yuval> the gate was out for a long time, and we had to merge patches without taking into account the fullstack gate
09:05:06 <yuval> so I was thinking about making the gate voting
09:05:21 <yuval> what is your opinion?
09:06:14 <chenying> +1
09:06:20 <edisonxiang> +1
09:06:28 <zengchen> yuval:but, fullstack can find some error even if all the unit test pass.
09:06:47 <yuval> the only downside, is that if we run into issues like those we had last week, we will not be able to merge patches
09:06:59 <chenying> but now the plugins have not been refactored, some fullstack test have not been run.
09:07:19 <yuval> the other option is leave the gate non-voting, but consider it as mandatory - cores shouldn't merge patches when gate fails
09:07:32 <yuval> chenying: only 1 test is being skipped
09:07:46 <chenying> yuval: ok
09:08:37 <yuval> zengchen: I don't understand your point
09:09:27 <zengchen> yuval:I agree with you.
09:09:58 <yuval> right, next topic
09:10:06 <zengchen> yuval:but if the issue happened like last week. then how do we do?
09:10:13 <yuval> zengchen: fix the gates
09:10:22 <chenying> The fullstack or tempest tests in other projects seam  that is not voting status.
09:10:33 <zengchen> yuval:+1
09:11:03 <yuval> chenying: yes, the fullstack/tempest gates seem to be more fragile
09:12:53 <yuval> until we make it voting, or if we decide to leave it as is - please do not merge patches with failing fullstack
09:13:02 <yinwei_computer> hello, I'm on line now
09:13:08 <yuval> #topic Adjust protection plugins
09:13:53 <yuval> we currently have the following protection plugins to adjust to the protection plugin api:
09:14:19 <yuval> cinder backup, image to bank, server to bank
09:14:39 <yuval> and write the new network topology to bank plugin
09:15:24 <yuval> I've almost finished the cinder backup protection plugin, and upload it as soon as it is complete
09:15:35 <yinwei_computer> so what's the target of the adjustment?
09:15:57 <yuval> yinwei_computer: https://review.openstack.org/348163 was merged
09:16:05 <zhonghua> yuval: great job
09:16:12 <yinwei_computer> ok, got it
09:16:33 <yinwei_computer> so every protection plugin should align with the new mechanism
09:16:38 <yuval> yinwei_computer: yup
09:17:44 <chenying> Adjust protection plugins, The vendors also hope that the interface exposed should be simple enough. Do we real need expose all the hooks to them to develop plugins? Can we keep some hooks in the base plugins? Most of time, the vendor only care the mian hook of operation.
09:18:02 <yuval> chenying: all the hooks are optional, including the main
09:18:11 <yuval> chenying: vendors can simply implement the main hook alone
09:18:18 <yinwei_computer> I heard that some providers have already developed plugins based on original interfaces.  Will there be an adapter base class to keep their plugins unchanged? @yuval
09:18:45 <chenying> yinwei_computer: +1
09:19:12 <yuval> yinwei_computer: besides the api, there is another change - hooks are synchronous. each hook needs not only to start the work (i.e cinder_client.backups.create ...) but also poll and verify it is complete
09:19:59 <yinwei_computer> so by default, the protection would be serialized instead of on parallel previously?
09:20:40 <yuval> yinwei_computer: it will be parallel, in relation to the number of greenthreads in the taskflow executor
09:21:13 <yinwei_computer> @yuval I see.  do you think the adapter solution is feasible?
09:21:14 <yuval> yinwei_computer: previously, all work began in the same moment, with no order between different types of resources
09:21:41 <yuval> yinwei_computer: it is, but it might require some adaptions on the protection plugin's part
09:22:33 <yinwei_computer> the adapter itself will do the adpations work, and thus those existed provider plugins could keep unchanged.
09:23:31 <yuval> yinwei_computer: might be possible, but we should consider marking that interface as deprecated
09:23:41 <chenying> The creat_backup/delete_backup/restore_backup these interfaces seam more reasonable and suitable for vendors to understand the logic of plugins. We can consider adding the adapter module in base class.
09:23:50 <yinwei_computer> if they prefer better control of protection dependencies, they could choose to develop new plugins.  But if not, they could keep it the same.
09:24:44 <yuval> yinwei_computer: chenying: again, the problem is not in the api, but the sync/async nature of the protection plugins
09:25:33 <yinwei_computer> yuval: agree. so your concern is the effort to maintain two series of interfaces in our code, right?
09:26:28 <yuval> yinwei_computer: yes
09:27:35 <yinwei_computer> chenying: what do you think? maintain two series of interfaces, and we need map the old one into the new model.
09:27:50 <yinwei_computer> It seems to me like the compatible issue.
09:28:24 <chenying> maintain two series of interfaces sounds not a good idea.
09:28:37 <yinwei_computer> or we will support incoming  providers with the simplified interfaces as well?
09:31:03 <chenying> or we will support incoming  providers with the simplified interfaces as well?  I don't understand.
09:31:45 <yinwei_computer> option 1: only provide adapter to those old provider plugins;
09:32:20 <yinwei_computer> option2: for incoming new provider plugins, we also provider two interfaces: simplified one and full one.
09:33:27 <chenying> yuval: what's your opinion?
09:33:49 <yuval> How many vendors we have right now who already wrote protection plugins? I know only about EISOO
09:35:23 <chenying> The commvalt is developint the plugins base on the old interfaces.
09:36:10 <yuval> chenying: let's start with working with the vendors and try to migrate into the current api
09:36:33 <yuval> chenying: shouldn't be that hard, and they can consult with us
09:37:11 <yinwei_computer> yuval: currently we heard the voice that vendors prefer simplified version interfaces :(
09:37:38 <chenying> yinwei_computer: +1
09:37:48 <yinwei_computer> they prefer an idiot way if they don't have a dependency organization requirement
09:38:37 <yuval> I'll send the cinder backup protection plugin, maybe it will be clearer that is shouldn't be much effort to migrate
09:39:09 <yinwei_computer> I guess the adapter is not an independent interface series, but a reference implementation, like cinder lvm driver.
09:39:17 <yinwei_computer> ok
09:39:31 <chenying> ok good idea.
09:39:49 <yuval> #topic Ocata bugs and schedule
09:40:05 <yuval> Ocata MS2 was last week
09:40:28 <yuval> you can view Ocata schedule here: https://releases.openstack.org/ocata/schedule.html
09:40:54 <yuval> January 23-27 is MS3
09:41:21 <yuval> we still have unresolved bugs, and worse - unassigned bugs here: https://launchpad.net/karbor/+milestone/ocata
09:42:12 <yuval> ಥ_ಥ
09:43:08 <chenying> I don't think all the tasks in bug list must be solved in Ocata. If it is a real a problow/error, we need fix it. If it is a optimized task, we can do it later version.
09:43:14 <yuval> zengchen: edisonxiang: chenying: yinwei_computer: zhonghua: please assign bugs to yourselves if you think you can handle them soon
09:43:42 <yuval> chenying: if you think something can be deferred to pike, can you comment in the bug and/or mark it?
09:44:23 <zengchen> yinwei_computer:https://bugs.launchpad.net/karbor/+bug/1577698. look at my comment. I think it is resolved now.
09:44:24 <openstack> Launchpad bug 1577698 in Karbor "set per request one client for sync protection status" [High,Triaged]
09:44:34 <edisonxiang> yuval:)
09:44:45 <chenying> yuval: OK
09:45:17 <yuval> I see some bugs assigned to Wang Hui and Chen Huayi, which are not very active, I believe
09:46:34 <yuval> #topic Open Discussion
09:46:56 <yuval> anything else? :)
09:48:20 <yuval> alright, thank you all!
09:48:28 <yuval> may the force be with you
09:48:41 <yuval> #endmeeting