You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by Robert Kanter <rk...@cloudera.com> on 2013/03/14 01:30:58 UTC
JIRAs in branch-3.3 that aren't in branch-4.0
Hi,
I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in branch-4.0
(4.0.0):
OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add ability
to configure Oozie to use HTTPS (SSL)
OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242> Dryrun option
for workflows mentions version 3.4 when it should be 3.3.2
OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set the
renewer correctly for JT/RM delegation tokens
OOZIE-1242: a trivial docs change, so no reason not to put into branch-4.0.
What about the other two? We can put them into branch-4.0 too or move them
only to trunk.
thanks
- Robert
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
Thanks for taking a look (you obviously figured it out, but I meant
OOZIE-1268 not OOZIE-670 in my last message). I just committed it to trunk
and branch-3.3; can you port OOZIE-1233 and OOZIE-1268 to branch-4.0? And
also OOZIE-1242? I think everything will be in sync then :)
thanks
- Robert
On Fri, Mar 15, 2013 at 2:50 PM, Robert Kanter <rk...@cloudera.com> wrote:
> I've just uploaded a patch to OOZIE-670 with the fix. I had to make some
> other changes in how the scripts handle the files to make it work better;
> its explained in the comments. Please take a look.
>
> thanks
> - Robert
>
>
>
> On Fri, Mar 15, 2013 at 2:24 PM, Robert Kanter <rk...@cloudera.com>wrote:
>
>> Ya, I've just re-worked how it moves the ssl files around in
>> oozie-setup.sh and addtowar.sh. I need to check with Bowen about
>> OOZIE-670 <https://issues.apache.org/jira/browse/OOZIE-670> (Merge
>> addtowar and oozie-setup scripts into one) on whether he minds rebasing it
>> on my changes for OOZIE-1268 or if I should wait and rebase on his changes
>> in OOZIE-670.
>>
>> - Robert
>>
>>
>> On Fri, Mar 15, 2013 at 12:56 PM, Mona Chitnis <ch...@yahoo-inc.com>wrote:
>>
>>> Yes that sounds like the right approach Robert. Will you be updating
>>> OOZIE-1268 with this change?
>>>
>>> Thanks,
>>>
>>> Mona
>>>
>>> On 3/14/13 4:50 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>>
>>> >I'll look into it more tomorrow, but I think the fix is to make the
>>> >-secure
>>> >option take an optional path to the dir containing server.xml etc;
>>> >otherwise, it will default to the current behavior. Does that sound
>>> like
>>> >the right approach?
>>> >I've created OOZIE-1268 for this.
>>> >
>>> >thanks
>>> >- Robert
>>> >
>>> >
>>> >On Thu, Mar 14, 2013 at 4:10 PM, Mona Chitnis <ch...@yahoo-inc.com>
>>> >wrote:
>>> >
>>> >> Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes
>>> >>'addtowar'
>>> >> directly and not the oozie-setup way that sources from oozie-sys
>>> >>(default
>>> >> CONFIG value). The conf dir path is then a tomcat specific property,
>>> >> instead of an Oozie env variable.
>>> >>
>>> >> I am guessing some other users might also have such alternate scripts
>>> >>for
>>> >> setting up their servers.
>>> >>
>>> >> - Mona
>>> >>
>>> >>
>>> >> On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>> >>
>>> >> >The reason I put the non-https files in there too is so that if you
>>> >>want
>>> >> >to
>>> >> >get rid of ssl, you can simply re-run oozie-setup.sh prepare-war
>>> >>without
>>> >> >the -secure option and it will put back the non-ssl versions of the
>>> >>files.
>>> >> > There shouldn't be any manual steps; the assemblies/distro.xml file
>>> >> >should
>>> >> >have copied server.xml and web.xml to the conf/ssl folder. One thing
>>> >>that
>>> >> >I just realized I didn't check is when you use a different location
>>> for
>>> >> >the
>>> >> >conf folder other than the default one; are you using the default
>>> conf
>>> >> >folder or did you change the env var to point to somewhere else?
>>> >> >
>>> >> >
>>> >> >- Robert
>>> >> >
>>> >> >
>>> >> >
>>> >> >On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <chitnis@yahoo-inc.com
>>> >
>>> >> >wrote:
>>> >> >
>>> >> >> Robert,
>>> >> >>
>>> >> >> I took a look at patch OOZIE-1233 and I was concerned about how the
>>> >> >>folder
>>> >> >> "ssl" is generated and why do the non-https server.xml and web.xml
>>> >>need
>>> >> >>to
>>> >> >> reside inside the 'ssl' folder. Running addtowar script in our
>>> >>existing
>>> >> >> environment is breaking with
>>> >> >>
>>> >> >> "File/Dir does no exist: /ssl/server.xml"
>>> >> >>
>>> >> >> So is this a new manual step?
>>> >> >>
>>> >> >> --
>>> >> >> Mona
>>> >> >>
>>> >> >> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>> >> >>
>>> >> >> >Ya, OOZIE-1233 and OOZIE-1242.
>>> >> >> >
>>> >> >> >- Robert
>>> >> >> >
>>> >> >> >
>>> >> >> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
>>> >> >> >rohini.aditya@gmail.com> wrote:
>>> >> >> >
>>> >> >> >> Robert,
>>> >> >> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other
>>> >>jira
>>> >> >>you
>>> >> >> >>are
>>> >> >> >> asking about?
>>> >> >> >>
>>> >> >> >> Regards,
>>> >> >> >> Rohini
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter
>>> >><rkanter@cloudera.com
>>> >> >
>>> >> >> >> wrote:
>>> >> >> >>
>>> >> >> >> > Hi,
>>> >> >> >> >
>>> >> >> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
>>> >> >>branch-4.0
>>> >> >> >> > (4.0.0):
>>> >> >> >> >
>>> >> >> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233>
>>> >>Add
>>> >> >> >> ability
>>> >> >> >> > to configure Oozie to use HTTPS (SSL)
>>> >> >> >> >
>>> >> >> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
>>> >> >>Dryrun
>>> >> >> >> > option
>>> >> >> >> > for workflows mentions version 3.4 when it should be 3.3.2
>>> >> >> >> >
>>> >> >> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148>
>>> >>Set
>>> >> >>the
>>> >> >> >> > renewer correctly for JT/RM delegation tokens
>>> >> >> >> >
>>> >> >> >> > OOZIE-1242: a trivial docs change, so no reason not to put
>>> into
>>> >> >> >> branch-4.0.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > What about the other two? We can put them into branch-4.0 too
>>> >>or
>>> >> >>move
>>> >> >> >> them
>>> >> >> >> > only to trunk.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > thanks
>>> >> >> >> > - Robert
>>> >> >> >> >
>>> >> >> >>
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>
>>
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
I've just uploaded a patch to OOZIE-670 with the fix. I had to make some
other changes in how the scripts handle the files to make it work better;
its explained in the comments. Please take a look.
thanks
- Robert
On Fri, Mar 15, 2013 at 2:24 PM, Robert Kanter <rk...@cloudera.com> wrote:
> Ya, I've just re-worked how it moves the ssl files around in
> oozie-setup.sh and addtowar.sh. I need to check with Bowen about
> OOZIE-670 <https://issues.apache.org/jira/browse/OOZIE-670> (Merge
> addtowar and oozie-setup scripts into one) on whether he minds rebasing it
> on my changes for OOZIE-1268 or if I should wait and rebase on his changes
> in OOZIE-670.
>
> - Robert
>
>
> On Fri, Mar 15, 2013 at 12:56 PM, Mona Chitnis <ch...@yahoo-inc.com>wrote:
>
>> Yes that sounds like the right approach Robert. Will you be updating
>> OOZIE-1268 with this change?
>>
>> Thanks,
>>
>> Mona
>>
>> On 3/14/13 4:50 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>
>> >I'll look into it more tomorrow, but I think the fix is to make the
>> >-secure
>> >option take an optional path to the dir containing server.xml etc;
>> >otherwise, it will default to the current behavior. Does that sound like
>> >the right approach?
>> >I've created OOZIE-1268 for this.
>> >
>> >thanks
>> >- Robert
>> >
>> >
>> >On Thu, Mar 14, 2013 at 4:10 PM, Mona Chitnis <ch...@yahoo-inc.com>
>> >wrote:
>> >
>> >> Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes
>> >>'addtowar'
>> >> directly and not the oozie-setup way that sources from oozie-sys
>> >>(default
>> >> CONFIG value). The conf dir path is then a tomcat specific property,
>> >> instead of an Oozie env variable.
>> >>
>> >> I am guessing some other users might also have such alternate scripts
>> >>for
>> >> setting up their servers.
>> >>
>> >> - Mona
>> >>
>> >>
>> >> On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>> >>
>> >> >The reason I put the non-https files in there too is so that if you
>> >>want
>> >> >to
>> >> >get rid of ssl, you can simply re-run oozie-setup.sh prepare-war
>> >>without
>> >> >the -secure option and it will put back the non-ssl versions of the
>> >>files.
>> >> > There shouldn't be any manual steps; the assemblies/distro.xml file
>> >> >should
>> >> >have copied server.xml and web.xml to the conf/ssl folder. One thing
>> >>that
>> >> >I just realized I didn't check is when you use a different location
>> for
>> >> >the
>> >> >conf folder other than the default one; are you using the default conf
>> >> >folder or did you change the env var to point to somewhere else?
>> >> >
>> >> >
>> >> >- Robert
>> >> >
>> >> >
>> >> >
>> >> >On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com>
>> >> >wrote:
>> >> >
>> >> >> Robert,
>> >> >>
>> >> >> I took a look at patch OOZIE-1233 and I was concerned about how the
>> >> >>folder
>> >> >> "ssl" is generated and why do the non-https server.xml and web.xml
>> >>need
>> >> >>to
>> >> >> reside inside the 'ssl' folder. Running addtowar script in our
>> >>existing
>> >> >> environment is breaking with
>> >> >>
>> >> >> "File/Dir does no exist: /ssl/server.xml"
>> >> >>
>> >> >> So is this a new manual step?
>> >> >>
>> >> >> --
>> >> >> Mona
>> >> >>
>> >> >> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>> >> >>
>> >> >> >Ya, OOZIE-1233 and OOZIE-1242.
>> >> >> >
>> >> >> >- Robert
>> >> >> >
>> >> >> >
>> >> >> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
>> >> >> >rohini.aditya@gmail.com> wrote:
>> >> >> >
>> >> >> >> Robert,
>> >> >> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other
>> >>jira
>> >> >>you
>> >> >> >>are
>> >> >> >> asking about?
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Rohini
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter
>> >><rkanter@cloudera.com
>> >> >
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
>> >> >>branch-4.0
>> >> >> >> > (4.0.0):
>> >> >> >> >
>> >> >> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233>
>> >>Add
>> >> >> >> ability
>> >> >> >> > to configure Oozie to use HTTPS (SSL)
>> >> >> >> >
>> >> >> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
>> >> >>Dryrun
>> >> >> >> > option
>> >> >> >> > for workflows mentions version 3.4 when it should be 3.3.2
>> >> >> >> >
>> >> >> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148>
>> >>Set
>> >> >>the
>> >> >> >> > renewer correctly for JT/RM delegation tokens
>> >> >> >> >
>> >> >> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
>> >> >> >> branch-4.0.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > What about the other two? We can put them into branch-4.0 too
>> >>or
>> >> >>move
>> >> >> >> them
>> >> >> >> > only to trunk.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > thanks
>> >> >> >> > - Robert
>> >> >> >> >
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
Ya, I've just re-worked how it moves the ssl files around in oozie-setup.sh
and addtowar.sh. I need to check with Bowen about
OOZIE-670<https://issues.apache.org/jira/browse/OOZIE-670> (Merge
addtowar and oozie-setup scripts into one) on whether he minds rebasing it
on my changes for OOZIE-1268 or if I should wait and rebase on his changes
in OOZIE-670.
- Robert
On Fri, Mar 15, 2013 at 12:56 PM, Mona Chitnis <ch...@yahoo-inc.com>wrote:
> Yes that sounds like the right approach Robert. Will you be updating
> OOZIE-1268 with this change?
>
> Thanks,
>
> Mona
>
> On 3/14/13 4:50 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>
> >I'll look into it more tomorrow, but I think the fix is to make the
> >-secure
> >option take an optional path to the dir containing server.xml etc;
> >otherwise, it will default to the current behavior. Does that sound like
> >the right approach?
> >I've created OOZIE-1268 for this.
> >
> >thanks
> >- Robert
> >
> >
> >On Thu, Mar 14, 2013 at 4:10 PM, Mona Chitnis <ch...@yahoo-inc.com>
> >wrote:
> >
> >> Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes
> >>'addtowar'
> >> directly and not the oozie-setup way that sources from oozie-sys
> >>(default
> >> CONFIG value). The conf dir path is then a tomcat specific property,
> >> instead of an Oozie env variable.
> >>
> >> I am guessing some other users might also have such alternate scripts
> >>for
> >> setting up their servers.
> >>
> >> - Mona
> >>
> >>
> >> On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
> >>
> >> >The reason I put the non-https files in there too is so that if you
> >>want
> >> >to
> >> >get rid of ssl, you can simply re-run oozie-setup.sh prepare-war
> >>without
> >> >the -secure option and it will put back the non-ssl versions of the
> >>files.
> >> > There shouldn't be any manual steps; the assemblies/distro.xml file
> >> >should
> >> >have copied server.xml and web.xml to the conf/ssl folder. One thing
> >>that
> >> >I just realized I didn't check is when you use a different location for
> >> >the
> >> >conf folder other than the default one; are you using the default conf
> >> >folder or did you change the env var to point to somewhere else?
> >> >
> >> >
> >> >- Robert
> >> >
> >> >
> >> >
> >> >On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com>
> >> >wrote:
> >> >
> >> >> Robert,
> >> >>
> >> >> I took a look at patch OOZIE-1233 and I was concerned about how the
> >> >>folder
> >> >> "ssl" is generated and why do the non-https server.xml and web.xml
> >>need
> >> >>to
> >> >> reside inside the 'ssl' folder. Running addtowar script in our
> >>existing
> >> >> environment is breaking with
> >> >>
> >> >> "File/Dir does no exist: /ssl/server.xml"
> >> >>
> >> >> So is this a new manual step?
> >> >>
> >> >> --
> >> >> Mona
> >> >>
> >> >> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
> >> >>
> >> >> >Ya, OOZIE-1233 and OOZIE-1242.
> >> >> >
> >> >> >- Robert
> >> >> >
> >> >> >
> >> >> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
> >> >> >rohini.aditya@gmail.com> wrote:
> >> >> >
> >> >> >> Robert,
> >> >> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other
> >>jira
> >> >>you
> >> >> >>are
> >> >> >> asking about?
> >> >> >>
> >> >> >> Regards,
> >> >> >> Rohini
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter
> >><rkanter@cloudera.com
> >> >
> >> >> >> wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
> >> >>branch-4.0
> >> >> >> > (4.0.0):
> >> >> >> >
> >> >> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233>
> >>Add
> >> >> >> ability
> >> >> >> > to configure Oozie to use HTTPS (SSL)
> >> >> >> >
> >> >> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
> >> >>Dryrun
> >> >> >> > option
> >> >> >> > for workflows mentions version 3.4 when it should be 3.3.2
> >> >> >> >
> >> >> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148>
> >>Set
> >> >>the
> >> >> >> > renewer correctly for JT/RM delegation tokens
> >> >> >> >
> >> >> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
> >> >> >> branch-4.0.
> >> >> >> >
> >> >> >> >
> >> >> >> > What about the other two? We can put them into branch-4.0 too
> >>or
> >> >>move
> >> >> >> them
> >> >> >> > only to trunk.
> >> >> >> >
> >> >> >> >
> >> >> >> > thanks
> >> >> >> > - Robert
> >> >> >> >
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Mona Chitnis <ch...@yahoo-inc.com>.
Yes that sounds like the right approach Robert. Will you be updating
OOZIE-1268 with this change?
Thanks,
Mona
On 3/14/13 4:50 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>I'll look into it more tomorrow, but I think the fix is to make the
>-secure
>option take an optional path to the dir containing server.xml etc;
>otherwise, it will default to the current behavior. Does that sound like
>the right approach?
>I've created OOZIE-1268 for this.
>
>thanks
>- Robert
>
>
>On Thu, Mar 14, 2013 at 4:10 PM, Mona Chitnis <ch...@yahoo-inc.com>
>wrote:
>
>> Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes
>>'addtowar'
>> directly and not the oozie-setup way that sources from oozie-sys
>>(default
>> CONFIG value). The conf dir path is then a tomcat specific property,
>> instead of an Oozie env variable.
>>
>> I am guessing some other users might also have such alternate scripts
>>for
>> setting up their servers.
>>
>> - Mona
>>
>>
>> On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>
>> >The reason I put the non-https files in there too is so that if you
>>want
>> >to
>> >get rid of ssl, you can simply re-run oozie-setup.sh prepare-war
>>without
>> >the -secure option and it will put back the non-ssl versions of the
>>files.
>> > There shouldn't be any manual steps; the assemblies/distro.xml file
>> >should
>> >have copied server.xml and web.xml to the conf/ssl folder. One thing
>>that
>> >I just realized I didn't check is when you use a different location for
>> >the
>> >conf folder other than the default one; are you using the default conf
>> >folder or did you change the env var to point to somewhere else?
>> >
>> >
>> >- Robert
>> >
>> >
>> >
>> >On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com>
>> >wrote:
>> >
>> >> Robert,
>> >>
>> >> I took a look at patch OOZIE-1233 and I was concerned about how the
>> >>folder
>> >> "ssl" is generated and why do the non-https server.xml and web.xml
>>need
>> >>to
>> >> reside inside the 'ssl' folder. Running addtowar script in our
>>existing
>> >> environment is breaking with
>> >>
>> >> "File/Dir does no exist: /ssl/server.xml"
>> >>
>> >> So is this a new manual step?
>> >>
>> >> --
>> >> Mona
>> >>
>> >> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>> >>
>> >> >Ya, OOZIE-1233 and OOZIE-1242.
>> >> >
>> >> >- Robert
>> >> >
>> >> >
>> >> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
>> >> >rohini.aditya@gmail.com> wrote:
>> >> >
>> >> >> Robert,
>> >> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other
>>jira
>> >>you
>> >> >>are
>> >> >> asking about?
>> >> >>
>> >> >> Regards,
>> >> >> Rohini
>> >> >>
>> >> >>
>> >> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter
>><rkanter@cloudera.com
>> >
>> >> >> wrote:
>> >> >>
>> >> >> > Hi,
>> >> >> >
>> >> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
>> >>branch-4.0
>> >> >> > (4.0.0):
>> >> >> >
>> >> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233>
>>Add
>> >> >> ability
>> >> >> > to configure Oozie to use HTTPS (SSL)
>> >> >> >
>> >> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
>> >>Dryrun
>> >> >> > option
>> >> >> > for workflows mentions version 3.4 when it should be 3.3.2
>> >> >> >
>> >> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148>
>>Set
>> >>the
>> >> >> > renewer correctly for JT/RM delegation tokens
>> >> >> >
>> >> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
>> >> >> branch-4.0.
>> >> >> >
>> >> >> >
>> >> >> > What about the other two? We can put them into branch-4.0 too
>>or
>> >>move
>> >> >> them
>> >> >> > only to trunk.
>> >> >> >
>> >> >> >
>> >> >> > thanks
>> >> >> > - Robert
>> >> >> >
>> >> >>
>> >>
>> >>
>>
>>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
I'll look into it more tomorrow, but I think the fix is to make the -secure
option take an optional path to the dir containing server.xml etc;
otherwise, it will default to the current behavior. Does that sound like
the right approach?
I've created OOZIE-1268 for this.
thanks
- Robert
On Thu, Mar 14, 2013 at 4:10 PM, Mona Chitnis <ch...@yahoo-inc.com> wrote:
> Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes 'addtowar'
> directly and not the oozie-setup way that sources from oozie-sys (default
> CONFIG value). The conf dir path is then a tomcat specific property,
> instead of an Oozie env variable.
>
> I am guessing some other users might also have such alternate scripts for
> setting up their servers.
>
> - Mona
>
>
> On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>
> >The reason I put the non-https files in there too is so that if you want
> >to
> >get rid of ssl, you can simply re-run oozie-setup.sh prepare-war without
> >the -secure option and it will put back the non-ssl versions of the files.
> > There shouldn't be any manual steps; the assemblies/distro.xml file
> >should
> >have copied server.xml and web.xml to the conf/ssl folder. One thing that
> >I just realized I didn't check is when you use a different location for
> >the
> >conf folder other than the default one; are you using the default conf
> >folder or did you change the env var to point to somewhere else?
> >
> >
> >- Robert
> >
> >
> >
> >On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com>
> >wrote:
> >
> >> Robert,
> >>
> >> I took a look at patch OOZIE-1233 and I was concerned about how the
> >>folder
> >> "ssl" is generated and why do the non-https server.xml and web.xml need
> >>to
> >> reside inside the 'ssl' folder. Running addtowar script in our existing
> >> environment is breaking with
> >>
> >> "File/Dir does no exist: /ssl/server.xml"
> >>
> >> So is this a new manual step?
> >>
> >> --
> >> Mona
> >>
> >> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
> >>
> >> >Ya, OOZIE-1233 and OOZIE-1242.
> >> >
> >> >- Robert
> >> >
> >> >
> >> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
> >> >rohini.aditya@gmail.com> wrote:
> >> >
> >> >> Robert,
> >> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira
> >>you
> >> >>are
> >> >> asking about?
> >> >>
> >> >> Regards,
> >> >> Rohini
> >> >>
> >> >>
> >> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rkanter@cloudera.com
> >
> >> >> wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
> >>branch-4.0
> >> >> > (4.0.0):
> >> >> >
> >> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add
> >> >> ability
> >> >> > to configure Oozie to use HTTPS (SSL)
> >> >> >
> >> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
> >>Dryrun
> >> >> > option
> >> >> > for workflows mentions version 3.4 when it should be 3.3.2
> >> >> >
> >> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set
> >>the
> >> >> > renewer correctly for JT/RM delegation tokens
> >> >> >
> >> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
> >> >> branch-4.0.
> >> >> >
> >> >> >
> >> >> > What about the other two? We can put them into branch-4.0 too or
> >>move
> >> >> them
> >> >> > only to trunk.
> >> >> >
> >> >> >
> >> >> > thanks
> >> >> > - Robert
> >> >> >
> >> >>
> >>
> >>
>
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Mona Chitnis <ch...@yahoo-inc.com>.
Yes that was the other thing - $OOZIE_CONFIG. Our setup invokes 'addtowar'
directly and not the oozie-setup way that sources from oozie-sys (default
CONFIG value). The conf dir path is then a tomcat specific property,
instead of an Oozie env variable.
I am guessing some other users might also have such alternate scripts for
setting up their servers.
- Mona
On 3/14/13 3:37 PM, "Robert Kanter" <rk...@cloudera.com> wrote:
>The reason I put the non-https files in there too is so that if you want
>to
>get rid of ssl, you can simply re-run oozie-setup.sh prepare-war without
>the -secure option and it will put back the non-ssl versions of the files.
> There shouldn't be any manual steps; the assemblies/distro.xml file
>should
>have copied server.xml and web.xml to the conf/ssl folder. One thing that
>I just realized I didn't check is when you use a different location for
>the
>conf folder other than the default one; are you using the default conf
>folder or did you change the env var to point to somewhere else?
>
>
>- Robert
>
>
>
>On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com>
>wrote:
>
>> Robert,
>>
>> I took a look at patch OOZIE-1233 and I was concerned about how the
>>folder
>> "ssl" is generated and why do the non-https server.xml and web.xml need
>>to
>> reside inside the 'ssl' folder. Running addtowar script in our existing
>> environment is breaking with
>>
>> "File/Dir does no exist: /ssl/server.xml"
>>
>> So is this a new manual step?
>>
>> --
>> Mona
>>
>> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>>
>> >Ya, OOZIE-1233 and OOZIE-1242.
>> >
>> >- Robert
>> >
>> >
>> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
>> >rohini.aditya@gmail.com> wrote:
>> >
>> >> Robert,
>> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira
>>you
>> >>are
>> >> asking about?
>> >>
>> >> Regards,
>> >> Rohini
>> >>
>> >>
>> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rk...@cloudera.com>
>> >> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in
>>branch-4.0
>> >> > (4.0.0):
>> >> >
>> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add
>> >> ability
>> >> > to configure Oozie to use HTTPS (SSL)
>> >> >
>> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242>
>>Dryrun
>> >> > option
>> >> > for workflows mentions version 3.4 when it should be 3.3.2
>> >> >
>> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set
>>the
>> >> > renewer correctly for JT/RM delegation tokens
>> >> >
>> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
>> >> branch-4.0.
>> >> >
>> >> >
>> >> > What about the other two? We can put them into branch-4.0 too or
>>move
>> >> them
>> >> > only to trunk.
>> >> >
>> >> >
>> >> > thanks
>> >> > - Robert
>> >> >
>> >>
>>
>>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
The reason I put the non-https files in there too is so that if you want to
get rid of ssl, you can simply re-run oozie-setup.sh prepare-war without
the -secure option and it will put back the non-ssl versions of the files.
There shouldn't be any manual steps; the assemblies/distro.xml file should
have copied server.xml and web.xml to the conf/ssl folder. One thing that
I just realized I didn't check is when you use a different location for the
conf folder other than the default one; are you using the default conf
folder or did you change the env var to point to somewhere else?
- Robert
On Thu, Mar 14, 2013 at 2:56 PM, Mona Chitnis <ch...@yahoo-inc.com> wrote:
> Robert,
>
> I took a look at patch OOZIE-1233 and I was concerned about how the folder
> "ssl" is generated and why do the non-https server.xml and web.xml need to
> reside inside the 'ssl' folder. Running addtowar script in our existing
> environment is breaking with
>
> "File/Dir does no exist: /ssl/server.xml"
>
> So is this a new manual step?
>
> --
> Mona
>
> On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>
> >Ya, OOZIE-1233 and OOZIE-1242.
> >
> >- Robert
> >
> >
> >On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
> >rohini.aditya@gmail.com> wrote:
> >
> >> Robert,
> >> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira you
> >>are
> >> asking about?
> >>
> >> Regards,
> >> Rohini
> >>
> >>
> >> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rk...@cloudera.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in branch-4.0
> >> > (4.0.0):
> >> >
> >> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add
> >> ability
> >> > to configure Oozie to use HTTPS (SSL)
> >> >
> >> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242> Dryrun
> >> > option
> >> > for workflows mentions version 3.4 when it should be 3.3.2
> >> >
> >> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set the
> >> > renewer correctly for JT/RM delegation tokens
> >> >
> >> > OOZIE-1242: a trivial docs change, so no reason not to put into
> >> branch-4.0.
> >> >
> >> >
> >> > What about the other two? We can put them into branch-4.0 too or move
> >> them
> >> > only to trunk.
> >> >
> >> >
> >> > thanks
> >> > - Robert
> >> >
> >>
>
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Mona Chitnis <ch...@yahoo-inc.com>.
Robert,
I took a look at patch OOZIE-1233 and I was concerned about how the folder
"ssl" is generated and why do the non-https server.xml and web.xml need to
reside inside the 'ssl' folder. Running addtowar script in our existing
environment is breaking with
"File/Dir does no exist: /ssl/server.xml"
So is this a new manual step?
--
Mona
On 3/14/13 9:57 AM, "Robert Kanter" <rk...@cloudera.com> wrote:
>Ya, OOZIE-1233 and OOZIE-1242.
>
>- Robert
>
>
>On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
>rohini.aditya@gmail.com> wrote:
>
>> Robert,
>> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira you
>>are
>> asking about?
>>
>> Regards,
>> Rohini
>>
>>
>> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rk...@cloudera.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in branch-4.0
>> > (4.0.0):
>> >
>> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add
>> ability
>> > to configure Oozie to use HTTPS (SSL)
>> >
>> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242> Dryrun
>> > option
>> > for workflows mentions version 3.4 when it should be 3.3.2
>> >
>> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set the
>> > renewer correctly for JT/RM delegation tokens
>> >
>> > OOZIE-1242: a trivial docs change, so no reason not to put into
>> branch-4.0.
>> >
>> >
>> > What about the other two? We can put them into branch-4.0 too or move
>> them
>> > only to trunk.
>> >
>> >
>> > thanks
>> > - Robert
>> >
>>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Robert Kanter <rk...@cloudera.com>.
Ya, OOZIE-1233 and OOZIE-1242.
- Robert
On Wed, Mar 13, 2013 at 10:48 PM, Rohini Palaniswamy <
rohini.aditya@gmail.com> wrote:
> Robert,
> OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira you are
> asking about?
>
> Regards,
> Rohini
>
>
> On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rk...@cloudera.com>
> wrote:
>
> > Hi,
> >
> > I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in branch-4.0
> > (4.0.0):
> >
> > OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add
> ability
> > to configure Oozie to use HTTPS (SSL)
> >
> > OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242> Dryrun
> > option
> > for workflows mentions version 3.4 when it should be 3.3.2
> >
> > OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set the
> > renewer correctly for JT/RM delegation tokens
> >
> > OOZIE-1242: a trivial docs change, so no reason not to put into
> branch-4.0.
> >
> >
> > What about the other two? We can put them into branch-4.0 too or move
> them
> > only to trunk.
> >
> >
> > thanks
> > - Robert
> >
>
Re: JIRAs in branch-3.3 that aren't in branch-4.0
Posted by Rohini Palaniswamy <ro...@gmail.com>.
Robert,
OOZIE-1148 is already part of 4.0.0. Is OOZIE-1233 the other jira you are
asking about?
Regards,
Rohini
On Wed, Mar 13, 2013 at 5:30 PM, Robert Kanter <rk...@cloudera.com> wrote:
> Hi,
>
> I found 3 JIRAs that are in branch-3.3 (3.3.2) but not in branch-4.0
> (4.0.0):
>
> OOZIE-1233 <https://issues.apache.org/jira/browse/OOZIE-1233> Add ability
> to configure Oozie to use HTTPS (SSL)
>
> OOZIE-1242 <https://issues.apache.org/jira/browse/OOZIE-1242> Dryrun
> option
> for workflows mentions version 3.4 when it should be 3.3.2
>
> OOZIE-1148 <https://issues.apache.org/jira/browse/OOZIE-1148> Set the
> renewer correctly for JT/RM delegation tokens
>
> OOZIE-1242: a trivial docs change, so no reason not to put into branch-4.0.
>
>
> What about the other two? We can put them into branch-4.0 too or move them
> only to trunk.
>
>
> thanks
> - Robert
>