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