14:00:15 <SergeyLukjanov> #startmeeting sahara
14:00:16 <openstack> Meeting started Thu Aug 13 14:00:15 2015 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'sahara'
14:00:21 <weiting> O/
14:00:34 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
14:00:37 <sreshetnyak> o/
14:01:23 <vgridnev> o/
14:01:26 <AndreyPavlov> hi
14:01:27 <esikachev> hi
14:01:42 <SergeyLukjanov> #topic sahara@horizon status (crobertsrh, NikitaKonovalov)
14:01:49 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon
14:01:56 <SergeyLukjanov> folks, please :)
14:01:58 <tosky> hi
14:01:58 <pino|work> o/
14:02:01 <crobertsrh> hello/
14:02:12 <kchen> o/
14:02:31 <huichun> hi
14:02:39 <egafford> Hello!
14:02:49 <NikitaKonovalov> ok, so I have not got any new patches
14:02:52 <vgridnev> several stuff got merged in horizon this week
14:03:11 <NikitaKonovalov> @vgridnev has found an issue with event log patch
14:03:36 <vgridnev> and also horizon have new meeting where you can to approve your bp filed to horizon
14:03:49 <elmiko> nice
14:04:06 <kchen> Hi all, I recently installed a devstack with Sahara, but I found cannot open the Horizon mainpage. I am not sure whether you guy met this.
14:04:15 <NikitaKonovalov> vgridnev: thanks for fixing it quickly
14:04:16 <kchen> I reported a bug https://bugs.launchpad.net/horizon/+bug/1483955
14:04:16 <openstack> Launchpad bug 1483955 in OpenStack Dashboard (Horizon) "Horizon homepage shows internal server error" [Undecided,New]
14:04:33 <SergeyLukjanov> @NikitaKonovalov have you seen working horizon in devstack last week? :)
14:04:43 <vgridnev> NikitaKonovalov, fairly it was done by esikachev
14:04:49 <vgridnev> found*
14:04:54 <SergeyLukjanov> kchen, okay, we need to take a look on it
14:05:11 <crobertsrh> I think I may have also seen that one yesterday, late in the day.
14:05:12 <kchen> I think it is like a sahara dashboard issue.
14:05:14 <elmiko> we've also had a few users report issues with horizon/sahara integration in kilo
14:05:26 <tmckay> hi folks, sorry, quick break between meetings went too long :)
14:05:26 <SergeyLukjanov> NikitaKonovalov, crobertsrh, vgridnev, have you testing horizon with sahara after moving our code to contrib?
14:05:41 <SergeyLukjanov> tmckay :)
14:05:52 <crobertsrh> I had been using it.  Then I grabbed the latest yesterday and saw issues.
14:06:03 <tmckay> oh, I have a very strange Horizon bug that I talked to crobertsrh about.  May be only F21
14:06:03 <crobertsrh> I was hoping it was just something that I was doing wrong locally.
14:06:05 <vgridnev> SergeyLukjanov, I tested that on my own laptop and that worked fine
14:06:12 <egafford> SergeyLukjanov: I developed the interface map UI changes against contrib; it worked fine then.
14:06:18 <NikitaKonovalov> I've ran it a lot and havent seen that issue yet
14:06:33 <tmckay> but, in one place apparently we need to test for ["None", None, ""]
14:06:53 <elmiko> this issue, #link https://bugs.launchpad.net/sahara/+bug/1483397 has come up on ask.openstack.org and we've had someone asking about it in channel
14:06:54 <openstack> Launchpad bug 1483397 in Sahara "Resolver404 error during Node Group Template Creation (via Horizon)" [Undecided,New]
14:06:56 <tmckay> not verified yet, but we should do that and file a bug. crobertsrh, did you get a chance to see it?
14:07:17 <crobertsrh> No, I've never come across it.
14:07:21 <tmckay> doh
14:07:32 <tmckay> I will make an F21 box and let you experience it
14:07:38 <tmckay> ;-)
14:07:43 <crobertsrh> Ok, I haven't tried f21
14:07:56 <NikitaKonovalov> what does sahara 0.8.0 mean? what release is that?
14:08:11 <elmiko> when does that happen tmckay, i have been using sahara/horizon on f21
14:08:39 <SergeyLukjanov> NikitaKonovalov, probably it's client release?
14:08:50 <tmckay> On submission of a Java job type, the code that looks at the input_id and output_id fields ends up passing "None" to the client instead of None
14:08:57 <tmckay> (or just not including in the dict)
14:09:16 <tmckay> so, Sahara sees the string "None" and it breaks the schema
14:09:39 <elmiko> NikitaKonovalov: the person who reported that was installing everything through the ubuntu packager, agreed with SergeyLukjanov though, probably client
14:09:50 <elmiko> tmckay: i can try and give it a run later today
14:09:54 <tmckay> I hacked my horizon in devstack to screen for "None", but I haven't validated on a clean box
14:09:54 <huichun> tmckay: hi Trevor recurrence edp spec has been updated with your review comments last time
14:10:20 <tmckay> huichun, thank you.  I am behind on reviews (I think I said that before :) ) and look to do a bunch today and tomorrow
14:10:43 <huichun> ^^
14:11:40 <NikitaKonovalov> elmiko: I've never seen Sahara installed from Ubuntu packages, but it looks more like a Horizon templates failure rathe than Sahara issue
14:12:19 <elmiko> NikitaKonovalov: ack, maybe it's something to do with the ubuntu installation of horizon (which is what crobertsrh speculated)
14:12:54 <crobertsrh> for sure, something either in Horizon or in the ubuntu package
14:13:55 <SergeyLukjanov> #topic News / updates
14:14:00 <elmiko> not sure if we could do much, someone would need to dig into the ubuntu packaging...
14:14:01 <SergeyLukjanov> switching to the next topic :)
14:14:24 <tmckay> my update -- I will push a spec today for the manila data source change that I wrote :) Had to make sure it worked first
14:14:29 <vgridnev> nothing new, vanilla plugin is got merged
14:14:37 <SergeyLukjanov> so, re dashboard issue - we need more details and keep track on it
14:14:44 <SergeyLukjanov> hopefully it's some local issue
14:14:55 <elmiko> i've got the first keystone/session patch up, also the apiv2 spec is under way, and i'm about to start pushing the improved secret storage patches
14:15:04 <AndreyPavlov> working on shared/protected support, some researches about keystone auth plugins and tokens
14:15:06 <tmckay> yay!
14:15:35 <NikitaKonovalov> I've been adding some rally improvements to support the gateway node.
14:15:56 <egafford> My Manila stuff is in; working on a final mergeable rev of the interface map UI; also working on TripleO integration again now that that project is in a better place. :)
14:16:02 <elmiko> AndreyPavlov: did you see #link https://review.openstack.org/#/c/207208/
14:16:04 <NikitaKonovalov> I'm also planing to work on enabling rally job in the gate
14:16:18 <egafford> (Tried a few moths ago; going back now is a different world.)
14:16:44 <tmckay> oh, we made hdp test non-voting in the gate, looked like it was a timeout to the ambari repos?  Has anyone looked at that more?
14:16:46 * SergeyLukjanov I'm working on a spec for sahara-tests separation, hope to complete this week - I really think it'll be great to extract it before the Liberty RC1
14:16:53 <AndreyPavlov> elmiko: just a little, we have some topics to talk about)
14:16:56 <tosky> SergeyLukjanov: \o/
14:17:03 <kchen> I am working on enabling Yarn resourcemanager HA in CDH plugin.
14:17:23 <SergeyLukjanov> tosky :) yeah, I wanna to have the separated testing tool too, already have some code prepared ;)
14:17:26 <tmckay> I think it was hdp 2.0.6
14:17:36 <SergeyLukjanov> kchen cool!
14:17:46 <weiting> I am working on NetApp Hadoop NFS driver integration
14:18:00 <vgridnev> tmckay, is it possible to build hdp image locally? if yes, it can ci issue
14:18:40 <tmckay> vgridnev, yes, elmiko worked on that a while back. We had a version where ambari instead from local on the image
14:18:49 <tmckay> but I don't think it is up to date currently
14:19:02 <elmiko> tmckay: +1, i think it has regressed
14:19:05 <tosky> NikitaKonovalov: what is your scope for Rally usage in Sahara? I'd like to understand if there are overlaps with scenario tests and tempest API tests
14:19:40 <tmckay> it might be a good idea to keep that up to date for hdp images, so that we avoid network damage to the gate tests
14:19:47 <tmckay> it slows everything down (a lot)
14:19:57 <vgridnev> tmckay, anyway I think we should concentrate on new hdp plugin which is on review already
14:19:58 <elmiko> +1
14:20:17 <NikitaKonovalov> tosky: Rally is more of a performance tool rather than a test framework
14:20:17 <tmckay> vgridnev, agreed, but even that should install locally if possible
14:20:29 <tmckay> we want to avoid going to outside repos
14:20:42 <tosky> NikitaKonovalov: good to hear that, and I agree; I heard others saying otherwise
14:21:33 <NikitaKonovalov> tosky: Rally is only depending on sahara-client and what it does is creates a series of clusters in parrallel or in sequence while measureing the performance of create and delete operations
14:21:34 <SergeyLukjanov> tosky, in rally we're implementing perf tests for API and for workloads as well - to spam templates create and list for example and to create tons of hadoop clusters throuh sahara api and then run dfsio on them using EDP
14:22:05 <SergeyLukjanov> tosky, honestly it 100% overlaps with tempest api tests, but tempest doesn't allow to make perf. testing
14:22:28 <NikitaKonovalov> tosky: the same for the jobs, It can run on job a lot of times and get some average and divation stats
14:22:57 <SergeyLukjanov> tosky, scenario tests could be partially covered with rally too (as clusters api tests :) ) but scenario tests allows tons of customizations, so, it's a very different use case
14:23:41 <tosky> SergeyLukjanov, NikitaKonovalov: that's what I thought, I think rally could be used to *run* existing tests and repeat them (even scenario tests maybe?)
14:24:20 <tosky> I'm a bit skeptical about using it natively for writing tests, that's where I see the overlap; I see more gain in using it's reporting capabilities
14:24:32 <tosky> that's my opinion
14:24:42 <SergeyLukjanov> tosky, I think we should evaluate integration rally + scenario tests
14:24:48 <NikitaKonovalov> tosky: rally is able to run templest tests, I could actually look to find if I can teach it to run our scenarios
14:24:51 <SergeyLukjanov> AFAIK rally supports running tempest
14:25:22 <tosky> NikitaKonovalov: there was a WIP spec to allow rally to run integration tests, but the way I would do it is different
14:25:31 <NikitaKonovalov> (those are kept in not_for_producetion module though)
14:25:40 <kchen> Is there any spec on introducing Rally in Sahara?
14:25:46 <SergeyLukjanov> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/tempest/tempest.py it looks pretty simple :)
14:25:49 <tosky> I would rather slowly use more parts from tempest-lib in scenario tests and use the new tempest spec for discovering additional tests
14:26:00 <NikitaKonovalov> kchen: no, we dont need any modefications to Sahara
14:26:12 <tosky> this one: http://specs.openstack.org/openstack/qa-specs/specs/tempest/tempest-external-plugin-interface.html
14:26:26 <SergeyLukjanov> tosky, interesting
14:26:43 <tosky> and access scenario tests through normal tempest interface, so it would be easy to run them from rally to
14:26:50 <kchen> NikitaKonovalov: I am not familiar with Rally and want to see what benefit can be brought by it :)
14:26:55 <SergeyLukjanov> tosky, I'm not sure how it'll work due to the core generation phase...
14:27:07 <tosky> SergeyLukjanov: core generation?
14:27:17 <SergeyLukjanov> tosky, I mean code generation
14:27:34 <tosky> SergeyLukjanov: ah, right; well, it can be explored
14:27:37 <SergeyLukjanov> tosky, in the first phase scenario tests generates actual code from the yaml
14:27:41 <SergeyLukjanov> tosky, yup
14:28:31 <tosky> I didn't investigate too much because some basic part were missing; my idea is simply to reuse existing parts as much as possible and integrate the pieces seamlessly
14:29:51 <SergeyLukjanov> tosky, I would say that it's probably a good integration point to be able to run scenario tests as a tempest tests and through the sahara-tests command
14:30:08 <SergeyLukjanov> both approaches have pros and cons
14:30:38 <SergeyLukjanov> any other news to share?
14:30:48 <NikitaKonovalov> kchen: you can have a look on what is currently supported in rally right now https://github.com/openstack/rally/tree/master/rally/plugins/openstack/scenarios/sahara
14:31:00 <SergeyLukjanov> #topic Client release plans
14:31:05 <SergeyLukjanov> https://etherpad.openstack.org/p/sahara-liberty-client
14:31:22 <SergeyLukjanov> I've updated it with a label RELEASE 0.10.0
14:31:33 <SergeyLukjanov> version already bumped in global requirements
14:31:36 <elmiko> \o/
14:31:42 <SergeyLukjanov> so, we could use it from any project
14:31:45 <NikitaKonovalov> kchen: and here are the examples of rally scenrios for Sahara https://github.com/openstack/rally/tree/master/samples/tasks/scenarios/sahara
14:31:50 <kchen> NikitaKonovalov: thanks!
14:32:05 <SergeyLukjanov> we'll need one more client release before the L3 to make sure all features support merged
14:32:08 <NikitaKonovalov> kchen: ping me if you have any questions
14:32:37 <SergeyLukjanov> any q. re client?
14:33:03 <tosky> one more, do you mean 0.10.1 or 0.11?
14:33:03 <SergeyLukjanov> #topic Bug triage / fix days / doc days
14:33:05 <kchen> NikitaKonovalov: sure
14:33:16 <SergeyLukjanov> tosky 0.11 due to the new features and updated requirements
14:33:22 <tosky> oki
14:33:48 <SergeyLukjanov> so, we need to have a bug triage day sooner and than bug fix day as wekk
14:34:02 <SergeyLukjanov> docs should be updated before RC1 release too
14:34:06 <elmiko> sounds worthwhile ;)
14:35:02 <SergeyLukjanov> so, what's about doing bug triage, bug fix and doc update days next three weeks?
14:35:04 <SergeyLukjanov> one by week
14:35:18 <tmckay> sounds great
14:35:23 <elmiko> +1
14:35:27 <vgridnev> SergeyLukjanov, +1
14:35:39 <egafford> SergeyLukjanov: +1
14:35:56 <SergeyLukjanov> probably on Mondays to have a week after to complete patches before next *** day?
14:36:38 <elmiko> agreed
14:37:04 <tmckay> agreed
14:37:24 <SergeyLukjanov> crobertsrh, egafford, sreshetnyak, NikitaKonovalov, vgridnev ^^
14:37:40 <egafford> SergeyLukjanov: Yup, sounds good.
14:37:40 <vgridnev> I am ok with that
14:37:41 <tosky> makes sense
14:37:47 <NikitaKonovalov> I'm fine with that
14:37:51 <crobertsrh> Yeah, that seems like a good idea
14:38:08 <tellesnobrega> +1
14:38:56 <SergeyLukjanov> does any body wants to volunteer to coordinate this days? (one volunteer per each of events needed IMO)
14:38:59 <SergeyLukjanov> :)
14:39:27 <elmiko> i'll volunteer for doc fix
14:40:02 <egafford> I can do bug fix if we like.
14:40:41 <SergeyLukjanov> anyone for bug triaging? :)
14:41:24 <vgridnev> If someone will explain what i should do, I can be one :)
14:41:30 <SergeyLukjanov> #agreed Bug triage day on Aug 17 (TBD volunteer), Bug fix day on Aug 24 (egafford) and Doc update day on Aug 31 (elmiko)
14:41:32 <huichun> i can do bug fix if we like
14:42:41 <kchen> huichun: Sergey means bug fix coordinator
14:42:53 <kchen> huichun: are you sure you have time to do this?
14:42:55 <SergeyLukjanov> to coordinate some of this day we need to have an etherpad with a list of tasks (probably created in collaboration at the day start) and ensure everyone using this doc to avoid duplicated efforts
14:43:10 <huichun> sorry misunderstand
14:43:42 <SergeyLukjanov> sounds like that's pretty all for this topic
14:43:47 <SergeyLukjanov> #topic Open discussion
14:44:04 <elmiko> i have a couple issues
14:44:17 <elmiko> #link https://review.openstack.org/207208
14:44:24 <elmiko> this review seems to not be triggering ci
14:44:32 <elmiko> ಠ_ಠ
14:44:47 <elmiko> also, #link https://review.openstack.org/212172
14:45:01 <elmiko> api v2 spec is up, i'm looking for feedback before i start pushing patches
14:45:02 <vgridnev> I heard that there are several issues on ci
14:45:09 <elmiko> ok, good to know
14:45:20 <elmiko> AndreyPavlov: did you want to talk about auth plugin/tokens?
14:45:24 <AndreyPavlov> yep
14:45:57 <AndreyPavlov> Currently we have an issue with token expiration during long operations (like creation or scale of big clusters) or in case of small lifetime of auth tokens.
14:46:02 <aignatov> is @lu huichun here? :)
14:46:08 <AndreyPavlov> It leads to keystone Unauthorized errors when sahara tries to communicate with openstack clients.
14:46:21 <aignatov> not sure if he has different nick in IRC :)
14:46:29 <tmckay> aignatov, yes, huichun is here
14:46:29 <AndreyPavlov> Combination of auth plugin + session can deal with that, but only if auth plugin object has enough information to get new token.
14:46:54 <elmiko> AndreyPavlov: i think that would have to be a password token?
14:46:56 <vgridnev> aignatov, seems that his nick is huichun
14:47:01 <huichun> elmiko:  Michael I notice that you have filed a bug to change put with patch?
14:47:19 <AndreyPavlov> Auth plugin that we take from middleware has not. It has a token and it cant refresh it. Password is getting new tokens fine
14:47:20 <huichun> i am here with mobile client
14:47:23 <elmiko> huichun: yes
14:47:30 <aignatov> vgridnev: tmckay thanks
14:47:46 <huichun> aignatov: hello
14:47:49 <aignatov> I am regarding https://review.openstack.org/#/c/192097/
14:47:51 <elmiko> AndreyPavlov: the only problem is that we won't be able to get a password token from the user (i don't think)
14:48:04 <elmiko> AndreyPavlov: this is why we have been using trusts for some of the longer running operations
14:48:19 <AndreyPavlov> yep
14:48:26 <aignatov> idea looks cool but I’m not sure if it works correctly after implemenation as descripbed in spec
14:49:03 <huichun> aignatov:  so what is your main concern?
14:49:25 <aignatov> I think that reccuring jobs in most scenarios will not work if Sahara will not delete output datasource before running second and further jobs
14:50:29 <aignatov> if job has OUTPUT of course :)
14:50:36 <huichun> yes I see your comment, so should we make a patch for edp job that before it runs , we should check the whether the output is exist?
14:50:50 <SergeyLukjanov> aignatov, we have DataSource placeholders, I think they are solving this issue
14:50:51 <elmiko> AndreyPavlov: i think we should probably continue to follow the trust model for situations where we need tokens for extended periods of time.
14:51:17 <tmckay> huichun, aignatov, or use the %JOB_EXEC_ID% stuff that alazarev wrote
14:51:40 <tmckay> we have had an idea for a long time to add <prepare> tags to oozie jobs
14:51:43 <AndreyPavlov> elmiko: yes, that was my point
14:51:56 <elmiko> AndreyPavlov: ok, cool. i agree =)
14:52:02 <tmckay> that I think would be the way to do it.  For spark, I don't think it cares if the output is already there
14:52:03 <aignatov> @SergeyLukjanov @tmckay Cool, so this needs to be described in spec
14:52:51 <tmckay> I mean, yes, I think there are 2 ways: placeholders (exist now), prepare tags (would have to be added to allow delete)
14:53:23 <vikram_> #join /openstack-meeting-4
14:53:33 <huichun> tmckay:  prepare tags to do delete action
14:53:41 <tmckay> yes
14:53:56 <aignatov> tmckay: ok, I know only second way :) didn’t play with placeholders
14:54:00 <huichun> JOB_EXEC_ID is for?
14:54:24 <tmckay> huichun, better to let oozie do it as part of the workflow if possible I think, than to have Sahara issue ssh comands for delete
14:54:39 <huichun> agree
14:54:41 <aignatov> it looks like a new bp to implement :)
14:55:10 <tmckay> huichun, data source urls can have symbol substitution for exactly this problem, so swift://container/my_path_%JOB_EXEC_ID%
14:55:20 <huichun> tmckay:  so should I raise a separate spec for that prepare tag?
14:55:34 <tmckay> huichun, so Sahara will replace the job_exec_id with a uuid when it submits the job
14:55:58 <tmckay> huichun, of course, if this is being launched from an Oozie coordinator job that won't work ....
14:56:07 <SergeyLukjanov> 4 mins left
14:56:11 <tmckay> because Oozie will be doing the launch, not Sahara
14:56:12 <huichun> I remember there is a data source patch to resolve this issue, right?
14:56:37 <tmckay> huichun, yes, I think it merged
14:56:50 * tmckay looks
14:57:15 <huichun> tmckay:  so should I raise a separate spec for adding prepare tag?
14:57:40 <huichun> before the recurrence edp job spec?
14:57:57 <huichun> aignatov:  is that so?
14:57:57 <SergeyLukjanov> note: I've just proposed egafford to sahara core reviewer team - http://lists.openstack.org/pipermail/openstack-dev/2015-August/071985.html existing core team members, please vote on it
14:58:03 <tmckay> huichun, hmm, yes, I think adding prepare tags should be a separate spec
14:58:05 <egafford> \o/
14:58:12 <tmckay> yay egafford!
14:58:12 <elmiko> nice =)
14:58:13 <aignatov> huichun: I think implementing with placeholders would be enough
14:58:29 <aignatov> like it is existing functional already
14:58:31 <tmckay> aignatov, huichun, we can discuss on the spec :)
14:58:35 <huichun> congs Ethan
14:58:41 <huichun> ok
14:58:58 <aignatov> yes, new spec for tags would be great :)
14:59:01 * regXboi grabs ice
14:59:15 <aignatov> congrats Ethan :)
14:59:23 <SergeyLukjanov> thanks folks, have a good rest of day!
14:59:29 <tmckay> bye
14:59:30 <egafford> Very honored by the nomination; it's a fabulous team.
14:59:31 <kchen> thanks
14:59:36 <kchen> bye
14:59:37 <egafford> Bye!
14:59:42 <elmiko> thanks SergeyLukjanov
14:59:43 <SergeyLukjanov> #endmeeting