Wednesday, 2015-06-03

*** egafford has joined #openstack-sahara00:08
*** shakamunyi has joined #openstack-sahara00:12
*** barra204 has joined #openstack-sahara00:12
*** egafford has quit IRC00:27
*** superfly_ has joined #openstack-sahara01:12
*** superfly_ is now known as superflyy01:14
*** barra204 has quit IRC01:24
*** shakamunyi has quit IRC01:24
*** superflyy has quit IRC01:24
*** hdd has joined #openstack-sahara01:55
*** Networkn3rd has joined #openstack-sahara01:58
*** robsparker has joined #openstack-sahara02:23
*** Networkn3rd has quit IRC02:40
*** egafford has joined #openstack-sahara03:17
*** robsparker has quit IRC03:26
*** hdd has quit IRC03:39
*** Longgeek_ has quit IRC03:53
*** Longgeek has joined #openstack-sahara03:54
*** sgotliv has joined #openstack-sahara03:55
*** Longgeek_ has joined #openstack-sahara03:57
*** Longgeek has quit IRC04:00
*** egafford has quit IRC04:01
*** Longgeek has joined #openstack-sahara04:02
*** Longgeek_ has quit IRC04:04
*** Longgeek_ has joined #openstack-sahara04:08
*** Longgeek has quit IRC04:10
*** Longgeek_ has quit IRC04:12
*** Longgeek has joined #openstack-sahara04:18
*** Longgeek has quit IRC04:18
*** Longgeek has joined #openstack-sahara04:19
*** Longgeek has quit IRC04:20
*** Longgeek has joined #openstack-sahara04:20
*** Longgeek_ has joined #openstack-sahara04:23
*** Longgee__ has joined #openstack-sahara04:25
*** Longgeek has quit IRC04:25
*** Longgeek_ has quit IRC04:26
*** Longgeek has joined #openstack-sahara04:26
*** hdd has joined #openstack-sahara04:26
*** Longgeek_ has joined #openstack-sahara04:28
*** Longge___ has joined #openstack-sahara04:29
*** Longgee__ has quit IRC04:30
*** coolsvap|afk is now known as coolsvap04:30
*** coolsvap is now known as coolsvap|afk04:31
*** Longgeek has quit IRC04:32
*** coolsvap|afk is now known as coolsvap04:32
*** Longgeek_ has quit IRC04:32
*** nkrinner has joined #openstack-sahara05:03
*** robsparker has joined #openstack-sahara05:25
*** robsparker has quit IRC05:29
openstackgerritKen Chen proposed openstack/sahara: Add CDH5.4 support in sahara  https://review.openstack.org/17766005:32
*** hdd has quit IRC05:34
*** sgotliv has quit IRC06:15
*** shakamunyi has joined #openstack-sahara06:16
*** barra204 has joined #openstack-sahara06:17
openstackgerritKen Chen proposed openstack/sahara: Transform configuration values into int or float when needed  https://review.openstack.org/18744406:34
*** Longgeek has joined #openstack-sahara06:35
*** Longge___ has quit IRC06:37
openstackgerritlu huichun proposed openstack/sahara-specs: Add scheduling and recurring oozie workflow to EDP jobs  https://review.openstack.org/17571907:17
openstackgerritlu huichun proposed openstack/sahara-specs: Add scheduling and recurring oozie workflow to EDP jobs  https://review.openstack.org/17571907:22
*** chlong has quit IRC07:37
*** coolsvap is now known as coolsvap|afk07:41
*** coolsvap|afk is now known as coolsvap07:46
*** sgotliv has joined #openstack-sahara07:47
*** witlessb has joined #openstack-sahara07:52
*** esikachev has joined #openstack-sahara08:50
*** nkrinner has quit IRC08:52
*** nkrinner has joined #openstack-sahara08:57
*** pino|work has joined #openstack-sahara08:57
*** tellesnobrega has quit IRC09:07
*** tosky_ has joined #openstack-sahara09:09
*** witlessb has quit IRC09:38
*** witlessb has joined #openstack-sahara09:40
openstackgerritEvgeny Sikachev proposed openstack/sahara: Added method for connect to node and run command  https://review.openstack.org/18541909:51
*** tellesnobrega has joined #openstack-sahara10:02
*** robsparker has joined #openstack-sahara10:25
*** robsparker has quit IRC10:31
*** sudipto has joined #openstack-sahara10:41
*** sudipto has quit IRC10:42
*** sudipto has joined #openstack-sahara10:43
*** sudipto has quit IRC10:44
*** esikachev has quit IRC11:01
*** sudipto has joined #openstack-sahara11:07
sudiptoHi, can anyone please tell me if libguestfs is a must for sahara to inject ssh keys?11:08
SergeyLukjanovsudipto, hi, which version of sahara are you using?11:16
sudiptoSergeyLukjanov, I am using the Kilo one.11:17
*** esikachev has joined #openstack-sahara11:18
SergeyLukjanovsudipto, we're using user data script to push keys // https://github.com/openstack/sahara/blob/master/sahara/service/engine.py#L16611:19
SergeyLukjanovsudipto, so, I think guestfs is not needed for it11:19
SergeyLukjanovand user key is passed as a parameter for instance creation https://github.com/openstack/sahara/blob/master/sahara/service/direct_engine.py#L36311:21
openstackgerritEvgeny Sikachev proposed openstack/sahara: Added method for connect to node and run command  https://review.openstack.org/18541911:22
sudiptoSergeyLukjanov, Thanks. During my deployments - Sahara would not be able to login to the VMs at all, I observed the guestfs errors in the logs. So i thought it might be dependent on that.  Libguestfs had issues on my nodes.11:24
sudiptoguestfs errors in the nova logs to be precise.11:24
SergeyLukjanovsreshetnyak, ^^ any thoughts?11:24
tosky_sudipto: which kind of errors?11:26
tosky_sudipto: can you run instances from those images directly from nova? I think it may be unrelated to Sahara11:26
sudiptotosky_, Let me get the exact details. I have destroyed my environment and re-building it again.11:27
tosky_sudipto: also, which platform is running on the OS, and which distribution on images?11:27
sudiptotosky_, If i enable the config drive in nova - I am able to work on a standalone deploy using the ssh key11:27
sudiptotosky_, but when i deploy the VMs using sahara...the sahara logs show that it's unable to login to the VMs.11:27
sudiptotosky_, the platform is Power and the distribution is Fedora.11:28
sudiptotosky_, Let me re-run my setup again and get back with all the details needed...11:28
SergeyLukjanovtosky_, I'd like to collect your feedback on extracting scenario tests to separate repo to make installable, packageable, add CLI and release it separately with backward compat for at least 1-2 OpenStack releases11:34
SergeyLukjanovtosky_, I'm now working on a detailed spec, but it's the main changes I'm thinking about so far11:35
*** robsparker has joined #openstack-sahara11:41
*** sudipto has quit IRC11:58
tosky_SergeyLukjanov: I think splitting is a good idea; regarding the supported versions, I would consider at least the same deadlines that Tempest considers, if no more12:03
SergeyLukjanovtosky_, yup, most probably it should be the same as tempest from the support PoV12:04
*** sgotliv has quit IRC12:09
*** sgotliv has joined #openstack-sahara12:12
*** tmckay has quit IRC12:18
openstackgerritAndrey Pavlov proposed openstack/sahara: Changing log level inside execute_with_retries method  https://review.openstack.org/18797812:20
*** robsparker has quit IRC12:34
*** _crobertsrh is now known as crobertsrh12:54
*** nkrinner has quit IRC13:15
*** tmckay has joined #openstack-sahara13:19
*** tmckay has quit IRC13:19
*** tmckay has joined #openstack-sahara13:20
*** robsparker has joined #openstack-sahara13:22
openstackgerritEvgeny Sikachev proposed openstack/sahara: Added method for connect to node and run command  https://review.openstack.org/18541913:28
*** hdd has joined #openstack-sahara13:30
openstackgerritVitaly Gridnev proposed openstack/sahara: Implement recommendations for vanilla 2.6.0  https://review.openstack.org/17728013:35
openstackgerritVitaly Gridnev proposed openstack/sahara: Implement recommendations for vanilla 2.6.0  https://review.openstack.org/17728013:39
*** rnowling has joined #openstack-sahara13:39
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/sahara-specs: Allow multiple clusters creation simultaneously  https://review.openstack.org/18801113:53
*** egafford has joined #openstack-sahara13:58
*** egafford has quit IRC13:58
*** egafford1 has joined #openstack-sahara13:58
openstackgerritVitaly Gridnev proposed openstack/sahara: [Spark] Add recommendation about dfs.replication  https://review.openstack.org/18759013:59
*** coolsvap is now known as coolsvap|afk14:00
*** hdd has quit IRC14:05
*** tmckay has quit IRC14:07
*** tmckay has joined #openstack-sahara14:07
*** esikachev has quit IRC14:08
*** tmckay has joined #openstack-sahara14:11
*** tmckay has joined #openstack-sahara14:12
*** tmckay has left #openstack-sahara14:12
*** tmckay has joined #openstack-sahara14:13
*** tmckay has quit IRC14:17
*** tmckay has joined #openstack-sahara14:17
*** tmckay has quit IRC14:18
*** Networkn3rd has joined #openstack-sahara14:19
*** tmckay has joined #openstack-sahara14:19
openstackgerritVitaly Gridnev proposed openstack/sahara: [CDH] Load missed configs from yarn-gateway.json  https://review.openstack.org/18717914:20
openstackgerritVitaly Gridnev proposed openstack/sahara: Support recommendations in CDH plugin  https://review.openstack.org/18537114:20
openstackgerritVitaly Gridnev proposed openstack/sahara: [CDH] Load missed configs from yarn-gateway.json  https://review.openstack.org/18717914:22
*** barra204 has quit IRC14:36
*** shakamunyi has quit IRC14:36
*** raildo has joined #openstack-sahara14:39
*** hdd has joined #openstack-sahara14:41
egafford1crobertsrh, NikitaKonovalov: ping14:50
crobertsrhyes?14:50
egafford1Hi Chad. I was wondering first about whether you'd thought at all about how you'd like the UI for the Job Interface Map story to work, and secondly, whether you see a purpose for storing the execution arguments as data rows. In implementation, I've found that the JobExecutionArguments table is pretty vestigial.14:52
egafford1Don't want to remove it, though, without talking to UI folks, in case you think there's a solid point in favor from a presentation standpoint. I can scrounge you links on the subject if you need a refresher, or just answer questions.14:53
crobertsrhIt's been on my todo list for awhile, but I haven't yet had any strokes of genius.  I need to go through that spec again.  Do you have any ideas?14:53
egafford1Well, on the job side, it seems reasonably straightforward if not easy to implement; we need some manner of table with little + buttons to add more rows, little - buttons to remove them, etc.14:54
*** robsparker has quit IRC14:54
crobertsrhTo answer the other question though, I'm not sure I can see a reason for having execution arguments stored as data rows.14:56
egafford1On the execution side, though, because the execution object is frozen when it gets to the EDP engine, there's not a clean way to merge in place when the job is ready to run without updating the object, so we don't really gain any record keeping power (as I was hoping) by having the execution arguments table and I'm thinking of dropping it for simplicity.14:56
egafford1Yeah, the execution arguments can always be reconstituted from the merged job_configs json and the interface in a pinch.14:56
crobertsrhRight.  I think that makes sense.  Simplicity is probably the way to go there.14:57
egafford1Agreed. Thanks crobertsrh.14:57
crobertsrhWell...for job relaunch, we do need to be able to get the arguments14:58
crobertsrhSo, I suppose there needs to be a reasonably efficient way to make that happen.14:58
crobertsrhegafford1:  Does that change anything? ^^^15:03
egafford1crobertsrh: Well, we'll have the merged, eventual argument set (that the job actually ran with,) and we'll still have the interface itself, so we can throw the form back up if we want to.15:05
egafford1That feels to me like enough, but whether that is enough is very precisely the question. :)15:05
crobertsrhOk, that question came mostly from me not having read through things in awhile.15:05
egafford1No, it's a reasonable question.15:05
*** esikachev has joined #openstack-sahara15:06
openstackgerritEvgeny Sikachev proposed openstack/sahara: Added method for connect to node and run command  https://review.openstack.org/18541915:09
egafford1elmiko: API question: I'm strongly considering dropping the JobExecutionArguments table in the unified job interface map story, which would naturally result in dropping that from the GET for job executions (and just representing the final configuration state.) Many folks have many beliefs about what makes an API RESTful, but one such belief I've heard from time to time is that the resource that you GET is the resource that15:13
elmikoegafford1: resource that....?15:15
egafford1elmiko: ...you GET is the resource that you PUT. Do we have such scruples here, or is it perfectly fine by the API WG's standards to drop some input fields from the output when necessary (just as we inevitably add new fields to the output?)15:16
elmikohmm15:16
egafford1Just trying to assess which flavor of RESTafarians we are.15:16
elmikoso far, the api-wg has mainly addressed request methods and the proper usage of them. there aren't any guidelines yet as to content. i think that is solidly in the developers hands at this point.15:17
egafford1The data that you provide will come back to you under the new model; it'll just be munged into the normal job_configs json. Okay, cool. If it's solidly in my hands, I'll run with it. Thanks elmiko.15:17
elmikoin general though, i think folks would agree with you. i would expect the resrouce i PUT to be returned in the response, but i don't think that is a hard rule.15:17
egafford1elmiko: Right, I've thought of it as a good guideline to follow in almost all cases. Here, though, on review, I don't think any purpose is served by not just returning the job_configs.15:19
elmikoegafford1: i think the JobExecutionArguments table makes a great deal of sense if we consider the possibility of an endpoint just for that resource15:20
elmikootherwise, i think it would be ok to return what the final job config looks like. i dunno, this is a tough question.15:20
egafford1The execution is frozen by the time it gets to the edp job manager (where I was hoping to do the merge to avoid committing the merge to the execution object,) so I have to update in order to prevent the edp api from becoming more complex.15:21
egafford1Well, I can definitely see a case for a JobInterfaceArgument resource, easy. I have trouble seeing a JobExecutionArgument resource unless we just go crazy with the resources.15:22
elmikoi don't remember, because i need to read the spec again, but it might be worthwhile to have an /job-execution/{j-e id}/arguments resource that could be manipulated?15:22
egafford1I don't think so; job-executions are the one resource that can't be edited.15:22
elmikook, maybe i just misinterpretted. JobInterfaceArgument makes sense15:22
elmikoi'm a little off on the specifics, but i think you get my gist15:23
egafford1(And really shouldn't be.) They can be replayed, but not edited. Yeah, the interface args are ABSOLUTELY a resource-ready model. I do; I think we're in broad agreement on both the ideal and the reasonable.15:23
elmikook, cool15:23
elmikosorry for munging the details so badly15:24
openstackgerritEthan Gafford proposed openstack/sahara-specs: Removing JobExecutionArgument Table  https://review.openstack.org/18804715:25
egafford1elmiko: It is utterly not your job to know the intimate details of everything I'm working on right right now. :) Thanks for the counsel; it's great to have an OS API authority on tap.15:34
egafford1I think the terminology change around job_templates/job_executions/jobs probably can't have helped recollection of the details either, but, hey, that's what v2 is for.15:35
openstackgerritDenis Egorenko proposed stackforge/sahara-ci-config: Rename all plugins to full plugin version  https://review.openstack.org/18805315:36
*** Networkn3rd has quit IRC15:37
elmikoegafford1: yea, i feel like i should have remembered more details. and yea, those route changes are in my first pass lineup for v2.15:38
egafford1elmiko: Well, if you had remembered all the details, I'd be moderately amazed at you. And +1 for those changes.15:40
elmikolol!15:40
openstackgerritDenis Egorenko proposed stackforge/sahara-ci-config: Rename all plugins to full plugin version  https://review.openstack.org/18805315:43
*** esikachev has quit IRC16:01
*** jamielennox is now known as jamielennox|away16:21
*** barra204 has joined #openstack-sahara16:21
*** barra204 has quit IRC16:28
openstackgerritShilla Saebi proposed openstack/sahara: made a number of changes to sahara docs  https://review.openstack.org/17752316:50
*** Longgeek has quit IRC16:55
openstackgerritMerged openstack/sahara: [CDH] Load missed configs from yarn-gateway.json  https://review.openstack.org/18717917:00
openstackgerritSergey Reshetnyak proposed openstack/sahara: Fix problem with removing PID from list  https://review.openstack.org/18715517:09
openstackgerritEthan Gafford proposed openstack/sahara: [WIP][EDP] Unified Map to Define Job Interface  https://review.openstack.org/18780917:13
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/sahara-specs: Allow multiple clusters creation simultaneously  https://review.openstack.org/18801117:25
openstackgerritOpenStack Proposal Bot proposed openstack/sahara: Updated from global requirements  https://review.openstack.org/18810217:39
*** Networkn3rd has joined #openstack-sahara17:44
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/sahara-specs: Allow multiple clusters creation simultaneously  https://review.openstack.org/18801117:47
tmckayegafford1, setting up a stack to give your job stuff a whirl17:49
elmikotmckay: i take it the grid0/1 stuff worked?17:49
openstackgerritOpenStack Proposal Bot proposed openstack/sahara: Updated from global requirements  https://review.openstack.org/18810217:49
tmckayelmiko, heh, still in progress17:49
elmikoah ok, just getting my hopes up =)17:50
tmckayI just tossed up an allinone on one of the machines so I could whack at ethan's patch17:50
tmckayelmiko, I am still hoping for this week, but I've been remiss on reviews and the job mapping seems like a good one to focus on17:50
tmckayit's all about balance ;-)17:50
elmikooh yea, no questions from me. i was just curious given our pre-lunch conversation.17:53
elmikoi thought you might be close to a "eureka" moment ;)17:54
openstackgerritVitaly Gridnev proposed openstack/sahara: Implement recommendations for vanilla 2.6.0  https://review.openstack.org/17728017:56
openstackgerritVitaly Gridnev proposed openstack/sahara: Support recommendations in CDH plugin  https://review.openstack.org/18537117:56
elmikoSergeyLukjanov: ping17:58
*** sgotliv has quit IRC18:02
openstackgerritVitaly Gridnev proposed openstack/sahara: Remove WritableLogger wrapper  https://review.openstack.org/18813018:05
*** hdd has quit IRC18:06
openstackgerritVitaly Gridnev proposed openstack/sahara: Remove deprecated group name of option  https://review.openstack.org/18813218:11
openstackgerritMichael McCune proposed openstack/sahara-specs: Reworking improved secret storage spec  https://review.openstack.org/17939318:14
*** hdd has joined #openstack-sahara18:21
*** Networkn3rd has quit IRC18:37
*** stanchan has joined #openstack-sahara18:40
*** witlessb has quit IRC18:50
*** witlessb has joined #openstack-sahara18:52
elmikoegafford1: i just want to understand https://review.openstack.org/#/c/188047 a little better18:54
*** hdd has quit IRC18:54
elmikoegafford1: so, the actual execution arguments won't be stored in the db?18:54
elmikothey will be parsed/aggregated and stored as the true configs?18:55
*** Networkn3rd has joined #openstack-sahara18:56
*** barra204 has joined #openstack-sahara18:57
*** Networkn3rd has quit IRC19:00
*** Networkn3rd has joined #openstack-sahara19:00
*** barra204 has quit IRC19:02
*** hdd has joined #openstack-sahara19:03
egafford1elmiko: That's correct; the execution args will be folded into their final form in the config map for storage.19:11
egafford1The arguments can always be reconstituted from their locations if desired. We'll lose whether the user passed in the argument via the interface or the map, but that's all we lose.19:12
elmikoegafford1: ok, thanks. just wanted to make sure i understood19:13
egafford1elmiko: In order to fold relatively seamlessly into the current edp job runner, the configs had to all be updated into the execution object's job_configs attribute anyway, so there didn't seem to be much upside in storing them all twice.19:14
egafford1elmiko: So while I was planning on merging just pre-run, I ended up pulling the merge of the interface back to the initial execution storage. Do you have concerns about removing the execution args table?19:16
egafford1elmiko: Apparently not. :)19:17
*** Networkn3rd has quit IRC19:17
elmikoegafford1: yea, not really. i just want to better understand the problem space19:19
egafford1elmiko: Solid.19:22
egafford1Basically, I ran into "the job execution is frozen when it gets to the executor, so I can either jump through a bunch of hoops and clutter the executor's interface or pre-merge the configs". Pre-merging the configs was a lot cleaner, and once I did that, I was well below my indifference curve on the existence of the execution_args table (which was already kind of pushing it, as without a join the presentation was just a bu19:24
elmikoyea, makes total sense19:24
elmikono need to clutter up the db with more stuff when it's a wash in the ned19:24
elmikoend19:24
egafford1And the ned.19:25
egafford1They both work.19:25
elmikolol19:25
elmikoahh ned19:25
egafford1It's always a wash in that guy.19:25
elmikolol19:25
*** Networkn3rd has joined #openstack-sahara19:51
*** barra204 has joined #openstack-sahara19:58
*** barra204 has quit IRC20:03
htrutahi guys! do you know something about this bp https://blueprints.launchpad.net/sahara/+spec/ceilometer-integration ?20:08
htrutaI mean, it is marked as complete, but looks like we don't have any sahara metrics collected by ceilometer... only the cluster events20:09
elmikohtruta: hmm, i dunno. looks like the patches were abandonned20:11
htrutaelmiko: so, that's all sahara sends to ceilometer?20:14
elmikohtruta: not sure, i don't know much about what sahara sends to sahara20:15
elmikolooks like this patch, https://review.openstack.org/#/c/108982/ , made it through20:15
htrutaelmiko: yes... that's the one which sends the cluster events20:16
elmikothat might be all, i'm not 100% sure on our ceil. integration20:16
htrutaelmiko: ok20:23
htrutawhat about some sort of internal cluster performance monitoring20:23
htrutadoes sahara do that?20:23
elmikothere are some reviews up for cluster health checks,20:23
elmikobut i don't think they touch on performance20:23
elmikohttps://review.openstack.org/#/c/175363/20:24
elmikothat's the spec20:24
elmikohtruta: what kind of performance data are you thinking about?20:24
htrutaelmiko: I'll take a look at the spec20:29
htrutaI'm talking about some plugin specific metrics...20:30
htrutamap/reduce tasks, throughput...20:30
htrutain the hadoop example20:30
elmikook, yea. i don't think we have much in sahara for that. it might be that ambari and cloudera manager expose that type of info20:30
elmikocertainly sounds cool though =)20:31
openstackgerritVitaly Gridnev proposed openstack/sahara: Support recommendations in CDH plugin  https://review.openstack.org/18537120:35
htrutaelmiko: cool. I need to take a look in Ambari, then20:40
elmikohtruta: i think only the hdp plugin supports ambari, but i might be wrong about that.20:40
htrutajust made a quick grep here, and I guess you're not wrong20:41
elmikoi think we might be able to build some simple metrics based on the start/stop time for jobs20:42
*** egafford1 has quit IRC20:46
htrutaelmiko: wouldn't it be the job execution finish time?20:52
htrutamy big picture is looking at the job at runtime and get some metrics to see if we can make it faster20:54
elmikohtruta: yea, my bad, job execution20:54
htrutaby using, for example, opportunistic instances (cc tellesnobrega )20:54
htrutaor in the future, vm migrations20:54
elmikoi think the topic has rich possibilities for features we could implement20:55
tellesnobregaelmiko, +120:55
tellesnobregaif we push this through we have to detail a roadmap and where we want to arrive (what we need in the end)20:57
tellesnobregaso we can decide milestones and work an implementation plan20:58
elmikodefinitely20:59
*** Networkn3rd has quit IRC21:00
*** Networkn3rd has joined #openstack-sahara21:01
*** stanchan has quit IRC21:04
alazarevtmckay, hi, are you here?21:06
tmckayalazarev, hi21:06
alazarevtmckay, I'm trying to make a demo with spark EDP21:07
alazarevtmckay, and it looks like all examples print to stdout which is lost21:07
alazarevtmckay, what did you use to test spark-swift integration (you did it, right?)21:07
tmckayalazarev, yeah, hmm.  I think I read something in, don't remember if I output something.  I'll take a look.  And, if I can't find it, I have some colleagues doing spark stuff, I'm sure I can get some help from them.21:09
tmckayalazarev, I understand you want output for the demo.  For your own debug, you can see stdout if you go to the spark master node in the cluster and look in /tmp/spark-edp21:09
tmckayall the files for you job will be there.  Including a log file showing the command, so you can rerun by hand :)21:10
tmckayalazarev, I have to run, I'21:10
alazarevtmckay, I can make custom job (e.g. using "Word Count" from https://spark.apache.org/examples.html), but I thought there is something standard21:10
tmckayI'll look for my spark example tomorrow.  Shouldn't be too hard to write something to swift21:10
tmckayalazarev, not sure we have a standard example -- first example was sparkPi, which pre-dated swift integration21:11
tmckaywe probably should add a swift example21:11
alazarevtmckay, I'm surprized that all spark examples from jar file with spark don't write to file21:13
alazarevtmckay, the only exeption is web page PageRank which is a little bit overkill for demo21:13
tmckayalazarev, ah, found some notes.  I used org.apache.spark.examples.SparkHdfsLR and created some silly data, put it in swift://tmckay.sahara/data21:15
tmckayI think I also used WordCount21:15
tmckaysince the swift integration depended on authentication and use of the hadoop openstack jar, I didn't test output21:15
tmckayJust a read.  Should be the same case.21:16
tmckayalazarev, you're right, though, we really should have an example with input/output21:16
tmckayeven modifying WordCount to write results to a path instead of stdout would be good21:16
*** rnowling has quit IRC21:17
*** tmckay has left #openstack-sahara21:17
*** jamielennox|away is now known as jamielennox22:20
*** barra204 has joined #openstack-sahara22:48
*** htruta_ has joined #openstack-sahara22:49
*** barra204 has quit IRC22:53
*** witlessb has quit IRC23:09
*** pino|work has quit IRC23:11
*** chlong has joined #openstack-sahara23:19
*** hdd has quit IRC23:26
*** hdd has joined #openstack-sahara23:33
*** tellesnobrega has quit IRC23:40
*** hdd has quit IRC23:55
*** tosky_ has quit IRC23:57

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