<div dir="ltr">I like the dot-separated name. There are several reasons for it:<div><br></div><div>* it'll not require changes in all Savanna subprojects;</div><div>* eventually we'd like to use not only Oozie for EDP (for example, if we'll support Twitter Storm) and this new tools could require additional 'subtypes'.</div>
<div><br></div><div>Thanks for catching this.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 10:47 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Andrew.<br>
<br>
My author thought, which is in between, is to allow dotted types.<br>
"MapReduce.streaming" for example.<br>
<br>
This gives you the subtype flavor but keeps all the APIs the same.<br>
We just need a wrapper function to separate them when we compare types.<br>
<br>
Best,<br>
<br>
Trevor<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, 2014-02-03 at 14:57 -0800, Andrew Lazarev wrote:<br>
> I see two points:<br>
> * having Savanna types mapped to Oozie action types is intuitive for<br>
> hadoop users and this is something we would like to keep<br>
> * it is hard to distinguish different kinds of one job type<br>
><br>
><br>
> Adding 'subtype' field will solve both problems. Having it optional<br>
> will not break backward compatibility. Adding database migration<br>
> script is also pretty straightforward.<br>
><br>
><br>
> Summarizing, my vote is on "subtype" field.<br>
><br>
><br>
> Thanks,<br>
> Andrew.<br>
><br>
><br>
> On Mon, Feb 3, 2014 at 2:10 PM, Trevor McKay <<a href="mailto:tmckay@redhat.com">tmckay@redhat.com</a>><br>
> wrote:<br>
><br>
>         I was trying my best to avoid adding extra job types to<br>
>         support<br>
>         mapreduce variants like streaming or mapreduce with pipes, but<br>
>         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<br>
>         by<br>
>         examining the data in the job record.  Presence/absence of<br>
>         certain<br>
>         things, or null values, etc, can provide adequate indicators<br>
>         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<br>
>         job is<br>
>         makes things easier and better for the user.  When a user<br>
>         creates a<br>
>         streaming mapreduce job and the UI is aware of the type later<br>
>         on at job<br>
>         launch, the user can be prompted to provide the right configs<br>
>         (i.e., the<br>
>         streaming mapper and reducer values).<br>
><br>
>         The explicit job type also supports validation without having<br>
>         to add<br>
>         extra flags (which impacts the savanna client, and the JSON,<br>
>         etc). For<br>
>         example, a streaming mapreduce job does not require any<br>
>         specified<br>
>         libraries so the fact that it is meant to be a streaming job<br>
>         needs to be<br>
>         known at job creation time.<br>
><br>
>         So, to that end, I propose that we add a MapReduceStreaming<br>
>         job type,<br>
>         and probably at some point we will have MapReducePiped too.<br>
>         It's<br>
>         possible that we might have other job types in the future too<br>
>         as the<br>
>         feature set grows.<br>
><br>
>         There was an effort to make Savanna job types parallel Oozie<br>
>         action<br>
>         types, but in this case that's just not possible without<br>
>         introducing a<br>
>         "subtype" field in the job record, which leads to a database<br>
>         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>
><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>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Sincerely yours,</div><div>Sergey Lukjanov</div><div>Savanna Technical Lead</div><div>Mirantis Inc.</div></div>
</div>