14:04:24 #startmeeting Rally 14:04:25 Meeting started Mon Apr 25 14:04:24 2016 UTC and is due to finish in 60 minutes. The chair is andreykurilin__. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:04:28 The meeting name has been set to 'rally' 14:04:32 hi folks 14:05:10 hi 14:05:49 #link https://wiki.openstack.org/wiki/Meetings/Rally 14:05:52 agenda^ 14:06:01 we have several items today:) 14:06:27 let's wait a bit for more attendees 14:07:20 o/ 14:07:39 hi 14:08:24 ok, let's start 14:08:33 #topic news 14:09:05 At the last meeting I announced 0.4.0 release 14:09:21 There was a change related to releasing new tags 14:09:43 But we finally released new version! 14:09:55 so we can work on new release 14:10:02 hi 14:10:04 great! 14:10:05 I think it will be major release too 14:10:41 as far as I know amaretskiy submitted a base class for Service entity 14:10:47 Sure because of services) 14:10:57 #link https://review.openstack.org/#/c/309967 14:10:58 #link https://review.openstack.org/#/c/309967/ 14:11:01 :) 14:11:19 it is high-priority patch 14:11:28 please spend a bit of time and review it 14:12:01 ... and propose services based on this patch :) 14:12:08 sure:) 14:12:13 my service is network 14:12:34 let's move to the next topic 14:12:41 about priority agree will review soon 14:12:59 #topic [amaretskiy] Let's define what messages we always wrap with rally.commin.i18n._ and what we don't translate. It would be great to save this rule somewhere. 14:13:14 i believe the question is clear 14:13:19 ideas? 14:13:43 my thought is that errors and user-related messages should be internationalized 14:14:02 #link http://docs.openstack.org/developer/oslo.i18n/guidelines.html 14:14:02 all log messages (debug, warnings. etc) - not 14:14:28 Imo, we should accept this guideline ^ 14:14:36 agree 14:14:46 all levels except debug should be translated 14:15:19 Also, it will be great, if we start translating reports ;) 14:15:48 BUT we have an issue with translations now. 14:15:57 it is not enabled now for Rally 14:15:59 :( 14:16:00 i think this should be confirmed by boris-42 14:16:24 if i'm not mistaken, he told that log messages should not be translated 14:16:39 O_o 14:16:45 also, i see guidelines how to translate but not WHAT translate 14:16:53 all log messages? 14:17:27 amaretskiy: see Note for http://docs.openstack.org/developer/oslo.i18n/guidelines.html#log-translation 14:17:27 i'm not sure 14:17:40 >Debug level log messages are not translated. 14:18:00 * redixin is trying to imagine user who understand log files but don't understand english 14:18:11 :D 14:18:14 but i think we should get confirmation from boris-42 14:18:40 we should not be strict for these rules until we enable translations 14:19:17 anyway we'd better wait for boris-42 if we mention his opinion)) 14:19:19 so what the conclusion? 14:19:34 agreed with ikhudoshyn 14:19:52 lets move all i18n discussions to the next release 14:20:05 to the next meeting ;) 14:20:09 no 14:20:13 to the next meeting:) 14:20:24 *to the next release 14:20:26 lol 14:21:17 so when will we discuss that ? 14:21:37 yep we seem to busy nowadays -- next release sounds goog 14:21:41 *good 14:22:04 Imo, we have enough tasks for this release and we should not be strict for i18n until we enable it. It is not high priority feature, but let try to enable i18n during next release and define rules for it 14:23:16 ok, let's move this topic just forward 14:23:26 #topic * [amaretskiy] How to prevent unexpected changing of mutable data (for example context configuration)? 14:23:39 - https://review.openstack.org/#/c/307340/ FrozenDict looks good for first sign, however it (at least for now) does not prevent changing of nested data (http://paste.openstack.org/show/495134/) 14:23:47 - copy.deepcopy() works fine but does not raise exceptions, which is also bad 14:24:46 amaretskiy? 14:24:54 there is an idea to process given dict recursively and transfrom all dict's into FrozenDict 14:25:24 for example: FrozenDict({"foo": {"bar": {"spam": 42}}}) 14:25:36 here we have 3 levels of nexting 14:25:40 *nesting 14:25:53 so there will be 3 FrozenDict instances 14:26:04 any ideas? 14:26:13 does this look fine? 14:26:19 alternatives? 14:26:52 why deepcopy is not good for us? 14:27:05 because we want to have error raised 14:27:10 if dict is changed 14:27:26 this feature is requested by boris-42 14:27:35 do we? I thought we just want some isolation of context instances? 14:28:03 the idea is not only isolation, but keeping context config unchanged 14:28:08 this may help us to detect some hidden errors 14:28:14 Why not to use already implemented examples and see how they work? 14:28:18 changing it in runtime is something wrong 14:28:20 +1 to ikhudoshyn 14:28:56 well.. 14:29:08 deepcopy simply solves bug but it does not prevent doing wrong approach 14:29:14 also frozenDict uses less memory lol 14:29:34 of cause we need frozenDict 14:30:01 we actually can run in trouble if scenario changes context and EXPECTS that this change will persist 14:30:16 in this case we DO need an exception here 14:30:31 ikhudoshyn: we have mechanism for that 14:30:34 instead of implementing bicycles with it's(frozenDict) prperties 14:30:35 i guess i agree with nesting frozenDicts 14:30:40 FrozenDict actually allows changes 14:30:48 via explicit interface 14:31:07 with frozendict_inst.unlocked(): do changes here 14:31:26 what unlock on frozenDict?) 14:31:47 context manager interface 14:31:51 __enter__() 14:31:56 __exit__() 14:32:16 with frozen_dict.unlocked(): {here changes} 14:32:23 unlocked() returns manager 14:32:31 so this is an explicit interface 14:32:35 so it can be used 14:32:40 in some cases 14:32:48 __exit__() locks th edict 14:34:42 ideas? confirmations? 14:34:46 __enter__() simple dict without lock or unlock __exit__() "lock" dict - frozenDict 14:34:49 ? 14:35:39 In a lot of realizations they just pass simple dict to FrozenDict() and that is all 14:35:43 rvasilets__: this context manager interface is already implemented - see https://review.openstack.org/#/c/307340/ 14:35:47 then its locked forever 14:35:57 What is not proposed is recursive processing 14:36:20 the problem is that FrozenDict actually freezes only 1st level of dict 14:36:37 for example: fd = FrozenDict({"foo": {"bar": {"spam": 42}}}) 14:36:54 fd[42] = 24 # have error! 14:37:10 fd["foo"][42] = 24 # works! not locked!!!! 14:37:21 this can be fixed 14:37:34 via recursive FrozenDict transformation 14:38:00 yes I wrote this case in comments itself 14:38:10 so fd["foo"] will be also FrozenDict, and the idea is that it will be another instance of FrozenDict 14:38:25 maybe there ar eanother ideas 14:38:33 well recursive frozendicts look goot for the first view 14:38:37 please propose ideas, thoughts, 14:38:43 or maybe confirm my idea 14:39:14 And as we discussed with Boris 14:39:17 alternative is having all data in single FrozenDict 14:39:18 yet it can be rather tedious when we need to make a change on the, say, fourth level of nesting 14:39:21 This is how python works 14:39:31 He told me that its normal) 14:39:47 I think we can do transformation in getitem method 14:39:50 and gave me the lnk to reference tpe 14:39:59 *reference type 14:40:47 andreykurilin__: this would be weird 14:40:49 He told that for every python user this is normal and would be scary if we will get other behavior) 14:41:02 just to consider: if we have relatively simple FrozenDict class and just transfrom all dict->FrozenDict recursively, we will have this: 14:41:12 rvasilets__: yep, reference types are soooo reference 14:41:19 The only idea is to iterate recursovaly 14:41:21 with fd["foo"]["bar"]["spam"].unlocked(): do changes 14:41:27 nothing else 14:41:31 amaretskiy: +1 14:41:38 but with complex class, we will have this: 14:41:40 amaretskiy: great, I missed that 14:42:05 I'm completely +2 for recursive frozendicts 14:42:12 with fd.unlocked(): changes in fd["foo"]["bar"]["spam"] 14:42:32 ^^^ that looks wrong 14:43:23 personally I like approach with simple FrozenDict - it is simple :) 14:43:42 with fd["foo"]["bar"]["spam"].unlocked(): do changes -->> This would be not the frozen actually already if we will get such possibility( 14:43:47 #vote for interface with fd["foo"]["bar"]["spam"].unlocked(): do changes 14:44:11 Do we ever need unlock mechanism at all? 14:44:34 I don't undestand fo what I should vote what is the quastion? 14:44:45 4 PM Do we ever need unlock mechanism at all? 14:44:47 +1111 14:44:56 andreykurilin__: 1) this is requested by boris-42 and 2) https://review.openstack.org/#/c/306489/4/rally/plugins/openstack/context/api_versions.py 14:45:20 2) it should be fixed ;) 14:45:31 the code is changable 14:45:48 and with boris-42 we could discuss 14:45:56 so do we need? 14:45:58 rvasilets__: with fd["foo"]["bar"]["spam"].unlocked(): do changes <---- vs. ---> with fd.unlocked(): changes in fd["foo"]["bar"]["spam"] <--- vs. --> another idea 14:46:35 Dowe need such ability if think without boris? 14:46:42 ... <--- vs. ----> deepcopy() 14:46:49 amaretskiy: Imo, if we say that config should not be edited, we should not provide mechanism to do it 14:47:26 I think, api_version config should use self.context["api_version"] 14:47:44 *api_versions context should ... 14:47:50 andreykurilin__: the idea is lock dict for updates, but have an explicit interface to do changes if we really need them 14:48:08 I see no cases when we really need to change it 14:48:31 we have only one place, which looks like wrong usage:) 14:48:41 " an explicit interface to do changes if we really need them" ->> real frozen dict can't be unlocked 14:48:55 and don't have such interface 14:49:06 let's imagine we do not allow editing the dict 14:49:12 I'm fully agree with andreykurilin__ now 14:49:19 the topic is about another problem 14:49:22 :) 14:49:33 it is about how to prevent changes by reference 14:50:02 so I'm ok about recursive freeze 14:50:16 i mention with... unlocked() just to show the problem of wrapping data 14:50:47 we can invoke __getitem__() and make changes 14:51:21 okay 14:51:37 maybe just vote for this idea: 14:52:25 FrozenDict({"foo": {"bar" {"spam": 42}}}) -> FrozenDict({"foo": FrozrnDict({"bar": FrozenDict({"spam": 42})})}) 14:52:33 # +1 14:52:36 #vote +1 14:53:08 -2 -W for option #2 14:53:27 -1 14:53:32 :D 14:53:41 +1 14:53:48 ok so I'm misunderstood the question 14:54:01 ))) 14:54:12 possibly me too) 14:54:23 FrozenDict({"foo": {"bar" {"spam": 42}}}) -> FrozenDict({"foo": FrozrnDict({"bar": FrozenDict({"spam": 42})})}) 14:54:26 democracy is so much fun 14:54:33 what is the question?) 14:54:42 I thought that amaretskiy proposes a way how to initialize FrozenDict 14:54:57 But it looks like the question is only about auto transformation 14:55:07 no he proposes to recursively convert dicts to frozendicts 14:55:09 and to make immutable nested instances& 14:55:10 ? 14:55:17 Or 14:55:21 ou 14:55:37 I don't see any other options 14:55:40 +0.5 14:55:42 ) 14:55:44 me too 14:56:06 amaretskiy: go as you started)) 14:56:16 andreykurilin__: lets give by 0.5 and totally this would be +1) 14:56:23 btw we're running out of time 14:57:07 any other topics? 14:57:22 nothing from me 14:57:29 thanks to everyone 14:57:34 #endmeeting