18:00:51 <SergeyLukjanov> #startmeeting sahara 18:00:51 <openstack> Meeting started Thu Mar 19 18:00:51 2015 UTC and is due to finish in 60 minutes. The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:56 <openstack> The meeting name has been set to 'sahara' 18:00:59 <SergeyLukjanov> #topic sahara@horizon status (crobertsrh, NikitaKonovalov) 18:01:10 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon 18:01:24 <elmiko> crobertsrh is at spark summit east, might not be here 18:01:31 <NikitaKonovalov> as usual we still have changes on review 18:01:32 <SergeyLukjanov> NikitaKonovalov, it looks like Chad is offline, so, it's fully your topic 18:01:37 <elmiko> but i saw that his guided cluster stuff got workflow+ 18:01:40 <SergeyLukjanov> elmiko, oh, spark summit, interesting ;) 18:01:46 <NikitaKonovalov> the most critical is Job executions fix 18:02:00 <tmckay> howdy 18:02:12 <NikitaKonovalov> but we've got cluster and job execution wizard merged 18:02:17 <NikitaKonovalov> which is a good sign 18:02:23 <elmiko> \o/ 18:02:29 <tosky> yep, the job execution fix is *really* needed 18:02:43 <tosky> NikitaKonovalov: did you rebase it? Few hours ago it had a merge conflict 18:02:48 <NikitaKonovalov> It does not look like we might need any new changes for kilo 18:03:20 <NikitaKonovalov> tosky: I did but now I've noticed that I had not sent it on review again 18:03:27 <NikitaKonovalov> thanks for the reminder 18:03:54 <tosky> NikitaKonovalov: if you do it now, everyone here can refresh the +1 "live" 18:04:03 <tosky> :) 18:04:03 <elmiko> hehe 18:04:07 <NikitaKonovalov> I'll do that 18:04:30 <NikitaKonovalov> as for the huge feature changes, the event-log is almost ready 18:04:43 <NikitaKonovalov> It is waiting for the client change 18:05:00 <NikitaKonovalov> so that's all updates I've got 18:05:08 <SergeyLukjanov> okay, thx 18:05:14 <SergeyLukjanov> ++ for job exec 18:05:16 <vgridnev_> is there some probability that is would be merged in Kilo? 18:05:28 <SergeyLukjanov> vgridnev_, I think it should be 18:05:37 <SergeyLukjanov> #topic Feature Freeze / kilo-3 18:05:48 <SergeyLukjanov> we're now in feature freeze 18:06:02 <SergeyLukjanov> there are three FFEs approved 18:06:13 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Sahara/Kilo/FPF_Exceptions 18:06:24 <SergeyLukjanov> everything else deferred to liberty 18:06:35 <elmiko> i think we should consider https://review.openstack.org/#/c/164684/ 18:06:48 <elmiko> i don't think we need the extra requirement going into kilo 18:07:01 <SergeyLukjanov> if you'll have something to request for FFE - please ping me and we'll discuss it and if needed I'll help to make a FFE 18:07:32 <SergeyLukjanov> elmiko, ++ it's a kind of bug, so, no FFE needed for it 18:07:49 <elmiko> k, just wanted to bring it up 18:07:55 <elmiko> i agree we don't want extra requirements 18:08:09 <SergeyLukjanov> elmiko, agreed 18:08:22 <vgridnev_> what about sahara.conf.sample? can we remove it under FF? 18:08:31 <SergeyLukjanov> #info consider 164684 - drop barbican client req. 18:08:41 <SergeyLukjanov> vgridnev_, yup, it's not a new feature 18:08:44 <alazarev> vgridnev_, what is wrong with .sample? 18:09:06 <SergeyLukjanov> vgridnev_, we have a bug about the fact that it's now always out of date and it's just a fix for it 18:09:29 <SergeyLukjanov> NOTE: we'll have RC1 early April, about April 9, it'll mean that CodeFreeze begins but master will be open for Liberty dev 18:09:47 <SergeyLukjanov> so, master will be open for Liberty in ~3 weeks 18:09:59 <elmiko> egafford brought up the idea of having the .sample generated as a post-commit hook, is that something we can investigate? 18:10:35 <huichun> vgridnev_: Hi Vitaly so we will not add new code in the old style integration test? we need to apply new integration test in the future? https://review.openstack.org/#/c/165640/ 18:10:52 <SergeyLukjanov> elmiko, the main issue is that when our requirements changing - config changing as well 18:11:01 <SergeyLukjanov> elmiko, and it really depends on requirements installed 18:11:13 <elmiko> SergeyLukjanov: ack, just wanted to bring it up 18:11:39 <SergeyLukjanov> elmiko, I've done the .sample file removal exactly the same way like it was done in nova 18:11:49 <elmiko> SergeyLukjanov: ok, sounds good 18:11:50 <vgridnev_> huichun, yes 18:12:20 <SergeyLukjanov> any question re FF, CF, etc *F? 18:13:12 <tmckay> SergeyLukjanov, so as long as exceptions are done before CF, it's okay? they should be. 18:13:49 <tmckay> and then after CF, can we still fix bugs? Or only on approval for RC-X 18:15:07 <pino|work> SergeyLukjanov: just one: an eventual bump of dib requirements in s-i-e (ie https://review.openstack.org/#/c/165930/ i just sent) is L material now only, right? 18:15:16 <tmckay> SergeyLukjanov, related question on the scope of exceptions. For default-templates, we don't have any for MapR. Should we? And for job-type-endpoints, we haven't tried to make config hints any better, we've just moved them to the new endpoint. Should we try to improve config hints? 18:15:44 <SergeyLukjanov> tmckay, yeah, exceptions works for the time frame before the RC 18:15:58 <SergeyLukjanov> after CF only critical bugs should be fixed 18:16:05 <SergeyLukjanov> + docs 18:16:29 <SergeyLukjanov> pino|work, FF is for the sahara repo itself, s-i-e not on such freeze 18:16:42 <pino|work> ah? interesting to know 18:17:03 <vgridnev_> tmckay, I think we should try to ping guys from MapR to add some default templates 18:17:19 <SergeyLukjanov> pino|work, FF means for s-i-e that we should carefully merge to stuff to not break but we can do 18:17:35 <SergeyLukjanov> tmckay, it's ok to add MapR templates as part of this bp 18:17:46 <pino|work> SergeyLukjanov: i see, thank you 18:17:47 <SergeyLukjanov> tmckay, about config hints, it's a tricky question 18:18:01 <tmckay> okay, my thought too on mapr. I'll to to contact those guys. 18:18:17 <SergeyLukjanov> tmckay, AFAIR the spec was talking something about config hints 18:18:37 <tmckay> yes, we moved them, but we didn't improve them 18:18:39 <SergeyLukjanov> tmckay, so, if we'll be able to improve them in time than we probably should do it 18:18:43 <tmckay> okay 18:18:54 <tmckay> I'll try, after everything else is done 18:19:16 <tmckay> At the very least, we can add some for spark/java for the "edp." configs. At least that 18:19:24 <elmiko> tmckay: i could help if needed 18:19:39 <tmckay> elmiko, ack, thanks 18:20:17 <tmckay> elmiko, a lot of poking around documentation and xml files for the various distros and figuring out what options apply to a job 18:20:29 <SergeyLukjanov> tmckay, cool! 18:20:35 <elmiko> tmckay: ok, lets talk alter 18:20:38 <elmiko> *later 18:20:38 <tmckay> and maybe dependent on which services are deployed 18:20:59 <elmiko> could get complicated 18:21:02 <SergeyLukjanov> #topic Open discussion 18:21:06 <tmckay> elmiko :) yep 18:21:19 <elmiko> i'm curious if sreshetn1 is going to take the wadl stuff? 18:21:34 <SergeyLukjanov> elmiko, tmckay yeah, it's tricky a lot 18:21:58 <SergeyLukjanov> re wadl - it sounds like we can separate work at least by edp and provisioning parts 18:21:59 <tmckay> folks, on the default-templates CR, I have generate a template.conf.sample, is the name okay? 18:22:15 <tmckay> Very basic, sets flavor to 2 except for cdh masters (flavor 4) 18:22:15 <SergeyLukjanov> sreshetn1 now investigating the right way of wadl creation 18:22:33 <elmiko> SergeyLukjanov: ok, i'm going to back off then, unless sreshetn1 wants some help 18:22:36 <tmckay> fixing up the manifest file now, too 18:22:55 <elmiko> SergeyLukjanov: i do have swagger json for our api though, so we could generate skeleton xml from that fyi 18:23:16 <Poornima> folks would like to know can tempest api test migrated to sahara ? 18:24:00 <alazarev> Poornima, it looks that it will be plan 18:24:23 <Poornima> yeah Tempest has a scope of migrating api test to sahara project 18:24:31 <tosky> about that: I'm going to help with moving *CLI* tests from tempest to python-saharaclient - any concerns? 18:24:53 <elmiko> tosky: that makes sense to me 18:25:44 <Poornima> cool tosky 18:26:00 <alazarev> tosky, do you think client is a good place? other projects depend on clirnt 18:26:27 <tosky> alazarev: I think they QA are doing it for all the projects 18:26:50 <alazarev> tosky, do you have link with that? 18:27:03 <SergeyLukjanov> elmiko, ack 18:27:17 <tosky> alazarev: I can point you to the discussion yesterday 18:27:29 <SergeyLukjanov> Poornima, yeah, it was a global plan I think 18:27:38 <alazarev> tosky, yes please 18:27:50 <tosky> alazarev: from 2015-03-18T15:00:46 here: http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2015-03-18.log 18:28:43 <elmiko> SergeyLukjanov: i'd like to talk a little about the external key manager stuff, considering we're pushing to Liberty should i maybe bring it up on ML? 18:28:44 <Poornima> thanks SergeyLukjanov 18:28:47 <tosky> alazarev: I started checking what was done by nova developers (mentioned there), it's not too difficult, but few steps that needs to be checked 18:29:08 <Poornima> in this cycle i would also like know what all functional test considered for sahara 18:30:09 <SergeyLukjanov> elmiko, ++ for ML 18:30:37 <SergeyLukjanov> Poornima, we have a scenario based framework for integration testing sahara, it's based on the tempest-lib 18:31:30 <Poornima> okay 18:31:44 <pino|work> SergeyLukjanov: as mentioned earlier (and also in a couple of previous meetings), i'd like to ask about the dib requirements in s-i-e 18:33:31 <elmiko> SergeyLukjanov: ack 18:33:47 <pino|work> as i said, i just proposed a change to bump to the latest dib version there: https://review.openstack.org/#/c/165930/ 18:34:13 <pino|work> so far all my image generation tests were okay (could not try the generated images yet, though) 18:34:42 <pino|work> in this situation, the only problem left in dib when generating centos images is https://review.openstack.org/#/c/162239/ 18:35:04 <pino|work> ... which can be worked around easily, with export REG_HALT_UNREGISTER=1 18:35:28 <pino|work> (registration is subscription-manager, hence rhel-only stuff) 18:36:05 <pino|work> hence i have two questions (with the second depending on the first) 18:36:43 <pino|work> a) provided there are no regression (even with export workaround in place), is it desirable to accept a dib requirement bump in s-i-e now? 18:37:53 <pino|work> b) if (a), would further fixes/changes to adapt to a newer dib (like use DIB_DEBUG_TRACE instead of unconditional set -x everywhere, use the new yaml stuff for package installation, etc) be acceptable as well? 18:38:09 <pino|work> (end) 18:38:55 <elmiko> pino|work: i'm +1 for a dib version upgrade 18:39:27 <elmiko> not so sure about (b), it sounds good but i don't know enough about the changes 18:40:04 <SergeyLukjanov> +1 for dib version upgrade 18:40:17 <SergeyLukjanov> we already been waiting for a long time for it ;) 18:42:14 <SergeyLukjanov> anything else to discuss? 18:42:21 <SergeyLukjanov> pino|work, thx for improving s-i-e 18:42:29 <pino|work> so (a) is okay, and potentially (b) as well, depending on the changes? 18:43:37 <SergeyLukjanov> pino|work, yup, a) is ok for sure 18:43:46 <SergeyLukjanov> and yes b) depends on changes 18:43:58 <SergeyLukjanov> IMO we should try to use latest dib always 18:44:00 <elmiko> we don't have any sort of specs for s-i-e, how should we propose the changes, in a bug? 18:44:07 <pino|work> makes sense, thank you for your answers! 18:44:10 <SergeyLukjanov> but we should be very careful to not introduce regressions 18:44:36 <SergeyLukjanov> let's create a separated dir for it in specs like it done for client 18:44:41 <SergeyLukjanov> I'll do it after the meeting 18:44:46 <elmiko> awesome 18:44:52 <SergeyLukjanov> it'll be very helpful to discuss changes 18:44:56 <elmiko> +1 18:45:01 <pino|work> oki 18:46:24 <tosky> alazarev: re moving CLI tests, do you think I can proceed in the meantime? 18:47:56 <alazarev> tosky, yes, if it is suggested way 18:48:07 <tosky> alazarev: ack, thanks 18:49:07 <SergeyLukjanov> folks, please share your thoughts on summit topics https://etherpad.openstack.org/p/sahara-liberty-proposed-sessions 18:49:11 <SergeyLukjanov> #info please share your thoughts on summit topics https://etherpad.openstack.org/p/sahara-liberty-proposed-sessions 18:49:26 <elmiko> SergeyLukjanov: can you assign this to me, https://bugs.launchpad.net/sahara/+bug/1429989 18:49:26 <openstack> Launchpad bug 1429989 in Sahara "Hardcoded, weak, potentially unchangeable password in Cloudera plugin" [Critical,Confirmed] 18:49:35 <elmiko> SergeyLukjanov: i have a question about summit topics 18:50:08 <elmiko> i'd like to propose a security update talk, we had good attendence in Paris, do you think i should propose fishbowl or smaller talk? 18:50:17 <Poornima> SergeyLukjanov++ tosky++ alazarev++ thanks for quick answers :) 18:51:30 <elmiko> SergeyLukjanov: i guess the question is, fish bowl or working session? 18:51:46 <SergeyLukjanov> elmiko, assigned 18:51:52 <elmiko> thanks =) 18:52:03 <SergeyLukjanov> elmiko, mm 18:52:17 <elmiko> yea... not sure it's big enough for fish bowl 18:52:34 <SergeyLukjanov> elmiko, it's very important topic and we'd like to more folks to participate, so, probably it's fish bowl 18:52:45 <elmiko> SergeyLukjanov: ack, i'll add it to the pad 18:52:46 <SergeyLukjanov> elmiko, fish bowl is good to attract more folks 18:52:50 <elmiko> agreed 18:52:51 <SergeyLukjanov> elmiko, great, thx 18:53:11 <SergeyLukjanov> we need more ideas or we'll not have sessions at all :) 18:53:26 <elmiko> yea, i didn't want to add it without a little more info 18:53:39 <elmiko> we'll do some brainstorming and think of more =) 18:53:57 * Poornima peeps in provided links 18:54:15 <SergeyLukjanov> elmiko, if you have even 5 word idea - please add it, it's ok 18:54:28 <elmiko> SergeyLukjanov: ack 18:54:36 <SergeyLukjanov> elmiko, it's important to have ideas 18:55:08 <elmiko> SergeyLukjanov: just a warning i'm adding a v2 api topic ;) 18:55:40 <SergeyLukjanov> elmiko, yeah :) 18:55:45 <SergeyLukjanov> elmiko, I've been expecting it :) 18:56:07 <elmiko> i know much more about pecan now, still not sure we want to switch but w/e 18:56:14 <weiting> We got one idea from our customer side, they would like to use one big virtual cluster to run different job by tenant. 18:56:32 <elmiko> weiting: +1 multi-tenancy is a big topic 18:56:34 <SergeyLukjanov> weiting, oh, interesting 18:56:36 <weiting> Is it possible in current OpenStack? 18:56:42 <SergeyLukjanov> weiting, nope 18:57:08 <SergeyLukjanov> but if we'll have a public support in ACLs than we'll be able to create a public cluster 18:57:14 <elmiko> we need to watch keystone OS-FEDERATION too for that stuff 18:57:23 <SergeyLukjanov> and then users from different tenants will be able to run jobs 18:57:39 <weiting> I think the request actually is because to create a cluster spends too much time currently. 18:58:13 <SergeyLukjanov> 2 mins left 18:58:44 <elmiko> anyways, good topic for summit 18:58:51 <weiting> May I add it in pad? 18:58:52 <SergeyLukjanov> agreed 18:58:58 <elmiko> weiting: yes! 18:58:59 <SergeyLukjanov> weiting, sure 18:59:07 <SergeyLukjanov> weiting, it's for ideas :) 19:00:06 <SergeyLukjanov> sreshetn1, you're a bit late :) 19:00:14 <elmiko> good timing 19:00:23 <SergeyLukjanov> thank you folks! 19:00:26 <SergeyLukjanov> #endmeeting