Review Patches
Can somebody review these please: https://issues.apache.org/jira/browse/OOZIE-1562 https://issues.apache.org/jira/browse/OOZIE-1314 Thanks, Shwetha -- _ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
[jira] [Assigned] (OOZIE-1535) Update job properties for WF/COORD
[ https://issues.apache.org/jira/browse/OOZIE-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shwetha G S reassigned OOZIE-1535: -- Assignee: Shwetha G S > Update job properties for WF/COORD > -- > > Key: OOZIE-1535 > URL: https://issues.apache.org/jira/browse/OOZIE-1535 > Project: Oozie > Issue Type: Improvement >Reporter: Srikanth Sundarrajan >Assignee: Shwetha G S > > It should be possible to update job submission properties for a running job, > both for WF and COORD jobs. The updated properties would be used for all > subsequent actions (not yet started). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OOZIE-1537) Suspending a sub-workflow is not reflected in the parent workflow
[ https://issues.apache.org/jira/browse/OOZIE-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shwetha G S resolved OOZIE-1537. Resolution: Fixed Fixed as part of OOZIE-1448 > Suspending a sub-workflow is not reflected in the parent workflow > - > > Key: OOZIE-1537 > URL: https://issues.apache.org/jira/browse/OOZIE-1537 > Project: Oozie > Issue Type: Improvement >Reporter: Srikanth Sundarrajan > > Suspending a sub-workflow is not reflected in the parent workflow, thus you > don't know what is going on. The status of the sub-flow should be reflected > in the parent workflow just as in any other action. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[
https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807523#comment-13807523
]
Hadoop QA commented on OOZIE-1542:
--
Testing JIRA OOZIE-1542
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:red}-1 COMPILE{color}
.{color:red}-1{color} HEAD does not compile
.{color:red}-1{color} patch does not compile
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color} - patch does not compile, cannot run testcases
{color:red}-1 DISTRO{color}
.{color:red}-1{color} distro tarball fails with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/868/
> When extjs isn't installed, the web UI is unhelpfully blank
> ---
>
> Key: OOZIE-1542
> URL: https://issues.apache.org/jira/browse/OOZIE-1542
> Project: Oozie
> Issue Type: Bug
>Affects Versions: trunk, 4.0.0
>Reporter: Robert Kanter
>Assignee: Robert Kanter
>Priority: Minor
> Fix For: trunk, 4.0.1
>
> Attachments: OOZIE-1542.patch, OOZIE-1542.patch
>
>
> When extjs isn't installed, the web UI page is currently unhelpfully blank
> (it has the oozie logo and docs link). In the past (when it used to be an
> html page instead of a jsp page) it had some text to let the user know that
> they have to install extjs to see the UI.
> It would be good to put back the same or similar text; otherwise, users may
> be confused why they can't see the UI if they forget to install extjs.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[ https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807506#comment-13807506 ] Virag Kothari commented on OOZIE-1542: -- +1 > When extjs isn't installed, the web UI is unhelpfully blank > --- > > Key: OOZIE-1542 > URL: https://issues.apache.org/jira/browse/OOZIE-1542 > Project: Oozie > Issue Type: Bug >Affects Versions: trunk, 4.0.0 >Reporter: Robert Kanter >Assignee: Robert Kanter >Priority: Minor > Fix For: trunk, 4.0.1 > > Attachments: OOZIE-1542.patch, OOZIE-1542.patch > > > When extjs isn't installed, the web UI page is currently unhelpfully blank > (it has the oozie logo and docs link). In the past (when it used to be an > html page instead of a jsp page) it had some text to let the user know that > they have to install extjs to see the UI. > It would be good to put back the same or similar text; otherwise, users may > be confused why they can't see the UI if they forget to install extjs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[ https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kanter updated OOZIE-1542: - Attachment: OOZIE-1542.patch Uploading same patch to kick off Jenkins again; the HEAD didn't even compile. > When extjs isn't installed, the web UI is unhelpfully blank > --- > > Key: OOZIE-1542 > URL: https://issues.apache.org/jira/browse/OOZIE-1542 > Project: Oozie > Issue Type: Bug >Affects Versions: trunk, 4.0.0 >Reporter: Robert Kanter >Assignee: Robert Kanter >Priority: Minor > Fix For: trunk, 4.0.1 > > Attachments: OOZIE-1542.patch, OOZIE-1542.patch > > > When extjs isn't installed, the web UI page is currently unhelpfully blank > (it has the oozie logo and docs link). In the past (when it used to be an > html page instead of a jsp page) it had some text to let the user know that > they have to install extjs to see the UI. > It would be good to put back the same or similar text; otherwise, users may > be confused why they can't see the UI if they forget to install extjs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[
https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807492#comment-13807492
]
Hadoop QA commented on OOZIE-1542:
--
Testing JIRA OOZIE-1542
Cleaning local svn workspace
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
132
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:red}-1 COMPILE{color}
.{color:red}-1{color} HEAD does not compile
.{color:red}-1{color} patch does not compile
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.{color:green}+1{color} the patch does not change any JPA
Entity/Colum/Basic/Lob/Transient annotations
.{color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color} - patch does not compile, cannot run testcases
{color:red}-1 DISTRO{color}
.{color:red}-1{color} distro tarball fails with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/867/
> When extjs isn't installed, the web UI is unhelpfully blank
> ---
>
> Key: OOZIE-1542
> URL: https://issues.apache.org/jira/browse/OOZIE-1542
> Project: Oozie
> Issue Type: Bug
>Affects Versions: trunk, 4.0.0
>Reporter: Robert Kanter
>Assignee: Robert Kanter
>Priority: Minor
> Fix For: trunk, 4.0.1
>
> Attachments: OOZIE-1542.patch
>
>
> When extjs isn't installed, the web UI page is currently unhelpfully blank
> (it has the oozie logo and docs link). In the past (when it used to be an
> html page instead of a jsp page) it had some text to let the user know that
> they have to install extjs to see the UI.
> It would be good to put back the same or similar text; otherwise, users may
> be confused why they can't see the UI if they forget to install extjs.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[
https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter updated OOZIE-1542:
-
Attachment: OOZIE-1542.patch
When jquery was added, the loading of oozie-console.js got moved earlier than
the div element that had the message. The javascript in oozie-console.js that
was making this element visible when it can't find extjs would now be executed
before the element existed (the order matters:
http://stackoverflow.com/questions/14028959/why-does-jquery-or-a-dom-method-such-as-getelementbyid-not-find-the-element).
As suggested in the stack overflow answer, the patch simply moves that checking
code into {{.ready()}} so that it is executed after the DOM is ready and the
element exists.
No tests because its a UI change, but I verified that it worked. I'm not a
javascript expert, but this was a pretty trivial fix that seems to be working
as far as I can tell.
> When extjs isn't installed, the web UI is unhelpfully blank
> ---
>
> Key: OOZIE-1542
> URL: https://issues.apache.org/jira/browse/OOZIE-1542
> Project: Oozie
> Issue Type: Bug
>Affects Versions: trunk, 4.0.0
>Reporter: Robert Kanter
>Assignee: Robert Kanter
>Priority: Minor
> Fix For: trunk, 4.0.1
>
> Attachments: OOZIE-1542.patch
>
>
> When extjs isn't installed, the web UI page is currently unhelpfully blank
> (it has the oozie logo and docs link). In the past (when it used to be an
> html page instead of a jsp page) it had some text to let the user know that
> they have to install extjs to see the UI.
> It would be good to put back the same or similar text; otherwise, users may
> be confused why they can't see the UI if they forget to install extjs.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[ https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kanter updated OOZIE-1542: - Affects Version/s: trunk Fix Version/s: 4.0.1 trunk I think we should fix this in 4.0.1 because its technically a regression in 4.0.0 from 3.3.2 > When extjs isn't installed, the web UI is unhelpfully blank > --- > > Key: OOZIE-1542 > URL: https://issues.apache.org/jira/browse/OOZIE-1542 > Project: Oozie > Issue Type: Bug >Affects Versions: trunk, 4.0.0 >Reporter: Robert Kanter >Assignee: Robert Kanter >Priority: Minor > Fix For: trunk, 4.0.1 > > Attachments: OOZIE-1542.patch > > > When extjs isn't installed, the web UI page is currently unhelpfully blank > (it has the oozie logo and docs link). In the past (when it used to be an > html page instead of a jsp page) it had some text to let the user know that > they have to install extjs to see the UI. > It would be good to put back the same or similar text; otherwise, users may > be confused why they can't see the UI if they forget to install extjs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OOZIE-1542) When extjs isn't installed, the web UI is unhelpfully blank
[ https://issues.apache.org/jira/browse/OOZIE-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kanter reassigned OOZIE-1542: Assignee: Robert Kanter > When extjs isn't installed, the web UI is unhelpfully blank > --- > > Key: OOZIE-1542 > URL: https://issues.apache.org/jira/browse/OOZIE-1542 > Project: Oozie > Issue Type: Bug >Affects Versions: 4.0.0 >Reporter: Robert Kanter >Assignee: Robert Kanter >Priority: Minor > > When extjs isn't installed, the web UI page is currently unhelpfully blank > (it has the oozie logo and docs link). In the past (when it used to be an > html page instead of a jsp page) it had some text to let the user know that > they have to install extjs to see the UI. > It would be good to put back the same or similar text; otherwise, users may > be confused why they can't see the UI if they forget to install extjs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OOZIE-1599) Cache the list of available timezones from the admin servlet
[
https://issues.apache.org/jira/browse/OOZIE-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter reassigned OOZIE-1599:
Assignee: Robert Kanter
> Cache the list of available timezones from the admin servlet
>
>
> Key: OOZIE-1599
> URL: https://issues.apache.org/jira/browse/OOZIE-1599
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Fix For: trunk
>
>
> The admin servlet has a call that returns a list of available timezones. On
> startup, it prepares a list of GMT offsets (e.g. "GMT-12:00", "GMT-11:00",
> etc), which is only generated once. But the rest of the timezones (e.g.
> "America/Los_Angeles", etc) are processed from {{TimeZone}} every time the
> admin servlet is asked for the list.
> We should refactor this to generate/process the entire list either the first
> time its called or at startup and then simply return the {{JSONArray}} when
> the admin servlet is asked for the list.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OOZIE-1599) Cache the list of available timezones from the admin servlet
Robert Kanter created OOZIE-1599:
Summary: Cache the list of available timezones from the admin
servlet
Key: OOZIE-1599
URL: https://issues.apache.org/jira/browse/OOZIE-1599
Project: Oozie
Issue Type: Improvement
Affects Versions: trunk
Reporter: Robert Kanter
Fix For: trunk
The admin servlet has a call that returns a list of available timezones. On
startup, it prepares a list of GMT offsets (e.g. "GMT-12:00", "GMT-11:00",
etc), which is only generated once. But the rest of the timezones (e.g.
"America/Los_Angeles", etc) are processed from {{TimeZone}} every time the
admin servlet is asked for the list.
We should refactor this to generate/process the entire list either the first
time its called or at startup and then simply return the {{JSONArray}} when the
admin servlet is asked for the list.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1580) EL variables don't get resolved in configurations imported from a
[
https://issues.apache.org/jira/browse/OOZIE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807298#comment-13807298
]
Robert Kanter commented on OOZIE-1580:
--
It's just the contents of the {{}} section from the example:
{code:xml}
mapred.job.queue.name
${queueName}
mapred.mapper.class
org.apache.oozie.example.SampleMapper
mapred.reducer.class
org.apache.oozie.example.SampleReducer
mapred.map.tasks
1
mapred.input.dir
/user/${wf:user()}/${examplesRoot}/input-data/text
mapred.output.dir
/user/${wf:user()}/${examplesRoot}/output-data/${outputDir}
{code}
> EL variables don't get resolved in configurations imported from a
> ---
>
> Key: OOZIE-1580
> URL: https://issues.apache.org/jira/browse/OOZIE-1580
> Project: Oozie
> Issue Type: Improvement
>Reporter: Robert Kanter
>Assignee: Bowen Zhang
> Attachments: oozie-1580.patch
>
>
> If you use to include a file that includes an EL variable, it
> doesn't get resolved.
> For example:
> {code:xml|title=foo.xml|borderStyle=solid}
>
>
> some.property
> ${someVariable}
>
>
> {code}
> {code:title=job.propertiesl|borderStyle=solid}
> ...
> someVariable=bar
> {code}
> Then in the submitted job, {{some.property}} will be equal to
> "{{$\{someVariable}}}" when we would like it to be "{{bar}}".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1580) EL variables don't get resolved in configurations imported from a
[
https://issues.apache.org/jira/browse/OOZIE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807285#comment-13807285
]
Bowen Zhang commented on OOZIE-1580:
[~rkanter], Can you show me the foo.xml?
> EL variables don't get resolved in configurations imported from a
> ---
>
> Key: OOZIE-1580
> URL: https://issues.apache.org/jira/browse/OOZIE-1580
> Project: Oozie
> Issue Type: Improvement
>Reporter: Robert Kanter
>Assignee: Bowen Zhang
> Attachments: oozie-1580.patch
>
>
> If you use to include a file that includes an EL variable, it
> doesn't get resolved.
> For example:
> {code:xml|title=foo.xml|borderStyle=solid}
>
>
> some.property
> ${someVariable}
>
>
> {code}
> {code:title=job.propertiesl|borderStyle=solid}
> ...
> someVariable=bar
> {code}
> Then in the submitted job, {{some.property}} will be equal to
> "{{$\{someVariable}}}" when we would like it to be "{{bar}}".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1580) EL variables don't get resolved in configurations imported from a
[
https://issues.apache.org/jira/browse/OOZIE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807281#comment-13807281
]
Robert Kanter commented on OOZIE-1580:
--
Ah, I missed that its calling {{JavaActionExecutor}}; make sense.
I tried editing the mapreduce example by moving its {{}}
properties to a separate xml file and including that with {{
${jobTracker}
${nameNode}
foo.xml
{code}
The MR job succeeded, but Oozie had an {{IllegalArgumentException}} somewhere:
{noformat}
$ oozie job -info 000-131028144305717-oozie-rkan-W@mr-node
ID : 000-131028144305717-oozie-rkan-W@mr-node
Console URL :
http://localhost:50030/jobdetails.jsp?jobid=job_201310281439_0001
Error Code: IllegalArgumentException
Error Message : IllegalArgumentException: element cannot be null
External ID : job_201310281439_0001
External Status : SUCCEEDED
Name : mr-node
Retries : 0
Tracker URI : localhost:8021
Type : map-reduce
Started : 2013-10-28 21:44 GMT
Status: ERROR
Ended : -
{noformat}
You can see that the "external status" is "SUCCEEDED" (and I checked the MR
job); but the action itself was "ERROR". I looked at the Oozie log, but all I
see in there is this:
{noformat}
2013-10-28 14:44:50,525 WARN ActionEndXCommand:542 - SERVER[rkanter-MBP.local]
USER[rkanter] GROUP[-] TOKEN[] APP[map-reduce-wf]
JOB[000-131028144305717-oozie-rkan-W]
ACTION[000-131028144305717-oozie-rkan-W@mr-node] Error ending action
[mr-node]. ErrorType [ERROR], ErrorCode [IllegalArgumentException], Message
[IllegalArgumentException: element cannot be null]
{noformat}
Can you take a look?
> EL variables don't get resolved in configurations imported from a
> ---
>
> Key: OOZIE-1580
> URL: https://issues.apache.org/jira/browse/OOZIE-1580
> Project: Oozie
> Issue Type: Improvement
>Reporter: Robert Kanter
>Assignee: Bowen Zhang
> Attachments: oozie-1580.patch
>
>
> If you use to include a file that includes an EL variable, it
> doesn't get resolved.
> For example:
> {code:xml|title=foo.xml|borderStyle=solid}
>
>
> some.property
> ${someVariable}
>
>
> {code}
> {code:title=job.propertiesl|borderStyle=solid}
> ...
> someVariable=bar
> {code}
> Then in the submitted job, {{some.property}} will be equal to
> "{{$\{someVariable}}}" when we would like it to be "{{bar}}".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OOZIE-1588) upgrade oozie to sqoop 1.4.4
[ https://issues.apache.org/jira/browse/OOZIE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kanter resolved OOZIE-1588. -- Resolution: Won't Fix Sqoop 1.4.3 is close enough to 1.4.4 that we don't need to bother with this for now. We should wait until there's a more significant release and update to that whenever that happens. > upgrade oozie to sqoop 1.4.4 > > > Key: OOZIE-1588 > URL: https://issues.apache.org/jira/browse/OOZIE-1588 > Project: Oozie > Issue Type: Bug >Affects Versions: trunk, 4.0.0 >Reporter: Robert Kanter >Assignee: Robert Kanter > > We're currently using Sqoop 1.4.3 and the latest is 1.4.4 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OOZIE-1585) Upgrade oozie to pig 0.12.1
[ https://issues.apache.org/jira/browse/OOZIE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bowen Zhang updated OOZIE-1585: --- Summary: Upgrade oozie to pig 0.12.1 (was: Upgrade oozie to pig 12) > Upgrade oozie to pig 0.12.1 > --- > > Key: OOZIE-1585 > URL: https://issues.apache.org/jira/browse/OOZIE-1585 > Project: Oozie > Issue Type: Improvement >Reporter: Bowen Zhang >Assignee: Bowen Zhang > > Need to add automaton and joda-time dependency for pig 12. Automaton is for > optimization of java regular expression and Joda-time is for new "datetime" > data type in pig. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OOZIE-1585) Upgrade oozie to pig 0.12.1
[ https://issues.apache.org/jira/browse/OOZIE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807216#comment-13807216 ] Bowen Zhang commented on OOZIE-1585: pig 0.12.1 will be out soon which is a more stable release than 0.12.0. > Upgrade oozie to pig 0.12.1 > --- > > Key: OOZIE-1585 > URL: https://issues.apache.org/jira/browse/OOZIE-1585 > Project: Oozie > Issue Type: Improvement >Reporter: Bowen Zhang >Assignee: Bowen Zhang > > Need to add automaton and joda-time dependency for pig 12. Automaton is for > optimization of java regular expression and Joda-time is for new "datetime" > data type in pig. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OOZIE-1580) EL variables don't get resolved in configurations imported from a
[
https://issues.apache.org/jira/browse/OOZIE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807112#comment-13807112
]
Bowen Zhang commented on OOZIE-1580:
FsActionExecutor does call the method parseJobXmlAndConfiguration from
doOperations(). And all the other subclasses of actionExecutor don't invoke any
checks for "job-xml" tab because (i guess) it won't make sense to do it. This
is either by feature design or an existing bug in the code base which in either
case should be outside the scope of this ticket.
> EL variables don't get resolved in configurations imported from a
> ---
>
> Key: OOZIE-1580
> URL: https://issues.apache.org/jira/browse/OOZIE-1580
> Project: Oozie
> Issue Type: Improvement
>Reporter: Robert Kanter
>Assignee: Bowen Zhang
> Attachments: oozie-1580.patch
>
>
> If you use to include a file that includes an EL variable, it
> doesn't get resolved.
> For example:
> {code:xml|title=foo.xml|borderStyle=solid}
>
>
> some.property
> ${someVariable}
>
>
> {code}
> {code:title=job.propertiesl|borderStyle=solid}
> ...
> someVariable=bar
> {code}
> Then in the submitted job, {{some.property}} will be equal to
> "{{$\{someVariable}}}" when we would like it to be "{{bar}}".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: Review Request 14741: Setup sharelib using script and pickup latest(honor ship.launcher) and remove DFS dependency at startup.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14741/ --- (Updated Oct. 28, 2013, 5:58 p.m.) Review request for oozie. Changes --- + Sharelib mapping file support. Bugs: OOZIE-1584 https://issues.apache.org/jira/browse/OOZIE-1584 Repository: oozie Description (updated) --- Supported features. - 1. If Oozie.action.ship.launcher.jar = true then, Oozie auto-deploy jar at server start. 2. Admin copies sharelib to new timestamp directory and issues invalidate command to Oozie server. Oozie picks latest shared lib. 3. Oozie server doesn't auto deploy sharelib at startup. It picks the latest sharelib jar pushed by admin(based on timestamp). 4. Sharelib mapping files. Sharelib mapping file can be also configured.Configured file is a key value mapping, where key will be the action and value is DFS directory of sharelib files for action. This can be configured in oozie-site.xml as : oozie.service.ShareLibService.mapping.file Sharelib mapping files contains list of key=value, where key is the action key and value is the DFS location of sharelib files. DFS after generating launcher jar by ooozie server and sharelib by cli makebag-lm:example purushah$ /var/hadoop-1.2.1/bin/hadoop fs -ls /user/purushah/share/lib/ /user/purushah/share/lib/launcher_20131017092254 /user/purushah/share/lib/launcher_20131017093814 /user/purushah/share/lib/launcher_20131017094652 /user/purushah/share/lib/launcher_20131017094836 /user/purushah/share/lib/launcher_20131017095549 /user/purushah/share/lib/lib_20131017092806 makebag-lm:example purushah$ Purging. - There are two set( launcher_ for launcher jars and Lib_ for shared lib) of directory and purging happens for both at startup. Anything older than ( defined in property) is purged. We always keep 2 set of directory, purging happens if number of sharelib directory > 2. Multiple version. --- To support multiple version, sharelib will be in below format. Sharelib will cache all versions and return list of dfs files for a particular version. makebag-lm:example purushah$ /var/hadoop-1.2.1/bin/hadoop fs -ls /user/purushah/share/lib/ Found 15 items /user/purushah/share/lib/launcher_20131017092254 /user/purushah/share/lib/launcher_20131017093814 /user/purushah/share/lib/launcher_20131017094652 /user/purushah/share/lib/launcher_20131017094836 /user/purushah/share/lib/launcher_20131017095549 /user/purushah/share/lib/lib_20131017092806/pig/... /user/purushah/share/lib/lib_20131017092806/pig_9/... /user/purushah/share/lib/lib_20131017092806/pig_10/... makebag-lm:example purushah$ Diffs (updated) - http://svn.apache.org/repos/asf/oozie/trunk/core/src/main/conf/oozie-site.xml 1532127 http://svn.apache.org/repos/asf/oozie/trunk/core/src/main/java/org/apache/oozie/action/hadoop/JavaActionExecutor.java 1532127 http://svn.apache.org/repos/asf/oozie/trunk/core/src/main/java/org/apache/oozie/service/ShareLibService.java 1532127 http://svn.apache.org/repos/asf/oozie/trunk/core/src/test/java/org/apache/oozie/service/TestShareLibService.java 1532127 http://svn.apache.org/repos/asf/oozie/trunk/docs/src/site/twiki/AG_Install.twiki 1532127 http://svn.apache.org/repos/asf/oozie/trunk/docs/src/site/twiki/DG_QuickStart.twiki 1532127 http://svn.apache.org/repos/asf/oozie/trunk/tools/src/main/java/org/apache/oozie/tools/OozieSharelibCLI.java 1532127 Diff: https://reviews.apache.org/r/14741/diff/ Testing --- Thanks, Purshotam Shah
[jira] [Commented] (OOZIE-1565) OOZIE-1481 should only affect v2 of the API, not v1
[
https://issues.apache.org/jira/browse/OOZIE-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806996#comment-13806996
]
Alejandro Abdelnur commented on OOZIE-1565:
---
+1
> OOZIE-1481 should only affect v2 of the API, not v1
> ---
>
> Key: OOZIE-1565
> URL: https://issues.apache.org/jira/browse/OOZIE-1565
> Project: Oozie
> Issue Type: Bug
> Components: coordinator
>Affects Versions: trunk, 4.0.0
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Fix For: trunk, 4.0.1
>
> Attachments: OOZIE-1565.patch
>
>
> OOZIE-1481 changed the behavior of the v1 API such that when getting coord
> info, specifying {{len=0}} now returns 0 actions instead of all actions.
> Also, on the REST call, not specifying any {{len}} parameter is interpreted
> by the Oozie server as {{len=0}}.
> This is a logically backwards incompatible change. We should keep this
> change in the v2 API, but change the v1 API back to the original (incorrect)
> behavior.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1597) Cleanup database before every test
[
https://issues.apache.org/jira/browse/OOZIE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806990#comment-13806990
]
Alejandro Abdelnur commented on OOZIE-1597:
---
+1 LGTM
> Cleanup database before every test
> --
>
> Key: OOZIE-1597
> URL: https://issues.apache.org/jira/browse/OOZIE-1597
> Project: Oozie
> Issue Type: Improvement
> Components: tests
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1597.patch
>
>
> While investigating a flakey test
> ({{org.apache.oozie.sla.TestSLAJobEventListener.testOnJobEvent}}) I realized
> that some of the flakey SLA tests that I've seen lately are the same issue:
> The database has some leftover stuff from a previous test that its not
> expecting.
> Normally this is easy to fix because we can simply call
> {{cleanUpDBTables()}}. However, {{cleanUpDBTables}} requires some of the
> {{Services}} to be running, so you have to call it after starting
> {{Services}}; but, some of the failures were occurring during Services
> initialization (specifically when {{SLAService}} initializes the
> {{SLACalculatorMemory}}, which tries to load some data from the database,
> which may be incomplete (e.g. SLA registration for a job that doesn't
> exist)). So, in this case, we can't call {{cleanUpDBTables()}} before or
> after starting {{Services}}.
> This brings the larger issue that we should be cleaning up the database
> before every test anyway to make sure that the tests are truly independent
> and to prevent harmful leaking (just like we did a while back with the
> {{Services}}). I think we should have {{XTestCase.setup()}} call
> {{cleanUpDBTables()}} so that every test automatically it (and handle the
> {{Services}} dependency appropriately).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1589) TestZKLocksService is flakey
[
https://issues.apache.org/jira/browse/OOZIE-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806986#comment-13806986
]
Alejandro Abdelnur commented on OOZIE-1589:
---
+1
> TestZKLocksService is flakey
>
>
> Key: OOZIE-1589
> URL: https://issues.apache.org/jira/browse/OOZIE-1589
> Project: Oozie
> Issue Type: Bug
> Components: tests
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Robert Kanter
> Attachments: OOZIE-1589.patch
>
>
> TestZKLocksService is highly dependent on the order of things happening
> because its testing locks. I've seen tests in this class fail a number of
> times with messages like this:
> {noformat}
> expected: but was:
> {noformat}
> which is because things happened in a slightly different order than it was
> expecting (though everything is happening correctly)
> When I created these tests, I just took the TestLockService and made it use
> ZKLocks instead of MemoryLocks. The ZKLocks take longer to lock than the
> MemoryLocks, so the timings are sometimes too fast. I think we just need to
> increase the sleep calls, and use the {{sleep()}} method instead of
> {{Thread.sleep()}} so it will scale with the "waitfor ratio" on slower
> machines.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1596) TestOozieMySqlDBCLI.testCreateMysql fails when tests are executed in a different order
[
https://issues.apache.org/jira/browse/OOZIE-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806984#comment-13806984
]
Alejandro Abdelnur commented on OOZIE-1596:
---
+1
> TestOozieMySqlDBCLI.testCreateMysql fails when tests are executed in a
> different order
> --
>
> Key: OOZIE-1596
> URL: https://issues.apache.org/jira/browse/OOZIE-1596
> Project: Oozie
> Issue Type: Bug
> Components: tests
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Robert Kanter
>Priority: Minor
> Attachments: OOZIE-1596.patch
>
>
> {{TestOozieMySqlDBCLI.testCreateMysql}} will fail if the tests are executed
> in a different order.
> TestOozieMySqlDBCLI.testCreateMysql relies on the default setting of
> {{FakeConnection.CREATE}} (which is {{true}}), but if
> {{TestOozieMySqlDBCLI.testUpgradeMysql}} is executed first, it will change
> {{FakeConnection.CREATE}} to {{false}}, and
> {{TestOozieMySqlDBCLI.testCreateMysql}} will fail.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1580) EL variables don't get resolved in configurations imported from a
[
https://issues.apache.org/jira/browse/OOZIE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806988#comment-13806988
]
Robert Kanter commented on OOZIE-1580:
--
The changes will only affect actions that subclass the {{JavaActionExecutor}};
but some action executors, such as the {{FsActionExecutor}} do not so they
won't resolve the variables in their if they have one. I think we
should add a function to {{ActionExecutor}} that can resolve the
variables and then any subclasses (i.e. {{JavaActionExecutor}},
{{FsActionExecutor}}), can simply call it.
> EL variables don't get resolved in configurations imported from a
> ---
>
> Key: OOZIE-1580
> URL: https://issues.apache.org/jira/browse/OOZIE-1580
> Project: Oozie
> Issue Type: Improvement
>Reporter: Robert Kanter
>Assignee: Bowen Zhang
> Attachments: oozie-1580.patch
>
>
> If you use to include a file that includes an EL variable, it
> doesn't get resolved.
> For example:
> {code:xml|title=foo.xml|borderStyle=solid}
>
>
> some.property
> ${someVariable}
>
>
> {code}
> {code:title=job.propertiesl|borderStyle=solid}
> ...
> someVariable=bar
> {code}
> Then in the submitted job, {{some.property}} will be equal to
> "{{$\{someVariable}}}" when we would like it to be "{{bar}}".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OOZIE-1541) Typo in Oozie HA admin -servers command in documentation
[
https://issues.apache.org/jira/browse/OOZIE-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806983#comment-13806983
]
Alejandro Abdelnur commented on OOZIE-1541:
---
+1
> Typo in Oozie HA admin -servers command in documentation
>
>
> Key: OOZIE-1541
> URL: https://issues.apache.org/jira/browse/OOZIE-1541
> Project: Oozie
> Issue Type: Bug
> Components: docs, HA
>Affects Versions: trunk
>Reporter: Robert Kanter
>Assignee: Robert Kanter
>Priority: Trivial
> Fix For: trunk
>
> Attachments: OOZIE-1541.patch
>
>
> The CLI {{admin -servers}} command gives an example in the documentation:
> {noformat}
> $ oozie admin http://localhost:11000/oozie -servers
> OozieA : http://localhost:11000/oozie
> OozieB : http://localhost:12000/oozie
> OozieC : http://localhost:13000/oozie
> {noformat}
> The command is missing the {{-oozie}} before the address.
> It would also probably be more clear if they were different hosts instead of
> the same host with different ports (same with the REST docs).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
