<div dir="ltr">Additionally, I think that we should explicitly specify the need to ensure that all outputs doesn't contain any sensitive information like credentials.</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jan 28, 2014 at 4:06 PM, Alexander Ignatov <span dir="ltr"><<a href="mailto:aignatov@mirantis.com" target="_blank">aignatov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
“EDP internal” I meant current EDP specific code. And since job configs are job-specific<br>
I’d prefer to have urls containing /jobs or at least /edp for that.<br>
<br>
Regards,<br>
Alexander Ignatov<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 24 Jan 2014, at 23:20, Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>> wrote:<br>
<br>
> what do you consider "EDP internal", and how does it relate to the v1.1 or v2 API?<br>
><br>
> i'm ok with making it plugin independent. i'd just suggest moving it out of /jobs and to something like /extra/config-hints/{type}, maybe along with /extra/validations/config.<br>
><br>
> best,<br>
><br>
><br>
> matt<br>
><br>
> On 01/22/2014 06:25 AM, Alexander Ignatov wrote:<br>
>> Current EDP config-hints are not only plugin specific. Several types of jobs<br>
>> must have certain key/values and without it job will fail. For instance,<br>
>> MapReduce (former Jar) job type requires Mapper/Reducer classes parameters<br>
>> to be set[1]. Moreover, for such kind of jobs we already have separated<br>
>> configuration defaults [2]. Also initial versions of patch implementing<br>
>> config-hints contained plugin-independent defaults for all each job types [3].<br>
>> I remember we postponed decision about which configs are commmon for all<br>
>> plugins and agreed to show users all vanilla-specific defaults. That's why now<br>
>> we have several TODOs in the code about config-hints should be plugin-specific.<br>
>><br>
>> So I propose to leave config-hints REST call in EDP internal and make it<br>
>> plugin-independent (or job-specific) by removing of parsing all vanilla-specific<br>
>> defaults and define small list of configs which is definitely common for each type of jobs.<br>
>> The first things come to mind:<br>
>> - For MapReduce jobs it's already defined in [1]<br>
>> - Configs like number of map and reduce tasks are common for all type of jobs<br>
>> - At least user always has an ability to set any key/value(s) as params/arguments for job<br>
>><br>
>><br>
>> [1] <a href="http://docs.openstack.org/developer/savanna/userdoc/edp.html#workflow" target="_blank">http://docs.openstack.org/developer/savanna/userdoc/edp.html#workflow</a><br>
>> [2] <a href="https://github.com/openstack/savanna/blob/master/savanna/service/edp/resources/mapred-job-config.xml" target="_blank">https://github.com/openstack/savanna/blob/master/savanna/service/edp/resources/mapred-job-config.xml</a><br>
>> [3] <a href="https://review.openstack.org/#/c/45419/10" target="_blank">https://review.openstack.org/#/c/45419/10</a><br>
>><br>
>> Regards,<br>
>> Alexander Ignatov<br>
>><br>
>><br>
>><br>
>> On 20 Jan 2014, at 22:04, Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>> wrote:<br>
>><br>
>>> On 01/20/2014 12:50 PM, Andrey Lazarev wrote:<br>
>>>> Inlined.<br>
>>>><br>
>>>><br>
>>>> On Mon, Jan 20, 2014 at 8:15 AM, Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a><br>
>>>> <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a>>> wrote:<br>
>>>><br>
>>>> (inline, trying to make this readable by a text-only mail client<br>
>>>> that doesn't use tabs to indicate quoting)<br>
>>>><br>
>>>> On 01/20/2014 02:50 AM, Andrey Lazarev wrote:<br>
>>>><br>
>>>> ------<br>
>>>> FIX - @rest.get('/jobs/config-hints/____<job_type>') -<br>
>>>> should move to<br>
>>>> GET /plugins/<plugin_name>/<____plugin_version>, similar to<br>
>>>> get_node_processes<br>
>>>> and get_required_image_tags<br>
>>>> ------<br>
>>>> Not sure if it should be plugin specific right now. EDP<br>
>>>> uses it<br>
>>>> to show some<br>
>>>> configs to users in the dashboard. it's just a cosmetic<br>
>>>> thing.<br>
>>>> Also when user<br>
>>>> starts define some configs for some job he might not define<br>
>>>> cluster yet and<br>
>>>> thus plugin to run this job. I think we should leave it<br>
>>>> as is<br>
>>>> and leave only<br>
>>>> abstract configs like Mapper/Reducer class and allow<br>
>>>> users to<br>
>>>> apply any<br>
>>>> key/value configs if needed.<br>
>>>><br>
>>>><br>
>>>> FYI, the code contains comments suggesting it should be<br>
>>>> plugin specific.<br>
>>>><br>
>>>> <a href="https://github.com/openstack/____savanna/blob/master/savanna/____service/edp/workflow_creator/____workflow_factory.py#L179" target="_blank">https://github.com/openstack/____savanna/blob/master/savanna/____service/edp/workflow_creator/____workflow_factory.py#L179</a><br>
>>>> <<a href="https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179" target="_blank">https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179</a>><br>
>>>><br>
>>>> <<a href="https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179" target="_blank">https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179</a><br>
>>>> <<a href="https://github.com/openstack/savanna/blob/master/savanna/service/edp/workflow_creator/workflow_factory.py#L179" target="_blank">https://github.com/openstack/savanna/blob/master/savanna/service/edp/workflow_creator/workflow_factory.py#L179</a>>><br>
>>>><br>
>>>> IMHO, the EDP should have no plugin specific dependencies.<br>
>>>><br>
>>>> If it currently does, we should look into why and see if we<br>
>>>> can't<br>
>>>> eliminate this entirely.<br>
>>>><br>
>>>> [AL] EDP uses plugins in two ways:<br>
>>>> 1. for HDFS user<br>
>>>> 2. for config hints<br>
>>>> I think both items should not be plugin specific on EDP API<br>
>>>> level. But<br>
>>>> implementation should go to plugin and call plugin API for result.<br>
>>>><br>
>>>><br>
>>>> In fact they are both plugin specific. The user is forced to click<br>
>>>> through a plugin selection (when launching a job on transient<br>
>>>> cluster) or the plugin selection has already occurred (when<br>
>>>> launching a job on an existing cluster).<br>
>>>><br>
>>>> Since the config is something that is plugin specific, you might not<br>
>>>> have hbase hints from vanilla but you would from hdp, and you<br>
>>>> already have plugin information whenever you ask for a hint, my view<br>
>>>> that this be under the /plugins namespace is growing stronger.<br>
>>>><br>
>>>><br>
>>>> [AL] Disagree. They are plugin specific, but EDP itself could have<br>
>>>> additional plugin-independent logic inside. Now config hints return EDP<br>
>>>> properties (like mapred.input.dir) as well as plugin-specific<br>
>>>> properties. Placing it under /plugins namespace will give a vision that<br>
>>>> it is fully plugin specific.<br>
>>>><br>
>>>> I like to see EDP API fully plugin independent and in one workspace. If<br>
>>>> core side needs some information internally it can easily go into the<br>
>>>> plugin.<br>
>>><br>
>>> I'm not sure if we're disagreeing. We may, in fact, be in violent agreement.<br>
>>><br>
>>> The EDP API is fully plugin independent, and should stay that way as a project goal. config-hints is extra data that the horizon app can use to help give users suggestions about what config they may want to optionally add to their job. Those config options are independent of the job and specific to the cluster where the job will run, which is the purview of the plugin.<br>
>>><br>
>>> Moving config-hints out of the EDP API will make this even more clear.<br>
>>><br>
>>> Best,<br>
>>><br>
>>><br>
>>> matt<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>
<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>