*** Jeffrey4l_ has quit IRC | 02:02 | |
*** Jeffrey4l_ has joined #openstack-karbor | 02:03 | |
*** yamamot__ has joined #openstack-karbor | 02:27 | |
openstackgerrit | zhangshuai proposed openstack/karbor-dashboard: Update README.RST https://review.openstack.org/413873 | 02:32 |
---|---|---|
openstackgerrit | Merged openstack/python-karborclient: Fix the end_date filter in the checkpoint list API https://review.openstack.org/414482 | 02:38 |
openstackgerrit | zhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db https://review.openstack.org/398892 | 02:39 |
openstackgerrit | Merged openstack/karbor-dashboard: Fix using one str to initialize three variables on a single line https://review.openstack.org/408062 | 02:42 |
openstackgerrit | Merged openstack/karbor-dashboard: Fix deleting child_sid from nodes_dict one more time https://review.openstack.org/414676 | 02:43 |
*** yamamot__ has quit IRC | 03:34 | |
*** yamamot__ has joined #openstack-karbor | 03:39 | |
openstackgerrit | Merged openstack/karbor: Updated from global requirements https://review.openstack.org/414267 | 04:31 |
*** Jeffrey4l_ has quit IRC | 04:43 | |
*** Jeffrey4l has joined #openstack-karbor | 05:57 | |
*** zhangshuai has quit IRC | 06:53 | |
openstackgerrit | zhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db https://review.openstack.org/398892 | 07:20 |
*** yuval has joined #openstack-karbor | 07:35 | |
chenying | ping yuval | 07:39 |
chenying | ping yuvalb | 07:40 |
yuval | ping chenying | 07:55 |
openstackgerrit | zhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db https://review.openstack.org/398892 | 08:10 |
openstackgerrit | Merged openstack/karbor: fix scheduledoperation fullstack https://review.openstack.org/402347 | 08:11 |
chenying | hi yuval I note that the hook of plugin's operation don't return any value. Do we need think about it? | 08:50 |
yuval | hey chenying | 08:50 |
yuval | chenying: what value could it return? | 08:50 |
chenying | I have discussed the plugin's new hooks with one guy from Commvault. | 08:51 |
chenying | He introduced one use cases, we may need think about it. | 08:51 |
chenying | Now, this is no return value in main hook of plugin. | 08:51 |
chenying | His use case is that the main hook of the volume plugin can return some value about statistics and quotas. | 08:51 |
chenying | And then in the post hook of the volume plugin, he can use the return value form main hook do some operation about metering and quotas. | 08:51 |
*** yamamot__ has quit IRC | 08:52 | |
openstackgerrit | shizhihui proposed openstack/python-karborclient: Enable DeprecationWarning in test environments https://review.openstack.org/414899 | 08:53 |
yuval | chenying: we can already provide that, with no return value: | 08:54 |
chenying | yuval I mean that we provider the return value mechanism, like a dict, we don't define the keys about it. If the vendors need the return value from main hook, he can define the keys as he want, and he can use the values in the post hook of his plugin. | 08:54 |
openstackgerrit | shizhihui proposed openstack/karbor: Set access_policy for messaging's dispatcher https://review.openstack.org/413528 | 08:55 |
chenying | yuval: we can already provide that, with no return value: ---- I don't understand | 08:56 |
yuval | chenying: I'll be writing an explanation, please let me write for a minute | 08:56 |
chenying | yuval: OK :) | 08:57 |
yuval | chenying: in the protection service, we have a few 'context' levels for protection plugins. 1) the context of the service (the instance of the protection service currently running) 2) the context of the operation (protect/restore/delete) 3) the context of the resource | 08:58 |
yuval | The first context is not very interesting. Protection Plugins define classmethods for service-level context (get_options_schema, get_supported_resources_types, etc) | 08:59 |
yuval | it is like 'global' protection plugin attributes | 08:59 |
yuval | then we have the operation-context. things that are specific to the current operation | 09:00 |
yuval | for that, the protection plugin implements get_{restore,delete,protect}_operation methods | 09:00 |
yuval | these methods return an *instance* of Operation | 09:00 |
yuval | the protection plugin instance is created for each operation | 09:01 |
yuval | so if you need to save attributes which will presist between operations, you can set them into the protection plugin instance in get_{restore,delete,protect}_operation methods | 09:01 |
*** yamamoto has joined #openstack-karbor | 09:01 | |
yuval | the Operation class can be created for each resource. So if we protect a volume, the protection plugin will create a ProtectOperation, for that operation & resource | 09:02 |
yuval | every attribute defined for that instance will be available for all hooks | 09:02 |
yuval | So the short answer is - if in on_prepare_begin() you do: self.my_variable = 1 | 09:03 |
yuval | Then in on_main() you can access it by using self.my_variable | 09:03 |
yuval | because it is stored in the Operation instance | 09:03 |
yuval | I hope that this is clear :| | 09:04 |
yuval | chenying: are you still here? | 09:05 |
chenying | yuval : I have noted that every resource will introduce one plugin/Operation instance. You mean that save some values to this instance, it can be get from every hook of this instance. | 09:07 |
yuval | chenying: if get_protect_operation returns a new operation for every resource (and it should in most cases), then yes | 09:07 |
chenying | yuval: You know that the hook of operation have been wrapped to a task. So I will think it over, use the variable of operation instance to pass values between operation's hooks. | 09:13 |
yuval | chenying: sorry, didn't understand :\ | 09:13 |
*** gouthamr has joined #openstack-karbor | 09:18 | |
chenying | yuval: My thought is that use the task's provide/require parameters to return value form main hook task and get the return value in the post hook task. | 09:28 |
yuval | chenying: there is no need for that | 09:28 |
yuval | chenying: as I said, in on_prepare_begin(): self.my_variable = 1 in on_main(): access self.my_variable | 09:29 |
chenying | yuval: I am clear now, I will introduce this to the guy from a vendor. | 09:32 |
yuval | chenying: sure :) ping me if something is not clear | 09:32 |
chenying | yuval: Why we need init operation instances for every resources? Yuval, If you have saw the cinder/manila plugin mechanism, one service only have one plugin instance, the plugin module just is a executer, the variable about share/volume will not be saved to this plugin instance. | 09:39 |
yuval | chenying: you don't have to create an operation for each resource, but it might be a very good idea to do so | 09:40 |
yuval | chenying: especially if you want to store variables between hooks | 09:40 |
chenying | yuval: That may be the question, if in the post hook task need the return value from main hook, we have to create an operation for each resource. If use the task's provide/require parameters, we may don't have to. | 09:44 |
yuval | chenying: are you concerned about performance? | 09:44 |
yuval | using provide/require is problematic, mostly because: 1) we are being bound to taskflow, which we might change when day. 2) name clashes 3) we already set the 'require' for functor tasks. not sure we can update it from whithin the task | 09:47 |
chenying | yuval: We may don't concern the performance now, but the vendor use karbor to provide DPaaS service to tenant, they care about the performance very much. | 09:47 |
yuval | chenying: performance is crucial, but creating an instance in python for each resource is not such an impact on performance | 09:48 |
chenying | yuval: If karbor will be used in public cloud to provide DPaaS service, the amount of resources in one services is huge. | 09:52 |
openstackgerrit | Merged openstack/karbor: Use parenthesis instead of slash for multiline https://review.openstack.org/414746 | 09:57 |
*** gouthamr has quit IRC | 10:19 | |
openstackgerrit | Pengju Jiao proposed openstack/karbor: Fix creating protection flow failed. Class that inherited from ProtectionPlugin should implement methods named 'get_protect_operation', 'get_restore_operation' and 'get_delete_operation'. Otherwise, karbor-protection will throw NotImplementedError. https://review.openstack.org/414929 | 10:41 |
openstackgerrit | Merged openstack/python-karborclient: Enable DeprecationWarning in test environments https://review.openstack.org/414899 | 11:42 |
openstackgerrit | Pengju Jiao proposed openstack/karbor: Fix creating protection flow failed. https://review.openstack.org/414929 | 12:00 |
*** zhangshuai has joined #openstack-karbor | 12:45 | |
*** zhurong has joined #openstack-karbor | 12:48 | |
*** tommylikehu_ has joined #openstack-karbor | 13:38 | |
*** tommylikehu_ has quit IRC | 13:40 | |
*** tommylikehu_ has joined #openstack-karbor | 13:42 | |
*** zhurong has quit IRC | 13:47 | |
*** tommylikehu_ has quit IRC | 14:41 | |
*** tommylikehu_ has joined #openstack-karbor | 14:45 | |
*** tommylikehu_ has quit IRC | 15:03 | |
*** yuval has quit IRC | 16:02 | |
*** yamamoto has quit IRC | 16:38 | |
*** yamamoto has joined #openstack-karbor | 16:44 | |
*** yamamoto has quit IRC | 17:22 | |
*** edisonxiang has quit IRC | 17:30 | |
*** edisonxiang has joined #openstack-karbor | 17:30 | |
*** yamamoto has joined #openstack-karbor | 18:23 | |
*** yamamoto has quit IRC | 18:33 | |
*** edisonxiang has quit IRC | 19:21 | |
*** edisonxiang has joined #openstack-karbor | 19:21 | |
*** x00350071_ has joined #openstack-karbor | 19:25 | |
*** edisonxiang has quit IRC | 19:28 | |
*** x00350071_ has quit IRC | 19:31 | |
*** x00350071_ has joined #openstack-karbor | 19:32 | |
*** gouthamr has joined #openstack-karbor | 19:51 | |
*** Jeffrey4l has quit IRC | 21:35 | |
*** Jeffrey4l has joined #openstack-karbor | 21:47 | |
*** gouthamr has quit IRC | 22:32 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!