14:01:00 <gampel> #startmeeting Smaug
14:01:01 <openstack> Meeting started Tue Mar  8 14:01:00 2016 UTC and is due to finish in 60 minutes.  The chair is gampel. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'smaug'
14:01:14 <gampel> hi zhonghua-lee
14:01:20 <zhonghua-lee> hi
14:01:30 <gampel> who is here  ?
14:01:34 <saggi1> hi
14:02:15 <gampel> #info saggiq ,zhonghua-lee , gampel  in the meeting
14:02:22 <xiangxinyong456> hi
14:02:31 <yuval> Hey
14:02:45 <gampel> #info xiangxinyong456 , yuval in the meeting
14:03:05 <gampel> Welcome Yuval,   Please welcome yuval he joined the team this week
14:03:24 <zhonghua-lee> welcome
14:03:32 <gampel> Lets start or should we wait for someone
14:03:51 <gampel> #topic Smaug API v1.0
14:04:06 <gampel> I am the only one that approved it, please vote so we could merge tomorrow or fix it
14:04:22 <gampel> #link https://review.openstack.org/#/c/244756/
14:04:55 <zhonghua-lee> I will go over it later
14:05:02 <gampel> are there any open issues in the  API that someone what to  talk about ?
14:05:25 <gampel> we are  Missing operation log will be added in another patch
14:05:32 <xiangxinyong456> ok
14:05:40 <gampel> saggi will you take care of the next patch
14:05:48 <zhonghua-lee> looks good, no question
14:05:57 <xiangxinyong456> eran
14:06:36 <gampel> yes xiangxinyong456:
14:06:47 <xiangxinyong456> do you think we need the modify workflow in the version 1?
14:06:47 <gampel> saggi: ?
14:07:04 <saggi1> gampel: I don't understand the question
14:07:40 <gampel> #action saggi send another patch for the operation log
14:08:13 <gampel> xiangxinyong456: can you please explain i am not sure i understand
14:08:38 <xiangxinyong456> ok
14:09:07 <xiangxinyong456> about the update operation
14:09:39 <gampel> which update ?
14:10:20 <xiangxinyong456> you know we need add ,delete,select and update on the rest api
14:10:28 <gampel> yes
14:10:59 <xiangxinyong456> for example,modify the plan
14:11:13 <gampel> whats the work flow modification needed
14:12:03 <gampel> when we modify a plan it should be updated to the DB , as i discussed with @chenying  in his patch
14:12:06 <xiangxinyong456> e.g. modify the checkpoint
14:12:14 <gampel> it shoudl be done only in suspended state
14:12:42 <saggi1> You can't modify the checkpoint from the api
14:12:50 <saggi1> except for changing the status for deletion
14:13:19 <xiangxinyong> ok
14:13:20 <gampel> the plan update is not relevant to the checkpoint all ready created we will serialize the plan into the checkpoint
14:13:40 <gampel> do you see other work flow modification needed ?
14:13:54 <saggi1> gampel: Checkpoint are inherently immutable
14:14:00 <xiangxinyong> modify trigger?
14:14:37 <gampel> I think if we modify a trigger we should update the operation engine
14:15:01 <gampel> and update the trigger that are registered in the system
14:15:05 <saggi1> plans can update but checkpoints are static data in the bank
14:15:46 <xiangxinyong> gampel: yeah, we need these workflow.
14:15:57 <xiangxinyong> saggi:understood
14:16:29 <gampel> xiangxinyong:  ok i agree can you create a file with all the needed workflow  and we could all verify them ?
14:17:38 <xiangxinyong> ok. we can gather these inforamtion and send to you
14:17:40 <gampel> #action xiangxinyong will define and verify  workflow for update on all the rest API
14:17:56 <gampel> #topic   REST API
14:18:14 <gampel> @chenying or @zengchen are here to update
14:18:39 <gampel> zhonghua-lee: can you update the status of the REST api
14:18:50 <gampel> #link https://review.openstack.org/#/c/286412/
14:18:58 <gampel> #link https://review.openstack.org/#/c/286406/
14:19:06 <gampel> #link https://review.openstack.org/#/c/287036/
14:19:25 <gampel> I think it will be good to start with the REST see how we can merge soon
14:20:03 <gampel> zhonghua-lee: can you please update the status for  @chenying and  @zengchen
14:20:36 <gampel> zhonghua-lee:  ?
14:21:04 <gampel> xiangxinyong:  do you know the status of this patches ?
14:21:31 <gampel> I review them all i think that they are almost there
14:21:39 <zhonghua-lee> gampel: ok
14:21:57 <zhonghua-lee> chenying, adn chenzeng's work are in good progress
14:21:57 <gampel> please everyone review today or tomorrow so we can merge them
14:22:09 <xiangxinyong> gampel: we will
14:22:33 <gampel> I think we should create priority of all the patches so we could start merging
14:22:42 <gampel> I think the fisrt to go in should be the REST
14:22:42 <zhonghua-lee> now, we have much work on UI
14:22:55 <zhonghua-lee> gampel: totally greee
14:23:10 <gampel> Ok next topic
14:23:28 <gampel> #Protectables status   & issues
14:23:50 <gampel> #topic Protectables status
14:24:13 <zhonghua-lee> I think we should think about how to get the child resource
14:24:45 <zhonghua-lee> right now , we get all volume from volume plug-in
14:25:02 <zhonghua-lee> it's not easy to understand
14:25:10 <zhonghua-lee> I think
14:25:16 <gampel> yes each  Protectables retruns its type only on the get_child_r..
14:25:48 <saggi1> zhonghua-lee: We know, it was something we thought about originally when designing the protectables.
14:25:57 <gampel> we had two option to do it top down or down to top
14:26:07 <saggi1> There are two ways. Have the VM Protectable in charge of getting the dependencies of all types
14:26:21 <saggi1> or have each type be reponsible for itself.
14:26:23 <zhonghua-lee> yes, i know why do that but, I think we should change the method name
14:26:40 <gampel> if this name is confusing no problem
14:26:44 <saggi1> zhonghua-lee: I don't mind, do you have a suggestion?
14:26:46 <gampel> whats your suggestion
14:27:29 <zhonghua-lee> saggi1: how about support a method wiht filter function
14:27:55 <gampel> I am not sure i understand  ?
14:28:44 <zhonghua-lee> I mean we can use the list_resouce method, and add a filter parameter
14:29:03 <zhonghua-lee> so that this method can filter resource by parent resource
14:29:41 <saggi1> so changing it to filter_by_parent_resource()?
14:30:01 <saggi1> or list_by_parent_resource()?
14:30:05 <zhonghua-lee> saggi1:something like that
14:30:27 <gampel> we must provide the resource
14:30:31 <gampel> as a param
14:30:34 <zhonghua-lee> list_by_parent_resource sounds betterr
14:30:34 <saggi1> of course
14:30:38 <saggi1> the interface is the same
14:30:41 <saggi1> it's just the name
14:30:52 <saggi1> list_by_parent_resource(parent_resource)
14:30:59 <zhonghua-lee> there are some difference
14:31:06 <saggi1> ?
14:31:33 <zhonghua-lee> I think "child resource" means the resource under the parent resource
14:31:34 <gampel> zhonghua-lee: : I think that  what you are proposing is not possible
14:31:50 <zhonghua-lee> e.g. volume is the child resource of VM
14:31:59 <saggi1> dependent
14:32:19 <zhonghua-lee> gampel: why?
14:32:33 <gampel> if it is changing the name no problem
14:32:44 <zhonghua-lee> gampel:it just change the name
14:32:57 <gampel> ok so no problem
14:33:53 <zhonghua-lee> gampel: it's just my suggestion.
14:34:12 <gampel> so get_dependent_ ..
14:34:31 <gampel> I am not sure i follow whats the proposed new name
14:34:49 <xiangxinyong> get_dependent_by_resource?
14:35:06 <zhonghua-lee> list_resource_by_parent?
14:35:27 <yuval> get_dependent_resources() ?
14:35:27 <gampel> Ok fine with me
14:35:37 <zhonghua-lee> some like that, whatever do not contain the "child"
14:36:01 <gampel> Ok saggi lets vote
14:36:06 <zhonghua-lee> s/some/something
14:36:44 <gampel> saggi: whats you view I am fine with both
14:36:54 <zengyingzhe_> what's the options?
14:37:06 <gampel> Hi welcome :)
14:37:18 <gampel> get_dependent_resources( parent)
14:37:22 <zengyingzhe_> sorry i'm late.
14:37:25 <gampel> and list_resource_by_parent
14:37:29 <gampel> no problem
14:37:51 <gampel> zengyingzhe_: we need an update of the protactable status
14:38:52 <gampel> Ok lets vote get_dependent_resources( parent) or  list_resource_by_parent
14:39:22 <saggi1> I'm partial to get_dependent_resources
14:39:43 <zengyingzhe_> get_dependent_resources +1
14:39:47 <xiangxinyong> get_dependent_resources
14:39:49 <yuval> get_dependent_resources
14:39:57 <gampel> ok we got a winer
14:40:24 <gampel> #action rename fetch_child to  get_dependent_resources
14:40:37 <zengyingzhe_> OK, i'll change this method name tomorrow.
14:40:46 <gampel> zengyingzhe_: can you please  update of the protactable status
14:41:26 <zengyingzhe_> you mean at etherpad?
14:41:52 <gampel> no i mean the patches
14:42:03 <gampel> #link   o    ProtectableRegistry https://review.openstack.org/#/c/281783/
14:42:17 <gampel> #link   oCinder https://review.openstack.org/#/c/285611/3
14:42:30 <gampel> #link   Nova https://review.openstack.org/#/c/286542/3
14:42:53 <gampel> #link   protectable RPC handlers https://review.openstack.org/#/c/285921/
14:43:10 <gampel> whats the status and what are we still missing
14:44:17 <gampel> zengyingzhe_:  ?
14:44:30 <zengyingzhe_> OK, i got it.
14:44:55 <saggi> Hi, got disconnected
14:45:07 <gampel> welcome back
14:45:07 <zhonghua-lee> right now , nove,cinder plug-in are ready
14:45:22 <saggi> good jobs!
14:45:25 <saggi> job
14:45:33 <zhonghua-lee> how about network,image plug-in?
14:45:38 <gampel> very good job please ask everyone top review them so we could merge tomorrow
14:45:51 <gampel> yuval do you want to take glace image
14:45:59 <yuval> Yes
14:46:02 <gampel> ok
14:46:28 <gampel> networking should be easy as we look at it as one entity
14:46:46 <zengyingzhe_> I'll start to work on rest protectable plugins tomorrow.
14:47:22 <xiangxinyong> :)
14:47:23 <gampel> I think we all ready merged it
14:47:33 <gampel> @chenying  did it
14:47:47 <zhonghua-lee> gampel:yeah, but after review :)
14:48:08 <gampel> Lets skip the    ·         Protection Plugin & Service
14:48:27 <gampel> I think that the developers of that part  are not here
14:48:36 <gampel> #topic UI dashboard status
14:49:00 <gampel> xiangxinyong or zhonghua-lee do you what to update on the status
14:49:16 <xiangxinyong> i have submit two patches, please review them
14:49:32 <saggi> xiangxinyong: it's in my queue
14:49:40 <gampel> yes in mine as well
14:49:51 <gampel> please ask all tyhe team to review it as well
14:50:02 <gampel> are there any issues  ?
14:50:18 <gampel> open issues ?
14:50:35 <xiangxinyong> not yet
14:50:38 <zengyingzhe_> Has the protectable resource paging issue discussed yet?
14:51:20 <gampel> let discuss this @chenying  include it in his REST patch
14:51:42 <gampel> but we can push the RPC and Plugin part to second phase
14:52:22 <gampel> xiangxinyong:  :) very good job keep us up to date and will try to review
14:52:33 <gampel> zengyingzhe_:  what do you think
14:53:10 <zengyingzhe_> I don't see why we need paging for protectable resources.
14:53:11 <xiangxinyong> gampel: np
14:53:32 <zengyingzhe_> it's represented as a graph
14:53:43 <zengyingzhe_> right?
14:54:16 <gampel> yes but the user can access the API  of only a Volume lets say and a user could have 10000
14:54:31 <saggi> We might need it if the user has a lot of VMS
14:54:39 <saggi> So in the UI we'll need to page it
14:54:50 <zhonghua-lee> saggi:+1
14:55:07 <zhonghua-lee> especially the method "list_resource"
14:55:25 <saggi> For dependencies we might not need ti
14:55:34 <saggi> since we need to hold them all in memory anyway
14:55:49 <saggi> but listing could be a problem
14:56:08 <xiangxinyong> but how to paging for protectable resources in a tree structure?
14:56:14 <gampel> i agree it is not argent but  from user experience and performance  it will be required      in second phase
14:56:38 <xiangxinyong> because the resource is listed by a tree
14:57:04 <zengyingzhe_> this means we must record all resources info in some place, such as DB or memory
14:57:21 <zhonghua-lee> xiangxinyong: you mean UI?
14:57:23 <zengyingzhe_> right now, there's no such implementation.
14:57:26 <gampel> Yes if the user as 10000 VMs you will have to show all the VMs and it will probebly take a very long time
14:57:38 <xiangxinyong> zhonghua-lee: yeah.
14:57:38 <saggi> Most openstack listing APIs support paging so we just forward it.
14:58:06 <gampel> I think that we will have to support this but it can be done in second phase
14:58:10 <zhonghua-lee> xiangxinyong:we can use async loading
14:58:15 <xiangxinyong> zhonghua-lee: the resources are listed in a tree.
14:58:30 <gampel> zengyingzhe_: do you agree
14:58:43 <xiangxinyong> zhonghua-lee: it is not related with async and sync.
14:58:57 <zhonghua-lee> xiangxinyong: what's th problem
14:59:03 <dneary> Joining a few minutes late today
14:59:10 <zengyingzhe_> gampel, yes, i'll think through it to find how to implement.
14:59:19 <gampel> we could open a bug about it so we will not forget and currently be focused on the end to end integration
14:59:35 <zengyingzhe_> sure
14:59:37 <gampel> so we could merge all teh  protactabole patchs
14:59:38 <zhonghua-lee> gampel:+1
14:59:57 <dneary> Sorry - wrong channel
15:00:01 <xiangxinyong> zhonghua-lee: the resource is listed by parent, i page the whole tree
15:00:07 <gampel> #action zengyingzhe_ open a bug about the pagination support in the protactable
15:00:14 <gampel> sorry thank you every one
15:00:21 <gampel> our time is done
15:00:33 <gampel> by end thank you for all the good work
15:00:36 <xiangxinyong> 3ks
15:00:37 <zhonghua-lee> xiangxinyong:let's disucss later
15:01:01 <zengyingzhe_> Thank you all, bye
15:01:02 <gampel> #endmeeting
15:01:02 <xiangxinyong> zhonghua-lee: ok
15:01:09 <gampel> #endmeeting