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