Tuesday, 2016-04-05

*** chenhuayi has joined #openstack-smaug01:27
openstackgerritsmile-luobin proposed openstack/smaug: Fix serialized_meta in SwiftBankPlugin  https://review.openstack.org/30142703:09
openstackgerrityinwei proposed openstack/smaug: Restore design spec (protection service level)  https://review.openstack.org/29695003:09
*** gampel1 has joined #openstack-smaug05:55
*** yuval has joined #openstack-smaug06:09
*** c00281451 has joined #openstack-smaug06:21
c00281451gampel & yuval: good morning. if you are on line, we can discuss. you have give me many good comments. thanks.06:26
*** c00281451 is now known as chenzeng06:26
yuvalhey chenzeng06:26
yuvalhow are you?06:26
gampel1 Hi everyone06:26
chenzengyuval:ya, fine. and you?06:27
chenzenghi gampel.06:27
yuvalchenzeng: good :)06:27
chenzengif you are have time now. we can start.06:27
gampel1sure06:27
chenzengok.06:27
chenzengwe start one by one.06:27
gampel1Ok06:28
chenzeng1. yuval said add add/remove/update trigger rpc interfaces. but i think we can create trigger when we use it.06:29
yinwei_computerping gampel106:29
yinwei_computerchenzeng is using this thread, right?06:30
yinwei_computercan I take Eran for several minutes?06:30
chenzengyinwei:ok06:31
yinwei_computerok, I will send private message to him06:31
gampel1 yinwei_computer:: yes sure  if we want to talk about the stack i think it will be best to include saggi06:31
yinwei_computerchenzeng, go ahead pls.06:31
yinwei_computeris him online now?06:32
yinwei_computersure06:32
gampel1he will be here soon i can ping you once he is here06:32
yinwei_computerok06:32
yinwei_computerthat's good06:32
yinwei_computerwe can start without conflict with chenzeng06:32
chenzenggampel:what's your opinion about the first topic.06:33
chenzengyinwei:thanks.06:33
gampel1why not have the trigger data in the Operation engine memory via RPC06:34
gampel1It is not allot of data and it will be easy  to sync startup / update ect06:34
chenzenggampel:because use may create the trigger, but not use it.06:35
chenzengbecause user may create the trigger, but not use it.06:35
gampel1I understand but it is just small memory footprint06:36
openstackgerritYuval Brik proposed openstack/smaug: Move swift client to be created by ClientFactory  https://review.openstack.org/30085406:36
gampel1for the first phase I do not see a problem and I can not imagine the trigger list becoming so big06:36
chenzengso you agree with adding more 3 rpc interfaces, do you?06:36
gampel1I think this is the obvious  solution that will be be easy to understate  and follow the flow06:37
chenzengok. i will update.06:37
gampel1If latter we have performance issues we could think of optimizations06:38
chenzengwe move to the "start_greenthread"06:38
yuvalok06:38
chenzenggampl & yuval:could you please recieve the document.06:39
chenzengi have send a picture to decribe my idea.06:39
yuvalwhat document?06:39
gampel1i did but it is very slow06:40
chenzengi send it to you from irc06:40
gampel1can you  send it by mail06:40
chenzengok06:40
chenzengyuval:can you give me your email06:40
yuvalyuval@brik.org.il06:41
chenzengok, wait a minute.06:41
gampel1 chenzeng:  yes "start_greenthread"06:41
chenzengi have sended the email to you.06:45
yuvalI received it06:45
gampel1i did not get it06:46
chenzengok, i send it again.06:47
yuvalchenzeng: why would compute_next_time(now-window) return t4 and not t2?06:48
yuvalchenzeng: I understand what you wrote06:49
gampel1Got it06:49
yuvalchenzeng: this might happen only if the time format is not fixed (deterministic)06:49
chenzengyuval:yes.06:51
gampel1The relative use case are not so important in my view06:51
gampel1We could event limit it as know to time format that are absolute06:51
gampel1even06:51
gampel1Currently crontab is absolute06:52
chenzenggampel:yes,  crontab is absolute.06:52
gampel1I do not think it is impotent  to have relative recurrent  and it does not matter when is the start06:53
gampel1if it is the trigger creation or the first operation using it06:53
gampel1We could limit the trigger formats  to only absolute06:54
chenzenggapel:but rfc2445 is more flexible. use may create a trigger using rfc2445 that is not absolute time.06:54
chenzenguser06:54
gampel1in  rfc2445 you define start time and the recurrent becomes absolute06:55
yuvalanother thing which supports absolute recurrence:06:56
yuvalin case the service is restarted, or started in different locations06:56
yuvalit must be ensured06:56
gampel1yes i agree06:56
yuvalthat the events will occur06:56
gampel1chenzeng: what do you think ?06:56
chenzengif we only suport absolute time, i agree.06:57
gampel1any other thoughts  for any one else about this  ?06:57
gampel1Ok so lets agree we only support absolute  recurrent  time definitions06:58
gampel1chenzeng:  by the way very good job on the Operation engine06:59
chenzengi have one more topic to discuss.06:59
gampel1chenzeng:Yes please me too06:59
chenzengabout the timezone of trigger.07:00
gampel1yes my topic as well07:00
chenzenguser is familiar with local time, and we change it to utc to keep the same with other modules like DB.07:00
gampel1chenzeng: our thoughts now is to have the API and DB all in UTC07:00
gampel1the UI will convert from USer local time to UTC07:00
gampel1so we only operate in UTC and all the server are set to UTC07:01
chenzengok. i got it.07:01
gampel1what do you think ?07:01
chenzengwindow should be less than the interval between two time points and be greater than 1 hour.07:01
chenzenggampel: i agree with you about the timezone.07:02
gampel1Ok great07:02
chenzenggampel:window should be less than the interval between two time points and be greater than 1 hour.07:02
yuvalchenzeng: why should the window be greater than 1 hour?07:02
chenzengthis is you said in the comments.07:03
gampel1Ok i think that we should limit the interval07:03
chenzenghttps://review.openstack.org/#/c/296880/12/smaug/operationengine/engine/triggers/timetrigger/timeformats/crontab_time.py07:03
gampel1so the minimal interval will be hour07:04
chenzengok.07:04
gampel1the window is how long did it take me to run the operation from the absolute trigger time07:05
gampel1so i do not think it should be be greater than 1 hour07:05
*** x00350071_ is now known as xiangxinyong07:06
gampel1as a default it should be minutes max07:06
chenzenggampel:sorry. you said the interval between two trigger time points should be greater than 1 hour.07:06
gampel1i mean the interval not the window07:07
chenzenggampel:the window should be less  than the interval between two time points.07:07
gampel1yes i agree07:08
gampel1i think the default  should be 1 minute07:08
gampel1for the window07:08
chenzengok. the interval is greater than 1 hour. and window is less than interval07:08
chenzengnow the default for window is 1 minuts.07:09
gampel1I would   even say that teh window max is 1/2 of the interval07:09
chenzenggot it.07:09
gampel1Any other open issues ?07:10
chenzengno.07:10
chenzengthanks gampel & yuval.07:10
gampel1thank you for a very good job07:10
yuvalthank you :D07:10
gampel1whats the status of the time trigger patch07:11
chenzengtoday i will update it based on our discuss.07:11
gampel1Thanks ping us to review it so we coudl try and merge it07:12
xiangxinyongHi Eran.07:12
gampel1hi07:12
chenzenggampel:ok.07:12
gampel1 xiangxinyong chenying : were you able to tag the python client07:13
xiangxinyongeran: we think chenying has no rights to tag it.07:13
gampel1Ok let mecheck07:13
xiangxinyongwe think he is not in the smaug-release group07:14
gampel1i just added him can you please check07:15
xiangxinyongok. He is in a meeting. i will tell him. Thanks07:15
gampel1let me knwo if it does not work07:15
saggiping yinwei_computer07:16
gampel1whats the status of the UI  ?07:16
xiangxinyongeran, do you think we need to add openstack bot in our project like this. https://review.openstack.org/#/c/28958407:16
gampel1yes can you sent the patch ?07:16
gampel1yinwei: ping07:17
xiangxinyongyes, i will do at once.07:17
xiangxinyongeran: i setup a sketon of ui, but i have some details to confirm with you and saggi.07:17
gampel1please add all of us as reviewers07:17
xiangxinyongwhen do you have spare time?07:17
gampel1do you want to discuss know07:17
xiangxinyongeran: ok, i will07:17
gampel1now07:17
xiangxinyongyeah.07:18
gampel1Ok lets go07:18
saggixiangxinyong: I have some now if yinwei_computer and wangliuan are not here.07:18
xiangxinyongsaggi: so?07:18
gampel1 xiangxinyong: we could start do you need to send us something ?07:19
xiangxinyongdo we make espace meeting?07:20
gampel1sure saggi you can join me on my computer07:20
xiangxinyongi could share my screen07:21
gampel1Ok07:21
yinwei_computerI'm here07:53
yinwei_computersorry, was talking with chenying07:53
yinwei_computerhello, saggi07:53
saggi yinwei_computer: hi07:53
yinwei_computerare you free to talk now?07:53
saggiyes07:53
saggiyinwei_computer: How are you doing?07:54
yinwei_computergood, except finding your comment on task stack07:54
yinwei_computer:)07:54
yinwei_computerkidding07:54
yinwei_computerpls. go ahead07:54
yinwei_computerdo you need wangliuan to be here?07:55
yinwei_computeryou're looking for him as well?07:55
saggiyinwei_computer: I would prefer it just so I know we are all on the same page. But you can explain to him later if he is unavailable.07:55
yinwei_computerok07:55
yinwei_computerwhat's issue about liuan?07:56
saggiyinwei_computer: In general I like the stack idea. It's a very clean solution to the problem of attaching to parent/child tasks in the tree.07:56
yinwei_computerthe task stack or flow engine?07:56
saggiboth07:56
yinwei_computerok07:57
saggibut the stack is written on top of the flow engine07:57
yinwei_computerit's written based on the interface of flow engine, not bond to implementation07:57
saggiyinwei_computer: The only issue is that the stack is managed by the base plugin. This means that a plugin can override this behavior and corrupt the stack. The only thing we want to change is to have the stack managed by the ResourceGraphWalker implementation instead of the base plugin.07:58
yinwei_computeryour point is it's not good to locate in base protection plugin, right?07:58
saggiYes07:58
yinwei_computerLet me see07:58
saggiWhat we suggest is having the task builder have an internal stack.07:59
saggiThe RGW will push a noop task on enter and pop it on exit.07:59
saggithe plugin can only look at the top of the stack.07:59
saggiand can either link to this noop task or create unrelated tasks that will run in parallel.08:00
saggiThe top of the stack in on_enter is the parent task (meaning I wait until the parent is done)08:00
saggithe top of the stack in on_exist (is a task that depends on all the child stacked tasks)08:01
saggiThis means that I get the functionality without letting the plugin manage the stack itself.08:01
saggiyinwei_computer: Am I being clear enough?08:02
yinwei_computerthinking08:02
yinwei_computerconfirm:08:03
saggi:)08:03
gampel1I am in another meeting will join you when i am done08:03
yinwei_computerok08:04
yinwei_computer1. RGW will manage the task stack but won't expose the task stack to plugin08:04
yinwei_computer2. RGW will expose some interfaces for plugin to operate task create and task link08:05
yinwei_computersaggi, hello?08:09
saggiyinwei_computer: 1 sec yuval is having comments too08:10
yinwei_computerok08:10
*** asdfghj has joined #openstack-smaug08:10
saggi1 yes08:11
saggi2 this is what Yuval is suggesting we can remove. I'm trying to understand him now.08:12
yinwei_computerchecked the code08:14
yinwei_computerit seems to me that, on_resource_start in base plugin could keep the same, right?08:15
yinwei_computersince plugin still need build task or search task and append it08:15
saggiyinwei_computer: 1 min08:16
yinwei_computeror we just require on_resource_start to return a task of this resource?08:16
yinwei_computerit looks to me that we need divide which part should be done by plugin while which part should be done by RGW08:18
saggiyinwei_computer: yuval had a good idea let me try and explain it.08:24
saggiyinwei_computer: Let us no what you think about it08:24
saggiyinwei_computer: He says that we don't really need a stack if we change things a little bit.08:24
saggiyinwei_computer: First we make on_enter() optional it will be used only for scoping aggregate protection plugins.08:25
saggiyinwei_computer: Second we have on_exit() return a task.08:25
saggiNow the way it works is that each node's returned in on_exit() will automatically depend on all it's childrens' returned tasks. This will be done in RGW.08:26
saggiIf the plugins wants a task that depend on nothing it can just create it and not return it. It will return a noop instead. This will make a task that is independent.08:27
saggiIf the plugins wants a task to run after it's children have finished it can just return it.08:27
saggi*BTW when I say task I mean Atom (task or flow)08:28
saggiIf the plugin want to make several task to run in parallel but declare that it's done only after both of them finish it can make a nnop task and have both tasks depend on the noop and return the noop.08:29
yinwei_computerhmm, I recalled that we used to think in this way as you told above08:29
saggiThe main difference is not having a task in on_enter()08:29
yinwei_computerbut there's some problem in this solution08:29
saggiWhich was confusing08:30
saggiWhat problem?08:30
yinwei_computeryes, I recalled that Bin has proved that we have to append the task on_enter08:30
yinwei_computerlet me recall details08:30
saggiFrom what I recall the main issue was that the difference between on_enter and on_exit was confusing.08:31
yinwei_computerok08:35
yinwei_computerthe problem is when you link your parent task to children task, you have no idea which tasks are your children tasks08:36
saggiThat was the problem with on_enter() when you do on_exit() you necessarily visited all the children and collected their tasks.08:37
yinwei_computeryes, but how to differenciate the task below on the stack is your right sibling or your parent?08:38
yinwei_computersay, you have task1 as parent,  task2 and task3 as children08:39
yuvaland your own task08:39
yinwei_computerthe stack of tasks should be task2, task3, task108:39
yuvalnvm08:39
yinwei_computershall we link task2 to task3?08:39
yinwei_computeror link task2 and task3 to task1?08:39
saggithe latter08:40
yinwei_computerthe idea of current way is only keep parent task on top of the stack08:40
yinwei_computerhow to tell on push task3?08:40
yinwei_computershall we pop task2 out and link it to task3, or shall we push task3 and then pop the two after task1 pushed into stack08:41
yinwei_computerwe need extra context to tell the right sibling and the parent08:41
* saggi is thinking...08:41
saggiyinwei_computer: When before on_enter() we mark the size of the stack. after on_exit() we pop until the stack is the same size as in on_enter() and link them to the returned task and push it to the stack.08:43
saggiIt's all O(1) operations.08:44
yinwei_computeractually, we are trying to reconstruct a tree by its iteration result.  AFAK, at least we need two ordering of iteration result, we can reconstruct it.  first root and middle root.  we need at least  two information08:45
yinwei_computerI don't get your point08:46
* saggi is cooking some pseudo code08:46
yuvalwe can push on the dfs stack a tuple: (node, parent node)08:47
yinwei_computeractually, the current way is trying to make use the stack calling of the dfs itself08:48
yinwei_computerI don't see any benefit to save extra information to simulate it08:48
saggiyinwei_computer: http://fpaste.org/349705/59846388/08:53
yinwei_computer* yinwei_computer is reading code08:53
yinwei_computerI need switch to blue cloud to check your code08:54
*** zhang2005 has joined #openstack-smaug08:54
saggiyinwei_computer: Do you have a paste site you can connect to?08:54
zhang2005hi i am zhangshuai08:54
saggihi08:55
*** pzchen has joined #openstack-smaug08:55
yinwei_computersaggi: could you pls. send it to my email yinwei3@huawei.com08:55
yinwei_computerIt seems that personal storage is denied here08:56
saggiyinwei_computer: sent08:57
*** pzchen has quit IRC08:58
yinwei_computersaggi, I see your pc09:00
yinwei_computerquestion, how to tell the marker of different node?09:00
saggiyinwei_computer: You don't need to. Since we are doing DFS. We know that the topmost marker is our marker and the next topmost marker is the parent marker.09:01
yinwei_computerthen it's the same with the current way, just we move the task append and task link out09:02
yinwei_computerthe marker in current way is the task produced by the protection plugin09:02
yinwei_computerI agree we could move the append and link logic to RGW, but I don't see the benefit of inserting a marker09:03
saggiWithout the marker you can't group siblings tasks.09:04
saggiyinwei_computer: Yuval suggest we use two stacks09:07
saggiinstead of a marker09:07
yinwei_computerwhy not just have on_task_start to return task and just move the task append and task link to RGW09:08
yinwei_computerI mean I didn't see the benefit of marker compared with just insert parent task on node enter09:08
saggiwhat is on_task_start?09:08
saggiThis means that the protection plugins knows about the details of the linking09:09
yinwei_computerplugin.on_resource_start to produce its own task09:09
yinwei_computerand then BGW append it to task stack09:09
yinwei_computerthis is the same as the marker09:10
yinwei_computerthe marker is the parent task now09:10
saggiyinwei_computer: hmm09:10
saggiBut that means that if the plugin needs to modify the task in on_resource_exit() it has to somehow do the bookkeeping itslef09:10
saggiPlugins that manage multiple resources in the same task can only know the real task on_exit09:11
yinwei_computerit could call RGW.task_stack.peek() to get the task, right?09:11
saggiIf we expose it to it.09:12
saggiBut I would rather not.09:12
yinwei_computerwe can have RGW to provide interfaces to retrieve task stack, but without exposing the interfaces of construct them09:12
saggiBut that means that we bind the plugin implementation to the stack implementation.09:13
yinwei_computerwhy?09:14
yinwei_computerit means we do bookeeping for the plugin, it could retrieve its context through RGW09:14
yinwei_computernot necessarily stack09:14
yinwei_computerit doesn't need know there's a stack09:14
saggiWhat it really means is that we push the parent task as part of the context.09:15
yinwei_computeryes, of course09:15
saggiSince the plugin doesn't need the entire stack.09:15
* saggi is thinking....09:15
yinwei_computerthat's why there is a task stack09:15
yinwei_computerwhy we made a task stack is because we don't want walk() function to return certain value, like task09:16
yinwei_computerthat's why we made task stack into context and plugin09:16
yinwei_computerwe just have plugin to produce task in on_resource_start, RGW will append it to stack; while on_resource_end, plugin could do nothing but RGW will link tasks by default.  If it want to change its task on resource end, it could call RGW.get_current_task, and the top of the task should be the task of this plugin.09:18
yinwei_computerthe task could be a task flow itself09:19
saggiyinwei_computer: I sent you another pseudo code to make sure we are on the same page09:20
gampel1saggi: launch ?09:20
saggiyinwei_computer: Tell me if I got this correctly09:20
gampel1yuval ?09:20
saggigampel1: 10 min, I think we're close to agreeing.09:20
yinwei_computerchecking saggi's pseudo code09:21
yinwei_computersaggi: we need link tasks in RGW's on_node_exit, missing it?09:23
yinwei_computersaggi: in RGW's on_node_enter, if the node visited, we don't call plugin.on_resource_start but go to search its task in task stack and push it to stack.09:24
yinwei_computersaggi: basically, I agree with your patch09:24
yinwei_computerjust with above 2 minor issue09:25
yinwei_computerbtw, what's the point of if not already_visited:09:25
yinwei_computer            self.context.status_getters.append(09:25
yinwei_computer                {"resource_id": resource.id,09:25
yinwei_computer                 "get_resource_stats": protection_plugin.get_resource_stats}09:25
yinwei_computer            )09:25
saggiyinwei_computer: I don't like the fact that they search for their own task in the stack. This exposes the task stack to the plugin.09:27
yinwei_computeroh, plugin won't do that09:27
yinwei_computerRGW will do it for plugin09:27
saggiThat means that it must always reuse the task if it was already visited.09:27
yinwei_computeryes, why not?09:28
saggiIf we split volume restore to restoring the data and doing an attack it will reuse the restore task but we will have to attack ops09:28
yinwei_computerplugin should tell the context which time it has been visited and thus produce different tasks?09:28
saggiattach09:28
saggiOr is volume attack responsibility of the VM pluigin?09:29
yinwei_computeroh, attach will be done in server node09:29
saggiSure09:29
yinwei_computeryes, it's parent node's responsibility09:29
yinwei_computerI've described this in restore design spec09:29
yinwei_computerwe have directional graph, only parent knows child, but child has no idea of parent09:30
saggiSure, than it's a good idea. And if we ever need to change that we can pass it in the context.09:30
saggiand the child can choose to reuse or modify.09:30
saggibut don't do it until we have a use case for it09:31
yinwei_computerok09:31
saggiyinwei_computer: OK, good job! You are really good at this.09:31
saggiyinwei_computer: Will you update wangliuan and lubin?09:32
yinwei_computerconfirm: so basically, RGW will search task for a visited node, and it will still call plugin.on_resource_start. Plugin itself will check the first visited flag, and decide to return task or not.  If it returns task, RGW will use the updated one.09:33
yinwei_computerIs this the logic you told in ' And if we ever need to change that we can pass it in the context. '?09:33
yinwei_computerYes, I will update to them.  But I'm afraid I need catch you guys for more issues later after you lunch.09:34
saggiyinwei_computer: I understood that RGW will skip the resource if it was already visited and just make the link.09:35
saggiAnd if we ever need handling for already visited in the plugin we will add that?09:35
saggi?=.09:35
yinwei_computeryes09:35
yinwei_computerfor now, we can implement in the simple way09:36
saggiyinwei_computer: yes09:36
saggiI got to go09:36
yinwei_computerif we need handle that kind of case, we give context to plugin09:36
saggiyinwei_computer: Thanks for your time.09:36
yinwei_computersure09:36
saggiWill try and catch you later.09:36
yinwei_computerthanks to you09:36
xiangxinyongwelcome zhang shuai and chen zipeng to join us.09:39
yinwei_computerwelcome09:45
zhang2005thanks09:46
zhonghua-leewelcome09:47
chenying_welcome09:49
xiangxinyongzhangshuai and pengzi, welcome to join our weekly meeting at the #openstack-meeting. tonight 22:00~23:0009:58
*** zhang2005 has quit IRC10:19
openstackgerritMerged openstack/smaug: Split Provider configuration into files  https://review.openstack.org/29867310:58
*** gampel2 has joined #openstack-smaug11:00
*** gampel1 has quit IRC11:02
chenying_ping saggi11:38
saggichenying_: pong11:38
chenying_saggi  have you seen the operation log comments?11:39
chenying_Have discussed xinyong  I think operation_log not only include scheduled protect operation11:40
chenying_Have discussed with xinyong It also include  protect/delete action without scheduler11:41
saggichenying_: I didn't find time to get around to it. I was away for a few days because of the army.11:44
saggichenying_: Will get to it now11:44
chenying_Ok thanks.11:46
*** zhongjun_ has joined #openstack-smaug11:49
*** gampel2 has quit IRC12:00
*** gampel1 has joined #openstack-smaug12:01
*** yinweiishere has joined #openstack-smaug12:37
yinweiishereping saggi12:38
yinweiishereping gampel112:38
saggipong yinweiishere12:38
yinweiisherehi saggi12:38
yinweiishereneed confirm two issues with you guys12:39
saggishoot12:39
yinweiisherefirst is the granularity of network plugin12:39
yinweiishereshall we make all the networks of one tenant as one resource node in resource graph12:39
yinweiishereor resources of one network per resource graph node?12:41
yinweiishereper my understanding, to solve the share resource among networks, like sg, we only make one resource node in resource graph per project12:42
yinweiisheresaggi?12:44
saggiWe will have one network resource.12:45
saggiStuff that are part of the VM will be part of the VM12:45
saggilike it's IP12:45
saggiand what SGs are attached to the port12:45
saggibut the SGs will be in the network resource12:45
saggisimilar to how volumes are handled by cinder but attach is handled by nova12:46
yinweiisherelast time I aligned it to Eran that we will make ports as resources of network12:46
yinweiishereand attach is in server12:46
saggiso attaching a VM to a network or attaching an SG to it is a Server's responsibility12:46
yinweiishereyes12:46
yinweiishereactually there is one case I'm not sure how to handle it12:46
saggiYes, ports are part of the network. But ports aren't really an entity that you back up.12:47
saggiYou just need to save the links between the VM to a network (which is a port) and info about this link (eg. sg)12:47
yinweiisheresay, user pick up several servers as protection plan resources, those servers all attached to networkA.  Tenant actually has two networks, networkA and networkB.12:48
yinweiisherewith one network graph node, it will protect networkA and networkB or only networkA would be enough?12:48
saggiHow do you know A is enough? If there is a router between A and B and VMs in B are created because of actions from the VMs in network A (workers for compute) B might be integral to the project.12:50
yinweiishereI mean, with one network graph node, it wont' construct different resource node with different parent.  It should return a graph node which will protect all networks of this project.12:50
yinweiishereso you mean that we won't check the scope of the network resources, but protect whole tenant network resources?12:51
yinweiisherethat would be simple12:51
saggiyes12:51
saggiYes, this is the simplest way to handle it now. Anything else becomes very complex.12:51
yinweiisherehmm, from semantics, we protect more. But more is better than less.12:51
saggiAnd it has a lot of open questions. We would much rather have concrete use cases for protecting less.12:52
yinweiishereOK, I will have people to comment this into code.  And pls. check this limitation with Eran.12:52
saggiEran knows about it.12:52
yinweiisherewe will protect super set of network resources of the plan12:52
yinweiishereok12:52
yinweiisherethat's good12:52
yinweiisherethe second issue is about the restoration12:53
yinweiisherethansk for your comments12:53
yinweiishereI replied you in comment12:53
yinweiisherenot sure if you have seen them12:54
saggiWhat we think is to maybe expose options in the network plugin to backup only some aspects (disable backup of SGs) but for now just back up everything we can restore.12:55
yinweiisherehmm, seems to persist whole neutron db in protection plugin12:56
yinweiishere:)12:56
yinweiishereand see what would be useful in restore12:56
saggiyinweiishere: not yet. I will do it after I finish going over the comments on the operation log since I've been neglecting this for days now.12:56
saggiyinweiishere: The problem is managing different versions of neutron since the db format is not part of the api12:56
saggiyinweiishere: And we don't want different versions of neutron to break us.12:57
yinweiisherejust kidding, we will list neutron resources by neutron client12:57
yinweiisherebut in fact, it equals backup the database12:57
saggiyinweiishere: Great. I gtg for a few minutes now.12:58
yinweiishereok12:58
yinweiishereone last thing, what about the checkpoint patch?12:58
yinweiishereI have commit the patch enable lease dependent on you patch. Not sure when you will commit it?12:59
yinweiishereand the resource graph serialization patch?  If you're busy, chen ying is willing to help on this part.13:00
saggiHe can start working on it. I can't seem to manage to get any coding done lately.13:05
saggiyinweiishere: ^^^^13:10
*** yinweiishere has quit IRC13:21
*** chenhuayi has quit IRC13:21
*** saggi has quit IRC13:21
*** zhongjun_ has quit IRC13:21
*** chenzeng has quit IRC13:21
*** asdfghj has quit IRC13:21
*** openstackgerrit has quit IRC13:21
*** jhesketh has quit IRC13:21
*** gampel has quit IRC13:21
*** xiangxinyong has quit IRC13:21
*** smcginnis has quit IRC13:21
*** ChanServ has quit IRC13:21
*** yinwei_computer has quit IRC13:21
*** gampel1 has quit IRC13:22
*** CrayZee has quit IRC13:22
*** yuval has quit IRC13:22
*** chenying_ has quit IRC13:22
*** zhonghua-lee has quit IRC13:22
*** yinweiishere has joined #openstack-smaug13:24
*** chenhuayi_ has joined #openstack-smaug13:24
*** gampel1 has joined #openstack-smaug13:24
*** zhongjun_ has joined #openstack-smaug13:24
*** asdfghj has joined #openstack-smaug13:24
*** chenzeng has joined #openstack-smaug13:24
*** yuval has joined #openstack-smaug13:24
*** gampel has joined #openstack-smaug13:24
*** saggi has joined #openstack-smaug13:24
*** yinwei_computer has joined #openstack-smaug13:24
*** CrayZee has joined #openstack-smaug13:24
*** openstackgerrit has joined #openstack-smaug13:24
*** xiangxinyong has joined #openstack-smaug13:24
*** chenying_ has joined #openstack-smaug13:24
*** zhonghua-lee has joined #openstack-smaug13:24
*** smcginnis has joined #openstack-smaug13:24
*** jhesketh has joined #openstack-smaug13:24
*** ChanServ has joined #openstack-smaug13:24
*** wolfe.freenode.net sets mode: +o ChanServ13:24
*** xiangxinyong456 has joined #openstack-smaug13:50
*** AndroUser has joined #openstack-smaug13:51
*** AndroUser is now known as zhangshuai13:55
*** Zhongjun has joined #openstack-smaug14:00
gampel1Saggi14:02
*** xiangxinyong456 has quit IRC14:07
*** xiangxinyong456 has joined #openstack-smaug14:08
*** yinweimac has joined #openstack-smaug14:12
*** zhangshuai has quit IRC14:53
*** zhangshuai has joined #openstack-smaug14:54
yinweimacgampel and saggi, since we have a demo schedule on the end of April, is it possible to postpone some enhancement patches, like task stack change and image chunking change to May? I mean, we mark those items done, but deliver a functional correct one first?14:58
yinweimacmark them down15:01
saggitask stack is simple. Image chunking could be postponed.15:01
gampelI have no problem but I think you will not be able to do a backup to swift without chunking15:01
saggiIt's not even merged yet15:01
*** zhang2005 has joined #openstack-smaug15:01
saggitask stak ^^15:01
gampelwe could reuse the code in dragon for the chunking15:01
yinweimacnot exactly15:01
gampelYou think it will work with out the chunking15:02
yinweimacwhen you download it, you need organize it as well15:02
yinweimacthe ideal solution is to use the manufest of swift object15:02
gampelYes so you will do a demo of a very small image and volume ?15:02
yinweimacyes15:02
yinweimacI think we've got ideal solution but we need take time to optimize it15:03
saggixiangxinyong: Will you be online tomorrow at 8:00 Israel time? (I think it's 13:00 in China)15:03
zhonghua-leeyinweimac:we should work together and speed it up15:03
zhonghua-leesaggi: what's the matter?15:03
xiangxinyongsaggi: ok15:03
yinweimacthat's no problem15:03
saggixiangxinyong: So go to sleep. I'll catch you up tomorrow about the parameters.15:04
yinweimaczhonghua-lee: sure, we can work together15:04
saggi:)15:04
yinweimacbut we need a workable one first15:04
xiangxinyongsaggi:  i will wait for you. saggi.15:04
gampelI have no problem merging it if we file a bug that we should add chunking15:04
xiangxinyongsaggi: thanks15:04
zhonghua-leeyeah, understood15:04
yinweimacnot only chunking, but also manufest15:04
yinweimacyes, thanks15:04
gampeland maybe start working on it in parallel15:04
zhonghua-lee13:00 is our rest time :)15:05
yinweimacyes, if there's enough hands15:05
xiangxinyongit is no matter15:05
xiangxinyong:)15:05
zhonghua-leeokay15:05
yinweimacsince I'd like have Luobin to work on restore ASAP15:05
gampelOk thanks everyone i know it is very late in china15:05
xiangxinyong^-^15:06
yinweimaclast item to check15:06
gampelsure15:06
yinweimacsaggi, how about your checkpoint patch?15:06
yinweimacwill you merge it?15:06
yinweimacand what's your plan to serialize resource graph?15:06
yinweimacrestore will depend on the resource graph serialization15:07
gampellthis one https://review.openstack.org/#/c/280325/15:07
yinweimactwo items15:07
yinweimacfirst is to merge this one (there's some bugs as jenkins failed, note my comment)15:08
yinweimacsecond is another patch, not sure if saggi is working on it15:08
gampelwhich one ?15:08
gampelsagii: are you here ?15:09
saggiyinweimac: I can't find the time to get to it. I don't need a lot of time just some time without meetings. I will try and get to it on Monday (I have reserve duty on Sunday). The plan is to just generate the tree from the plan and walk it building a json file than persist it in a file near the checkpoint index.15:09
yinweimacresource graph serialize15:09
gampelsaggi: maybe yuval or yinwei can take this patch15:09
yinweimacyes15:09
yinweimacjust mean if you need ask for help15:10
gampelyinwei can you share the other patch link ?15:10
zhonghua-leesaggi: is there anything that we can help you?15:10
yinweimacthe resource graph serialize15:10
yinweimacthe other patch hasn't commit yet15:10
yinweimacjust in saggi's mind :)15:10
saggi:)15:10
yinweimacchenying told me that he would like to help on restore and could start on this patch15:11
saggisure15:11
yinweimacif you're busy this week, I will have chenying to work on this patch15:11
yinweimacthanks, zhonghua!15:11
yinweimacyou helped a lot15:11
zhonghua-leeyinweimac: welcome15:12
yinweimacsaggi: just in case we work on the repeated items15:12
zhonghua-leeyinweimac: i know you have no much time to waste15:12
gampelsaggi: what about the resource graph serialize15:12
yinweimaclet's see if chenying have time to commit it this week15:12
saggiIf someone starts doing it before Monday just send me an email.15:12
zhonghua-leeyinweimac: let's speed it up, hopes can catch your point15:13
yinweimacif not, sagg will take it in net monday15:13
saggiI will not have time to work on it until then anyway15:13
yinweimacgood15:13
gampelso chenying will take this two patches ?15:13
yinweimacno15:13
zhonghua-leegampel: let me check tommorrow.15:13
yinweimacthe first one I have tested it and found bugs already15:13
chenying_ After saggi's operation log patch  I may need work on this api.15:13
yuvalI can start working on the resource graph serialization15:14
saggiI think chenying is doing way to much as it is15:14
yinweimacthanks, yuval15:14
gampelsaggi: please explain yuval your idea about the resource graph serialization today15:14
yinweimacthanks, everyone15:15
gampelthanks everyone good night15:15
yuvalall: if you have time, there are some minor patches we can merge quickly15:15
yinweimacgood night15:15
zhonghua-leebye,everyone15:15
xiangxinyong8815:15
chenying_bye15:16
gampelbye15:16
*** yinweimac has quit IRC15:16
*** zhang2005 has quit IRC15:16
*** zhangshuai has quit IRC15:18
*** asdfghj has quit IRC15:24
*** asdfghj has joined #openstack-smaug15:25
*** yuval has quit IRC15:34
*** Zhongjun has quit IRC16:49
*** chenhuayi_ has quit IRC17:35
*** gampel1 has quit IRC18:53
*** xiangxinyong456 has quit IRC22:40
*** xiangxinyong456 has joined #openstack-smaug22:43
*** xiangxinyong456 has quit IRC23:00
*** xiangxinyong456 has joined #openstack-smaug23:03
*** xiangxinyong456 has quit IRC23:14

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!