14:04:59 <boris-42> #startmeeting Rally
14:05:00 <openstack> Meeting started Mon Jun  6 14:04:59 2016 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:03 <openstack> The meeting name has been set to 'rally'
14:05:16 <boris-42> ping rvasilets_ amaretskiy andreykurilin__ r
14:05:21 <boris-42> ping ikhudoshyn
14:05:29 <ikhudoshyn> o/
14:05:41 <amaretskiy> hi
14:05:46 <boris-42> what's up guys?
14:05:47 <rvasilets_> pong
14:06:14 <ikhudoshyn> still fighting with gates ((
14:06:27 <boris-42> ikhudoshyn: what happend with gates?
14:06:46 <ikhudoshyn> 'existing users'
14:06:57 <boris-42> ikhudoshyn: ah
14:07:25 <ikhudoshyn> everything seemed ok the day before yesterday yet I somehow unavailable to update quotas
14:08:00 <rvasilets_> Doing some minor refactoring/bu fixing of Rally. Preparing to write the code of validation refactoring
14:08:24 <boris-42> rvasilets_: we will need to fix a bit spec
14:08:49 <boris-42> rvasilets_: ikhudoshyn amaretskiy btw I think that we should try to have less code and more exploration in specs
14:09:45 <ikhudoshyn> oh I good at it already )) not a single line of code from my side for a week (( (excapt gate script)
14:09:59 <boris-42> lol
14:10:14 <ikhudoshyn> (i sucks actually)
14:10:22 <ikhudoshyn> s/i/it/
14:10:27 <ikhudoshyn> i'm good
14:10:29 <rvasilets_> boris-42, Ok. I just have one more question to you about realization
14:11:06 <boris-42> ikhudoshyn: lol
14:11:17 <boris-42> rvasilets_: so ask it lol
14:12:55 <rvasilets_> boris-42, Will we need to hide unexpected exceptions inside validators? Or we write theirs trace into db and reraise an exception?
14:13:24 <boris-42> rvasilets_: so from my perspective it would be nice to do the next
14:13:26 <rvasilets_> *"we want to write"
14:13:32 <boris-42> rvasilets_: do the next
14:13:54 <boris-42> 1) keep results of all validators like a (boolean, message)
14:14:28 <boris-42> 2) if some of validators rises exceptions return (False, TraceInStr)
14:14:43 <boris-42> 3) in case of exceptions if debug mode is on log errors
14:15:04 <andreykurilin1> o/
14:17:04 <rvasilets_> Ok, I get. But is it better to show for end user unexpected errors as it is now in our validators? This is explicit
14:17:40 <amaretskiy> boris-42: just to remind one proposal  - how about to expect that validators never return values, only raise exception ValidationError if something is wrong? This is how Django validators work
14:17:59 <amaretskiy> currently we expect that validator return ValidationResult
14:18:17 <boris-42> amaretskiy: I remember that we have already this disucssion
14:18:21 <amaretskiy> yes
14:18:41 <amaretskiy> but I do not remember the result of discussion
14:18:53 <amaretskiy> only fact that we discussed this
14:19:23 <rvasilets_> =)
14:19:39 <boris-42> amaretskiy: so I don't remember the reasons why it is better to raise expections
14:19:51 <amaretskiy> the code is simpler
14:20:14 <amaretskiy> actually validators should never change anything
14:20:15 <boris-42> amaretskiy: and how can you return message that describes why validator was successfull ?
14:20:38 <rvasilets_> "My will!" - http://www.zuguide.com/images/14530/14530.0.570.359.jpg
14:20:41 <amaretskiy> raise ValidationError(message)
14:20:41 <rvasilets_> )
14:20:54 <boris-42> amaretskiy: in case of success*
14:20:59 <boris-42> amaretskiy: not in case of failures
14:21:09 <amaretskiy> validator just makes desicion taht something is valid or not
14:21:28 <amaretskiy> is valid - then it keep silence
14:21:34 <rvasilets_> By default they could be valid)
14:21:41 <amaretskiy> if error - raise exception
14:21:51 <boris-42> amaretskiy: I would prefer to provide info about why it made such decisisons
14:22:01 <boris-42> amaretskiy: that it is right
14:22:18 <amaretskiy> ok
14:22:32 <boris-42> amaretskiy: that will simplify really debuggability
14:23:06 <rvasilets_> Okey master)
14:24:10 <rvasilets_> Why we ned msg that validator was successfulд?
14:24:33 <boris-42> rvasilets_: amaretskiy one sample
14:24:45 <boris-42> rvasilets_: amaretskiy you are specifying image by reg exp
14:25:32 <boris-42> rvasilets_: it will show you message (image_validatior, "True", "Image with UUID and name matches pattern XXX")
14:25:35 <boris-42> amaretskiy: ^
14:26:21 <amaretskiy> we can use logging in validators
14:26:30 <rvasilets_> We could write such msges at the last line of validator
14:27:00 <rvasilets_> but we will not controll then writting of validator...
14:27:13 <boris-42> amaretskiy: this will be already more complicated
14:27:24 <boris-42> amaretskiy: because it is logging + rising exceptions
14:27:43 <boris-42> amaretskiy: plus logs won't be stored in DB and you won't be able to retrive results of validation of specific task
14:28:42 <rvasilets_> boris-42, Looks like I get you point. We want to have msg in ANY case
14:28:49 <amaretskiy> I would not insist on exceptions-based validators, let it be so
14:29:03 <rvasilets_> even if user wrote very bad validator
14:30:29 <rvasilets_> "plus logs won't be stored in DB and you won't be able to retrive results of validation of specific task" - This can be hacked by catching erroe inside engine, write to db information and reraise)
14:31:09 <boris-42> rvasilets_: so rising excetpions in case of success is very bad idea
14:33:30 <rvasilets_> Okey, I will wrote the code by your wish) In both cases from perspective of code not to much to change)
14:33:51 <rvasilets_> boris-42, ^
14:34:14 <boris-42> rvasilets_: thanks
14:34:32 <boris-42> amaretskiy: andreykurilin1 rvasilets_ ikhudoshyn do we have something to disucss?
14:34:43 <ikhudoshyn> https://review.openstack.org/#/c/167060/
14:34:45 <andreykurilin1> nothing from my side:)
14:35:04 <ikhudoshyn> we got two +2's yet we're waiting for u
14:35:15 <amaretskiy> no ideas
14:35:42 <boris-42> ikhudoshyn: ok
14:35:45 <rvasilets_> Nothing from me
14:35:45 <boris-42> ikhudoshyn: I will reivew it
14:35:50 <ikhudoshyn> tnx
14:35:56 <rvasilets_> ou
14:35:58 <ikhudoshyn> that's all from my side
14:36:00 <rvasilets_> I have
14:36:30 <rvasilets_> In spec by Rally db there are described not all changes
14:36:40 <rvasilets_> is it normal?
14:37:13 <rvasilets_> Previously we dissussed that there is only task related part
14:37:20 <amaretskiy> I guess rvasilets_ is talking about changes in Deployment (like cloud_info)
14:37:29 <rvasilets_> yes
14:37:51 <rvasilets_> Do we want to store Cloud info?
14:38:02 <rvasilets_> boris-42, ^
14:38:58 <rvasilets_> And minor question: Will we need to describe Deployment table changes at those spec?
14:38:59 <boris-42> rvasilets_: heh we need to do that but in smart way
14:39:04 <amaretskiy> good question, because it is relatively easy to add this information to reports, and it will be nice to have it there
14:39:32 <rvasilets_> boris-42, Do you know the smart way or we need to think?
14:39:33 <boris-42> amaretskiy: rvasilets_ so we need to think where to collect this data
14:39:55 <boris-42> amaretskiy: rvasilets_ basically we need to move this to the deployment plugins related to openstack
14:40:11 <amaretskiy> keep in mind that this is an openstack-related info, it must be universal
14:40:29 <boris-42> amaretskiy: nope it must not be
14:40:34 <boris-42> amaretskiy: =)
14:40:38 <amaretskiy> :)
14:41:00 <boris-42> amaretskiy: if we collect this data in plugins of deployment
14:41:13 <boris-42> amaretskiy: as a JSON
14:41:24 <boris-42> amaretskiy: then we can collect anything
14:41:29 <rvasilets_> How to collect? - What is the problem to make some linux api calls? In case of not distributed rally?\
14:41:44 <amaretskiy> yes, arbitrary key-value data in JSON format
14:42:48 <rvasilets_> Okey. What cloud info we want to store? - CPUs, RAM?
14:42:59 <boris-42> amaretskiy: yep
14:43:05 <boris-42> rvasilets_: everything that can be collected
14:43:20 <amaretskiy> nodes, services available
14:44:04 <amaretskiy> field name should not contain "cloud"
14:44:30 <amaretskiy> so this will not point to openstack
14:45:14 <boris-42> amaretskiy: rvasilets_ yep it should be like info
14:45:21 <boris-42> amaretskiy: rvasilets_ and can point anything
14:45:29 <amaretskiy> +
14:45:54 <rvasilets_> Lets create separate plugin. Cloud_info etc
14:46:18 <amaretskiy> Simply "Info" :)
14:46:19 <rvasilets_> And will allow users to write there own plugins to collect the data
14:46:21 <rvasilets_> )
14:46:29 <boris-42> rvasilets_: nope plugin is bad idea imho
14:46:34 <rvasilets_> This was my first idea)
14:46:41 <boris-42> rvasilets_: I would preer rather to extend existings
14:46:46 <boris-42> rvasilets_: deployment plugins
14:46:59 <rvasilets_> Okey
14:47:12 <rvasilets_> Maybe reasonable
14:47:14 <amaretskiy> I guess this information should be populated while making "deployment create"
14:47:25 <boris-42> amaretskiy: yep
14:48:15 <rvasilets_> We could extend it then to collect how cloud resources changed during task execution)
14:48:27 <rvasilets_> or bad швуф
14:48:32 <rvasilets_> *idea
14:48:39 <rvasilets_> ?
14:49:12 <boris-42> rvasilets_: I don't think so=)
14:49:18 <rvasilets_> ((
14:49:21 <amaretskiy> I think we should bind this data collection to Task start
14:49:24 <boris-42> rvasilets_: it's called monitoring and should be done in other place
14:49:33 <amaretskiy> because remote system can be changed
14:49:34 <rvasilets_> agree(
14:49:54 <amaretskiy> and show this info per-task in report
14:50:08 <boris-42> amaretskiy: rvasilets_ I think this is spearated discussion
14:50:17 <boris-42> amaretskiy: rvasilets_ we should do the spec about it
14:50:26 <rvasilets_> Okey. The question was do we need to describe this in spec and the answer we need)
14:50:31 <rvasilets_> yes)
14:50:40 <rvasilets_> Then I have -1 to spec)
14:50:43 <amaretskiy> this is important whether to add this field to Task or to Deployment in the Spec
14:51:30 <amaretskiy> Spec is about Task-related schema
14:51:37 <boris-42> amaretskiy: yep
14:51:51 <boris-42> amaretskiy: rvasilets_ so for now it should be described in the spec from Ilya
14:51:57 <boris-42> amaretskiy: rvasilets_ because it's different topic
14:52:12 <amaretskiy> ok
14:52:26 <rvasilets_> should be ->  shouldn't be?
14:52:44 <rvasilets_> Okey
14:53:00 <rvasilets_> We need separeted spec as I understand
14:53:14 <rvasilets_> *separate
14:54:11 <rvasilets_> Who will make it?)
14:54:22 <amaretskiy> any decision will not make problems in implementaton, so we can make separate spec for this topic
14:54:30 <rvasilets_> Or we will decide later?
14:55:14 <boris-42> rvasilets_: I can start it
14:55:30 <boris-42> rvasilets_: there is another question as well to let users provide info about task & deploymnt amaretskiy
14:55:47 <boris-42> okay seems like we can end todays meeting
14:55:51 <boris-42> #endmeeting