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