[jira] [Created] (OOZIE-2765) Allow customizing SLA email subject line
Peter Orova created OOZIE-2765: -- Summary: Allow customizing SLA email subject line Key: OOZIE-2765 URL: https://issues.apache.org/jira/browse/OOZIE-2765 Project: Oozie Issue Type: New Feature Affects Versions: 4.1.0 Reporter: Peter Orova Priority: Minor https://github.com/apache/oozie/blob/branch-4.1/core/src/main/java/org/apache/oozie/sla/listener/SLAEmailEventListener.java#L273-L279 suggests that the SLA email's subject line is hard coded into Oozie. A way to configure the subject line for the SLA emails via the workflow definition would be useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OOZIE-3029) The currentlty reported errors for action should be propagated
Peter Orova created OOZIE-3029: -- Summary: The currentlty reported errors for action should be propagated Key: OOZIE-3029 URL: https://issues.apache.org/jira/browse/OOZIE-3029 Project: Oozie Issue Type: New Feature Reporter: Peter Orova Priority: Minor Oozie should provide the detailed failure message of a sub workflow in the parent workflow on failure instead of only specifying that the parent workflow failed at the sub workflow action -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OOZIE-3234) Revise TestAuthorizationService
Peter Orova created OOZIE-3234:
--
Summary: Revise TestAuthorizationService
Key: OOZIE-3234
URL: https://issues.apache.org/jira/browse/OOZIE-3234
Project: Oozie
Issue Type: Improvement
Components: tests
Affects Versions: 5.0.0
Reporter: Peter Orova
Assignee: Peter Orova
The {{TestAuthorizationService}}'s maintainability is low due to
* the many magic boolean variables
* the init methods having 3+ parameters
One way this could be addressed is to introduce a simplified version of Builder
pattern via a private nested class, to replace the functionality of the
{{init}} methods.
This approach would allow for a much more readable, flexible and maintainable
code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Attachment: OOZIE-3217.007.patch
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch,
> OOZIE-3217.003.patch, OOZIE-3217.004.patch, OOZIE-3217.005.patch,
> OOZIE-3217.006.patch, OOZIE-3217.007.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473857#comment-16473857
]
Peter Orova commented on OOZIE-3217:
[~andras.piros] the previous patch got corrupted, please find attached the
corrected one
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch,
> OOZIE-3217.003.patch, OOZIE-3217.004.patch, OOZIE-3217.005.patch,
> OOZIE-3217.006.patch, OOZIE-3217.007.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OOZIE-3247) Allow specifying what actions to skip on subworkflow when rerunning parent
Peter Orova created OOZIE-3247: -- Summary: Allow specifying what actions to skip on subworkflow when rerunning parent Key: OOZIE-3247 URL: https://issues.apache.org/jira/browse/OOZIE-3247 Project: Oozie Issue Type: Improvement Reporter: Peter Orova When rerunning a workflow one can specify the nodes to be skipped as per [documentation|https://oozie.apache.org/docs/5.0.0/DG_WorkflowReRun.html]. In case one of the nodes is a [subworkflow|https://oozie.apache.org/docs/5.0.0/WorkflowFunctionalSpec.html#a3.2.5_Sub-workflow_Action], a mechanism should exist to specify what nodes to skip within the subworkflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Attachment: OOZIE-3217.004.patch
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch,
> OOZIE-3217.003.patch, OOZIE-3217.004.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456586#comment-16456586
]
Peter Orova edited comment on OOZIE-3214 at 4/27/18 3:12 PM:
-
+1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way
in the coordinator.xml would definitely result a more natural interpretation of
the tag and thereby a better user experience.
Having said that, there is an area where a design decision needs to be made:
what happens to the workflows that are triggered in the time interval, omitted
or doubled by the DST change?
h2. Example from winter to summer:
Let us consider the US winter to summer change in 2018. The transition is the
following:
Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to
Sunday, 11 March 2018, *03:00:00* local daylight time.
Question 1:
* What happens to a workflow that should be triggered at 2:30 on March 11?
Should it be 'forgotten'? Should it be compensated for by launching an instance
at 3:00 local daylight time?
h2. Example from summer to winter:
Let us consider the US summer to winter change in 2018. The transition is the
following:
Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to
Sunday, 4 November 2018, *01:00:00* local standard time instead.
Question 2:
* What happens to a the workflow that is triggered at 1:30 on November 4?
Should it run twice? Should the "second" execution be omitted?
was (Author: orova):
+1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way
in the coordinator.xml would definitely result a more natural interpretation of
the tag and thereby a better user experience.
Having said that, there is an area where a design decision needs to be made:
what happens to the workflows that are triggered in the time interval, omitted
or doubled by the DST change?
h2. Example from winter to summer:
Let us consider the US winter to summer change in 2018. The transition is the
following:
Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to
Sunday, 11 March 2018, *03:00:00* local daylight time.
Question 1:
* What happens to a workflow that should be triggered at 2:30 on March 11?
Should it be 'forgotten'? Should it be compensated for by launching an instance
at 3:00 local daylight time?
h2. Example from summer to winter:
Let us consider the US summer to winter change in 2018. The transition is the
following:
Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to
Sunday, 4 November 2018, *01:00:00* local standard time instead.
Question 2:
* What happens to a the workflow that is triggered at 1:30? Should it run
twice? Should the "second" execution be omitted?
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Attachment: OOZIE-3217.002.patch
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3214) Allow configurable timezone for coordinators
[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456586#comment-16456586
]
Peter Orova commented on OOZIE-3214:
+1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way
in the coordinator.xml would definitely result a more natural interpretation of
the tag and thereby a better user experience.
Having said that, there is an area where a design decision needs to be made:
what happens to the workflows that are triggered in the time interval, omitted
or doubled by the DST change?
h2. Example from winter to summer:
Let us consider the US winter to summer change in 2018. The transition is the
following:
Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to
Sunday, 11 March 2018, *03:00:00* local daylight time.
Question 1:
* What happens to a workflow that should be triggered at 2:30 on March 11?
Should it be 'forgotten'? Should it be compensated for by launching an instance
at 3:00 local daylight time?
h2. Example from summer to winter:
Let us consider the US summer to winter change in 2018. The transition is the
following:
Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to
Sunday, 4 November 2018, *01:00:00* local standard time instead.
Question 2:
* What happens to a the workflow that is triggered at 1:30? Should it run
twice? Should the "second" execution be omitted?
> Allow configurable timezone for coordinators
>
>
> Key: OOZIE-3214
> URL: https://issues.apache.org/jira/browse/OOZIE-3214
> Project: Oozie
> Issue Type: New Feature
> Components: coordinator
>Affects Versions: trunk
>Reporter: Julia Kinga Marton
>Assignee: Julia Kinga Marton
>Priority: Major
>
> Right now in case of coordinators only daylight saving time corrections are
> applied, the processing timezone for the coordinators is always the Oozie
> processing timezone.
> It would be more transparent to have an option for changing the {{timezone}}
> attribute itself, such as an additional attribute in the {{coordinator.xml}}
> (meaning a new version of {{coordinator.xsd}}). I would make this option
> switched off by default(to have the actual behavior).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Attachment: OOZIE-3217.005.patch
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch,
> OOZIE-3217.003.patch, OOZIE-3217.004.patch, OOZIE-3217.005.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471983#comment-16471983
]
Peter Orova commented on OOZIE-3217:
[~andras.piros] thank you for your additional observations, please find
patch.006 attached addressing those.
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch, OOZIE-3217.002.patch,
> OOZIE-3217.003.patch, OOZIE-3217.004.patch, OOZIE-3217.005.patch,
> OOZIE-3217.006.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3275) [docs] Update AG_Install.twiki with Access Control List documentation
[
https://issues.apache.org/jira/browse/OOZIE-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515905#comment-16515905
]
Peter Orova commented on OOZIE-3275:
+1 lgtm
> [docs] Update AG_Install.twiki with Access Control List documentation
> -
>
> Key: OOZIE-3275
> URL: https://issues.apache.org/jira/browse/OOZIE-3275
> Project: Oozie
> Issue Type: Improvement
> Components: docs
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Attachments: OOZIE-3275.001.patch, OOZIE-3275.002.patch
>
>
> It's hard to find a detailed description about ACL based authorization setup.
> Let's extend {{AG_Install.twiki}} and have some.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OOZIE-3275) [docs] Update AG_Install.twiki with Access Control List documentation
[
https://issues.apache.org/jira/browse/OOZIE-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515905#comment-16515905
]
Peter Orova edited comment on OOZIE-3275 at 6/20/18 7:37 AM:
-
+1 lgtm (non binding)
was (Author: orova):
+1 lgtm
> [docs] Update AG_Install.twiki with Access Control List documentation
> -
>
> Key: OOZIE-3275
> URL: https://issues.apache.org/jira/browse/OOZIE-3275
> Project: Oozie
> Issue Type: Improvement
> Components: docs
>Affects Versions: 5.0.0
>Reporter: Andras Piros
>Assignee: Andras Piros
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3275.001.patch, OOZIE-3275.002.patch
>
>
> It's hard to find a detailed description about ACL based authorization setup.
> Let's extend {{AG_Install.twiki}} and have some.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OOZIE-3215) Improve testability for authorization
Peter Orova created OOZIE-3215: -- Summary: Improve testability for authorization Key: OOZIE-3215 URL: https://issues.apache.org/jira/browse/OOZIE-3215 Project: Oozie Issue Type: Improvement Reporter: Peter Orova The LocalOozie should be enhanced to be able to run integration tests on Authorisation. One way of achieving this could be to launch an embedded servlet container within. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3216) Enable Authorization testing on REST endpoints
Peter Orova created OOZIE-3216: -- Summary: Enable Authorization testing on REST endpoints Key: OOZIE-3216 URL: https://issues.apache.org/jira/browse/OOZIE-3216 Project: Oozie Issue Type: Improvement Reporter: Peter Orova Currently there is no straightforward way of testing the Authorization service's functionality together with the Rest endpoints. The authorization decisions are made based on the contents of the authToke and the authToken in the request is filled by the AuthenticationFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[ https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orova reassigned OOZIE-3217: -- Assignee: Peter Orova > Enable definition of admin users using oozie-site.xml > - > > Key: OOZIE-3217 > URL: https://issues.apache.org/jira/browse/OOZIE-3217 > Project: Oozie > Issue Type: Improvement >Reporter: Peter Orova >Assignee: Peter Orova >Priority: Minor > > Currently the list of admin users is defined in the adminusers.txt file hard > coded to the oozie config dir. For a more streamlined solution, we could > define the list of admin users via oozie-site.xml by introducing the > following configuration, which receives the comma separated values of the > users that are admins. > oozie.service.AuthorizationService.admin.users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
Peter Orova created OOZIE-3217: -- Summary: Enable definition of admin users using oozie-site.xml Key: OOZIE-3217 URL: https://issues.apache.org/jira/browse/OOZIE-3217 Project: Oozie Issue Type: Improvement Reporter: Peter Orova Currently the list of admin users is defined in the adminusers.txt file hard coded to the oozie config dir. For a more streamlined solution, we could define the list of admin users via oozie-site.xml by introducing the following configuration, which receives the comma separated values of the users that are admins. oozie.service.AuthorizationService.admin.users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435398#comment-16435398
]
Peter Orova commented on OOZIE-3217:
[~andras.piros], no I thought we could merge the contents of {{adminusers.txt}}
and the envisioned {{oozie-site.xml}}
parameters for backwards compatibility.
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16430243#comment-16430243 ] Peter Orova edited comment on OOZIE-3196 at 4/9/18 8:16 AM: Some follow up: # In the minimal viable product described by [~andras.piros] and [~dbist13], it seems that the authorization level of non-admin user in the current authorization scheme is not present. I.e. a user with read privileges on 'all' does not exist. Such user could be useful when creating dashboards and such. What do you all think? # As far as the different levels of authorization that should be enforced, as discussed with [~andras.piros] offline, a three level schema seems reasonable with the following levels: * level1 - no authorization * level2 - currently existing authorization (admins, and plain users - the latter having read privileges on all) * level3 - restricted (admins, users having r/w privileges on 'owned' items, possibly service user(s) having read only access) Could you share your thoughts on this? was (Author: orova): Some follow up: 1./ In the minimal viable product described by [~andras.piros] and [~dbist13], it seems that the authorization level of non-admin user in the current authorization scheme is not present. I.e. a user with read privileges on 'all' does not exist. Such user could be useful when creating dashboards and such. What do you all think? 2./ As far as the different levels of authorization that should be enforced, as discussed with [~andras.piros] offline, a three level schema seems reasonable with the following levels: level1 - no authorization level2 - currently existing authorization (admins, and plain users - the latter having read privileges on all) level3 - restricted (admins, users having r/w privileges on 'owned' items, possibly service user(s) having read only access) Could you share your thoughts on this? > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16430243#comment-16430243 ] Peter Orova commented on OOZIE-3196: Some follow up: 1./ In the minimal viable product described by [~andras.piros] and [~dbist13], it seems that the authorization level of non-admin user in the current authorization scheme is not present. I.e. a user with read privileges on 'all' does not exist. Such user could be useful when creating dashboards and such. What do you all think? 2./ As far as the different levels of authorization that should be enforced, as discussed with [~andras.piros] offline, a three level schema seems reasonable with the following levels: level1 - no authorization level2 - currently existing authorization (admins, and plain users - the latter having read privileges on all) level3 - restricted (admins, users having r/w privileges on 'owned' items, possibly service user(s) having read only access) Could you share your thoughts on this? > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437029#comment-16437029 ] Peter Orova commented on OOZIE-3196: Hello [~dionusos]! Thank you for your suggestion. I agree that an ACL like capability would bring value, although I believe a better way of doing that would be by providing an authorization API that could be used by 3rd party applications. What do you think? > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1, 5.0.0 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > Fix For: 5.1.0 > > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orova updated OOZIE-3196: --- Attachment: OOZIE-3196.001.patch > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1, 5.0.0 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > Fix For: 5.1.0 > > Attachments: OOZIE-3196.001.patch > > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437411#comment-16437411 ] Peter Orova commented on OOZIE-3196: WIP Patch - Web UI portions are not complete contains implementation for OOZIE-3217 > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1, 5.0.0 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > Fix For: 5.1.0 > > Attachments: OOZIE-3196.001.patch > > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Affects Version/s: (was: trunk)
5.0.0
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OOZIE-3217) Enable definition of admin users using oozie-site.xml
[
https://issues.apache.org/jira/browse/OOZIE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova updated OOZIE-3217:
---
Attachment: OOZIE-3217.001.patch
> Enable definition of admin users using oozie-site.xml
> -
>
> Key: OOZIE-3217
> URL: https://issues.apache.org/jira/browse/OOZIE-3217
> Project: Oozie
> Issue Type: Improvement
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
> Attachments: OOZIE-3217.001.patch
>
>
> Currently the list of admin users is defined in the {{adminusers.txt}} file
> hard coded to the Oozie config dir. For a more streamlined solution, we could
> define the list of admin users via {{oozie-site.xml}} by introducing the
> following configuration, which receives the comma separated values of the
> users that are admins.
> {{oozie.service.AuthorizationService.admin.users}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418626#comment-16418626 ] Peter Orova commented on OOZIE-3196: +1 for the internal implementation [~dbist13]. Let's focus first on the implementations necessary within Oozie, having in mind the possible integration patterns with external tools. As to the granularity, the best would be to secure the whole REST Api and the different use cases will have to be mapped to that. e.g. do we want to grant access to an "ordinary" user on oozie server configs? on server state? on the workflow list? > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3196) Authorization: restrict world readability by user
[ https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425248#comment-16425248 ] Peter Orova commented on OOZIE-3196: I think that from an integration perspective, securing the REST endpoints is the most impactful, and as such that should have the highest priority. The CLI uses the REST endpoints, so securing the REST takes care of that too. Not sure about the popularity of the UI, but I agree that it should also be addressed. > Authorization: restrict world readability by user > - > > Key: OOZIE-3196 > URL: https://issues.apache.org/jira/browse/OOZIE-3196 > Project: Oozie > Issue Type: New Feature > Components: bundle, coordinator, workflow >Affects Versions: 5.0.0b1 >Reporter: Andras Piros >Assignee: Peter Orova >Priority: Major > > The [*current authorization > model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the > enterprise requirements as everything is readable and writable by everyone by > default. > Write access can be restricted using authorization but restricting read > rights is only possible via Yarn ACLs and HDFS rights which still does not > prevent accessing the workflow, coordinator or bundle job’s configurations > for everyone. > Improve authorization so it’s possible to configure read/write access for > workflows, coordinators, and bundles in a more granular way. Could involve > Sentry during implementation or create and design a new system that fits the > needs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OOZIE-3362) When killed, SSH action should kill the spawned processes on target host
[ https://issues.apache.org/jira/browse/OOZIE-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orova reassigned OOZIE-3362: -- Assignee: Peter Orova > When killed, SSH action should kill the spawned processes on target host > > > Key: OOZIE-3362 > URL: https://issues.apache.org/jira/browse/OOZIE-3362 > Project: Oozie > Issue Type: Improvement >Reporter: Peter Orova >Assignee: Peter Orova >Priority: Major > > When killing a workflow running an ssh action, currently only the process > executing the ssh-wrapper.sh is killed on the target host. > Upon killing, the ssh action should not only kill the process executing the > wrapper script, but the one launched by that also. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3362) When killed, SSH action should kill the spawned processes on target host
Peter Orova created OOZIE-3362: -- Summary: When killed, SSH action should kill the spawned processes on target host Key: OOZIE-3362 URL: https://issues.apache.org/jira/browse/OOZIE-3362 Project: Oozie Issue Type: Improvement Reporter: Peter Orova When killing a workflow running an ssh action, currently only the process executing the ssh-wrapper.sh is killed on the target host. Upon killing, the ssh action should not only kill the process executing the wrapper script, but the one launched by that also. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3405) SSH action shows empty error Message and Error code
[
https://issues.apache.org/jira/browse/OOZIE-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732765#comment-16732765
]
Peter Orova commented on OOZIE-3405:
[~asalamon74] Thank you for your insight, so setting the {{errorCode}} is off
the table. Do you think we could still provide some information via the
{{wf:errorMessage(String message)}} function? If we stored the return value of
the script in the {{.error}} file, could we return that via the
{{errorMessage}} function in the case of SSH actions?
> SSH action shows empty error Message and Error code
> ---
>
> Key: OOZIE-3405
> URL: https://issues.apache.org/jira/browse/OOZIE-3405
> Project: Oozie
> Issue Type: Improvement
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
>
> Currently, when an SSH action fails the only message that is returned is the
> Status. Neither the {{error Message}} nor {{Error code}} fields are filled.
> This makes reporting on the causes of SSH Action failures via Oozie highly
> impractical: the only meaningful bit of information there is on a failed SSH
> Action is the Status.
> The Status is filled based on the presence (or lack of) the {{.error file}}
> that is produced in case the user submitted script returns with any other
> value than 0.
> {noformat}
> SshActionExecutor#getActionStatus
> ...
> String outFile = getRemoteFileName(context, action, "error", false, true);
> String checkErrorCmd = SSH_COMMAND_BASE + action.getTrackerUri() + " ls " +
> outFile;
> int retVal = getReturnValue(checkErrorCmd);
> ...
> {noformat}
>
> User requirement is to provide some more detailed information on the
> success/failure of the user-submitted script. That could be at a minimum the
> return value, optionally the last ~1K of the stderr that is drained. This
> information could then be communicated via {{errorMessage}} and {{ErrorCode}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OOZIE-3424) Enable definition of admin users on a group membership basis
[ https://issues.apache.org/jira/browse/OOZIE-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Orova reassigned OOZIE-3424: -- Assignee: Peter Orova > Enable definition of admin users on a group membership basis > > > Key: OOZIE-3424 > URL: https://issues.apache.org/jira/browse/OOZIE-3424 > Project: Oozie > Issue Type: Improvement >Reporter: Peter Orova >Assignee: Peter Orova >Priority: Major > > As per [OOZIE-3217|https://issues.apache.org/jira/browse/OOZIE-3217] the > administrative users are defined on a per user basis. > Introducing a group based definition of access would be the next step towards > a role based access control. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3424) Enable definition of admin users on a group membership basis
Peter Orova created OOZIE-3424: -- Summary: Enable definition of admin users on a group membership basis Key: OOZIE-3424 URL: https://issues.apache.org/jira/browse/OOZIE-3424 Project: Oozie Issue Type: Improvement Reporter: Peter Orova As per [OOZIE-3217|https://issues.apache.org/jira/browse/OOZIE-3217] the administrative users are defined on a per user basis. Introducing a group based definition of access would be the next step towards a role based access control. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3405) SSH action shows empty error Message and Error code
Peter Orova created OOZIE-3405:
--
Summary: SSH action shows empty error Message and Error code
Key: OOZIE-3405
URL: https://issues.apache.org/jira/browse/OOZIE-3405
Project: Oozie
Issue Type: Improvement
Reporter: Peter Orova
Currently, when an SSH action fails the only message that is returned is the
Status. Neither the {{error Message}} nor {{Error code}} fields are filled.
This makes reporting on the causes of SSH Action failures via Oozie highly
impractical: the only meaningful bit of information there is on a failed SSH
Action is the Status.
The Status is filled based on the presence (or lack of) the {{.error file}}
that is produced in case the user submitted script returns with any other value
than 0.
{noformat}
SshActionExecutor#getActionStatus
...
String outFile = getRemoteFileName(context, action, "error", false, true);
String checkErrorCmd = SSH_COMMAND_BASE + action.getTrackerUri() + " ls " +
outFile;
int retVal = getReturnValue(checkErrorCmd);
...
{noformat}
User requirement is to provide some more detailed information on the
success/failure of the user-submitted script. That could be at a minimum the
return value, optionally the last ~1K of the stderr that is drained. This
information could then be communicated via {{errorMessage}} and {{ErrorCode}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OOZIE-3405) SSH action shows empty error Message and Error code
[
https://issues.apache.org/jira/browse/OOZIE-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Orova reassigned OOZIE-3405:
--
Assignee: Peter Orova
> SSH action shows empty error Message and Error code
> ---
>
> Key: OOZIE-3405
> URL: https://issues.apache.org/jira/browse/OOZIE-3405
> Project: Oozie
> Issue Type: Improvement
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
>
> Currently, when an SSH action fails the only message that is returned is the
> Status. Neither the {{error Message}} nor {{Error code}} fields are filled.
> This makes reporting on the causes of SSH Action failures via Oozie highly
> impractical: the only meaningful bit of information there is on a failed SSH
> Action is the Status.
> The Status is filled based on the presence (or lack of) the {{.error file}}
> that is produced in case the user submitted script returns with any other
> value than 0.
> {noformat}
> SshActionExecutor#getActionStatus
> ...
> String outFile = getRemoteFileName(context, action, "error", false, true);
> String checkErrorCmd = SSH_COMMAND_BASE + action.getTrackerUri() + " ls " +
> outFile;
> int retVal = getReturnValue(checkErrorCmd);
> ...
> {noformat}
>
> User requirement is to provide some more detailed information on the
> success/failure of the user-submitted script. That could be at a minimum the
> return value, optionally the last ~1K of the stderr that is drained. This
> information could then be communicated via {{errorMessage}} and {{ErrorCode}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OOZIE-3405) SSH action shows empty error Message and Error code
[
https://issues.apache.org/jira/browse/OOZIE-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724854#comment-16724854
]
Peter Orova commented on OOZIE-3405:
For the {{errorCode}} we could write the exit code of the submitted user script
into the {{.error}} file that is touched on failure. Any thoughts
[~asalamon74], [~andras.piros]?
> SSH action shows empty error Message and Error code
> ---
>
> Key: OOZIE-3405
> URL: https://issues.apache.org/jira/browse/OOZIE-3405
> Project: Oozie
> Issue Type: Improvement
>Reporter: Peter Orova
>Assignee: Peter Orova
>Priority: Minor
>
> Currently, when an SSH action fails the only message that is returned is the
> Status. Neither the {{error Message}} nor {{Error code}} fields are filled.
> This makes reporting on the causes of SSH Action failures via Oozie highly
> impractical: the only meaningful bit of information there is on a failed SSH
> Action is the Status.
> The Status is filled based on the presence (or lack of) the {{.error file}}
> that is produced in case the user submitted script returns with any other
> value than 0.
> {noformat}
> SshActionExecutor#getActionStatus
> ...
> String outFile = getRemoteFileName(context, action, "error", false, true);
> String checkErrorCmd = SSH_COMMAND_BASE + action.getTrackerUri() + " ls " +
> outFile;
> int retVal = getReturnValue(checkErrorCmd);
> ...
> {noformat}
>
> User requirement is to provide some more detailed information on the
> success/failure of the user-submitted script. That could be at a minimum the
> return value, optionally the last ~1K of the stderr that is drained. This
> information could then be communicated via {{errorMessage}} and {{ErrorCode}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OOZIE-3430) Filter by endTime on Jobs servlet
Peter Orova created OOZIE-3430:
--
Summary: Filter by endTime on Jobs servlet
Key: OOZIE-3430
URL: https://issues.apache.org/jira/browse/OOZIE-3430
Project: Oozie
Issue Type: Improvement
Reporter: Peter Orova
As per [documentation |
https://oozie.apache.org/docs/5.1.0/DG_CommandLineTool.html#Checking_the_Status_of_multiple_Workflow_Jobs]
when retrieving the information on multiple jobs the only time-related filter
is based on {{createdtime}}. Propose to add filters for {{endTime}}.
Use case: display jobs having finished in the last n minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
