13:00:19 #startmeeting senlin 13:00:19 Meeting started Tue Aug 9 13:00:19 2016 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:23 The meeting name has been set to 'senlin' 13:00:45 hello? 13:02:59 o/ 13:03:07 hi, elynn 13:03:23 hi, everyone~ 13:03:25 evening Qiming 13:03:29 hi, guoshan_ 13:04:06 pls feel free to add items to the meeting agenda 13:04:20 #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Weekly_Senlin_.28Clustering.29_meeting 13:04:43 due to firewall problem, adding meeting items is not easy now, we have to use proxy 13:05:17 yanyan cannot join us today, I heard nothing from xinhui or haiwei 13:05:25 let's get started? 13:05:29 ok, It's my first time in IRC meeting 13:05:37 thanks, guoshan_ 13:05:49 #link https://etherpad.openstack.org/p/senlin-newton-workitems 13:06:09 let's go thru the etherpad and see where we are 13:06:47 hi 13:07:01 yanyan has updated the etherpad for Rally support 13:07:05 hi, lixinhui_ 13:07:13 we just got started 13:07:43 the Rally side support was just merged, Roman has help review another patch in senlin code base, which is good ... 13:08:13 I'm not gonna copy/paste yanyan's update here 13:08:17 please read it 13:08:36 Will delete those text later 13:08:44 integration test 13:08:54 test job has been merged at gate side 13:09:11 we found things to be fixed related to neutron set up 13:09:42 these tests are pretty important for us to ensure we are not breaking any contracts with any other services 13:10:29 at the same time, I'm working on revising the docs about testing infrastructure 13:10:36 #link http://git.openstack.org/cgit/openstack/senlin/tree/doc/source/developer/testing.rst 13:10:47 the current doc is only about unit tests 13:11:13 while we have added api test, functional test, integration test and stress test (ongoing) 13:11:37 need to update the docs so we all know how to run them in our local env 13:12:05 pls help review the patches and see if there things to be fixed 13:12:21 https://review.openstack.org/347654 13:12:22 sure, pleasure to do that 13:12:29 https://review.openstack.org/348110 13:12:41 moving on ... 13:12:46 health management 13:13:17 lixinhui_, the LB member status one is fixed? 13:14:02 2 of 3 patches have been approved 13:14:19 the root one is pending for cores' approval 13:14:19 great 13:15:03 next thing is about fencing 13:15:21 I know you have added some support into python-openstacksdk side 13:15:52 those are already well shaped, just address brian's concern would be fine 13:15:56 neutron-lbaas community is not very active 13:15:57 I added Armando as reviewer 13:15:57 hope he can help 13:15:57 in future, Octavia will replace lbaas 13:16:06 Brian just add comments there 13:16:23 yep 13:16:39 okay 13:16:39 I will followup soon 13:16:48 for those of you who are not aware of these patches: 13:16:49 https://review.openstack.org/352723 13:16:56 https://review.openstack.org/351061 13:17:20 these are the ones added to sdk so that we can invoke nova service operations later -- for fencing's purpose 13:17:46 moving on to next item 13:17:59 documentation, not much update from me 13:18:12 but I did submitted some patches about api docs 13:18:41 one thing to notice is that the global version requirement of os-api-ref has been bumped to 0.4.0 13:19:00 which means it has a better support to success code and error code now 13:20:03 if you are interested in it, you can check this subsection: http://git.openstack.org/cgit/openstack/os-api-ref/tree/doc/source/usage.rst#n185 13:20:38 moving on to next one 13:20:46 profile/policy version control 13:20:58 yanyan has proposed a patch which I forgot to review 13:21:11 please jump on to it when you have time 13:21:40 it is very important a feature, though in future we plan to generalize versioning control of many things 13:22:11 https://review.openstack.org/#/c/348709/ 13:22:18 will review it later. 13:22:19 ^ is the patch 13:22:29 thx elynn 13:23:07 next topic is container cluster support 13:23:28 haiwei has a new patchset for review: https://review.openstack.org/#/c/349906 13:23:53 though it still not comprehensive, as a working prototype, it looks not bad 13:24:09 also need reviews from you 13:24:31 haiwei is not online today, seems 13:24:41 so we move on to next one 13:24:47 zaqar receiver support 13:25:06 yanyan has been pushing hard on zaqar support at sdk side 13:25:28 due to api doc and some implementation nits, the patches are still pending for review/merge 13:25:42 but we are pretty close to get it done 13:26:06 next one 13:26:11 events/notifications 13:26:37 not update from me on this, probably we won't have time to get it done in newton 13:27:40 some updates on cluster-collect 13:28:02 the senlin side has a fix to the docs merged: https://review.openstack.org/350982 13:28:40 and finally we got API micro-versioning support merged in openstacksdk: https://review.openstack.org/343992 13:29:17 following that, we got a new API (collect_cluster_attrs) merged: https://review.openstack.org/350978 13:29:50 I'm now working at senlinclient side on the micro-versioning and cluster-collect operation support 13:31:03 the output is something like this: 13:31:04 $ senlin cluster-collect -p details.addresses.private[0] c1 13:31:04 WARNING (shell) "senlin cluster-collect" is deprecated, please use "openstack cluster collect" instead. 13:31:04 10.0.0.12 13:31:04 10.0.0.13 13:31:04 10.0.0.14 13:31:48 looks great! 13:32:27 and also this: 13:32:28 $ openstack cluster collect -f value -c attr_value --path details.addresses.private[0] c1 13:32:28 10.0.0.12 13:32:28 10.0.0.13 13:32:28 10.0.0.14 13:32:56 need to add test cases then commit the patch 13:33:13 a question, how would the users know what kind of attributes they can get? 13:33:34 it is a JSON path 13:33:47 when you do senlin node-show 13:33:55 you get the attributes 13:33:58 oh, I see. 13:34:32 then you think to yourself, how can I get all the values from all nodes instead of doing cluster node-show one by one 13:34:52 well, that is when you decide to use senlin cluster-collect or openstack cluster collect 13:35:27 by the way, just found a bug in sdk and proposed a patch 13:35:28 https://review.openstack.org/352853 13:35:31 Glad that we could provide this API. 13:36:02 when senlin is retrieving the details about a nova server, the 'image' property disappeared, so does the 'flavor' property 13:36:15 hope it can be merged soon 13:37:17 besides that, I don't have more updates 13:37:38 questions/comments about items on etherpad? 13:38:20 okay, that is a no 13:38:23 Not from me, newton-3 will be end this month? 13:38:23 :) 13:38:51 yep, http://releases.openstack.org/newton/schedule.html 13:39:31 newton-3 on august 29 13:39:40 rc-1 on sep 12 13:39:47 okay.thanks 13:39:55 rc-2 on sep-26 13:40:28 since we don't have a lot of features pipeline 13:40:45 so we don't need to practice a feature freeze type of thing 13:41:11 just work to our best ... deliver what can be made stable 13:41:18 #topic open discussions 13:42:04 anything else? 13:42:16 Qiming, have you tried the vertioned_nova? 13:42:31 versioned_nova? 13:42:32 no 13:42:39 what is versioned_nova? 13:43:05 a software? 13:44:13 https://review.openstack.org/350364 13:45:11 okay, you mean versioned notification from nova 13:45:47 it is good to add versioned_notifications as a target 13:46:23 my question was whether that new target can be used for notifications with 'notifications' as topic 13:47:02 why that way? 13:47:24 or, a different way to ask the question ... has nova migrated all their notifications to this versioned way? 13:48:54 is that enough to migrate all instance.update? 13:48:55 a safer way to add 'versioned_notifications' as a Target is to keep the old one, we won't get hurt if there are not messages with that topic 13:50:04 but if nova is only migrating part of their notifications to the versioned way, ... that is bad 13:50:14 according to the doc, original one will be retired 13:50:27 why we receive two channels 13:50:37 I never trust their docs 13:50:47 they said they will work out a v3 api 13:50:56 they said they will split scheduler out 13:51:21 I tested instance.update and service.update 13:51:36 we can listen to two channels, if one channel is really quiet, we can delete it later 13:51:54 yes, I figured that 13:52:08 but instance.update and service.update is not the whole world, right? 13:52:13 how about noisy 13:52:23 according to its design, yes 13:52:47 whole world of nova notifications 13:52:52 just throw a question here 13:53:20 we can leave the old one till compute service failure detection 13:54:18 a target is constructed with a 'topic' and an 'exchange' 13:54:29 we already set the 'exchange' to 'nova' 13:54:43 there is no change on exchange 13:55:09 I use Rabbitmq as message provide 13:55:16 the combination means, we listen to 'notifications' from 'nova' 13:55:37 if nova has migrated all its notifications to the versioned implementation 13:55:43 that target should be quiet 13:55:59 provider 13:55:59 and confirm no change on exchange 13:56:01 if it is not, it means nova is still doing the migration 13:56:17 I know you didn't change exchange 13:56:36 I'm trying my best to explain to you why I think keeping the existing target doesn't hurt us 13:57:30 not I change the exchange 13:57:48 I just trying to explain the test result 13:57:52 anyway 13:57:52 if nova has migrated all notifications to versioned one, the existing target will be quiet, we won't get anything from it, we are not hurt 13:58:12 you are only testing instance.update and service.update, right? 13:58:48 do we know when an instance is stopped, or deleted? using the 'instance.update' notification? 13:59:10 or maybe the protocol has changed, I haven't looked into that for a time 13:59:28 yes 13:59:55 okay, I'll do some experiements to verify 14:00:00 stop or delete are details of instance.update 14:00:01 thanks for bringing this up 14:00:11 time is up 14:00:18 thanks for joining, guys 14:00:21 #endmeeting