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