13:00:07 <yanyanhu> #startmeeting senlin 13:00:08 <openstack> Meeting started Tue Nov 29 13:00:07 2016 UTC and is due to finish in 60 minutes. The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:12 <openstack> The meeting name has been set to 'senlin' 13:00:22 <yanyanhu> hi, guys 13:00:32 <XueFengLiu> hi yanyan 13:00:37 <yanyanhu> hi, XueFengLiu 13:00:44 <lvdongbing> hi, all 13:00:48 <yanyanhu> hello 13:00:52 <Qiming> hi 13:00:56 <yanyanhu> hi, Qiming 13:01:13 <yanyanhu> lets wait for a while for other attenders 13:01:20 <yanyanhu> here is the agenda, https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282016-11-29_1300_UTC.29 13:01:27 <yanyanhu> please feel free to add items 13:02:26 <yanyanhu> ok, lets move on 13:02:39 <yanyanhu> #topic ocata workitem 13:02:45 <yanyanhu> https://etherpad.openstack.org/p/senlin-ocata-workitems 13:02:51 <yanyanhu> here is the list 13:03:03 <yanyanhu> - Improve tempest API test 13:03:21 <yanyanhu> I think we can consider to start working on it for the versioned request support is almost done 13:04:39 <yanyanhu> the basic idea is adding the verification of exception message 13:04:52 <Qiming> we have removed the performance benchmarking work completely? 13:04:56 <yanyanhu> to ensure the request handling logic is correct 13:05:11 <yanyanhu> Qiming, I plan to move it back to todo list 13:05:26 <yanyanhu> for I don't have time to work on it recently... 13:05:36 <yanyanhu> if anyone want to pick it up, that will be great 13:05:50 <Qiming> I see 13:06:11 <yanyanhu> the basement is there, just need efforts to support more profiles and scenarios 13:06:59 <yanyanhu> ok, next one 13:07:04 <yanyanhu> HA support 13:07:17 <yanyanhu> hi, lixinhui 13:07:34 <yanyanhu> we just started the topic about HA in seconds :) 13:07:55 <lixinhui> okay 13:07:57 <lixinhui> :) 13:08:30 <yanyanhu> any new progress? 13:08:33 <lixinhui> in the past week, I submitted the ocativia BP and patch 13:08:43 <Qiming> noticed that and your patch 13:08:46 <Qiming> good work 13:08:52 <yanyanhu> great 13:09:28 <lixinhui> Michael has some question about the background 13:09:44 <lixinhui> and I gave some answer 13:10:00 <yanyanhu> about using lbaas hm for HA purpose? 13:10:35 <lixinhui> if answer can not resolve his questions, may need to discuss that on the weekly meeting of ocativa 13:10:55 <lixinhui> yes, I mentioned the use case 13:11:05 <Qiming> emm 13:11:07 <lixinhui> https://review.openstack.org/402296 13:11:21 <Qiming> hope it won't become next vpnaas 13:11:25 <Qiming> which is dying 13:11:34 <lixinhui> yes, it is dying 13:12:04 <yanyanhu> people do have strong requirement for native lb support 13:12:05 <lixinhui> anyway, not a big change. hope he can accept 13:12:19 <yanyanhu> although imho, lbaas is not ready fro production requirement 13:12:26 <yanyanhu> s/fro/for 13:12:33 <Qiming> agreed 13:13:22 <yanyanhu> so maybe we can give them a simple introduction about our use case 13:13:35 <Qiming> they may and may not care 13:13:41 <yanyanhu> Qiming, yes 13:13:50 <yanyanhu> so we just try our best 13:13:56 <Qiming> it is not about our use case 13:14:00 <Qiming> it is their BUG 13:14:01 <lixinhui> okay 13:14:06 <yanyanhu> actually this is a contribution for lbaas I feel 13:14:10 <Qiming> a serious bug, they need to take care of it 13:14:12 <yanyanhu> no harm for them :) 13:14:39 <yanyanhu> Qiming, you mean the incorrect health status of lb member 13:14:43 <Qiming> if lbaas is maintaining health status for nodes, they should do it right 13:15:00 <yanyanhu> I mean omitting event for status change 13:15:20 <Qiming> we tried help fix it, and they reject the patch, and they "WON'T" fix the bug 13:15:43 <yanyanhu> I have more strong feeling that our work about event/notification is such important :) 13:15:45 <Qiming> now xinhui is trying another workaround, let them send out notifications when node health change 13:15:58 <lixinhui> I think it is not reasonable to submit patch into lbaas any more 13:16:00 <yanyanhu> Qiming, yes, have the save feeling for that patch 13:16:09 <yanyanhu> anyway, it's their decision. 13:16:24 <lixinhui> so we are trying to use ocativia to emit event 13:16:38 <lixinhui> then any listener can handle in their own way 13:16:51 <Qiming> maybe need a ptl to ptl talk with them 13:16:52 <yanyanhu> lixinhui, yes, that's pretty reasonable 13:16:54 <lixinhui> no need to care about neutron-lbaas anymore 13:17:19 <lixinhui> yes, agree Qiming :) 13:17:29 <yanyanhu> so neutron-lbaas and ocaticia are two individual projects? 13:17:36 <lixinhui> yes 13:17:41 <yanyanhu> ocativia 13:17:44 <yanyanhu> I see 13:17:47 <lixinhui> neutron-lbaas is dying 13:17:57 <yanyanhu> I thought they are the same project 13:18:08 <Qiming> octavia 13:18:20 <lixinhui> haha 13:18:31 <yanyanhu> :) 13:18:38 <XueFengLiu> :) 13:19:07 <haiwei_> there is lbaasv2? 13:19:08 <lixinhui> I will keep tracking the patch 13:19:18 <lixinhui> that is my part 13:19:21 <yanyanhu> so maybe we need to have further discussion on this issue 13:19:22 <lixinhui> of update 13:19:37 <lixinhui> Yes, Haiwei_ 13:19:38 <yanyanhu> to see how to move on 13:19:45 <lixinhui> lbaasv1 has been droped 13:20:01 <yanyanhu> yes, lbaasv2 is now the default enabled api 13:20:13 <Qiming> neutron ptl is armax 13:20:36 <lixinhui> Michael Johnson is the octavia PTL 13:20:37 <yanyanhu> octavia is part of neutron? 13:20:42 <Qiming> yes 13:20:55 <yanyanhu> or an individual project? 13:20:56 <lixinhui> yes 13:20:57 <Qiming> octavia has its own core team: https://review.openstack.org/#/admin/groups/370,members 13:21:12 <lixinhui> they have the same weekly meeting with neutron 13:21:17 <haiwei_> lbaas is dying, lbaasv2 is the substitute？ 13:21:25 <Qiming> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2205 13:21:30 <Qiming> yes, I think so, haiwei_ 13:22:05 <yanyanhu> wait a minute, lbaasv1 is dying or lbaas project is dying? 13:22:28 <elynn> Oh, I thought lbv2 is dying too 13:22:35 <yanyanhu> I see 13:22:36 <haiwei_> thanks goddess , they are not dying both 13:22:46 <yanyanhu> ... 13:22:47 <lixinhui> lbaasv1 has been dropped 13:22:52 <yanyanhu> yes, it is 13:23:14 <haiwei_> v1 is dead, v2 is dying? 13:23:31 <yanyanhu> I don't know, I'm listening :) 13:23:56 <lixinhui> I did not hear anything about v2 is dying 13:24:27 <yanyanhu> sigh, if so, lbaas project is ok 13:24:30 <yanyanhu> just its v1 api is deprecated which is expected 13:24:31 <haiwei_> it seems the advanced feature like lbaas , vpn are done by vendors themselves 13:24:36 <lixinhui> ocativa will replace neutron-lbaas 13:24:39 <lixinhui> project 13:24:53 <lixinhui> octavia 13:25:15 <lixinhui> they are on the path of transforming 13:25:24 <yanyanhu> replace? you mean enhancement or completely replacement 13:25:38 <yanyanhu> so no more haproxy based lb 13:25:42 <Qiming> deprecation 13:25:44 <yanyanhu> only vm based one 13:26:01 <lixinhui> that is another reason why we should not submit patch to the dying project 13:26:04 <yanyanhu> and neutron-lbaas will be renamed to octivia? 13:26:38 <lixinhui> by default, octavia provide haproxy lb 13:26:54 <Qiming> haproxy installed into a VM 13:26:54 <lixinhui> and it provide driver for different vendors to plugin 13:27:09 <yanyanhu> yes, this is what lbaas is doing now 13:27:19 <lixinhui> so it is not necessary to have also neutron-lbaas... 13:27:58 <yanyanhu> so octivia will replace lbaas in bigtent? 13:28:22 <lixinhui> no one ever mention big tent obviously 13:28:26 <yanyanhu> anyway, proposing patch to octivia is reasonable 13:28:34 <elynn> http://lists.openstack.org/pipermail/openstack-dev/2016-November/106911.html 13:28:51 <XueFengLiu> Octavia is currently the reference backend for Neutron LBaaS. In the near future, Octavia is likely to become the standard OpenStack LBaaS API endpoint. 13:29:00 <XueFengLiu> https://github.com/openstack/octavia 13:29:23 <lixinhui> Yes 13:29:34 <yanyanhu> I see. 13:30:00 <Qiming> should we move on? we have been talking about this extraterrestrial project for 30 minutes 13:30:02 <elynn> So customers who use lbv1 API will be easy to transfer to use octavia, right? 13:30:15 <yanyanhu> so we just focusing on communication with octavia team 13:30:15 <Qiming> 20 minutes, sorry 13:30:36 <yanyanhu> sorry, lets discuss this issue offline 13:30:39 <yanyanhu> lets move on now 13:30:49 <Qiming> ping the cores, send emails to mailinglist, we will find out 13:31:00 <yanyanhu> no document update I think 13:31:13 <Qiming> no 13:31:14 <yanyanhu> version request support 13:31:23 <yanyanhu> almost done 13:31:32 <yanyanhu> I will finish receiver part this week 13:31:45 <yanyanhu> I think XueFengLiu and lvdongbing's work has been done 13:32:05 <yanyanhu> then we can anounce the first step is finished 13:32:08 <lvdongbing> yes 13:32:19 <XueFengLiu> Yes, only action create/delete need to do. 13:32:42 <yanyanhu> XueFengLiu, thanks 13:32:46 <Qiming> remove line 20? 13:32:57 <yanyanhu> Qiming, yes 13:33:09 <yanyanhu> ok, next one, container profile 13:33:12 <yanyanhu> hi, haiwei_ 13:33:29 * Qiming really enjoys pressing the DEL key 13:33:42 <yanyanhu> :) 13:34:10 <haiwei_> hi, yanyanhu, I think we need to discuss the image management of containers 13:34:33 <yanyanhu> haiwei_, yes, that is an important issue 13:34:43 <yanyanhu> currently, we can get image from glance I think? 13:34:52 <yanyanhu> although it is not layered 13:34:59 <haiwei_> I think the next step maybe the image jobs, what do you think Qiming 13:35:18 <Qiming> what do you mean by image jobs? 13:35:24 <haiwei_> I am think about using Zun yanyanhu 13:35:48 <haiwei_> how to give the container an image 13:35:55 <Qiming> glance? 13:36:15 <Qiming> when you do glance image-create, you have this: 13:36:15 <yanyanhu> yes, maybe this is the first choice, at least for now? 13:36:16 <Qiming> --container-format <CONTAINER_FORMAT> 13:36:16 <Qiming> Format of the container Valid values: None, ami, ari, 13:36:16 <Qiming> aki, bare, ovf, ova, docker 13:36:18 <haiwei_> currently we only support downloading the images from the docker lab 13:36:46 <haiwei_> not the vm's image 13:37:06 <Qiming> 'container-format docker' 13:37:10 <Qiming> what does that mean? 13:37:42 <haiwei_> this is glance image-create? 13:37:47 <Qiming> yes 13:37:52 <XueFengLiu> It is 13:38:09 <haiwei_> never saw this before 13:38:29 <yanyanhu> may need more investigation here before making decision :) 13:38:32 <haiwei_> we usually use bare for container-format 13:38:32 <Qiming> okay 13:38:45 <haiwei_> ok, will check it 13:38:51 <yanyanhu> haiwei_, great, thanks a lot 13:38:51 <XueFengLiu> this means we can upload a docker image to glance 13:38:56 <Qiming> current docker profile relies on docker to parse and download the image 13:39:03 <XueFengLiu> use glance-create, I thiknk 13:39:06 <yanyanhu> Qiming, yes, it is now 13:39:16 <Qiming> em ... primary use case was for nova-docker I think 13:39:23 <lvdongbing> that's the way nova-docker used to work 13:39:39 <yanyanhu> so maybe an important issue is figuring out how to consume container image stored in glance 13:39:40 <Qiming> not sure how useful it is if we let docker(d) to check the image 13:40:02 <yanyanhu> zun has the same problem I think 13:40:31 <Qiming> the assumption is that the controller node has access to either the public hub or a local registry 13:40:55 <Qiming> it sounds more of the configuration/deployment topic than a senlin programming job ? 13:41:20 <yanyanhu> Qiming, yes it is 13:41:52 <haiwei_> if the image is not uploaded to glance, glance will download it from public lib and then support it to other project? 13:42:04 <yanyanhu> maybe this can be a property of container profile? 13:42:31 <yanyanhu> haiwei_, not sure about how it works 13:42:34 <Qiming> if wanted, user (of a public cloud) can create a vm for storing his private docker images, then start a container cluster referencing images stored there? 13:42:56 <Qiming> docker determines the registry using tag, .... 13:42:59 <yanyanhu> Qiming, you mean local registry for each container cluster? 13:43:06 <haiwei_> why use a vm to store the images? 13:43:12 <Qiming> just want to say that is possible 13:43:17 <Qiming> for public cloud 13:43:18 <haiwei_> ok 13:43:44 <yanyanhu> maybe we can collect different options and then have a dicussion to see which way is better 13:43:48 <Qiming> for private cloud, you can build it somewhere so long the controller node can access its 5000 port 13:44:24 <yanyanhu> haiwei_, maybe we can collect all possible options in an etherpad 13:44:38 <haiwei_> ok, yanyanhu, will create one 13:44:41 <yanyanhu> and we can leave comments there 13:44:49 <yanyanhu> haiwei_, great, thanks :) 13:44:59 <yanyanhu> ok, only 15 minutes left 13:45:04 <yanyanhu> lets move to next topic 13:45:09 <yanyanhu> event/notification 13:45:15 <yanyanhu> hi, Qiming, your turn 13:46:19 <Qiming> okay, almost done 13:46:25 <yanyanhu> great 13:46:34 <Qiming> common interface abstracted 13:46:39 <yanyanhu> https://blueprints.launchpad.net/senlin/+spec/generic-event 13:46:48 <Qiming> no reviews yet 13:46:57 <Qiming> may have to approve it myself 13:47:13 <Qiming> next thing would be about the configuration part 13:47:29 <Qiming> making 'database' and 'message' two plugins 13:47:40 <Qiming> and load them via steverdore 13:48:01 <Qiming> add senlin.conf section/options to control when/how to log ... 13:48:05 <yanyanhu> sounds great 13:48:39 <yanyanhu> about the message way, so the messages will be published to a public queue? 13:48:58 <Qiming> yes 13:49:01 <yanyanhu> which is accessable for all openstack services 13:49:06 <yanyanhu> I see 13:49:13 <Qiming> it is controller plane thing 13:49:20 <Qiming> irrelevant to zaqar 13:49:25 <yanyanhu> this is also what we expect octavia to do :) 13:49:31 <yanyanhu> Qiming, I see 13:49:45 <Qiming> zaqar is USER-FACING message queue 13:50:04 <yanyanhu> yes 13:50:23 <yanyanhu> sorry for didn't get time to review the code. Will check it tomorrow 13:50:36 <Qiming> if you have check the code: 13:50:44 <yanyanhu> Qiming, please feel free to self approve to avoid denpendency issue 13:50:45 <Qiming> 85 def _emit(self, context, event_type, publisher_id, payload): 13:50:45 <Qiming> 86 notifier = messaging.get_notifier(publisher_id) 13:50:45 <Qiming> 87 notify = getattr(notifier, self.priority) 13:50:45 <Qiming> 88 notify(context, event_type, payload) 13:50:48 <Qiming> that is all 13:51:02 <yanyanhu> looks simple 13:51:27 <yanyanhu> get_notifier is provided by oslo? 13:51:33 <Qiming> yes 13:51:35 <yanyanhu> I mean the backend logic 13:51:37 <yanyanhu> I see 13:51:59 <Qiming> we have a thin wrapper over it 13:52:04 <Qiming> also pretty simple 13:52:19 <yanyanhu> oh, is there any limit about publishing message to this public queue in control plane? 13:52:30 <Qiming> don't think so 13:52:47 <Qiming> it is the same message service for rpc 13:53:01 <yanyanhu> I mean if a service publishs too many messages, it could break the queue? 13:53:30 <Qiming> no experience 13:53:48 <yanyanhu> me neither... 13:54:00 <Qiming> if you have ever checked events collected by ceilometer, you will realize that we are very cautious on this 13:54:16 <yanyanhu> yep 13:54:24 <Qiming> if you compare this to the number of RPC calls received by keystone 13:54:34 <yanyanhu> I know ceilometer gets lots of message from other services 13:54:34 <Qiming> by neutron 13:54:55 <Qiming> things we are sending are trivial 13:55:21 <yanyanhu> yes, compared with others 13:55:55 <Qiming> also compare to what nova is sending out: http://git.openstack.org/cgit/openstack/nova/tree/nova/notifications/objects/instance.py#n246 13:56:14 <yanyanhu> @@ 13:56:42 <yanyanhu> message for each status switching for each instance 13:57:11 <Qiming> so I'm not that worried about it 13:57:14 <yanyanhu> ok, seems we don't need to worry about this issue 13:57:16 <yanyanhu> yep 13:57:28 <Qiming> in addition, we are making the behavior configurable 13:58:00 <yanyanhu> I see 13:58:34 <yanyanhu> ok, these are all workitems on the list 13:58:38 <yanyanhu> the time is almost done 13:58:48 <yanyanhu> any more update? 13:58:57 <yanyanhu> if not, will end the meeting. 13:59:03 <yanyanhu> hi, lixinhui, still there? 13:59:24 <yanyanhu> if it's ok, want to talk with you about the patch for octavia 13:59:47 <yanyanhu> we can discuss how to work on it together 13:59:53 <yanyanhu> to push it move on 14:00:05 <yanyanhu> ok, time is over. Thanks you guys for joining 14:00:09 <yanyanhu> have a good night 14:00:12 <yanyanhu> #endmeeting