Thursday, 2014-02-06

openstackgerritTrevor McKay proposed a change to openstack/savanna: Modify the REST doc to show a Java job type execution  https://review.openstack.org/7142300:02
*** tmckay has left #savanna00:06
*** qwerty_nor has quit IRC00:08
*** ruhe has joined #savanna00:13
*** matsuhashi has joined #savanna00:20
*** nosnos has joined #savanna00:56
*** ruhe has quit IRC01:18
*** mst89 has quit IRC01:45
openstackgerritAndrew Lazarev proposed a change to openstack/python-savannaclient: Changed base Resource class to prevent changing of passed arguments  https://review.openstack.org/7108601:56
mattfalazarev?01:57
*** IlyaE has quit IRC02:11
*** ityaptin has quit IRC02:16
*** ityaptin has joined #savanna02:16
*** aignatov_ is now known as aignatov03:11
*** ghenriks has quit IRC04:09
*** ghenriks has joined #savanna04:15
*** jcooley_ has quit IRC04:43
*** akuznetsov has joined #savanna04:45
openstackgerritAlexander Ignatov proposed a change to openstack/savanna-dashboard: Compatibility with python-savannaclient>=0.5  https://review.openstack.org/7036004:47
*** nosnos_ has joined #savanna05:02
*** nosnos has quit IRC05:06
*** aignatov is now known as aignatov_05:27
*** akuznetsov has quit IRC05:34
*** akuznetsov has joined #savanna05:36
*** DinaBelova_ is now known as DinaBelova05:41
*** jcooley_ has joined #savanna05:49
*** DinaBelova is now known as DinaBelova_06:06
*** matsuhashi has quit IRC06:07
*** matsuhashi has joined #savanna06:07
*** matsuhas_ has joined #savanna06:09
*** matsuhashi has quit IRC06:09
openstackgerritJenkins proposed a change to openstack/savanna: Imported Translations from Transifex  https://review.openstack.org/7091806:09
*** jcooley_ has quit IRC06:11
*** jcooley_ has joined #savanna06:24
*** _nadya_ has joined #savanna06:25
*** IlyaE has joined #savanna06:34
*** nosnos has joined #savanna06:40
*** nosnos_ has quit IRC06:42
*** _nadya_ has quit IRC06:43
*** IlyaE has quit IRC06:45
*** NikitaKonovalov_ is now known as NikitaKonovalov06:48
*** NikitaKonovalov is now known as NikitaKonovalov_06:54
*** IlyaE has joined #savanna06:58
*** akuznetsov has quit IRC07:06
*** akuznetsov has joined #savanna07:09
*** IlyaE has quit IRC07:09
*** _nadya_ has joined #savanna07:09
*** IlyaE has joined #savanna07:21
*** _nadya_ has quit IRC07:22
*** _nadya_ has joined #savanna07:27
*** _nadya_ has quit IRC07:28
*** IlyaE has quit IRC07:33
*** IlyaE has joined #savanna07:41
*** skolekonov has joined #savanna07:52
*** IlyaE has quit IRC07:54
*** NikitaKonovalov_ is now known as NikitaKonovalov08:20
openstackgerritDaniele Venzano proposed a change to openstack/savanna-image-elements: Add a Spark element  https://review.openstack.org/7123708:26
*** bogdando has joined #savanna08:30
*** dmitryme has joined #savanna09:00
*** aignatov_ is now known as aignatov09:10
*** jcooley_ has quit IRC09:32
*** DinaBelova_ is now known as DinaBelova09:37
openstackgerritA change was merged to openstack/savanna-extra: Small tweak to the wordcount example README  https://review.openstack.org/7141310:06
openstackgerritA change was merged to openstack/savanna-dashboard: Sync with global-requirements  https://review.openstack.org/7135510:07
openstackgerritSergey Lukjanov proposed a change to openstack/savanna: Modify the REST doc to show a Java job type execution  https://review.openstack.org/7142310:13
*** ruhe has joined #savanna10:21
*** aignatov is now known as aignatov_10:22
openstackgerritA change was merged to openstack/savanna: Sync with global-requirements  https://review.openstack.org/7135610:37
openstackgerritDaniele Venzano proposed a change to openstack/savanna-image-elements: Add a Spark element  https://review.openstack.org/7123710:49
openstackgerritA change was merged to openstack/savanna: Extract configs beginning with "edp." from job_configs['configs']  https://review.openstack.org/6971210:50
openstackgerritA change was merged to openstack/savanna: Generate streaming tag in mapreduce job  https://review.openstack.org/6972710:52
openstackgerritA change was merged to openstack/savanna: Add validation check for streaming elements on MapReduce without libs  https://review.openstack.org/6996010:52
*** NikitaKonovalov is now known as NikitaKonovalov_10:54
*** NikitaKonovalov_ is now known as NikitaKonovalov10:57
*** aignatov_ is now known as aignatov10:58
openstackgerritA change was merged to openstack/savanna: Add integration test for streaming mapreduce  https://review.openstack.org/7082911:02
openstackgerritNikita Konovalov proposed a change to openstack/savanna: Moving rest to Pecan/WSME framework  https://review.openstack.org/6390811:05
openstackgerritNikita Konovalov proposed a change to openstack/savanna: Moving rest to Pecan/WSME framework  https://review.openstack.org/6390811:12
*** venza has quit IRC11:37
*** venza has joined #savanna11:38
openstackgerritA change was merged to openstack/savanna-dashboard: Adding floating ip pool to node groups details for cluster  https://review.openstack.org/7138111:44
*** DinaBelova is now known as DinaBelova_11:52
*** DinaBelova_ is now known as DinaBelova12:05
*** IvanBerezovskiy has joined #savanna12:19
*** qwerty_nor has joined #savanna12:23
openstackgerritA change was merged to openstack/savanna: Refactored unit tests structure  https://review.openstack.org/7021112:25
*** venza has quit IRC12:25
*** jcooley_ has joined #savanna12:26
*** venza has joined #savanna12:26
*** jcooley_ has quit IRC12:31
openstackgerritSergey Reshetnyak proposed a change to openstack/savanna: Add IDH plugin  https://review.openstack.org/7150712:35
openstackgerritYaroslav Lobankov proposed a change to openstack/savanna: Default OpenStack auth port was changed  https://review.openstack.org/7150912:42
*** dmitryme has quit IRC12:43
*** _crobertsrh is now known as crobertsrh12:45
*** dmitryme has joined #savanna13:06
openstackgerritNikita Konovalov proposed a change to openstack/savanna: Moving rest to Pecan/WSME framework  https://review.openstack.org/6390813:41
openstackgerritNikita Konovalov proposed a change to openstack/savanna: Moving rest to Pecan/WSME framework  https://review.openstack.org/6390813:53
*** dmitryme has quit IRC13:55
*** jcooley_ has joined #savanna13:57
*** jcooley_ has quit IRC14:03
*** dmitryme has joined #savanna14:09
*** tmckay has joined #savanna14:37
*** dmitryme has quit IRC14:51
*** dmitryme has joined #savanna14:51
*** dmitryme has quit IRC15:01
*** matsuhas_ has quit IRC15:17
openstackgerritA change was merged to openstack/savanna: Default OpenStack auth port was changed  https://review.openstack.org/7150915:18
*** nosnos has quit IRC15:21
openstackgerritTrevor McKay proposed a change to openstack/savanna: Move 'main_class' and 'java_opts' into edp.java configs  https://review.openstack.org/6998215:35
openstackgerritTrevor McKay proposed a change to openstack/savanna: Update the edp user doc to discuss "edp." configs for Java jobs  https://review.openstack.org/7140315:38
openstackgerritTrevor McKay proposed a change to openstack/savanna: Modify the REST doc to show a Java job type execution  https://review.openstack.org/7142315:38
openstackgerritSergey Reshetnyak proposed a change to openstack/savanna: DO NOT MERGE Testing CI with cinder  https://review.openstack.org/7157215:43
*** jcooley_ has joined #savanna15:46
*** aignatov is now known as aignatov_15:48
*** jmaron has joined #savanna15:51
*** skostiuchenko has joined #savanna15:52
*** jcooley_ has quit IRC15:53
openstackgerritTrevor McKay proposed a change to openstack/savanna: Add utilities for supporting dotted job types  https://review.openstack.org/7138715:53
*** IvanBerezovskiy has left #savanna16:05
openstackgerritTrevor McKay proposed a change to openstack/savanna: Remove extra Java job type fields from JobExecutions  https://review.openstack.org/7042016:08
*** akuznetsov has quit IRC16:16
*** akuznetsov has joined #savanna16:29
*** jcooley_ has joined #savanna16:30
*** jcooley_ has quit IRC16:56
*** jcooley_ has joined #savanna16:57
*** NikitaKonovalov is now known as NikitaKonovalov_16:58
*** akuznetsov has quit IRC17:02
*** DinaBelova is now known as DinaBelova_17:04
*** mst89 has joined #savanna17:19
*** mst89 has quit IRC17:23
*** _nadya_ has joined #savanna17:29
*** mattf is now known as _mattf17:33
*** ylobankov1 has joined #savanna17:34
*** DinaBelova_ is now known as DinaBelova17:37
*** jcooley_ has quit IRC17:41
*** jcooley_ has joined #savanna17:42
*** akuznetsov has joined #savanna17:42
*** _nadya_ has quit IRC17:52
*** aignatov_ is now known as aignatov17:53
*** _mattf is now known as mattf17:55
SergeyLukjanovteam meeting will be in 5 mins17:59
*** alazarev has joined #savanna18:05
SergeyLukjanovirc meeting18:08
SergeyLukjanovjmaron18:08
SergeyLukjanovaignatov18:08
SergeyLukjanov^^18:08
*** NikitaKonovalov_ is now known as NikitaKonovalov18:08
aignatovSergeyLukjanov: I'm there18:08
*** DinaBelova is now known as DinaBelova_18:09
*** DinaBelova_ is now known as DinaBelova18:11
*** mst89 has joined #savanna18:17
*** NikitaKonovalov is now known as NikitaKonovalov_18:17
*** IlyaE has joined #savanna18:20
*** dmitryme has joined #savanna18:21
*** jcooley_ has quit IRC18:21
*** NikitaKonovalov_ is now known as NikitaKonovalov18:21
*** DinaBelova is now known as DinaBelova_18:23
*** akuznetsov has quit IRC18:37
*** NikitaKonovalov is now known as NikitaKonovalov_18:45
*** NikitaKonovalov_ is now known as NikitaKonovalov18:51
*** jcooley_ has joined #savanna18:58
*** ruhe_ has joined #savanna18:59
aignatovmattf: clone of what you meant?19:00
mattfmore thoughts on cancel/stop use case?19:00
mattfclone of running job. basically client can get details, let user edit and start a new job19:00
mattfthat's a useful feature anyway19:01
mattfstop becomes clone + delete old19:01
*** ylobankov1 has left #savanna19:01
aignatovwhy need to clone on 'stop'?19:01
mattfso the stop use case is to effectively "pause" a job, edit it and "unpause" (or restart)19:02
tmckayyes, that's the idea19:02
mattfit sounds like the use case has value of "start a new job" by allowing the user to avoid reentering information19:03
crobertsrhYes19:03
mattfso clone would solve this by letting the user take a running job, click clone, have prepopulated fields, make minor edits and click run/start/create19:03
mattfat that point you have the old job and the new job running. you can just delete the old one manually.19:03
aignatovbut if just don't run my old job and create new one totally different from the first?19:03
mattfthe ui could even have a clone w/ delete option19:04
tmckaymattf, it could also be used like job hold or checkpointing in condor19:04
tmckaystop it for a while, run it later, without losing the setup19:04
tmckaylong running cluster of course19:04
mattftmckay, but everyone agreed that stop was deleting the cluster in transient case19:05
tmckayyes19:05
mattfdeleting cluster wipes out the world, there's no incremental restart there19:05
crobertsrhHmm, that functionality is essentially there....you can currently "relaunch" a currently running job.19:05
crobertsrhand then just kill the original one.19:05
mattfcrobertsrh, funny that19:05
tmckaycrobertsrh, does relaunch have edit?19:06
crobertsrhYes, relaunch brings up job configs tab pre-populated with previous run19:07
tmckayso, maybe that's enough19:07
tmckaymaybe we have what we want without "cancel".  You just have to make sure you relaunch before you delete :)19:08
tmckayThat would keep the cluster from dying too, wouldn't it, in the transient case?19:08
crobertsrhYeah, that is the difference19:08
* tmckay has looked at that code, but it's been a while19:08
crobertsrhNot sure how cluster transientness is handled19:08
crobertsrhMight just be "if cluster is transient and not busy, blow it  away"19:08
crobertsrhor it might be "kill cluster after this job is done"19:09
tmckayIt's pretty simple, iirc.  Looks at active jobs19:09
* tmckay goes to look19:09
*** NikitaKonovalov is now known as NikitaKonovalov_19:09
crobertsrhMaybe I can just add another button that says "clone" (even though it points to same thing as "relaunch" :) )19:10
crobertsrhor just clarify what "relaunch" is with a better word19:10
tmckay            jc = conductor.job_execution_count(ctx,19:10
tmckay                                               end_time=None,19:10
tmckay                                               cluster_id=cluster.id)19:10
tmckay            if jc > 0:19:10
tmckay                continue19:10
tmckayso, any old job will do it looks like19:11
tmckaycrobertsrh, relaunch is probably fine, maybe just some verbage about relaunch semantics in the docs somewhere19:12
crobertsrhAs long as the job actually makes it into the cluster before you kill the first.19:12
tmckayI think that's a pretty good chance.  I can go look at what job_execution_count does, I think it's a db read...19:12
tmckayThe db write would be almost instantaneous19:12
aignatovmattf, when you have cluster with TBs of data and start writing the job for some scientific ops, let's say on pure java, with tons of configurations, and this job is running about two days/weeks or whatever. And then some research is done and you got that pig job will be more effective but it differs from pure java job and has its own set of configuration, so the simple use case: is to stop/cancel/kill old job, forget about it, nothing to clone because it'19:13
aignatovtotally uneeded for new pig job.19:13
*** DinaBelova_ is now known as DinaBelova19:14
mattfaignatov, ok, where are you headed?19:15
tmckaycrobertsrh, yes, it's literally a database count of job execution objects where end_time is Null, ie it hasn't completed yet19:15
*** NikitaKonovalov_ is now known as NikitaKonovalov19:15
crobertsrhok, I'll quit my worrying then19:16
aignatovi'd like to see just 'cancel' operation in new rest api :-)19:16
* mattf grins19:17
crobertsrhI should probably also add a "cancel" option to the job_executions in the dashboard as well....or maybe I'll call it "oops".19:17
mattfaignatov, is your concern that the TBs of data cluster was started via a transient job launch and it'll go away?19:17
mattfcrobertsrh, lol19:18
aignatovmattf, I'm talking only about long running clusters, not transient19:18
mattfin your use case, what's the difference from launching a new job against the TBs cluster?19:19
tmckayhmm, well, if you use the same output source...19:20
tmckaythen you're leaving it up to human timing.  "Probably, this will be fine, because I hit delete right after I hit submit"19:20
tmckayWorse if you have a <prep> tag that messes with your paths.  The old job might still be writing to it19:21
mattftmckay, client side you can delete before submitting new. you keep the old around long enough to get the details to save editing19:21
mattfaignatov, i've a feeling there's something to the case you're after. i'm just failing to grasp it.19:22
tmckaymattf, okay, that works.19:22
aignatovdifference is that my new job can't be created just by cloning old one and modifying few fields19:22
mattfwhat do you gain by cancel/stopping over deleting the running job on a persistent cluster?19:23
tmckayaignatov, if there is no value in the old job, why not just "delete" which means stop and erase19:23
tmckaywhat he said19:23
*** NikitaKonovalov is now known as NikitaKonovalov_19:23
* tmckay will be back soon19:24
aignatovI think stop or cancel means just shutdown map reduce tasks on cluster, but leave info about job in the savanna db, 'Delete" i see as 'stop' + 'erase'19:25
mattfbtw, there's a followup conversation on if stop/cancel should be part of the url or just a PUT (modify) w/ a new job state that the service understands19:25
aignatovwhere erase is clean of savanna db about job execution19:25
mattfaignatov, that's exactly how i see it. what i'm not seeing is why you want to care to separate stop & erase19:25
*** ruhe_ has quit IRC19:27
aignatovin my vision I can stop job at some time and erase it later and these are two separate operations19:28
*** NikitaKonovalov_ is now known as NikitaKonovalov19:28
mattfand you can stop a job and later restart it?19:29
mattfthe state graph has: PENDING -> RUNNING -> STOPPED -> PENDING ?19:29
mattfalso PENDING -> RUNNING -> DELETED and PENDING -> DELETED19:30
mattfplus * -> ERROR19:30
crobertsrhI don't think we have the means to "checkpoint" a job like that, do we?19:30
mattfthe transition to PENDING would have to mean a fresh start19:31
mattfvs RUNNING -> STOPPED -> RUNNING, which is more of a checkpoint transition19:31
crobertsrhAh....that might be an interesting addition too.19:32
crobertsrhbut not really different from relaunching as a new job_execution19:32
mattfit's probably quite possible w/ many big data frameworks, where it was a total pita for generic processes in condor19:32
*** NikitaKonovalov is now known as NikitaKonovalov_19:32
*** jcooley_ has quit IRC19:35
*** jcooley_ has joined #savanna19:36
mattfi need to scoot, bbiab19:36
*** NikitaKonovalov_ is now known as NikitaKonovalov19:38
*** NikitaKonovalov is now known as NikitaKonovalov_19:39
*** jcooley_ has quit IRC19:40
*** jcooley_ has joined #savanna19:41
tmckayI see two cases for clone.  1) add another job like one currently running, mostly the same but at least with a different output source and probably more differences19:43
tmckay2) rerun the current job with a config or 2 changed19:43
tmckayIn #1, we increase the job count19:44
tmckayIn #2, we just replace the running job.  But this is where it gets dicey if the same output data source is used, in my mind.  And if you allow it on transients, you can't delete old before you submit new because the cluster might go away in between19:45
*** jcooley_ has quit IRC19:45
tmckaycrobertsrh, ^^ what do you think?  Am I missing something?19:45
tmckayI'm not sure #2 is really possible with transients.  Unless a "stop" operation doesn't fill in the end time field.  It's not running, it just never... completed.  Then you have to delete it by hand later19:47
crobertsrhsorry...was afk for a sec19:48
*** jcooley_ has joined #savanna19:50
crobertsrhNot sure about #2....it seems to make sense to have a cloned/rerun job get a new job_ex id19:50
crobertsrhI suppose the UI could restrict use of some options on jobs that are on a transient cluster...might be confusing though.19:51
*** aignatov is now known as aignatov_19:56
*** jcooley_ has quit IRC19:56
*** jcooley_ has joined #savanna19:57
tmckaycrobertsrh, I agree, new job ex id.  I'm specifically worried about the case where the same output path is used (swift or hdfs).19:57
tmckayThe second you have two jobs exist that address the same output path, you have the potential for trouble.  Even if that potential is small, I still don't like it19:58
crobertsrhYeah, that is a potential problem.  Users definitely need to be aware there.  I specifically did NOT keep the input/output source selection for relaunched jobs for that reason.  The user needs to re-select input/output even on relaunch.19:59
*** dmitryme has quit IRC19:59
tmckayso if output is the same, that means somehow delete old before submitting new.  But deleting old before submitting new on a transient cluster means the cluster could get deleted in that split second.20:00
*** mattf is now known as _mattf20:00
crobertsrhOr, in the case of a swift output source, the user might need to handle that cleanup on their own...or have their job pre-clean the output dir20:00
tmckayAnd if you're copying old to new, editing new, deleting old, submitting new, that's got to be orchestrated through the interface and indicated by the user20:01
tmckayright20:01
tmckayThis is where "stop" to leave a job in limbo, do what you need to to, and delete it later may be a good option.  Certainly seems simpler from the UI side.20:02
*** _mattf is now known as mattf20:02
crobertsrhI agree20:02
tmckayI think we need a way to mark a job "undead"20:03
tmckayto cease action but preserve the cluster20:04
crobertsrhDoes oozie have a mechanism to pause a job?20:06
tmckaythat one, I don't know.  Pretty easy to check the client, though.20:07
*** _nadya_ has joined #savanna20:09
crobertsrhLooks like there is a SUSPEND state you can put a workflow into20:10
tmckayManaging a Job  -- A HTTP PUT request starts, suspends, resumes or kills a job.20:10
tmckay:)20:10
tmckayso there you go.  For a transient cluster with relaunch, I suspect what we really want is suspend, submit, delete suspended20:11
*** jcooley_ has quit IRC20:12
crobertsrhYep20:12
*** jcooley_ has joined #savanna20:12
tmckayIf Oozie can do suspend/resume, not sure why Savanna shouldn't20:15
crobertsrhYeah, seems like something we should definitely have.20:17
*** alazarev has quit IRC20:21
tmckayhmm, suspend is talked about together with something called bundles.  I'll have to look more20:22
*** mst89 has quit IRC20:23
*** _nadya_ has quit IRC20:24
*** eanxgeek has joined #savanna20:31
tmckaycrobertsrh, okay, it apparently applies at multiple levels. http://oozie.apache.org/docs/3.1.3-incubating/DG_CommandLineTool.html#Suspending_a_Workflow_Coordinator_or_Bundle_Job.20:36
tmckayThe advantage I see of suspend over "cancel" (ie KILL) is that the end_time I assume isn't filled in, so it counts as an active job in the savanna execution count20:37
crobertsrhPretty nifty20:37
* tmckay goes to work on something more well defined, like dotted names :)20:37
tmckaycrobertsrh, well, duh, even without any end_time semantics, the state becomes "suspended".20:38
tmckaySo that could be tested for20:38
crobertsrhright :)20:38
tmckayCase of the Thursdays, lol.  I think there is a case for every day, eventually...20:39
crobertsrhI'd take a case of the Saturdays.20:40
*** alazarev has joined #savanna20:41
*** alazarev has quit IRC20:41
tmckaybah, my alembic migration is still on the wrong branch somehow.  Darn this distributed development!20:42
tmckay;-)20:42
tmckaytime to start this bad boy from master20:43
mattf<tmckay> If Oozie can do suspend/resume, not sure why Savanna shouldn't20:43
mattf<crobertsrh> Yeah, seems like something we should definitely have.20:43
mattfwe may not always have oozie as our interface, e.g. the spark addition inbound20:43
tmckaymattf, that's a valid point20:44
mattfbegs the question tho, should spark be added to oozie?20:44
crobertsrhAh, I did not realize we had Spark coming20:44
tmckaymattf, does oozie have spark actions?20:45
mattfi dunno20:45
crobertsrhI'm looking for that right now :)20:46
tmckaymattf, so if you read back, there's still something troubling me.  It's relaunch on transient with the same output path.20:46
mattfhttp://comments.gmane.org/gmane.comp.lang.scala.spark.user/141720:46
mattf'Having said that, it is fairly easy to leverage oozie to launch spark20:46
mattfjobs - using the java action."20:46
crobertsrhsame thing I was reading :)20:46
tmckaymattf, ah, yes, I was thinking java action...20:47
* mattf hi5 crobertsrh 20:47
crobertsrhhooray google20:47
tmckayshoot, in java actions, we can do *stinkin* anything20:47
mattfit's the escape hatch20:47
mattfenter w/ caution20:47
tmckaymattf, I was thinking that "suspend" was a good way to stop a job without losing the cluster, submit the new one, then follow with "kill"20:48
tmckayno windows for badness20:49
mattfimho, as long as we're not making a new endpoint for cancel/stop/suspend and we're going the HTTP PUT to status field direction, we're in good shape and can add the feature later20:49
*** eanxgeek is now known as eanxgeek|log20:50
mattf^^ kinda the middle ground in my mind, since i still can't see the use case that needs cancel20:50
tmckayokay, I agree.  Do we have a HTTP Put for status in the CR?  I don't recall one...20:50
mattfwe do not, i can file one20:50
mattfaignatov_, thoughts?20:51
tmckayokay.  That would be great.  Then we can do anything we need to under the hood with the oozie client20:51
*** NikitaKonovalov_ is now known as NikitaKonovalov21:02
openstackgerritTrevor McKay proposed a change to openstack/savanna: Remove extra Java job type fields from JobExecutions  https://review.openstack.org/7042021:09
*** DinaBelova is now known as DinaBelova_21:25
*** jcooley_ has quit IRC21:28
*** jcooley_ has joined #savanna21:29
tmckaycrobertsrh, if https://review.openstack.org/#/c/70810/ is done let's take it out of work in progress21:41
crobertsrhWe will need the python-savannaclient updated as well.  Is that on tap?21:41
crobertsrhI took it out of WIP21:42
tmckayyeah, moving that out of WIP too.  We just have to bite the bullet and request a merge of all at the same time21:42
crobertsrhActually, it might still work even with the old client21:42
tmckayyeah, removing job_exec_data isn't strictly necessary.21:43
crobertsrhexactly21:43
tmckayyay, no more WIP changes21:47
*** mst89 has joined #savanna21:49
*** crobertsrh is now known as _crobertsrh21:52
*** IlyaE has quit IRC22:08
openstackgerritTrevor McKay proposed a change to openstack/savanna: Add utilities for supporting dotted job types  https://review.openstack.org/7138722:09
*** NikitaKonovalov is now known as NikitaKonovalov_22:11
*** IlyaE has joined #savanna22:14
*** tmckay is now known as _tmckay22:35
mattfSergeyLukjanov, fyi, i just finished a pass over the i3 milestone23:34
openstackgerritAndrew Lazarev proposed a change to openstack/savanna: [IDH] Fixed cluster start without jobtracker service  https://review.openstack.org/7168923:43

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!