openstackgerrit | smile-luobin proposed openstack/smaug: Store ResourceGraph and Plan in checkpoint https://review.openstack.org/307737 | 03:23 |
---|---|---|
xiangxinyong | saggi: good morning | 05:54 |
xiangxinyong | saggi: i have sent a smaug video to you by email. | 06:14 |
xiangxinyong | if something is need to modify, please let me know. I will modify it and send to you again. | 06:16 |
openstackgerrit | chenying proposed openstack/smaug: Add fullstack test to smaug https://review.openstack.org/306996 | 06:33 |
*** yuval has joined #openstack-smaug | 06:42 | |
*** yuval is now known as Guest15353 | 06:42 | |
*** Guest15353 has quit IRC | 06:43 | |
*** yuval_ has joined #openstack-smaug | 06:43 | |
*** yuval_ is now known as yuval | 06:43 | |
yuval | ping xiangxinyong | 06:51 |
xiangxinyong | yuval: hello | 06:56 |
yuval | xiangxinyong: how are you? :) | 06:56 |
xiangxinyong | fine, thanks | 06:56 |
xiangxinyong | and you? | 06:56 |
yuval | very well | 06:56 |
yuval | I've seen the demo clip | 06:56 |
yuval | looks great! | 06:56 |
xiangxinyong | Thanks | 06:57 |
yuval | I have few very minor comments | 06:57 |
yuval | 1. comitted -> commited | 06:57 |
yuval | 2. on volume restore, parameter is "replacement public ip", which should be the restore parameter of servers | 06:58 |
yuval | 3. operation logs should have time in the grid | 06:58 |
yuval | ---- | 06:58 |
xiangxinyong | ok | 06:58 |
xiangxinyong | Thanks for your suggestion | 07:00 |
yuval | Sure. It looks very very good | 07:01 |
openstackgerrit | Merged openstack/smaug: Add name property to protectable instances model https://review.openstack.org/302086 | 07:02 |
xiangxinyong | i will modify it | 07:05 |
xiangxinyong | yuval: on volume restore, do you have some parameters to suggest to me? thanks | 07:20 |
yuval | xiangxinyong: you can try looking here: | 07:22 |
yuval | https://review.openstack.org/#/c/286458/23/smaug/services/protection/protection_plugins/volume/volume_plugin_cinder_schemas.py | 07:22 |
xiangxinyong | got it | 07:23 |
xiangxinyong | yuval: about the operation logs time, does it mean createtime? | 07:25 |
yuval | xiangxinyong: started_at | 07:27 |
xiangxinyong | :) thanks | 07:27 |
yuval | thank you! :) | 07:27 |
xiangxinyong | i will send a email to all of you later. | 07:28 |
yuval | ping chenzeng | 07:34 |
chenzeng | yuval:yes | 07:35 |
chenzeng | yuval:how are you? | 07:35 |
openstackgerrit | smile-luobin proposed openstack/smaug: Store ResourceGraph and Plan in checkpoint https://review.openstack.org/307737 | 07:35 |
yuval | chenzeng: good, you? | 07:35 |
chenzeng | yuval:well. | 07:36 |
yuval | chenzeng: are you still working on creating clients without the request context? | 07:37 |
chenzeng | yuval:yes. it is the bug submitted by yinwei. | 07:38 |
chenzeng | today, i will submit the codes. | 07:38 |
yuval | great! :) | 07:38 |
yuval | would you like to continue our discussion about the logs? | 07:38 |
chenzeng | yes, thank you | 07:40 |
yuval | I asked why not create the log in the operation base class, and you said we risk losing it if the service crashes | 07:40 |
chenzeng | yes | 07:40 |
yuval | wouldn't the log be lost if the log is created in the executor also? | 07:41 |
chenzeng | at present, the operations are stored in the queue of executor for a while before they are executed. i mean i don't want to lose the operations in the queue. | 07:43 |
yuval | that is why you created _restore_operations in https://review.openstack.org/#/c/304048/4/smaug/operationengine/manager.py | 07:44 |
chenzeng | yes. | 07:46 |
chenzeng | _restore_operations is used to register operations which belong to this service to triggers. at same time resume the operations which are not finished. | 07:48 |
openstackgerrit | chenying proposed openstack/smaug: Add fullstack test to smaug https://review.openstack.org/306996 | 07:51 |
openstackgerrit | smile-luobin proposed openstack/smaug: Implement HeatTemplate for restore https://review.openstack.org/307549 | 07:55 |
yinweiishere | ping xiangxingyong | 07:58 |
chenzeng | yuval:? | 07:58 |
yuval | chenzeng: yes | 07:58 |
chenzeng | yuval:are you thinking the logs? | 07:59 |
yuval | no, I was reviewing | 07:59 |
yuval | well, I still don't understand what you said about losing the operations | 08:00 |
yuval | can you explain again? | 08:00 |
yuval | chenzeng: ? | 08:05 |
chenzeng | yuval:ok | 08:05 |
chenzeng | yuval:In the ThreadPoolExecutor, there is a queue to store the operation ids. if service creashes, then all the ids will be lost if we don't create a record of ScheduledOperationLog in the db first. | 08:08 |
chenzeng | yuval:the queue is in the futures.ThreadPoolExecutor. | 08:09 |
chenzeng | When the service restarts, then we will resume the operation by the records in the db. | 08:10 |
chenzeng | yuval:do you understand? | 08:11 |
yuval | I understand the problem, but I don't understand how the logs are related | 08:13 |
yuval | Don't we create a ScheduledOperationState just for that? | 08:13 |
yuval | And if we keep the log creation in the executor, the problem still exists | 08:14 |
openstackgerrit | smile-luobin proposed openstack/smaug: Store ResourceGraph and Plan in checkpoint https://review.openstack.org/307737 | 08:15 |
yuval | If the operation didn't start when the service crash -> it will be registered again. If it was running when we crashed, register it and resume | 08:17 |
openstackgerrit | Merged openstack/smaug: Add show protectables instance endpoint https://review.openstack.org/302144 | 08:39 |
openstackgerrit | Merged openstack/smaug: Add a field parameters to resource plans https://review.openstack.org/302730 | 08:39 |
chenzeng | yuval:in the db, there is one record of ScheduledOperationState, but there are many records of ScheduledOperationLog. i think we have different understandings. tonight, i will discuss with you again. now , i will submit the codes of clients. | 08:44 |
yuval | chenzeng: Ok, I understand. But still, what is the difference between placing the logging in operation and executor? | 08:49 |
chenzeng | The 'execute' method of the operation class like ProtectOperation just updates the 'extend_info' of ScheduledOperationLog record; but the executor creates the record of ScheduledOperationLog. | 08:53 |
chenzeng | we must create the log first, then update it. | 08:53 |
yuval | But why should the executor create it? The executor is class which is responsible for executing abstract operations | 08:55 |
yuval | Consider the following: | 08:55 |
yuval | class BaseOperation(): | 08:56 |
yuval | def exectue(): | 08:56 |
yuval | create_log() | 08:56 |
yuval | self._execute() | 08:56 |
yuval | the protect/delete/restore operations overrides the _execute method | 08:56 |
xiangxinyong | yuval: I modify the video details, please receive the email. thanks | 08:57 |
xiangxinyong | saggi: ping | 09:16 |
openstackgerrit | xiangxinyong proposed openstack/smaug-dashboard: [Operation Logs] Submit index view function https://review.openstack.org/307729 | 09:17 |
saggi | xiangxinyong: pong | 09:58 |
xiangxinyong | saggi: do you think we need to send the smaug video to mail list? | 09:59 |
*** xiangxinyong456 has joined #openstack-smaug | 10:03 | |
openstackgerrit | zengchen proposed openstack/smaug: Fix the expiry of token when creating client by context https://review.openstack.org/308243 | 10:10 |
yuval | ping chenzeng | 10:11 |
chenzeng | yuval & yinwei:i have submitted the first version to fix the expiry of token when creating client by context. please review it. https://review.openstack.org/308243 | 10:11 |
chenzeng | yuva:yes | 10:11 |
yuval | chenzeng: great, I'm looking into it | 10:11 |
yuval | chenzeng: have you seen my comments on https://review.openstack.org/#/c/304048/ ? | 10:12 |
chenzeng | yuval:not yet. i will see it tonight. then discuss with you. | 10:13 |
chenzeng | yuval:now, i have to leave the office. | 10:13 |
chenzeng | yuval:see you later. | 10:13 |
yuval | chenzeng: have a good night, thank you! | 10:13 |
yuval | :) | 10:13 |
saggi | xiangxinyong, please send it to me first | 10:20 |
xiangxinyong456 | saggi: ok | 10:21 |
xiangxinyong456 | saggi: i have already send it to your email | 10:22 |
saggi | I'll check it now | 10:22 |
xiangxinyong456 | yuval give some suggestions to me. | 10:22 |
yuval | xiangxinyong456: I've seen the new version and it looks good | 10:23 |
xiangxinyong456 | saggi: so please check the lastest version | 10:23 |
xiangxinyong456 | yuval: thanks: ) | 10:23 |
*** yinwei_computer has quit IRC | 10:25 | |
*** yinwei_computer has joined #openstack-smaug | 10:26 | |
saggi | xiangxinyong456: I can't find it. Where did you send it too? | 10:32 |
xiangxinyong456 | please wait a moment | 10:33 |
xiangxinyong456 | saggi: could you search steven gerrard | 10:34 |
xiangxinyong456 | i use my another email | 10:35 |
*** yinwei_computer has quit IRC | 10:38 | |
*** yinwei_computer has joined #openstack-smaug | 10:38 | |
xiangxinyong456 | i send it to this email | 10:38 |
xiangxinyong456 | saggi.mizrahi@toganetworks.com | 10:38 |
xiangxinyong456 | saggi: do you find it? | 10:39 |
saggi | xiangxinyong456: nope, I have only 3 emails from today and non of them are from you | 10:45 |
xiangxinyong456 | saggi: is there email title named “smaug-video” | 10:47 |
xiangxinyong456 | yuval: could you help me to send the lastest email to saggi? | 10:49 |
xiangxinyong456 | sorry, i am on my way home | 10:49 |
*** xiangxinyong456 has quit IRC | 11:22 | |
*** xiangxinyong456 has joined #openstack-smaug | 11:23 | |
*** xiangxi55 has joined #openstack-smaug | 11:24 | |
*** xiangxinyong456 has quit IRC | 11:24 | |
*** xiangxi41 has joined #openstack-smaug | 11:26 | |
*** xiangxi55 has quit IRC | 11:28 | |
*** xiangxi41 has quit IRC | 11:35 | |
xiangxinyong | saggi: are you around? i arrive home. | 11:37 |
*** WANGFeng has joined #openstack-smaug | 11:43 | |
xiangxinyong | yuval: ping | 11:48 |
yuval | xiangxinyong: saggi is here | 11:51 |
yuval | xiangxinyong: he saw the video | 11:51 |
yuval | xiangxinyong: he thinks it is a bit long | 11:51 |
yuval | xiangxinyong: maybe skip the trigger creation (in the end) | 11:51 |
xiangxinyong | yuval: ok | 11:53 |
xiangxinyong | i will clip cut the trigger part. | 11:54 |
xiangxinyong | I will send an email to all of you later | 11:55 |
xiangxinyong | yuval: is this saggi's email: saggi.mizrahi@toganetworks.com | 11:55 |
xiangxinyong | yuval: i send a new video to you by email. | 12:18 |
xiangxinyong | yuval: if it is possible, please tell saggi. thanks. | 12:20 |
*** dell has joined #openstack-smaug | 12:53 | |
*** dell is now known as zengchen | 13:02 | |
zengchen | yuval:good afternoon! are you there? | 13:02 |
yuval | zengchen: hey, I'm here | 13:02 |
zengchen | yuval:are you free now? | 13:02 |
yuval | zengchen: yes | 13:02 |
zengchen | yuval: we have two issues to discuss. | 13:04 |
zengchen | yuval:first, we talk the comments on the https://review.openstack.org/#/c/304048/4/smaug/operationengine/manager.py. why should filter the operation by 'running'. | 13:05 |
yuval | you pass the "resume=True" to register_operation() | 13:05 |
zengchen | yes | 13:06 |
yuval | the operation state can be "registered", "triggered", "running", "deleted", "init" | 13:06 |
yuval | what happens to operations which were in state "triggered" and "running" | 13:07 |
zengchen | actually, the operations which should be resumed are in running. but at present, i have not used the 'running'. | 13:07 |
yuval | so who should use "running"? | 13:08 |
zengchen | i intend to get the running operations by filter the records of SchedueledOperationLog whose state is 'in_progress'(scheduled_operation_execution_state.py) | 13:11 |
zengchen | so, i think i should tell you the design at present. | 13:12 |
zengchen | 1.when creating the operation, we will create a record of ScheduledOperationState in db with state 'registered'. | 13:13 |
zengchen | 2.when the operation is triggered, then i will create a record of ScheduledOperationLog in db with state 'in_progress'. | 13:14 |
*** chenying_ has joined #openstack-smaug | 13:16 | |
zengchen | 3. if the operation is executed, then i will update the record of ScheduledOperationLog in db with state 'success/failed/drop_out_of_window'. | 13:16 |
*** zhonghua-lee has quit IRC | 13:17 | |
*** zhonghua-lee has joined #openstack-smaug | 13:17 | |
*** chenying has quit IRC | 13:19 | |
zengchen | therefore, 1. I create a record of ScheduledOperationLog when invoke 'exuecute_operation' of RecordOperationLogExecutor, because I use DB to keep the operations which are triggered to avoid lose them. | 13:21 |
yuval | ping yinweiishere yinwei_computer | 13:22 |
zengchen | 2. becuase there is a state 'in_progress' to indicate that the operation is running. I have not filtered the operation by state 'running' when resuming it. | 13:24 |
zengchen | yuval:do you understand my words? | 13:25 |
yuval | Yes, but an executor shall not create a log | 13:26 |
yuval | An operation might | 13:26 |
yuval | Currently, when you restart the service, even tasks which were registered but not in the middle of a run, get resumed | 13:27 |
zengchen | ok, i have one question. suppose there 10 operation ids in the queue of ThreadPoolExecutor, then the service crashes. do we need to resume these 10 operations? | 13:28 |
yuval | if the we are still in the time window | 13:30 |
yuval | consider that the service crashes and comes back after 3 hours | 13:30 |
yuval | or 1 week | 13:30 |
yuval | zengchen: ? | 13:33 |
zengchen | i mean how to know which operatoins showld be resumed. your comments give me a way that update the state of ScheduledOperationState record when the operation is triggered. | 13:33 |
zengchen | but restart, filter the operation by 'running' and 'triggered'. | 13:34 |
zengchen | yes, you are right. if the operation is out of window, we will not resume it. | 13:35 |
yuval | so I don't understand: | 13:35 |
yuval | 1. why don't 'running' and 'triggered' operations are not sent to resume_operation | 13:36 |
zengchen | yuval:i understand your idea. it is very good. | 13:36 |
yuval | ok | 13:36 |
zengchen | but, one question. | 13:36 |
zengchen | we must make sure there are not two operation ids in the queue. | 13:37 |
yuval | yes, important | 13:38 |
zengchen | i mean if the operation's state is running when it is triggered again. then how do we do? ignore this time? | 13:39 |
zengchen | at present. the interval between two time points is >= 1h. and the window < interval/2. i think it is hardly to happen that. | 13:41 |
zengchen | yuval? | 13:43 |
yuval | but an operation can register to two triggers | 13:44 |
yuval | for example, every day at 12:00, and once a week at sunday 12:00 | 13:44 |
yuval | every sunday 12:00 they will collide | 13:45 |
zengchen | that are two different operations. you can see the api of create operation. we have not supported to bind one operation with tow different triggers. | 13:46 |
zengchen | one operation is mapping to one trigger. | 13:46 |
yuval | I'm not sure we are not supporting that | 13:52 |
yuval | brb | 13:53 |
zengchen | at present, we don't support that. I will update as you designed. | 13:56 |
zengchen | yuval:do you have time to review the patch today? https://review.openstack.org/#/c/308243/ | 13:58 |
yuval | zengchen: I already started writing comments, will post them once I finish | 14:23 |
zengchen | yuval:thanks for your work. very thanks. see you tomorrow!. | 14:57 |
yuval | zengchen: you too, see you :) | 14:57 |
*** zengchen has quit IRC | 14:58 | |
*** yuval has quit IRC | 15:03 | |
*** mingyu has joined #openstack-smaug | 16:21 | |
*** mingyu has quit IRC | 16:47 | |
*** mingyu has joined #openstack-smaug | 16:54 | |
*** WANGFeng has quit IRC | 17:12 | |
*** mingyu has quit IRC | 20:13 | |
*** mingyu has joined #openstack-smaug | 20:43 | |
*** mingyu has quit IRC | 20:48 | |
*** mingyu has joined #openstack-smaug | 22:33 | |
*** mingyu has quit IRC | 22:37 | |
*** mingyu has joined #openstack-smaug | 23:48 | |
*** mingyu has quit IRC | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!