Wednesday, 2013-07-31

*** openstack has joined #savanna17:19
*** IlyaE has joined #savanna17:20
*** dina_belova has quit IRC17:20
*** dina_belova has joined #savanna17:23
*** ruhe has quit IRC17:28
*** NikitaKonovalov has joined #savanna17:29
SergeyLukjanovthat's the first message in #savanna at eavesdrop17:32
*** NikitaKonovalov has quit IRC17:34
*** ChanServ changes topic to "Savanna project (Hadoop on OpenStack) - http://savanna.rtfd.org; channel logs: http://eavesdrop.openstack.org/irclogs/%23savanna/; discussions in this (#savanna) channel; weekly meetings on Thursdays at 18:00 UTC in #openstack-meeting-alt channel"17:35
*** NikitaKonovalov has joined #savanna17:38
*** mattf is now known as _mattf17:49
*** NikitaKonovalov has quit IRC17:51
*** _mattf is now known as mattf17:53
*** rnirmal has joined #savanna18:07
*** dina_belova has quit IRC18:49
*** NikitaKonovalov has joined #savanna18:51
openstackgerritJonathan Maron proposed a change to stackforge/savanna: Fix to convert parsing failure  https://review.openstack.org/3955318:51
*** dina_belova has joined #savanna18:52
*** NikitaKonovalov has quit IRC18:55
*** dmitryme has quit IRC19:03
tmckayrhHey savanna folks, crobertsrh and I have been chatting about job source things and were looking at https://etherpad.openstack.org/savanna_API_draft_EDP_extensions19:15
tmckayrhOn the example Job Source Object that is shown there, type is "Hive".  I think that's not correct -- Hive is a type of job, not a type of Job Source (meaning a place where jobs are retrieved from)19:16
SergeyLukjanovtmckayrh, yes, I think it's correct19:17
tmckayrhTwo thoughts:  Maybe we should rename Job Source to something else (Job Depot, Job Store, Job Repository, etc) so that "Job Source" meaning actual runtime code for a job is not confused with "Job Source" meaning where it is stored19:17
tmckayrhhmm, forgot my second thought19:20
tmckayrhOkay, so job source type should be something like "git", "internal", "swift", "hdfs", "mercurial", etc -- something that makes it easier to map to a plugin, maybe?19:22
tmckayrhAnd I suppose for "SCM" type solutions like git, mercurial, svn, cvs, etc it makes sense to break them out as separate distinct types rather than just "SCM" because they have to be subclassed at some point anyway.19:23
*** SergeyLukjanov has quit IRC19:24
crobertsrh+1 for separating them out19:24
tmckayrhwoohoo, +1!  I need to save those up, maybe I can trade them in for something19:25
*** SergeyLukjanov has joined #savanna19:27
openstackgerritJonathan Maron proposed a change to stackforge/savanna: Fix to convert parsing failure  https://review.openstack.org/3955319:28
SergeyLukjanovtmckayrh, crobertsrh, I think that there are good ideas, let's discuss them on tomorrows meeting19:30
tmckayrhSergeyLukjanov, crobertrh, ack, I have updated https://etherpad.openstack.org/savanna_API_draft_EDP_extensions with notes based on ^^19:32
tmckayrhI think maybe the terminology is not always clear.  "Source" is overloaded19:32
*** dina_belova has quit IRC19:33
openstackgerritJonathan Maron proposed a change to stackforge/savanna: Fix to convert parsing failure  https://review.openstack.org/3955319:36
tmckayrh SergeyLukjanov, crobertsrh, also note that there maybe is a conflict in the sequence diagram vs the blueprint.  On execution, when job executable code needs to be retrieved, does the job  manager component synthesize information from the job object and job source object to do the code retrieval itself (what the sequence says) or does the job manager pass the id from the job object to the job source component and it does the retrieval f19:41
tmckayrhI think the second.  I think job manager should call job source component and say "give me this job from this source"19:41
tmckayrhIf that's true, I should update the diagram19:42
*** IlyaE has quit IRC19:45
*** NikitaKonovalov has joined #savanna19:48
crobertsrhtmckahrh:  that might be the right thing to do19:49
tmckayrhcrobertsrh, yes, because otherwise the job manager component will have to have knowledge of job retrieval plugins.  Doesn't seem right.19:50
crobertsrhYes, that would be poor19:50
tmckayrhSo it's maybe an extra hop between components, but it's better design and encapsulation.  I think it was still a little fuzzy when I made the diagram19:51
*** NikitaKonovalov has quit IRC19:52
*** dina_belova has joined #savanna20:04
*** dina_belova has quit IRC20:09
*** SergeyLukjanov has quit IRC20:12
*** qwerty_nor has quit IRC20:15
*** dmitryme has joined #savanna20:18
*** dmitryme has quit IRC20:29
*** benl has joined #savanna20:31
*** dina_belova has joined #savanna20:44
*** NikitaKonovalov has joined #savanna20:48
*** dina_belova has quit IRC20:49
*** NikitaKo_ has joined #savanna20:51
*** NikitaKonovalov has quit IRC20:51
*** crobertsrh is now known as _crobertsrh20:54
*** NikitaKo_ has quit IRC20:56
*** IlyaE has joined #savanna21:11
*** IlyaE has quit IRC21:22
*** aignatov has quit IRC21:42
*** aignatov has joined #savanna21:43
*** dina_belova has joined #savanna21:46
*** dina_belova has quit IRC21:50
*** tstclair is now known as _tstclair22:00
*** mattf is now known as _mattf22:17
*** rnirmal has quit IRC22:33
*** dina_belova has joined #savanna22:47
*** lastidiot has quit IRC22:48
*** NikitaKonovalov has joined #savanna22:52
*** dina_belova has quit IRC22:52
*** NikitaKonovalov has quit IRC22:56
*** benl has quit IRC23:00
*** lastidiot has joined #savanna23:46
*** NikitaKonovalov has joined #savanna23:53
*** NikitaKonovalov has quit IRC23:58

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