Perl 6 - the future is here, just unevenly distributed

IRC log for #openstack-rally, 2015-04-27

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:29 dmorita joined #openstack-rally
00:45 jjmb1 joined #openstack-rally
00:56 jaypipes joined #openstack-rally
01:47 ilbot3 joined #openstack-rally
01:47 Topic for #openstack-rally is now ☁ Rally RoadMap: http://goo.gl/JZkmwY ☁ Rally IRC chat logs http://irclog.perlgeek.de/openstack-rally ☁ Key persons to ask:  boris-42, yfried, msdubov, rediskin, andreykurilin, amaretskiy  Ã¢ËœÂ Documentation: https://rally.readthedocs.org/en/latest/ ☁ To publish changes to Rally:  https://rally.readthedocs.org/en/latest/contribute.html
02:37 baker joined #openstack-rally
03:27 baker joined #openstack-rally
03:34 rdas joined #openstack-rally
03:46 baker joined #openstack-rally
03:51 echoingumesh joined #openstack-rally
04:09 exploreshaifali joined #openstack-rally
04:24 davideagnello joined #openstack-rally
04:34 tfreger joined #openstack-rally
05:19 pradeep joined #openstack-rally
05:30 subscope_ joined #openstack-rally
05:41 rdas_ joined #openstack-rally
05:48 rdas_ joined #openstack-rally
05:51 meteorfox joined #openstack-rally
06:02 tfreger joined #openstack-rally
06:03 kiran-r joined #openstack-rally
06:08 tfreger joined #openstack-rally
06:24 e0ne joined #openstack-rally
06:32 neeti joined #openstack-rally
06:36 yfried__ joined #openstack-rally
06:50 nkhare joined #openstack-rally
06:59 anshul joined #openstack-rally
07:12 gema joined #openstack-rally
07:13 gema joined #openstack-rally
07:22 pbandzi joined #openstack-rally
07:25 pbandzi joined #openstack-rally
07:53 arxcruz joined #openstack-rally
07:57 yfried__ meteorfox: ping
07:59 vaidy joined #openstack-rally
08:03 amaretskiy joined #openstack-rally
08:04 fhubik joined #openstack-rally
08:07 exploreshaifali joined #openstack-rally
08:13 karimb joined #openstack-rally
08:16 openstackgerrit joined #openstack-rally
08:48 tosky joined #openstack-rally
08:58 aix joined #openstack-rally
08:59 e0ne joined #openstack-rally
09:00 yingjun joined #openstack-rally
09:04 openstackgerrit Nikita Konovalov proposed openstack/rally: [Sahara] Split EDP context  https://review.openstack.org/177682
09:05 openstackgerrit svasheka proposed openstack/rally: Add keystone benchmark scenarios for roles  https://review.openstack.org/165409
09:07 openstackgerrit Li Yingjun proposed openstack/rally: Set default value for updated_at for task  https://review.openstack.org/176583
09:13 e0ne joined #openstack-rally
09:25 openstackgerrit Andrey Kurilin proposed openstack/rally: Adding FunctionalMixin class  https://review.openstack.org/146838
09:33 openstackgerrit Merged openstack/rally: Fix instance_dd_tests.sh always reading 1MiB  https://review.openstack.org/177447
10:07 openstackgerrit Nikita Konovalov proposed openstack/rally: [Sahara] Split EDP context  https://review.openstack.org/177682
10:15 openstackgerrit Nikita Konovalov proposed openstack/rally: [Sahara] Improve Image context  https://review.openstack.org/166859
10:16 tfreger joined #openstack-rally
10:16 openstackgerrit Nikita Konovalov proposed openstack/rally: [Sahara] Improve Image context  https://review.openstack.org/166859
10:16 openstackgerrit Nikita Konovalov proposed openstack/rally: [Sahara] Split EDP context  https://review.openstack.org/177682
10:24 openstackgerrit Alexander Gubanov proposed openstack/rally: Adds Nova floating IPs bulk tests  https://review.openstack.org/168054
10:32 openstackgerrit Vitaly Gusev proposed openstack/rally: [Ceilometer] Add scenarios for resources and samples  https://review.openstack.org/165092
10:32 karimb joined #openstack-rally
10:37 karimb joined #openstack-rally
10:39 yfried__ amaretskiy: do you have a few min? re https://review.openstack.org/#/c/172831/5/doc/specs/in-progress/os_services.rst,cm
10:40 amaretskiy yfried__ hi
10:40 amaretskiy yes
10:40 yfried__ did you see my comment?
10:45 yfried__ amaretskiy: ^?
10:45 amaretskiy yes
10:46 amaretskiy I've posted my comment about atomic actions
10:46 amaretskiy right now
10:46 amaretskiy we can discuss some points here
10:47 yfried__ amaretskiy: so yeah, I think we are on the same page re atomic actions
10:48 yfried__ amaretskiy: it's simpler when they are part of utils, but sometimes you want more control on the atomic actions (enable/disable them) or on parts of it, without duplicating code
10:48 yfried__ amaretskiy: on the other hand, we might want to use atomic actions in contexts
10:48 amaretskiy control over atomic actions must beflexible (no hardcoded names at all, on/off)
10:49 yfried__ amaretskiy: yeah. but should it be part of this spec?
10:50 yfried__ amaretskiy: seems like it's a different issue that needs better planning
10:50 amaretskiy I think that this spec should say where atomic actions should be
10:50 amaretskiy if in scenarios, that nothing else should be added to spec
10:50 amaretskiy if somewhere elese - then we must describe how flexibility is reached
10:51 amaretskiy currently atomic actions is important part of utils so we have to make a decision
10:51 yfried__ then  you want to remove all references to atomic action from utils modules (that will be changed to services)?
10:51 amaretskiy yes, this is my opinion
10:52 amaretskiy in other case, we can continue of using utils - just move the main code to services but keep atomic actions
10:52 amaretskiy my opinion is that atomic actions should NOT be in sevices
10:53 yfried__ amaretskiy: I'm not sure about that. but this could be discussed later.
10:53 softCloud joined #openstack-rally
10:54 amaretskiy okay, if you think that we can put atomic actions into services, then some code examples are required - how this can work
10:54 yfried__ amaretskiy: assuming we agree on the 1st option - the spec should say that part of refactoring would be removing all atomic actions from utils
10:54 amaretskiy I'm not sure about that
10:56 amaretskiy the main problem with utils is that they are bound to scenario, so it is strange to call them in context/cleanup/etc
10:56 amaretskiy related problem is if we call utils from non-scenario, then we also run hardcoded atomic actions
10:56 yfried__ amaretskiy: the spec is about changing "utils" to services and unbounding them from scenarios
10:57 amaretskiy yes
10:57 yfried__ amaretskiy: that's why I'm saying we need to remove atomic actions from utils
10:57 amaretskiy okay
10:57 amaretskiy remove them from utils
10:57 amaretskiy and place where?
10:57 yfried__ amaretskiy: scenarios - as you suggested
10:58 amaretskiy I agree with you :)
10:58 amaretskiy I believe others will agree too
10:58 yfried__ amaretskiy: would you like to write a different spec about enhancing atomic actions?
10:59 yfried__ meteorfox: here?
10:59 amaretskiy I would like to do that, but this will not be soon (have a lot of work)
10:59 yfried__ amaretskiy: :)
11:06 yfried joined #openstack-rally
11:09 karimb joined #openstack-rally
11:23 cdent joined #openstack-rally
11:31 openstackgerrit Alexander Gubanov proposed openstack/rally: Adds Nova floating IPs bulk tests  https://review.openstack.org/168054
11:42 openstackgerrit Oleh Anufriiev proposed openstack/rally: Removed task validation from api.Task.start  https://review.openstack.org/158899
11:44 pboldin joined #openstack-rally
11:45 pboldin yfried: hi. Can you please solve our dilemma https://review.openstack.org/#/c/174454/ ?
11:45 pboldin yfried: while it is obviously that unit-test is for units I'm not sure of what should I think of as a unit here
11:47 yfried pboldin: I'm out of loop with this patch. what is the question?
11:47 pboldin yfried: there is a small class CatcherHandler with a simply set of methods. should I cover these with unit-tests?
11:49 pboldin yfried: I would rather keep the tests as they are, because I think of a catcher as a single unit that is simply enough to be tested as a whole
11:52 yfried pboldin: I wanted to talk to you about this patch anyway
11:52 pboldin yfried: oh, great
11:52 yfried pboldin: but re tests
11:52 panbalag joined #openstack-rally
11:52 panbalag andreykurilin, Hi
11:53 yfried pboldin: I don't really like the unittests we do with mocks, but it's part of the project policy to have everything covered by it, so I guess you have to comply
11:53 pboldin yfried: then i would have to rewrite latter tests to use mocks
11:54 yfried pboldin: why?
11:54 pboldin yfried: because it would be no longer a 'unit'
11:54 yfried pboldin: could you hold? I have to relocate my laptop so I'm gonna drop out of the channel
11:54 pboldin yfried: ok
11:54 panbalag andreykurilin, amaretskiy, I had replied to the comments in the spec https://review.openstack.org/#/c/166487. Let me know if I you have any other questions.
11:57 msdubov_ joined #openstack-rally
11:58 amaretskiy panbalag okay
11:58 pboldin yfried: i think the simplest solution here is to move the CatcherHandler inside the LogCatcher but I'm unsure of py3 compatibility here
11:59 yfried pboldin: I'm back
11:59 pboldin yfried: have you got the previous message?
11:59 pboldin yfried:  i think the simplest solution here is to move the CatcherHandler inside the LogCatcher but I'm unsure of py3 compatibility here
11:59 e0ne joined #openstack-rally
12:01 pboldin yfried: so?
12:02 * yfried looking at pboldin's patch
12:03 yfried_ joined #openstack-rally
12:04 andreykurilin panbalag: oh...I forgot to answer you:( sorry
12:04 andreykurilin panbalag: I'll write a comment now
12:04 openstackgerrit Evgeny Sikachev proposed openstack/rally: [Sahara] Split Data Sources context  https://review.openstack.org/177732
12:05 yfried_ pboldin: assuming LogCatcher is already covered by LogCatcherTestCase I don't understand why CatcherHandlerTestCase would cause LogCatcherTestCase to change
12:05 pboldin yfried_: because splitting a CatcherHandlerTestCase would make a CatcherHandler a unit.
12:05 andreykurilin panbalog: btw, the most of statements from spec look good to me and for other cores, so you can start the implementation
12:05 yfried_ pboldin: but seems like your tests aren't unittests, but rather functional tests. shouldn't they go in functional tests tree?
12:05 panbalag andreykurilin, Thanks
12:06 pboldin yfried_ and this will make LogCatcherTestCase not a unit-test.
12:06 openstackgerrit joined #openstack-rally
12:06 pboldin1 joined #openstack-rally
12:07 pboldin1 yfried_: yes, they are not unit tests.
12:07 yfried_ pboldin1: so maybe move them to functional tests tree?
12:07 pboldin1 yfried_: well, i think that the code here is simply enough to be a 'unit' as a whole.
12:08 openstackgerrit Evgeny Sikachev proposed openstack/rally: [Sahara] Split Data Sources context  https://review.openstack.org/177732
12:08 kiran-r yfried_: could you please share the procedure to commit to rally? :)
12:08 yfried_ kiran-r: procedure?
12:08 pboldin1 kiran-r: of what?
12:08 kiran-r git commit.
12:08 kiran-r yfried_: git commit.
12:08 yfried_ kiran-r: git commit && git review
12:09 yfried_ pboldin1: my suggestion is to leave your test as is. it's a good test
12:10 pboldin1 yfried_: but to move it to functional tests?
12:10 yfried_ pboldin1: if you want. you don't have to
12:10 pboldin1 yfried_: so, could you please comment on this?
12:10 pboldin1 yfried_: i think we need to improve functional testing.
12:10 pboldin1 yfried_: the infrastructure there is not ready to accept these, there is only cli tests so far
12:11 yfried_ pboldin1: but if amaretskiy thinks you need unittests that test the different methods, then you should create simple and stupid tests that use mocks. that's the policy of Rally.
12:12 pboldin1 yfried_: so, you are unable to really decide and referencing the rally policies. I will have to wait for boris-42 then :-/
12:12 yfried_ pboldin1: you're gonna need Boris to give final judgement on such an issue and he's on vacation this week
12:12 yfried_ pboldin1: it's not that I'm unable to decide. the policies are there, and we have to follow them even if we don't agree
12:13 yfried_ pboldin1: sorry.
12:13 pboldin1 yfried_: you are unable to change the policies, i mean only that. ok, we will wait for boris
12:13 yfried_ pboldin1: I just think that writing the mocks would be quicker than waitingfor boris to come back, assuming he would agree with you
12:14 pboldin1 yfried_: well, my patches typically hang on reviews for some months and i can wait
12:14 pboldin1 yfried_: but lets talk about the patchset chain as a whole
12:14 yfried_ pboldin1: seems like this one should be ready to merge.
12:15 yfried_ pboldin1: I was gonna ask you about it. I'll try to ping you in 30min since I have a mtg
12:15 pboldin1 yfried_: okay
12:16 yfried_ pboldin1: could you please point to a patch in the chain that's using it?
12:16 pboldin1 yfried_: https://review.openstack.org/#/c/177011/3/tests/unit/benchmark/scenarios/vm/test_utils.py,cm
12:17 yfried_ pboldin1: that's a unittest, not an actual scenario
12:17 pboldin1 yfried_: of course, this is a unit-test thing
12:17 yfried_ pboldin1: oh...
12:18 yfried_ pboldin1: so maybe it's a functional tests thing?
12:18 yfried_ pboldin1: it's supposed to test rally logs, right? not openstack logs
12:18 pboldin1 yfried_: to test logs. any type of.
12:19 yfried_ pboldin1: it can't intercept openstack logs if they aren't on the same node as rally, can it?
12:19 pboldin1 yfried_: it can intercept openstack logs only issued by clients used in rally
12:22 pboldin1 yfried_: so i think i will have to move all the existing functional tests to the `cli' directory
12:22 pboldin1 *subdir
12:22 pboldin1 yfried_: and then add a directory `log' adding my test in here
12:23 yfried_ pboldin1: agree
12:23 yfried_ d
12:23 yfried_ pboldin1: however, arxcruz is working on fucntional testing so maybe sync with him to make sure you aren't duplicating effort?
12:23 pboldin1 yfried_: well, that is why i prefer to leave the patch as is and only note it with TODO
12:24 yfried_ pboldin1: I have a more fundemental issue with your work here:
12:24 pboldin1 yfried_: i'm all ears
12:25 yfried_ pboldin1: I have no idea where it's going. I see 10 related patches and I'm gonna have to dive into them without knowing why logcatcher was created until I get to the 5th patch
12:26 yfried_ pboldin1: this seems like a blueprint with a short discription of the main goal would help to tie all of these togather
12:26 pboldin1 yfried_: https://docs.google.com/document/u/1/d/1FQicnj6aIdbfYts9ofYdz0dUEf9zyssWqDjQR40h268/edit?pli=1
12:26 pboldin1 yfried_: agreed
12:28 yfried_ pboldin1: ok so could you please create a lauchpad pb that only has 3 lines of discription and a link to this doc?
12:28 pboldin1 yfried_: i want to use this instead https://blueprints.launchpad.net/rally/+spec/benchmark-vms
12:29 yfried_ pboldin1: that way, you could have all your patches point to it, and gerrit will group them into a single branch
12:30 yfried_ pboldin1: is it related? haven't read it yet, but it seems like it's already tracking lot's of patches. we not just create a new one? only for tracking
12:30 pboldin1 yfried_: ok
12:31 yfried_ pboldin1: tnx. it would make it easier to review these patches it context. wouldn't you agree?
12:31 pboldin1 yfried_: well, mostly people are in context. but you a right
12:35 yfried_ pboldin1: also if you push this https://review.openstack.org/#/c/177009/2 without dependency on logcatcher you should be able to merge it today
12:36 pboldin1 yfried_: i'm not in hurry
12:37 yfried_ pboldin1: me neither but I would like to merge simple stuff ASAP to clear the review queue
12:37 openstackgerrit joined #openstack-rally
12:37 pboldin1 yfried_: okay, as you wish
12:40 baker joined #openstack-rally
12:47 openstackgerrit Roman Vasilets proposed openstack/rally: Add Http Request Scenario  https://review.openstack.org/117705
12:48 dpaterson joined #openstack-rally
13:08 pbandzi joined #openstack-rally
13:12 yfried_ pboldin1: looking at http://logs.openstack.org/54/174454/6/check/rally-coverage/344b847/cover/rally_common_log.html
13:13 pboldin1 yfried_: i'm writing unittests already
13:13 pboldin1 yfried_: and have filed a bug
13:13 yfried_ pboldin1: seems like shouldFlush is the only thing not covered
13:13 pboldin1 yfried_: there is a remedy against methodology fanatics
13:13 pboldin1 yfried_: https://bugs.launchpad.net/rally/+bug/1449009
13:14 openstack Launchpad bug 1449009 in Rally "[unittest] unable to assert on deprecation warnings" [Undecided,In progress] - Assigned to Pavel Boldin (pboldin)
13:14 pboldin1 yfried_: nevermind
13:14 pboldin1 yfried_: of course, because it is tested by the 'functional test' below
13:15 yfried_ pboldin1: not according to the code-coverage tool
13:15 pboldin1 yfried_: yeah, I don't know why 'shouldFlush' is not getting covered
13:15 yfried_ pboldin1: my point is
13:16 yfried_ pboldin1: I was gonna say, if we achieve 100% coverage on this, I don't care about the rules
13:16 pboldin1 yfried_: nope. rules are rules
13:16 pboldin1 yfried_: i'm going to follow the sh*t out of them
13:16 yfried_ pboldin1: but since we don't, and this is one of the methods in question, I can't +2 this
13:16 pboldin1 yfried_: i have rewrited this
13:17 pboldin1 yfried_: well, i believe that 'return False' method is incredible hard to understand
13:17 pboldin1 yfried_: so it just must be covered
13:19 yfried_ pboldin1: don't be like that :)
13:19 pboldin1 yfried_: it's not my, it's the rules
13:20 pboldin1 yfried_: i'm just complying with them being brain-removed instruction executor
13:22 openstackgerrit joined #openstack-rally
13:30 pboldin1 yfried_: well, i have updated that https://review.openstack.org/#/c/174454/
13:30 pboldin1 yfried_: the only thing that is remaining (and it should be fixed imo) is that I don't mock the "in" operator.
13:30 pboldin1 yfried_: and don't test for it
13:32 ilyashakhat hi ralliers!, do you have any plans to make plugins folder location configurable?
13:35 yfried_ pboldin1: why workflow -1?
13:35 pboldin1 yfried_: missing the 'in' mock testing
13:36 pboldin1 yfried_: is relying on the str.__contains__ good enough or should I remove that code?
13:37 pboldin1 yfried_: and i should have removed the non-unit test leaving the code essentially untested but in full compliance with 'rally policies'
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Add command-dict option to specify command args  https://review.openstack.org/177016
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Split validation.file_exists, allow `required' arg  https://review.openstack.org/177010
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Introduce command-specifying dictionary  https://review.openstack.org/177011
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Add `LogCatcher' context manager  https://review.openstack.org/174454
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Introduce `valid_command' validator  https://review.openstack.org/177012
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Extend `sshutils` with `put_file'  https://review.openstack.org/177013
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Make `boot_runcommand_delete' accept command-dict  https://review.openstack.org/177014
13:37 openstackgerrit Pavel Boldin proposed openstack/rally: Add command-dict option to upload a local command  https://review.openstack.org/177015
13:40 yfried_ pboldin1: you really didn't need the LogCatcherUnitTestCase if it's covered by LogCatcherTestCase IMO
13:40 pboldin1 yfried_: the policies are the policies. I don't need LogCatcherTestCase because it is not unit-test and does not belongs here.
13:41 pboldin1 yfried_: i just want to show you that policies are not covering 100% of possible future things.
13:41 pboldin1 yfried_: and always forcing them makes code worse sometimes.
13:44 psd joined #openstack-rally
13:45 exploreshaifali joined #openstack-rally
13:49 flamebot joined #openstack-rally
13:50 BaQs joined #openstack-rally
13:51 yfried_ andreykurilin: https://review.openstack.org/#/c/177009/3 is ready to merge pending jenkins. could you please take a look? it passed previous verification and was just rebased
13:51 yfried_ msdubov_: ^
13:54 yfried_ meteorfox: around?
13:56 andreykurilin yfried_: ok, will check it now
13:56 yfried_ pboldin1: re https://review.openstack.org/#/c/177013/6 haven't read it yet, but should it be so far up that branch?
13:57 pboldin1 yfried_: it is logical to add this just before usage
13:57 mwagner_lap joined #openstack-rally
13:57 pboldin1 yfried_: that's why 177009 was in the place it was
13:57 pboldin1 yfried_: but the answer is 'no'. yet people will ask 'why do you add this?' if it is far away from the usage
13:58 mkoderer joined #openstack-rally
13:58 pboldin1 yfried_: if you review it i can move it to the bottom of the chain
13:58 yfried_ pboldin1: it's still part of that topic/bp so they won't have more reasons to do so than before, but we could merge it faster and save you the rebase hassle
13:59 pboldin1 yfried_: well, it is not related to the blueprint. i will file an arg
13:59 pboldin1 *a bug
13:59 yfried_ [16:58] <pboldin1> yfried_: if you review it i can move it to the bottom of the chain
13:59 yfried_ pboldin1: ^ say that backwards and you got yourself a deal :)
13:59 pboldin1 yfried_: ok
14:00 jjmb2 joined #openstack-rally
14:00 jjmb2 joined #openstack-rally
14:01 jjmb2 joined #openstack-rally
14:01 jjmb2 joined #openstack-rally
14:04 openstackgerrit Ilya Shakhat proposed openstack/rally: Make plugins location configurable  https://review.openstack.org/177773
14:08 yfried_ pboldin1: re https://review.openstack.org/#/c/177011/5
14:08 yfried_ pboldin1: "Both local and inline scripts require specifying interpreter. " why not remote path as well?
14:11 pboldin1 yfried_: remote path specifies a command, not a script. one should use shellbang to specify interpreter then
14:12 yfried_ pboldin1: yeah. understood it while reading the code. the doc is pretty good
14:12 pboldin1 yfried_: btw, that is the reason to use 'script_file' but 'local_path'. because we are opening file from a `script_file' but only using a path passing to the sftp
14:13 pboldin1 yfried_: so, these mean different things and thus have different names
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Add command-dict option to specify command args  https://review.openstack.org/177016
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Split validation.file_exists, allow `required' arg  https://review.openstack.org/177010
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Introduce command-specifying dictionary  https://review.openstack.org/177011
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Add `LogCatcher' context manager  https://review.openstack.org/174454
14:14 yfried_ pboldin1: yeah.
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Introduce `valid_command' validator  https://review.openstack.org/177012
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Extend `sshutils' with `put_file'  https://review.openstack.org/177013
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Make `boot_runcommand_delete' accept command-dict  https://review.openstack.org/177014
14:14 openstackgerrit Pavel Boldin proposed openstack/rally: Add command-dict option to upload a local command  https://review.openstack.org/177015
14:14 dmellado joined #openstack-rally
14:15 pboldin1 yfried_: considering this: _file_access_ok
14:16 pboldin1 yfried_: we are not checking that the file is accessible, we are checking that the file access is ok with *given mode*
14:16 yfried_ pboldin1: ok
14:17 pboldin1 yfried_: so it checks a little more than accessibility of the file and thus named file_access_ok (should be file_access_mode_ok probably)
14:17 yfried_ pboldin1: or _check_file_access
14:18 pboldin1 yfried_: i don't like to start names with _check or any other verb. but _check favors an exception being raised inside the function
14:18 pboldin1 yfried_: but there is no common naming scheme in python for this afaik
14:19 nkhare joined #openstack-rally
14:19 yfried_ pboldin1: I'm not gonna -1 because of this name
14:20 pboldin1 yfried_: well, i'm just trying to think of naming convention :)
14:23 pboldin joined #openstack-rally
14:25 pboldin1 joined #openstack-rally
14:25 pboldin1 joined #openstack-rally
14:27 pboldin1 yfried_: https://review.openstack.org/#/c/177013/7 << done
14:27 yfried_ pboldin1: tnx
14:27 * yfried_ reviewing
14:47 pradeep joined #openstack-rally
15:09 davideagnello joined #openstack-rally
15:12 openstackgerrit Carlos L. Torres proposed openstack/rally: [report] Improve reports data and units  https://review.openstack.org/161037
15:13 openstackgerrit Carlos L. Torres proposed openstack/rally: [report] Improve reports data and units  https://review.openstack.org/161037
15:15 meteorfox yfried_: I reverted the changes to mean() function. Please feel free to review ^^ whenever you have time. Thanks
15:17 yfried_ meteorfox: done. You better hope jenkins agrees with me :)
15:18 meteorfox yfried_: :) it should. thanks
15:34 Vishal__ joined #openstack-rally
15:35 Vishal__ amaretskiy: Hi
15:35 amaretskiy Vishal__ hi
15:36 Vishal__ amaretskiy: tried giving userdata in the nova boot and list scenario..but it is not working
15:37 amaretskiy Vishal__ paste this to paste.openstack.org
15:38 Vishal__ amaretskiy: http://paste.openstack.org/show/208493/
15:39 amaretskiy Vishal__ also need paste for errors output
15:40 Vishal__ amaretskiy: there is no error in rally logs but the desired output was not there...just want to verify is the way I am providing the userdata parameter is correct?
15:41 Vishal__ amaretskiy: same shell script is working fine when I am doing nova boot manually while providing user_data
15:49 amaretskiy Vishal__ I'm reading http://docs.openstack.org/developer/python-novaclient/ref/v2/servers.html
15:49 amaretskiy userdata – user data to pass to be exposed by the metadata server this can be a file type object as well or a string.
15:50 amaretskiy Vishal__ based on this doc I think that novaclient expects 1) file("path/to/file") or 2) string that represents file content, not its path
15:51 amaretskiy If I'm not mistaken, then there is only one choice for scenario arguments for now - using single-line script as userdata
15:53 Vishal__ amaretskiy: I had given path to file (as point 1) in the json file
15:53 amaretskiy Vishal__ my dues is that should be file content instead
15:54 amaretskiy since file("path") is not "path"
15:54 openstackgerrit Merged openstack/rally: Add create_and_upload_volume_to_image scenario to rally-neutron job  https://review.openstack.org/172425
16:01 amaretskiy Vishal__ sorry for a small mistake above
16:01 amaretskiy file object is actually result of open("path)
16:01 amaretskiy but the idea is same
16:02 Vishal__ amaretskiy: yes it reads the contents and than send it to nova
16:05 amaretskiy Vishal__ currently, for nova scenarios there is no possibility to specify userdata as file path
16:06 amaretskiy Vishal__ so I believe this should work as inline script
16:06 amaretskiy however there is similar implementation for vm scenarios: https://github.com/openstack/rally/blob/master/rally/benchmark/scenarios/vm/utils.py#L49-L51
16:07 Vishal__ amaretskiy: Yes but this one uses FIP to execute the script
16:08 dmellado joined #openstack-rally
16:08 amaretskiy Vishal__ I agree
16:08 Vishal__ amaretskiy: I specifically want to test metadata and snat functionality
16:08 Vishal__ amaretskiy: metadata through userdata and snat through the shell script
16:09 amaretskiy Vishal__ I think the only possible try is inline script, I hope this will work
16:09 openstackgerrit Merged openstack/rally: [Sahara] Fix the config descriptions  https://review.openstack.org/176321
16:09 amaretskiy Vishal__ yes, my mistake - metadata
16:10 Vishal__ amaretskiy: sorry not able to understand the inline concept properly...is it by specifying the contents of the script?
16:12 amaretskiy example:  "userdata": "echo \"hi there!\"; echo \"how are you?\""
16:13 amaretskiy maybe it is possible to put \n instead of ; as commands delimiter
16:13 amaretskiy the idea is put script in single line since JSON does not support multiline data
16:13 pradeep joined #openstack-rally
16:13 Vishal__ amaretskiy: Also why this path to file is not working...since novaClient is on the same machine as rally and it has the access to the path where the file is kept? Sorry if it is a dumb question
16:14 Vishal__ :)
16:15 amaretskiy path is not transformed into file object because path is actually a str value, and it is specified to nova client  as-is
16:15 kiran-r Hello, I am unable to perform ¨git review¨ Here is the error I face http://paste.openstack.org/show/208539/
16:15 kiran-r Please help me
16:15 amaretskiy rally does not transform userdata value into file object
16:17 pboldin1 https://review.openstack.org/#/c/177013/7 << review pls
16:17 amaretskiy kiran-r you should rebase your patches so there will be exactly one patch above master branch
16:18 Vishal__ amaretskiy: ok so after doing some code changes in rally I can make it work and pass the file object to the "servers.create" function of novaClient
16:20 amaretskiy Vishal__ yes, this is a reasonable idea, but you need a solution how to 100% differ string that represents path to file from small shell command
16:21 amaretskiy Vishal__ that was solved in vm scenarios by additional parameter `is_file'
16:21 Vishal__ amaretskiy: Thanks a lot...I feel in case of small shell command given in a single line we have to accomodate "#!/bin/sh"
16:22 Vishal__ amaretskiy: to tell cloud-init package to use bash for executing the line
16:22 pboldin1 amaretskiy: now, it was not
16:22 pboldin1 amaretskiy: *no
16:22 amaretskiy Vishal__, no, this will not work - script can be without she-bang, and it can include one command - path to some file
16:23 pboldin1 amaretskiy: check how it is implemented inb4 doing a statement.
16:24 pboldin1 amaretskiy: this is how the is_file implemented, actually
16:24 Vishal__ amaretskiy: ok will try
16:24 pboldin1 https://github.com/openstack/rally/blob/master/rally/benchmark/scenarios/vm/utils.py#L54-L63 <<
16:25 pboldin1 and this is wrong, because it hides away the command return
16:25 pboldin1 and still requires 'interpreter' to be specified
16:27 pboldin1 not to say this unnecessary spawns a process
16:28 pboldin1 Vishal__: "#!/bin/sh" is not using bash
16:39 openstackgerrit maplelabs proposed openstack/rally: LoadBalancer functionality with unit tests.  https://review.openstack.org/177865
17:05 davideagnello joined #openstack-rally
17:10 exploreshaifali joined #openstack-rally
17:12 openstackgerrit Alexander Maretskiy proposed openstack/rally: [Clients] Add function osclients.register  https://review.openstack.org/177884
17:14 anshul joined #openstack-rally
17:27 openstackgerrit Pradeep K Surisetty proposed openstack/rally: Add Ceilometer list samples  https://review.openstack.org/177890
17:30 yfried_ joined #openstack-rally
17:51 pboldin1 left #openstack-rally
17:56 echoingumesh joined #openstack-rally
18:04 kiran-r joined #openstack-rally
18:12 davideagnello joined #openstack-rally
18:30 exploreshaifali joined #openstack-rally
18:36 stpierre joined #openstack-rally
18:42 tfreger joined #openstack-rally
18:46 openstackgerrit Pradeep K Surisetty proposed openstack/rally: Add Ceilometer list samples  https://review.openstack.org/177890
18:46 e0ne joined #openstack-rally
19:00 softCloud1 joined #openstack-rally
19:06 davideagnello joined #openstack-rally
19:19 meteorfox andreykurilin:  can you review this too, please? https://review.openstack.org/#/c/161037/
19:36 msdubov_ joined #openstack-rally
19:41 exploreshaifali joined #openstack-rally
19:49 openstackgerrit Merged openstack/rally: Fix `sshutils' to execute commands with args  https://review.openstack.org/177009
20:06 echoingu_ joined #openstack-rally
20:21 echoingumesh joined #openstack-rally
20:23 echoingumesh joined #openstack-rally
20:40 echoingu_ joined #openstack-rally
20:45 echoingumesh joined #openstack-rally
20:51 turul joined #openstack-rally
20:59 karimb joined #openstack-rally
21:08 openstackgerrit Chris St. Pierre proposed openstack/rally: Add Nova scenario to boot and associate a floating IP  https://review.openstack.org/177968
21:16 openstackgerrit Chris St. Pierre proposed openstack/rally: Add Nova scenario to boot and associate a floating IP  https://review.openstack.org/177968
22:33 echoingumesh joined #openstack-rally
22:39 echoingu_ joined #openstack-rally
22:54 mwagner_lap joined #openstack-rally
23:07 echoingumesh joined #openstack-rally
23:09 echoing__ joined #openstack-rally
23:25 echoingumesh joined #openstack-rally
23:44 echoingumesh joined #openstack-rally

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary