Monday, 2016-12-26

*** Jeffrey4l_ has quit IRC02:02
*** Jeffrey4l_ has joined #openstack-karbor02:03
*** yamamot__ has joined #openstack-karbor02:27
openstackgerritzhangshuai proposed openstack/karbor-dashboard: Update README.RST  https://review.openstack.org/41387302:32
openstackgerritMerged openstack/python-karborclient: Fix the end_date filter in the checkpoint list API  https://review.openstack.org/41448202:38
openstackgerritzhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db  https://review.openstack.org/39889202:39
openstackgerritMerged openstack/karbor-dashboard: Fix using one str to initialize three variables on a single line  https://review.openstack.org/40806202:42
openstackgerritMerged openstack/karbor-dashboard: Fix deleting child_sid from nodes_dict one more time  https://review.openstack.org/41467602:43
*** yamamot__ has quit IRC03:34
*** yamamot__ has joined #openstack-karbor03:39
openstackgerritMerged openstack/karbor: Updated from global requirements  https://review.openstack.org/41426704:31
*** Jeffrey4l_ has quit IRC04:43
*** Jeffrey4l has joined #openstack-karbor05:57
*** zhangshuai has quit IRC06:53
openstackgerritzhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db  https://review.openstack.org/39889207:20
*** yuval has joined #openstack-karbor07:35
chenyingping yuval07:39
chenyingping yuvalb07:40
yuvalping chenying07:55
openstackgerritzhangshuai proposed openstack/karbor: Add and delete checkpoint_record of CheckpointRecord db  https://review.openstack.org/39889208:10
openstackgerritMerged openstack/karbor: fix scheduledoperation fullstack  https://review.openstack.org/40234708:11
chenyinghi yuval I note that the hook of plugin's operation don't return any value. Do we need think about it?08:50
yuvalhey chenying08:50
yuvalchenying: what value could it return?08:50
chenyingI have discussed the plugin's new hooks with one guy from Commvault.08:51
chenyingHe introduced one use cases, we may need think about it.08:51
chenyingNow, this is no return value in main hook of plugin.08:51
chenyingHis use case is that the main hook of the volume plugin can return some value about statistics and quotas.08:51
chenyingAnd 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 IRC08:52
openstackgerritshizhihui proposed openstack/python-karborclient: Enable DeprecationWarning in test environments  https://review.openstack.org/41489908:53
yuvalchenying: we can already provide that, with no return value:08:54
chenyingyuval 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
openstackgerritshizhihui proposed openstack/karbor: Set access_policy for messaging's dispatcher  https://review.openstack.org/41352808:55
chenyingyuval:  we can already provide that, with no return value: ---- I don't understand08:56
yuvalchenying: I'll be writing an explanation, please let me write for a minute08:56
chenyingyuval: OK :)08:57
yuvalchenying: 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 resource08:58
yuvalThe first context is not very interesting. Protection Plugins define classmethods for service-level context (get_options_schema, get_supported_resources_types, etc)08:59
yuvalit is like 'global' protection plugin attributes08:59
yuvalthen we have the operation-context. things that are specific to the current operation09:00
yuvalfor that, the protection plugin implements get_{restore,delete,protect}_operation methods09:00
yuvalthese methods return an *instance* of Operation09:00
yuvalthe protection plugin instance is created for each operation09:01
yuvalso 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 methods09:01
*** yamamoto has joined #openstack-karbor09:01
yuvalthe Operation class can be created for each resource. So if we protect a volume, the protection plugin will create a ProtectOperation, for that operation & resource09:02
yuvalevery attribute defined for that instance will be available for all hooks09:02
yuvalSo the short answer is - if in on_prepare_begin() you do: self.my_variable = 109:03
yuvalThen in on_main() you can access it by using self.my_variable09:03
yuvalbecause it is stored in the Operation instance09:03
yuvalI hope that this is clear :|09:04
yuvalchenying: are you still here?09:05
chenyingyuval : 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
yuvalchenying: if get_protect_operation returns a new operation for every resource (and it should in most cases), then yes09:07
chenyingyuval: 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
yuvalchenying: sorry, didn't understand :\09:13
*** gouthamr has joined #openstack-karbor09:18
chenyingyuval: 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
yuvalchenying: there is no need for that09:28
yuvalchenying: as I said, in on_prepare_begin(): self.my_variable = 1       in on_main(): access self.my_variable09:29
chenyingyuval: I am clear now, I will introduce this to the guy from a vendor.09:32
yuvalchenying: sure :) ping me if something is not clear09:32
chenyingyuval: 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
yuvalchenying: you don't have to create an operation for each resource, but it might be a very good idea to do so09:40
yuvalchenying: especially if you want to store variables between hooks09:40
chenyingyuval: 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
yuvalchenying: are you concerned about performance?09:44
yuvalusing 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 task09:47
chenyingyuval: 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
yuvalchenying: performance is crucial, but creating an instance in python for each resource is not such an impact on performance09:48
chenyingyuval: If karbor will be used in public cloud to provide DPaaS service,  the amount of resources in one services is huge.09:52
openstackgerritMerged openstack/karbor: Use parenthesis instead of slash for multiline  https://review.openstack.org/41474609:57
*** gouthamr has quit IRC10:19
openstackgerritPengju 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/41492910:41
openstackgerritMerged openstack/python-karborclient: Enable DeprecationWarning in test environments  https://review.openstack.org/41489911:42
openstackgerritPengju Jiao proposed openstack/karbor: Fix creating protection flow failed.  https://review.openstack.org/41492912:00
*** zhangshuai has joined #openstack-karbor12:45
*** zhurong has joined #openstack-karbor12:48
*** tommylikehu_ has joined #openstack-karbor13:38
*** tommylikehu_ has quit IRC13:40
*** tommylikehu_ has joined #openstack-karbor13:42
*** zhurong has quit IRC13:47
*** tommylikehu_ has quit IRC14:41
*** tommylikehu_ has joined #openstack-karbor14:45
*** tommylikehu_ has quit IRC15:03
*** yuval has quit IRC16:02
*** yamamoto has quit IRC16:38
*** yamamoto has joined #openstack-karbor16:44
*** yamamoto has quit IRC17:22
*** edisonxiang has quit IRC17:30
*** edisonxiang has joined #openstack-karbor17:30
*** yamamoto has joined #openstack-karbor18:23
*** yamamoto has quit IRC18:33
*** edisonxiang has quit IRC19:21
*** edisonxiang has joined #openstack-karbor19:21
*** x00350071_ has joined #openstack-karbor19:25
*** edisonxiang has quit IRC19:28
*** x00350071_ has quit IRC19:31
*** x00350071_ has joined #openstack-karbor19:32
*** gouthamr has joined #openstack-karbor19:51
*** Jeffrey4l has quit IRC21:35
*** Jeffrey4l has joined #openstack-karbor21:47
*** gouthamr has quit IRC22:32

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