<div dir="ltr"><div>I see two points:</div><div>* having Savanna types mapped to Oozie action types is intuitive for hadoop users and this is something we would like to keep</div><div>* it is hard to distinguish different kinds of one job type</div>
<div><br></div><div>Adding 'subtype' field will solve both problems. Having it optional will not break backward compatibility. Adding <span style="font-family:arial,sans-serif;font-size:13px">database migration</span></div>
<span style="font-family:arial,sans-serif;font-size:13px">script is also pretty straightforward.</span><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Summarizing, my vote is on "subtype" field.<br>
</font><div><br></div><div>Thanks,</div><div>Andrew.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 2:10 PM, Trevor McKay <span dir="ltr"><<a href="mailto:tmckay@redhat.com" target="_blank">tmckay@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I was trying my best to avoid adding extra job types to support<br>
mapreduce variants like streaming or mapreduce with pipes, but it seems<br>
that adding the types is the simplest solution.<br>
<br>
On the API side, Savanna can live without a specific job type by<br>
examining the data in the job record.  Presence/absence of certain<br>
things, or null values, etc, can provide adequate indicators to what<br>
kind of mapreduce it is.  Maybe a little bit subtle.<br>
<br>
But for the UI, it seems that explicit knowledge of what the job is<br>
makes things easier and better for the user.  When a user creates a<br>
streaming mapreduce job and the UI is aware of the type later on at job<br>
launch, the user can be prompted to provide the right configs (i.e., the<br>
streaming mapper and reducer values).<br>
<br>
The explicit job type also supports validation without having to add<br>
extra flags (which impacts the savanna client, and the JSON, etc). For<br>
example, a streaming mapreduce job does not require any specified<br>
libraries so the fact that it is meant to be a streaming job needs to be<br>
known at job creation time.<br>
<br>
So, to that end, I propose that we add a MapReduceStreaming job type,<br>
and probably at some point we will have MapReducePiped too. It's<br>
possible that we might have other job types in the future too as the<br>
feature set grows.<br>
<br>
There was an effort to make Savanna job types parallel Oozie action<br>
types, but in this case that's just not possible without introducing a<br>
"subtype" field in the job record, which leads to a database migration<br>
script and savanna client changes.<br>
<br>
What do you think?<br>
<br>
Best,<br>
<br>
Trevor<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>