14:04:23 #startmeeting Rally 14:04:27 Meeting started Mon Jun 13 14:04:23 2016 UTC and is due to finish in 60 minutes. The chair is amaretskiy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:04:30 The meeting name has been set to 'rally' 14:04:34 hi all! 14:04:45 o/ 14:05:01 o/ 14:05:36 hi hi 14:06:17 sdague dims: are you here?) 14:06:38 we have single topic in agenda 14:06:44 #topic Class RallyException does not provide i18n good enough without subclassing - we still have to use gettext in this case to split i18n part of message from non-translated args 14:07:25 please look at my small WIP patch that shows the problem and how it can be solved 14:07:39 #link https://review.openstack.org/#/c/328978/ 14:07:46 amaretskiy: unfortunately, i18n is not configured for rally 14:07:47 I'll take a look 14:07:52 the problem is explicit use of RallyException 14:08:02 we need someone how will finish integration at first 14:08:05 but I'd rather avoid all the gettext magic 14:08:05 yes, it's not configured right now 14:08:13 but we use i18n in code 14:08:20 maybe just use i18n properly? 14:09:10 the problem is that explicit use of RallyException causes i18n problem, at least if we have translated part of message + not translated args 14:09:36 and RallyException.__init__ is not ready for backward compatible fix 14:10:38 let's do not use rallyexcaption explicitly 14:10:48 hm 14:10:48 the main question is: whether is is Ok to raise RallyException explicitly at all? The opposite case is *always* subclass it (and have hundreds of exceptions in rally.exceptions 14:11:00 I think that explicit use is good 14:11:10 but we have i18n problem 14:11:31 creating new exception only for one usage is a wrong direction 14:11:37 +1 14:11:51 so I would rahter have a Exceptions that we can raise 14:11:53 moreover, if we event translate message and pass it to RallyException, like "raise RallyException(_("some message"))" 14:12:00 then gettext is calle dtwice 14:12:05 *called twice 14:12:12 we it will call it twice? 14:12:14 *why 14:12:43 I do not got it:) 14:13:07 from my point of view, the message will be translated on _() step 14:13:26 andreykurilin: 1) gettext in raise RallyException(_("some message")) and 2) at https://github.com/openstack/rally/blob/master/rally/exceptions.py#L37 14:13:26 our RallyException does not do any magic around it 14:13:53 amaretskiy: ` super(RallyException, self).__init__(self.msg_fmt % kwargs)` doesn't translate anything 14:13:57 https://github.com/openstack/rally/blob/master/rally/exceptions.py#L29 14:14:28 we should edit only L29 to not do a translation 14:14:40 that is all 14:14:47 so, I've explained the problem - we can not split translated and non-translated parts of message in explicit invokation 14:14:52 *invocation 14:14:56 any ideas? 14:15:15 `_("%s") % "asdasd"` will not translate anything except "%s" 14:15:21 so everything is ok 14:15:32 do not do _() in RallyException 14:15:40 +1 14:15:45 @amaretskiy that's bad we need to fix it somehow 14:15:45 it doesn't do anythin 14:15:45 call _explicitly in each exception raised 14:15:57 +1 14:16:11 the idea is using gettext inside rally.exceptions 14:16:14 explicit is better than implicit 14:16:22 how about my patch? 14:16:24 @andreykurilin @ikhudoshyn @amaretskiy ^ so maybe we can just write hacking rule? 14:16:45 boris-42: which one? 14:18:29 to check that "call _explicitly in each exception raised" 14:18:35 +1 14:18:40 like that ^^ 14:18:57 and avoid any magic 14:19:07 boris-42: is this good to call gettext while raising RallyException, not iside its __init__ ? 14:19:34 boris-42: we have to import i18n everywhere 14:19:39 in this case 14:19:49 amaretskiy: we already do it 14:20:04 i'm ok with the above 14:20:05 amaretskiy: so we can import in in exception module 14:20:21 amaretskiy: andreykurilin why this should produce any problems ^ ? 14:20:30 boris-42: we can not do this properly in rally.exceptions 14:21:04 boris-42: class RallyException can not translate message correctly in this cas 14:21:07 e*case 14:21:11 *case 14:22:08 okay, so, call gettext explicitly in place where we raise RallyException 14:22:08 okay I will think about this a bit more when I wake up ;) 14:22:51 amaretskiy: basically, I like the solution from your patch 14:23:33 ok, I think this topic finished 14:23:38 boris-42: the problem is that we can not raise RallyException without gettext, for example: raise RallyException("Error for %(key)", key="foo") 14:23:44 this is not possible 14:24:03 ok, let it be finished :) 14:24:11 amaretskiy: for this case boris-42 proposed hacking rule 14:24:14 #topic Free discussion 14:24:33 amaretskiy: can we discuss requirements 14:24:47 but it will not help for `msg = "asdfasdf"; raise RallyException(msg)` 14:24:55 @amaretskiy ^ 14:25:35 andreykurilin: that is why my patch is better approach 14:25:41 agrred 14:25:44 agree 14:26:20 #topic Requirements job 14:26:38 So guys I am trying to remove jobs 14:26:39 let's finally make a desicion :) 14:26:52 to not check rally requirements 14:26:57 basically 2 problems 14:27:08 1) it makes us hard to cut releaes each 3 weeks 14:27:27 2) we don't want to break gates with new versions of libs, without our control 14:28:04 sdague's comment from #openstack-dev channel: 14:28:07 > using fixed versions in requirements.txt basically makes it unpackagable by distros 14:28:19 > which... is fine I guess, but the team should realize that's what they are doing 14:28:41 @andreykurilin hm good point 14:29:21 @andreykurilin maybe we should think a bit more about this lol 14:29:29 let me try to ping dims and sdague again :) 14:31:36 andreykurilin: I will discuss today this with dims 14:31:50 boris-42: maybe we should not use fixed version, but use max and min versions instead? 14:32:06 or use constraints? 14:32:14 constraints exists to solve this problem 14:33:08 clarkb: constraints just check one version from many of possible matchers 14:33:34 so it can not guarantee that project requirements is not broken 14:34:09 correct it is there yo expose a complete known good 14:34:32 but there may be other valid dep lists as well 14:34:50 constraints allows distros to have flexibility while restricting testing to a known set 14:35:50 clarkb: it sounds like we have fixed version of requirements but you can try to use another version for your own risk :) 14:35:54 clarkb: so the thing is that we need at least to have upperconstraints 14:35:57 clarkb: for all libs 14:36:10 clarkb: at release tie 14:36:14 time* 14:36:30 clarkb: and exclude versions that we know that are broken 14:39:21 clarkb: also, current openstack requirements process doesn't allow to do something like https://review.openstack.org/#/c/252407/1/requirements.txt before release 14:41:04 andreykurilin: I never said use openstack requirements 14:41:07 :) 14:41:09 just use pip constraints 14:41:15 completely different concerns 14:41:24 clarkb: ya constraints makes sense 14:41:36 clarkb: fixed versions bad idea 14:41:44 clarkb: thanks for suggestion 14:42:38 clarkb: today I learned something new. thanks:) 14:42:46 will read about pip constrains 14:44:12 @amaretskiy back to open discussion? 14:44:52 yes 14:45:00 #topic Free discussion 14:45:02 I have one topic:) 14:45:07 *topic :) 14:45:32 I want to extend current schema of ExistingEngine 14:45:45 we have `endpoint_type` var there 14:46:04 and I want to propose one more variable - `keystone_endpoint_type` 14:46:10 andreykurilin: btw what about Nata from mailing list? 14:46:16 Nata? 14:46:18 andreykurilin: seems like he has some deep issues 14:46:26 Nate* 14:46:39 one moment 14:46:50 boris-42: I'm currently writing an answer to Nata, however there are no concrete solution from me 14:46:54 *Nate 14:47:06 yeah, it a bit related 14:47:12 so we have several problems 14:47:19 let me describe them 14:48:05 1) we do not transmit endpoint_type to keystone at all. maybe keystoneclient changed name of variable or we used wrong argument name from the start of rally:) 14:48:38 also keystoneclient ignores unknown arguments, so we did not received any AttributeError 14:49:32 2) default endpoint_type for keystone is admin, for other services is public 14:49:56 so when I tried to transmit endpoint type in correct way to keystoneclient, it failed 14:49:59 oh 14:50:01 omg 14:50:06 yeah 14:50:52 for most clouds `endpoint_type=public` will break kc, `endpoint_type=admin` or `endpoint_type=None` will break other services 14:51:15 that is why I propose to add one more variable to deployment config:) 14:51:26 maybe it should be auth_endpoint_type 14:51:30 or something like that 14:52:17 proofs you can find at https://review.openstack.org/#/c/320056/ 14:52:24 sounds good 14:52:29 just look at different patch-sets 14:52:36 @andreykurilin can you write email to mailing list 14:52:52 no:) I'm afraid 14:52:53 lol 14:53:43 What kind of mail you want? The answer to Nate or question about default endpoint_type for every service? 14:54:00 boris-42: ^ 14:54:23 answer to Nate 14:54:26 that we are working=) 14:54:52 ok ok 14:55:47 boris-42: btw, maybe the correct solution will be move all clients to use keystoneclient session object. it should handle endpoint_type=None and work for all services. 14:56:14 in such way openstackclient works 14:56:46 andreykurilin: so maybe 14:56:54 andreykurilin: and unify how all clients works 14:56:56 but it requires some volunteer, since I have not enough time:( 14:57:07 rvasilets__: ^ 14:57:17 rvasilets__: maybe you can be volunteer? 14:57:33 rvasilets__: he is on pto :) 14:57:43 boris-42: rvasilets is on pto 14:57:45 vacation:) 14:58:12 andreykurilin: he didn't say anything so he is agree LOL +) 14:58:19 lol 14:58:40 that's how democracy works lol 14:58:53 perfect 14:58:58 + 14:59:07 =) 15:00:06 boris-42: I'll try to find someone in our regular irc channel before rvasilets return 15:00:14 ok, it looks like we do not have time 15:00:21 amaretskiy: let's end the meeting 15:00:29 #endmeeting