Re: Docker-based app: defining application.def

[Yu Liu]

Hi, Olivier:

Sorry about the delay of the response. For some reason, I didn't receive your 
original email in my mailbox.

'application.def' is not required for launching Docker based application 
through Slider. I just re-verified with the tip of develop branch of Slider and 
it seems to work fine.

Can you please checkout the latest revision of develop branch if you don't have 
to stick to your current revision of Slider?



http://slider.incubator.apache.org/docs/slider_specs/application_pkg_docker.html
is the documentation for how to deploy Docker applications with Slider

Please let me know if your problem remains.

Thank you

Thomas



From: Gour Saha 
Sent: Wednesday, June 10, 2015 3:33 PM
To: dev@slider.incubator.apache.org
Subject: Re: Docker-based app: defining application.def

Fwd-ing to the DL again, as it seems our docker dev was not receiving
these emails.

-Gour

On 6/8/15, 4:43 AM, "Olivier Armand"  wrote:

>Hi,
>
>Rephrasing the initial question: should users consider Slider's Docker
>support usable starting from 0.80, as there doesn't seem to be any public
>sample nor up-to-date documentation?
>
>-- Olivier
>
>On Sun, May 24, 2015 at 9:59 PM, Olivier Armand 
>wrote:
>
>> Hi,
>>
>> I'm trying to deploy a simple docker-based application, following these
>> instructions:
>>
>>http://slider.incubator.apache.org/docs/slider_specs/application_pkg_dock
>>er.html
>>
>> The "slider create" exits with the following error:
>> ERROR main.ServiceLauncher - Application definition must be provided.
>> Missing option application.def from set global
>>
>> I indeed didn't specify any application.def. How should this attribute
>>be
>> set for a docker-based application?
>> Is there any up-to-date and working sample docker-based application?
>>
>> (Note: I also noticed that the application appears in "slider list"
>>output
>> and needs to be destroyed before recreating it, although I would expect
>>the
>> deployment to either entirely fail or succeed).
>>
>> -- Olivier
>>

Re: Docker-based app: defining application.def

[Gour Saha]

Fwd-ing to the DL again, as it seems our docker dev was not receiving
these emails.

-Gour

On 6/8/15, 4:43 AM, "Olivier Armand"  wrote:

>Hi,
>
>Rephrasing the initial question: should users consider Slider's Docker
>support usable starting from 0.80, as there doesn't seem to be any public
>sample nor up-to-date documentation?
>
>-- Olivier
>
>On Sun, May 24, 2015 at 9:59 PM, Olivier Armand 
>wrote:
>
>> Hi,
>>
>> I'm trying to deploy a simple docker-based application, following these
>> instructions:
>> 
>>http://slider.incubator.apache.org/docs/slider_specs/application_pkg_dock
>>er.html
>>
>> The "slider create" exits with the following error:
>> ERROR main.ServiceLauncher - Application definition must be provided.
>> Missing option application.def from set global
>>
>> I indeed didn't specify any application.def. How should this attribute
>>be
>> set for a docker-based application?
>> Is there any up-to-date and working sample docker-based application?
>>
>> (Note: I also noticed that the application appears in "slider list"
>>output
>> and needs to be destroyed before recreating it, although I would expect
>>the
>> deployment to either entirely fail or succeed).
>>
>> -- Olivier
>>

Re: component restart by making config changes.

[Chackravarthy Esakkimuthu]

Yeah understood now, thanks for the clarification.
On 11 Jun 2015 02:27, "Gour Saha"  wrote:

> You are right that upgrade cmd supersedes the update cmd. upgrade is a
> formal way to do a zero-downtime upgrade of your application in production
> env and requires you to tag your app config with an appropriate
> app_version.
>
> update cmd on the other hand requires a stop/start of your application. It
> is handy because you do not have to do stop, destroy and create all the
> time, just to make a config change. You just need to do stop, update and
> start. You are not forced to maintain an app_version property as well.
> Handy for dev/test env.
>
> -Gour
>
> On 6/10/15, 1:40 PM, "Chackravarthy Esakkimuthu" 
> wrote:
>
> >Thanks for the detailed explanation, yes Agreed that it would create
> >confusion when different components of same application runs with
> >different
> >versions.
> >
> >Since I had tried 'slider update' command to update the configs and then
> >to
> >do complete app restart, thought there would be an option to do at
> >component level as well.
> >
> >May be you might have provided 'update' command before getting 'upgrade'
> >on
> >board and now you have solved all binary as well as config upgrades using
> >'slider upgrade' command itself. Think this 'upgrade' command should be
> >replacing 'update' command as well if I am not wrong. Or is there any
> >specific use case which 'slider update' command solves?
> >
> >On Thu, Jun 11, 2015 at 1:55 AM, Gour Saha  wrote:
> >
> >> Upgrade of an application package should be visualized holistically.
> >>
> >> It could be as minor as a single config of a single component, OR as
> >>major
> >> as changes to all the binaries and 10s/100s of additional new configs.
> >>
> >> If the original version was 1.0.0, then a single config update version
> >> might be called 1.0.1, versus the major version update would probably be
> >> called 2.0.0.
> >>
> >> It all boils down to how you as an app owner track any changes to your
> >> application. But as long as there is a change, my guess is there is a
> >> version change to your application as a whole.
> >>
> >> Managing mixed versions of different components of your application is a
> >> challenge.
> >>
> >> Now coming back to your scenario -
> >>
> >> The newer version of your app config will pretty much be exactly the
> >>same
> >> as v1.0 with only 1 config change for NIMBUS. Everything else remains
> >>the
> >> same including the application binaries.
> >>
> >> So technically you do not need to call upgrade on components other than
> >> NIMBUS. They can continue to run as is. But remember in the fault
> >>tolerant
> >> world, containers are expected to fail without affecting your
> >>application
> >> as a whole. So somewhere down the line if a SUPERVISOR container fails,
> >> then a new container will take its place. It will show v1.0.1 although
> >> technically nothing has changed for the SUPERVISOR (since these
> >>components
> >> do not care about the new config property).
> >>
> >> If I have confused you more, then all it says is that we need Ambari to
> >> automate this whole thing and make version management a breeze.
> >>
> >> -Gour
> >>
> >> On 6/10/15, 12:58 PM, "Chackravarthy Esakkimuthu"
> >>
> >> wrote:
> >>
> >> >Thanks for the response Gour,
> >> >
> >> >Since I was facing issue with packaging storm, I tried with hbase
> >> >app-package and then identified that app_version reflects that. I tried
> >> >reconfiguration using upgrade command as per the doc and it resulted in
> >> >success.
> >> >
> >> >I understand that this upgrade will be really helpful in case of
> >>upgrading
> >> >from one version to another version, but should I follow this same
> >> >approach
> >> >for updating the configuration of a particular component as well?
> >> >
> >> >Consider I need to just update one or more configuration specific for
> >> >NIMBUS component, shouldn't be there a way to update the app_config.xml
> >> >and
> >> >restart that specific role/component instead of restarting all
> >>components?
> >> >I would not want to restart supervisor processes in such cases.
> >> >
> >> >Thanks,
> >> >Chackra
> >> >
> >> >On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha 
> >> wrote:
> >> >
> >> >> I think you are missing the app_version entry in your app_config
> >>file,
> >> >> like this -
> >> >> "site.global.app_version": "1.0",
> >> >>
> >> >> Please refer to this file as an example -
> >> >>
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/incubator-slider/blob/develop/app-packages/hbas
> >> >>e/appConfig-default.json
> >> >>
> >> >> If that does not work, can you send me your modified app_config.xml
> >>(the
> >> >> entire file) and also the complete cmd lines for "package --install"
> >>and
> >> >> "create", so that I can look further into it?
> >> >>
> >> >> -Gour
> >> >>
> >> >>
> >> >> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu"
> >> >> >> > wrote:
> >> >>
> >> 

Re: component restart by making config changes.

[Gour Saha]

You are right that upgrade cmd supersedes the update cmd. upgrade is a
formal way to do a zero-downtime upgrade of your application in production
env and requires you to tag your app config with an appropriate
app_version.

update cmd on the other hand requires a stop/start of your application. It
is handy because you do not have to do stop, destroy and create all the
time, just to make a config change. You just need to do stop, update and
start. You are not forced to maintain an app_version property as well.
Handy for dev/test env.

-Gour

On 6/10/15, 1:40 PM, "Chackravarthy Esakkimuthu" 
wrote:

>Thanks for the detailed explanation, yes Agreed that it would create
>confusion when different components of same application runs with
>different
>versions.
>
>Since I had tried 'slider update' command to update the configs and then
>to
>do complete app restart, thought there would be an option to do at
>component level as well.
>
>May be you might have provided 'update' command before getting 'upgrade'
>on
>board and now you have solved all binary as well as config upgrades using
>'slider upgrade' command itself. Think this 'upgrade' command should be
>replacing 'update' command as well if I am not wrong. Or is there any
>specific use case which 'slider update' command solves?
>
>On Thu, Jun 11, 2015 at 1:55 AM, Gour Saha  wrote:
>
>> Upgrade of an application package should be visualized holistically.
>>
>> It could be as minor as a single config of a single component, OR as
>>major
>> as changes to all the binaries and 10s/100s of additional new configs.
>>
>> If the original version was 1.0.0, then a single config update version
>> might be called 1.0.1, versus the major version update would probably be
>> called 2.0.0.
>>
>> It all boils down to how you as an app owner track any changes to your
>> application. But as long as there is a change, my guess is there is a
>> version change to your application as a whole.
>>
>> Managing mixed versions of different components of your application is a
>> challenge.
>>
>> Now coming back to your scenario -
>>
>> The newer version of your app config will pretty much be exactly the
>>same
>> as v1.0 with only 1 config change for NIMBUS. Everything else remains
>>the
>> same including the application binaries.
>>
>> So technically you do not need to call upgrade on components other than
>> NIMBUS. They can continue to run as is. But remember in the fault
>>tolerant
>> world, containers are expected to fail without affecting your
>>application
>> as a whole. So somewhere down the line if a SUPERVISOR container fails,
>> then a new container will take its place. It will show v1.0.1 although
>> technically nothing has changed for the SUPERVISOR (since these
>>components
>> do not care about the new config property).
>>
>> If I have confused you more, then all it says is that we need Ambari to
>> automate this whole thing and make version management a breeze.
>>
>> -Gour
>>
>> On 6/10/15, 12:58 PM, "Chackravarthy Esakkimuthu"
>>
>> wrote:
>>
>> >Thanks for the response Gour,
>> >
>> >Since I was facing issue with packaging storm, I tried with hbase
>> >app-package and then identified that app_version reflects that. I tried
>> >reconfiguration using upgrade command as per the doc and it resulted in
>> >success.
>> >
>> >I understand that this upgrade will be really helpful in case of
>>upgrading
>> >from one version to another version, but should I follow this same
>> >approach
>> >for updating the configuration of a particular component as well?
>> >
>> >Consider I need to just update one or more configuration specific for
>> >NIMBUS component, shouldn't be there a way to update the app_config.xml
>> >and
>> >restart that specific role/component instead of restarting all
>>components?
>> >I would not want to restart supervisor processes in such cases.
>> >
>> >Thanks,
>> >Chackra
>> >
>> >On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha 
>> wrote:
>> >
>> >> I think you are missing the app_version entry in your app_config
>>file,
>> >> like this -
>> >> "site.global.app_version": "1.0",
>> >>
>> >> Please refer to this file as an example -
>> >>
>> >>
>> >>
>> 
>>https://github.com/apache/incubator-slider/blob/develop/app-packages/hbas
>> >>e/appConfig-default.json
>> >>
>> >> If that does not work, can you send me your modified app_config.xml
>>(the
>> >> entire file) and also the complete cmd lines for "package --install"
>>and
>> >> "create", so that I can look further into it?
>> >>
>> >> -Gour
>> >>
>> >>
>> >> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu"
>>> >> > wrote:
>> >>
>> >> Gour, just tried with latest release 0.80.0 (slider client), but
>>facing
>> >> some issues with 'versioning'.
>> >>
>> >> slider app package install done with "--version 1.0" and also
>>modified
>> >>the
>> >> "application.def" in app_config.xml to include version in the path,
>> >>
>> >> Now cluster creation works and able to list all containers as we

Re: component restart by making config changes.

[Chackravarthy Esakkimuthu]

Thanks for the detailed explanation, yes Agreed that it would create
confusion when different components of same application runs with different
versions.

Since I had tried 'slider update' command to update the configs and then to
do complete app restart, thought there would be an option to do at
component level as well.

May be you might have provided 'update' command before getting 'upgrade' on
board and now you have solved all binary as well as config upgrades using
'slider upgrade' command itself. Think this 'upgrade' command should be
replacing 'update' command as well if I am not wrong. Or is there any
specific use case which 'slider update' command solves?

On Thu, Jun 11, 2015 at 1:55 AM, Gour Saha  wrote:

> Upgrade of an application package should be visualized holistically.
>
> It could be as minor as a single config of a single component, OR as major
> as changes to all the binaries and 10s/100s of additional new configs.
>
> If the original version was 1.0.0, then a single config update version
> might be called 1.0.1, versus the major version update would probably be
> called 2.0.0.
>
> It all boils down to how you as an app owner track any changes to your
> application. But as long as there is a change, my guess is there is a
> version change to your application as a whole.
>
> Managing mixed versions of different components of your application is a
> challenge.
>
> Now coming back to your scenario -
>
> The newer version of your app config will pretty much be exactly the same
> as v1.0 with only 1 config change for NIMBUS. Everything else remains the
> same including the application binaries.
>
> So technically you do not need to call upgrade on components other than
> NIMBUS. They can continue to run as is. But remember in the fault tolerant
> world, containers are expected to fail without affecting your application
> as a whole. So somewhere down the line if a SUPERVISOR container fails,
> then a new container will take its place. It will show v1.0.1 although
> technically nothing has changed for the SUPERVISOR (since these components
> do not care about the new config property).
>
> If I have confused you more, then all it says is that we need Ambari to
> automate this whole thing and make version management a breeze.
>
> -Gour
>
> On 6/10/15, 12:58 PM, "Chackravarthy Esakkimuthu" 
> wrote:
>
> >Thanks for the response Gour,
> >
> >Since I was facing issue with packaging storm, I tried with hbase
> >app-package and then identified that app_version reflects that. I tried
> >reconfiguration using upgrade command as per the doc and it resulted in
> >success.
> >
> >I understand that this upgrade will be really helpful in case of upgrading
> >from one version to another version, but should I follow this same
> >approach
> >for updating the configuration of a particular component as well?
> >
> >Consider I need to just update one or more configuration specific for
> >NIMBUS component, shouldn't be there a way to update the app_config.xml
> >and
> >restart that specific role/component instead of restarting all components?
> >I would not want to restart supervisor processes in such cases.
> >
> >Thanks,
> >Chackra
> >
> >On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha 
> wrote:
> >
> >> I think you are missing the app_version entry in your app_config file,
> >> like this -
> >> "site.global.app_version": "1.0",
> >>
> >> Please refer to this file as an example -
> >>
> >>
> >>
> https://github.com/apache/incubator-slider/blob/develop/app-packages/hbas
> >>e/appConfig-default.json
> >>
> >> If that does not work, can you send me your modified app_config.xml (the
> >> entire file) and also the complete cmd lines for "package --install" and
> >> "create", so that I can look further into it?
> >>
> >> -Gour
> >>
> >>
> >> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu"  >> > wrote:
> >>
> >> Gour, just tried with latest release 0.80.0 (slider client), but facing
> >> some issues with 'versioning'.
> >>
> >> slider app package install done with "--version 1.0" and also modified
> >>the
> >> "application.def" in app_config.xml to include version in the path,
> >>
> >> Now cluster creation works and able to list all containers as well.
> >>(even
> >> with specific roles)
> >>
> >> But list command does not work with "version" option
> >>
> >> sudo -u yarn /usr/hdp/current/slider-client/bin/./slider list storm1
> >> --containers --version 1.0
> >>
> >>
> >> ContainerInfo object does not contain the AppVersion.
> >>
> >>
> >>
> >> Am I missing something like updating the configuration or jar in some
> >> place?
> >>
> >> Changes I did as follows,
> >> I updated Slider distribution in client machine and then just modified
> >>the
> >> "application.def" in app_config.xml.
> >>
> >>
> >> On Mon, Jun 8, 2015 at 6:48 AM, Gour Saha   >> gs...@hortonworks.com>> wrote:
> >>
> >> Chackra,
> >> If you are thinking of updating without doing a complete stop of your
> >> applicati

Re: component restart by making config changes.

[Gour Saha]

Upgrade of an application package should be visualized holistically.

It could be as minor as a single config of a single component, OR as major
as changes to all the binaries and 10s/100s of additional new configs.

If the original version was 1.0.0, then a single config update version
might be called 1.0.1, versus the major version update would probably be
called 2.0.0.

It all boils down to how you as an app owner track any changes to your
application. But as long as there is a change, my guess is there is a
version change to your application as a whole.

Managing mixed versions of different components of your application is a
challenge.

Now coming back to your scenario -

The newer version of your app config will pretty much be exactly the same
as v1.0 with only 1 config change for NIMBUS. Everything else remains the
same including the application binaries.

So technically you do not need to call upgrade on components other than
NIMBUS. They can continue to run as is. But remember in the fault tolerant
world, containers are expected to fail without affecting your application
as a whole. So somewhere down the line if a SUPERVISOR container fails,
then a new container will take its place. It will show v1.0.1 although
technically nothing has changed for the SUPERVISOR (since these components
do not care about the new config property).

If I have confused you more, then all it says is that we need Ambari to
automate this whole thing and make version management a breeze.

-Gour

On 6/10/15, 12:58 PM, "Chackravarthy Esakkimuthu" 
wrote:

>Thanks for the response Gour,
>
>Since I was facing issue with packaging storm, I tried with hbase
>app-package and then identified that app_version reflects that. I tried
>reconfiguration using upgrade command as per the doc and it resulted in
>success.
>
>I understand that this upgrade will be really helpful in case of upgrading
>from one version to another version, but should I follow this same
>approach
>for updating the configuration of a particular component as well?
>
>Consider I need to just update one or more configuration specific for
>NIMBUS component, shouldn't be there a way to update the app_config.xml
>and
>restart that specific role/component instead of restarting all components?
>I would not want to restart supervisor processes in such cases.
>
>Thanks,
>Chackra
>
>On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha  wrote:
>
>> I think you are missing the app_version entry in your app_config file,
>> like this -
>> "site.global.app_version": "1.0",
>>
>> Please refer to this file as an example -
>>
>> 
>>https://github.com/apache/incubator-slider/blob/develop/app-packages/hbas
>>e/appConfig-default.json
>>
>> If that does not work, can you send me your modified app_config.xml (the
>> entire file) and also the complete cmd lines for "package --install" and
>> "create", so that I can look further into it?
>>
>> -Gour
>>
>>
>> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu" > > wrote:
>>
>> Gour, just tried with latest release 0.80.0 (slider client), but facing
>> some issues with 'versioning'.
>>
>> slider app package install done with "--version 1.0" and also modified
>>the
>> "application.def" in app_config.xml to include version in the path,
>>
>> Now cluster creation works and able to list all containers as well.
>>(even
>> with specific roles)
>>
>> But list command does not work with "version" option
>>
>> sudo -u yarn /usr/hdp/current/slider-client/bin/./slider list storm1
>> --containers --version 1.0
>>
>>
>> ContainerInfo object does not contain the AppVersion.
>>
>>
>>
>> Am I missing something like updating the configuration or jar in some
>> place?
>>
>> Changes I did as follows,
>> I updated Slider distribution in client machine and then just modified
>>the
>> "application.def" in app_config.xml.
>>
>>
>> On Mon, Jun 8, 2015 at 6:48 AM, Gour Saha > gs...@hortonworks.com>> wrote:
>>
>> Chackra,
>> If you are thinking of updating without doing a complete stop of your
>> application, you might want to look into rolling upgrade -
>> 
>>http://slider.incubator.apache.org/docs/slider_specs/application_pkg_upgr
>>ad
>> e.html
>>
>>
>> This feature is available from latest 0.80.0 release onwards.
>>
>> -Gour
>>
>> On 6/7/15, 4:16 AM, "Chackravarthy Esakkimuthu" > >
>> wrote:
>>
>> >I am able to do complete cluster restart with modified configs, by
>>doing
>> >'slider update' , 'slider stop', 'slider start'.
>> >
>> >Suppose If I want to restart a particular component alone (say STORM
>> >SUPERVISOR) with the modified configs, how can I do it? Is there an
>>option
>> >to stop/restart a particular component?
>>
>>
>>
>>

Re: component restart by making config changes.

[Steve Loughran]

> On 10 Jun 2015, at 20:58, Chackravarthy Esakkimuthu  
> wrote:
> 
> Thanks for the response Gour,
> 
> Since I was facing issue with packaging storm, I tried with hbase
> app-package and then identified that app_version reflects that. I tried
> reconfiguration using upgrade command as per the doc and it resulted in
> success.
> 
> I understand that this upgrade will be really helpful in case of upgrading
> from one version to another version, but should I follow this same approach
> for updating the configuration of a particular component as well?
> 
> Consider I need to just update one or more configuration specific for
> NIMBUS component, shouldn't be there a way to update the app_config.xml and
> restart that specific role/component instead of restarting all components?
> I would not want to restart supervisor processes in such cases.
> 
> Thanks,
> Chackra


you can sort of do that today by flexing down and then up all the components. I 
don't think the app config gets updated (just the resources.json bit), but 
there's no fundamental reason why not, except for the confusion you get if 
different instances are on different settings

Re: component restart by making config changes.

[Chackravarthy Esakkimuthu]

Thanks for the response Gour,

Since I was facing issue with packaging storm, I tried with hbase
app-package and then identified that app_version reflects that. I tried
reconfiguration using upgrade command as per the doc and it resulted in
success.

I understand that this upgrade will be really helpful in case of upgrading
from one version to another version, but should I follow this same approach
for updating the configuration of a particular component as well?

Consider I need to just update one or more configuration specific for
NIMBUS component, shouldn't be there a way to update the app_config.xml and
restart that specific role/component instead of restarting all components?
I would not want to restart supervisor processes in such cases.

Thanks,
Chackra

On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha  wrote:

> I think you are missing the app_version entry in your app_config file,
> like this -
> "site.global.app_version": "1.0",
>
> Please refer to this file as an example -
>
> https://github.com/apache/incubator-slider/blob/develop/app-packages/hbase/appConfig-default.json
>
> If that does not work, can you send me your modified app_config.xml (the
> entire file) and also the complete cmd lines for "package --install" and
> "create", so that I can look further into it?
>
> -Gour
>
>
> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu"  > wrote:
>
> Gour, just tried with latest release 0.80.0 (slider client), but facing
> some issues with 'versioning'.
>
> slider app package install done with "--version 1.0" and also modified the
> "application.def" in app_config.xml to include version in the path,
>
> Now cluster creation works and able to list all containers as well. (even
> with specific roles)
>
> But list command does not work with "version" option
>
> sudo -u yarn /usr/hdp/current/slider-client/bin/./slider list storm1
> --containers --version 1.0
>
>
> ContainerInfo object does not contain the AppVersion.
>
>
>
> Am I missing something like updating the configuration or jar in some
> place?
>
> Changes I did as follows,
> I updated Slider distribution in client machine and then just modified the
> "application.def" in app_config.xml.
>
>
> On Mon, Jun 8, 2015 at 6:48 AM, Gour Saha  gs...@hortonworks.com>> wrote:
>
> Chackra,
> If you are thinking of updating without doing a complete stop of your
> application, you might want to look into rolling upgrade -
> http://slider.incubator.apache.org/docs/slider_specs/application_pkg_upgrad
> e.html
>
>
> This feature is available from latest 0.80.0 release onwards.
>
> -Gour
>
> On 6/7/15, 4:16 AM, "Chackravarthy Esakkimuthu"  >
> wrote:
>
> >I am able to do complete cluster restart with modified configs, by doing
> >'slider update' , 'slider stop', 'slider start'.
> >
> >Suppose If I want to restart a particular component alone (say STORM
> >SUPERVISOR) with the modified configs, how can I do it? Is there an option
> >to stop/restart a particular component?
>
>
>
>

Re: NIMBUS Component not starting while running apache storm on slider

[Chackravarthy Esakkimuthu]

Thanks steve, I applied the patch and tried again. Now ended up in some
other error preventing NIMBUS to start,

Error opening zip file or JAR manifest missing :
/grid/2/hadoop/yarn/local/usercache/yarn/appcache/application_1433776215383_0025/container_1433776215383_0025_01_02/app/install/apache-storm-0.9.3/external/storm-jmxetric/lib/jmxetric-1.0.4.jar
Error occurred during initialization of VM
agent library failed to init: instrument

I will check about this and update and if you are already aware of this
problem, please help me out.

Thanks,
Chackra



On Wed, Jun 10, 2015 at 6:28 PM, Steve Loughran 
wrote:

>
> > On 9 Jun 2015, at 13:10, Chackravarthy Esakkimuthu <
> chaku.mi...@gmail.com> wrote:
> >
> > I created slider-storm package (with apache storm 0.9.3) following
> > instructions at README.txt, and then did install using slider.
> >
> > NIMBUS component failed to start with following error :
> >
> > /usr/bin/python: can't open file
> >
> '/grid/2/hadoop/yarn/local/usercache/yarn/appcache/application_1433776215383_0011/container_1433776215383_0011_01_02/app/install/apache-storm-0.9.3/bin/storm.py':
> > [Errno 2] No such file or directory
> >
> >
> > Before that, I was working with HDP slider-storm package (downloaded from
> >
> http://public-repo-1.hortonworks.com/HDP/debian6/2.x/GA/2.2.0.0/slider-app-packages/storm/slider-storm-app-package-0.9.3.2.2.0.0-2041.zip
> )
> > and everything was running fine. Do I need to make any change explicitly
> > when I want to use apache distribution?
> >
> > Because it is expecting storm.py (from slider) to be there inside storm
> > distribution and hence failing.
>
>
>
> now that is https://issues.apache.org/jira/browse/SLIDER-658 , "storm
> package cannot start storm 0.9.3; "storm.py" not found"
>
> At some point in the storm development process, the storm launcher script
> changed from  bin/storm to a bin/storm.py. This is what you see in the
> storm master branch:
> https://github.com/apache/storm/blob/master/bin/storm.py
>
> the app package script changed to the new one, which worked provided the
> storm release had the new script (which the HDP one clearly has, and which
> you get if you do a storm trunk release)
>
> I'd thought I'd patched the ASF source to revert back to the old name,
> with what my colleagues were releasing internally branched to storm.py, but
> I don't see it theren.
>
> If you apply the patch in SLIDER-658 everything should sync up again;
> later releases of Apache storm will be be back in sync.
>
> -steve
>

Re: component restart by making config changes.

[Gour Saha]

I think you are missing the app_version entry in your app_config file, like 
this -
"site.global.app_version": "1.0",

Please refer to this file as an example -
https://github.com/apache/incubator-slider/blob/develop/app-packages/hbase/appConfig-default.json

If that does not work, can you send me your modified app_config.xml (the entire 
file) and also the complete cmd lines for "package --install" and "create", so 
that I can look further into it?

-Gour


On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu" 
mailto:chaku.mi...@gmail.com>> wrote:

Gour, just tried with latest release 0.80.0 (slider client), but facing
some issues with 'versioning'.

slider app package install done with "--version 1.0" and also modified the
"application.def" in app_config.xml to include version in the path,

Now cluster creation works and able to list all containers as well. (even
with specific roles)

But list command does not work with "version" option

sudo -u yarn /usr/hdp/current/slider-client/bin/./slider list storm1
--containers --version 1.0


ContainerInfo object does not contain the AppVersion.



Am I missing something like updating the configuration or jar in some place?

Changes I did as follows,
I updated Slider distribution in client machine and then just modified the
"application.def" in app_config.xml.


On Mon, Jun 8, 2015 at 6:48 AM, Gour Saha 
mailto:gs...@hortonworks.com>> wrote:

Chackra,
If you are thinking of updating without doing a complete stop of your
application, you might want to look into rolling upgrade -
http://slider.incubator.apache.org/docs/slider_specs/application_pkg_upgrad
e.html


This feature is available from latest 0.80.0 release onwards.

-Gour

On 6/7/15, 4:16 AM, "Chackravarthy Esakkimuthu" 
mailto:chaku.mi...@gmail.com>>
wrote:

>I am able to do complete cluster restart with modified configs, by doing
>'slider update' , 'slider stop', 'slider start'.
>
>Suppose If I want to restart a particular component alone (say STORM
>SUPERVISOR) with the modified configs, how can I do it? Is there an option
>to stop/restart a particular component?

[jira] [Commented] (SLIDER-902) AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing on Windows

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580893#comment-14580893
 ] 

ASF subversion and git services commented on SLIDER-902:


Commit 8062780ebca75b972033a724e45e358fcb7700d5 in incubator-slider's branch 
refs/heads/develop from [~gsaha]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=8062780 ]

SLIDER-902 AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing 
on Windows (Thomas Liu via gourksaha)


> AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing on Windows
> -
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-902-001.patch
>
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-902:
-
Summary: AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing 
on Windows  (was: AMClientCertStoreRetrievalIT failing on Windows)

> AMClientCertStoreRetrievalIT#testRetrieveCertificateStores failing on Windows
> -
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-902-001.patch
>
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLIDER-901) AgentClientInstallIT#testAgentClientInstall last validation statement is failing on Windows

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580884#comment-14580884
 ] 

ASF subversion and git services commented on SLIDER-901:


Commit 074bdc1d857dda02decb6a1c83752ad6c6b48711 in incubator-slider's branch 
refs/heads/develop from [~gsaha]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=074bdc1 ]

SLIDER-901 AgentClientInstallIT#testAgentClientInstall last validation 
statement is failing on Windows (Thomas Liu via gourksaha)


> AgentClientInstallIT#testAgentClientInstall last validation statement is 
> failing on Windows
> ---
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-901-001.patch
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT#testAgentClientInstall last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Summary: AgentClientInstallIT#testAgentClientInstall last validation 
statement is failing on Windows  (was: AgentClientInstallIT last validation 
statement is failing on Windows)

> AgentClientInstallIT#testAgentClientInstall last validation statement is 
> failing on Windows
> ---
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-901-001.patch
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Use variables in "components" property in app config JSON file

[Steve Loughran]

right  now we've steered clear of doing any form of variable, or x-ref in the 
config files, though I do have my eye on the @{variable} pattern in future.

One of the reasons is the big question "when and where to evaluate these 
things", as well as "do you ever need to re-evaluate them as things change". 
That's the big lazy vs static schism in configuration management tools. 

that keytab binding is an interesting problem though. Slider does know who 
things were started as, and really needs that to be the same user, in something 
like user/host@realm. (at least I think so, Kerberos is something I can never 
claim to understand). 

What are you trying to set it to? something like  node4@realm?

> On 10 Jun 2015, at 16:08, Nathaniel Braun  wrote:
> 
> Hi,
> 
> In order to determine the principal name to use in my Kerberized AM, I need 
> the hostname of the machine the AM executes on.
> 
> Here is the part of the appConfig.json I'm interested in:
> 
>  "components": {
>"slider-appmaster": {
>  "jvm.heapsize": "256M",
>  "slider.hdfs.keytab.dir": ".slider/keytabs",
>  "slider.am.login.keytab.name": "httpfs.keytab",
>  "slider.keytab.principal.name" : "${THIS_HOST}@{KERBEROS_REALM} "
>}
> 
> Basically, I need THIS_HOST and KERBEROS_REALM to be replaced with their 
> actual values, coming from the AM's machine.
> 
> This does not work right now, those values are not interpreted.
> 
> Thanks for your help.
> 
> Regards,
> Nathaniel
> 

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-902:
--
Attachment: SLIDER-902-001.patch

Attaching the first fix

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-902-001.patch
>
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-902:
--
Attachment: (was: slider-902-001.patch)

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-902:
--
Comment: was deleted

(was: Attaching the first fix)

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-902:
--
Attachment: slider-902-001.patch

Attaching the first fix

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: slider-902-001.patch
>
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-901:
--
Attachment: SLIDER-901-001.patch

Attaching first fix

> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Attachments: SLIDER-901-001.patch
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Fix Version/s: (was: Slider 0.81)

> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-902:
-
Assignee: thomas liu

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-902:
-
Affects Version/s: Slider 0.80

> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-902:
-
Description: 
The test case is passing on Linux
It uses some Linux specific path so fails on Windows
Fixing the Linux specific path still produce error below:
{noformat}
2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
(NativeMethodAccessorImpl.java:invoke0(?)) - 

2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
ResourceManager at dal-slider1/10.79.146.141:8032
2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
specified via command line. Using dal-slider1
Exception: org.apache.slider.core.exceptions.SliderException: Error running 
command openssl pkcs12 -export -in 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -inkey 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
-certfile 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
 -password pass:welcome -passin 
pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
{noformat}


  was:
The test case is passing on Linux
It uses some Linux specific path so fails on Windows
Fixing the Linux specific path still produce error below:
{noformat}
2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
(NativeMethodAccessorImpl.java:invoke0(?)) - 

2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
ResourceManager at dal-slider1/10.79.146.141:80322015-06-09 19:41:53,673 [main] 
INFO  client.SliderClient - No hostname specified via command line. Using 
dal-slider1
Exception: org.apache.slider.core.exceptions.SliderException: Error running 
command openssl pkcs12 -export -in 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -inkey 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
-certfile 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
 -password pass:welcome -passin 
pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
{noformat}



> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:8032
> 2015-06-09 19:41:53,673 [main] INFO  client.SliderClient - No hostname 
> specified via command line. Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-902:
-
Description: 
The test case is passing on Linux
It uses some Linux specific path so fails on Windows
Fixing the Linux specific path still produce error below:
{noformat}
2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
(NativeMethodAccessorImpl.java:invoke0(?)) - 

2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
ResourceManager at dal-slider1/10.79.146.141:80322015-06-09 19:41:53,673 [main] 
INFO  client.SliderClient - No hostname specified via command line. Using 
dal-slider1
Exception: org.apache.slider.core.exceptions.SliderException: Error running 
command openssl pkcs12 -export -in 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -inkey 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
-certfile 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
 -password pass:welcome -passin 
pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
{noformat}


  was:
The test case is passing on Linux
It uses some Linux specific path so fails on Windows
Fixing the Linux specific path still produce error below:
2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
(NativeMethodAccessorImpl.java:invoke0(?)) - 

2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
ResourceManager at dal-slider1/10.79.146.141:80322015-06-09 19:41:53,673 [main] 
INFO  client.SliderClient - No hostname specified via command line. Using 
dal-slider1
Exception: org.apache.slider.core.exceptions.SliderException: Error running 
command openssl pkcs12 -export -in 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -inkey 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
-certfile 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
 -password pass:welcome -passin 
pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 




> AMClientCertStoreRetrievalIT failing on Windows
> ---
>
> Key: SLIDER-902
> URL: https://issues.apache.org/jira/browse/SLIDER-902
> Project: Slider
>  Issue Type: Bug
>Reporter: thomas liu
>
> The test case is passing on Linux
> It uses some Linux specific path so fails on Windows
> Fixing the Linux specific path still produce error below:
> {noformat}
> 2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
> (NativeMethodAccessorImpl.java:invoke0(?)) - 
> 
> 2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
> ResourceManager at dal-slider1/10.79.146.141:80322015-06-09 19:41:53,673 
> [main] INFO  client.SliderClient - No hostname specified via command line. 
> Using dal-slider1
> Exception: org.apache.slider.core.exceptions.SliderException: Error running 
> command openssl pkcs12 -export -in 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt 
> -inkey 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
> -certfile 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
> C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
>  -password pass:welcome -passin 
> pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Assignee: thomas liu

> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Fix For: Slider 0.81
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Fix Version/s: Slider 0.81

> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
>Assignee: thomas liu
> Fix For: Slider 0.81
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Affects Version/s: Slider 0.80

> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Affects Versions: Slider 0.80
>Reporter: thomas liu
> Fix For: Slider 0.81
>
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[Gour Saha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-901:
-
Description: 
AgentClientInstallIT passes on Linux.
However, on Windows, the second validation statement in the end of the test 
case fails:
{noformat}
assert list.contains(expectedFile2)
   |||
   |false
C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
 [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
​at 
org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
{noformat}


  was:
AgentClientInstallIT passes on Linux.
However, on Windows, the second validation statement in the end of the test 
case fails:
{quote}
assert list.contains(expectedFile2)
   |||
   |false
C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
 [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
​at 
org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
{quote}



> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Reporter: thomas liu
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {noformat}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLIDER-902) AMClientCertStoreRetrievalIT failing on Windows

[thomas liu (JIRA)]

thomas liu created SLIDER-902:
-

 Summary: AMClientCertStoreRetrievalIT failing on Windows
 Key: SLIDER-902
 URL: https://issues.apache.org/jira/browse/SLIDER-902
 Project: Slider
  Issue Type: Bug
Reporter: thomas liu


The test case is passing on Linux
It uses some Linux specific path so fails on Windows
Fixing the Linux specific path still produce error below:
2015-06-09 19:41:55,343 [JUnit] ERROR framework.ShellBase 
(NativeMethodAccessorImpl.java:invoke0(?)) - 

2015-06-09 19:41:53,482 [main] INFO  client.RMProxy - Connecting to 
ResourceManager at dal-slider1/10.79.146.141:80322015-06-09 19:41:53,673 [main] 
INFO  client.SliderClient - No hostname specified via command line. Using 
dal-slider1
Exception: org.apache.slider.core.exceptions.SliderException: Error running 
command openssl pkcs12 -export -in 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -inkey 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.key 
-certfile 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\client.crt -out 
C:\Users\hadoop\AppData\Local\Temp\sec1433878889711\security\keystore-client-.p12
 -password pass:welcome -passin 
pass:Kt8H0w2kJK6k7FyW52BAbJB82OcXowC7DW37TM5P0YVIilaciV 





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[thomas liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

thomas liu updated SLIDER-901:
--
Description: 
AgentClientInstallIT passes on Linux.
However, on Windows, the second validation statement in the end of the test 
case fails:
{quote}
assert list.contains(expectedFile2)
   |||
   |false
C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
 [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
​at 
org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
{quote}


  was:
AgentClientInstallIT passes on Linux.
However, on Windows, the second validation statement in the end of the test 
case fails:
assert list.contains(expectedFile2)
   |||
   |false
C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
 [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
​at 
org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)



> AgentClientInstallIT last validation statement is failing on Windows
> 
>
> Key: SLIDER-901
> URL: https://issues.apache.org/jira/browse/SLIDER-901
> Project: Slider
>  Issue Type: Bug
>Reporter: thomas liu
>
> AgentClientInstallIT passes on Linux.
> However, on Windows, the second validation statement in the end of the test 
> case fails:
> {quote}
> assert list.contains(expectedFile2)
>|||
>|false
> C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
>  
> [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
> at 
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
> ​at 
> org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLIDER-901) AgentClientInstallIT last validation statement is failing on Windows

[thomas liu (JIRA)]

thomas liu created SLIDER-901:
-

 Summary: AgentClientInstallIT last validation statement is failing 
on Windows
 Key: SLIDER-901
 URL: https://issues.apache.org/jira/browse/SLIDER-901
 Project: Slider
  Issue Type: Bug
Reporter: thomas liu


AgentClientInstallIT passes on Linux.
However, on Windows, the second validation statement in the end of the test 
case fails:
assert list.contains(expectedFile2)
   |||
   |false
C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\command-logger-app\operations.log
 [C:\Users\hadoopqa\AppData\Local\Temp\del8816690427180892258dir\operations.log]
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:648)
​at 
org.apache.slider.funtest.lifecycle.AgentClientInstallIT.testAgentClientInstall(AgentClientInstallIT.groovy:77)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLIDER-896) TestClientBasicArgs.testListUnknownRM fails on Windows

[Steve Loughran (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLIDER-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran resolved SLIDER-896.
---
   Resolution: Fixed
Fix Version/s: Slider 0.80

> TestClientBasicArgs.testListUnknownRM fails on Windows
> --
>
> Key: SLIDER-896
> URL: https://issues.apache.org/jira/browse/SLIDER-896
> Project: Slider
>  Issue Type: Bug
>  Components: client
>Affects Versions: Slider 0.80
>Reporter: Gour Saha
>Assignee: Steve Loughran
> Fix For: Slider 0.80
>
>
> Error stack -
> {noformat}
> org.apache.slider.client.TestClientBasicArgs.testListUnknownRM
> Error Message
> java.util.concurrent.ExecutionException: java.net.UnknownHostException: 
> Invalid host name: local host is: (unknown); destination host is: 
> "badhost":; java.net.UnknownHostException; For more details see:  
> http://wiki.apache.org/hadoop/UnknownHost
> Stacktrace
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.net.UnknownHostException: Invalid host name: local host is: (unknown); 
> destination host is: "badhost":; java.net.UnknownHostException; For more 
> details see:  http://wiki.apache.org/hadoop/UnknownHost
>   at org.apache.hadoop.ipc.Client$Connection.(Client.java:407)
>   at org.apache.hadoop.ipc.Client$1.call(Client.java:1470)
>   at org.apache.hadoop.ipc.Client$1.call(Client.java:1467)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4767)
>   at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568)
>   at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
>   at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
>   at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
>   at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
>   at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4764)
>   at org.apache.hadoop.ipc.Client.getConnection(Client.java:1467)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1397)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1358)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
>   at $Proxy19.getApplications(Unknown Source)
>   at 
> org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getApplications(ApplicationClientProtocolPBClientImpl.java:251)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at $Proxy20.getApplications(Unknown Source)
>   at 
> org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getApplications(YarnClientImpl.java:484)
>   at 
> org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getApplications(YarnClientImpl.java:468)
>   at 
> org.apache.slider.client.SliderYarnClientImpl.listDeployedInstances(SliderYarnClientImpl.java:101)
>   at 
> org.apache.slider.core.registry.YarnAppListClient.listInstances(YarnAppListClient.java:111)
>   at 
> org.apache.slider.client.SliderClient.listSliderInstances(SliderClient.java:2691)
>   at 
> org.apache.slider.client.SliderClient.actionList(SliderClient.java:2775)
>   at org.apache.slider.client.SliderClient.exec(SliderClient.java:514)
>   at 
> org.apache.slider.client.SliderClient.runService(SliderClient.java:428)
>   at 
> org.apache.slider.core.main.ServiceLauncher.launchService(ServiceLauncher.java:188)
>   at 
> org.apache.slider.test.SliderTestUtils.launch(SliderTestUtils.groovy:955)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
>   at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
>   at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1462)
>   at 
> org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.callStatic(StaticMetaClassSite.java:62)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArr

Use variables in "components" property in app config JSON file

[Nathaniel Braun]

Hi,

In order to determine the principal name to use in my Kerberized AM, I need the 
hostname of the machine the AM executes on.

Here is the part of the appConfig.json I'm interested in:

  "components": {
"slider-appmaster": {
  "jvm.heapsize": "256M",
  "slider.hdfs.keytab.dir": ".slider/keytabs",
  "slider.am.login.keytab.name": "httpfs.keytab",
  "slider.keytab.principal.name" : "${THIS_HOST}@{KERBEROS_REALM} "
}

Basically, I need THIS_HOST and KERBEROS_REALM to be replaced with their actual 
values, coming from the AM's machine.

This does not work right now, those values are not interpreted.

Thanks for your help.

Regards,
Nathaniel

Re: NIMBUS Component not starting while running apache storm on slider

[Steve Loughran]

> On 9 Jun 2015, at 13:10, Chackravarthy Esakkimuthu  
> wrote:
> 
> I created slider-storm package (with apache storm 0.9.3) following
> instructions at README.txt, and then did install using slider.
> 
> NIMBUS component failed to start with following error :
> 
> /usr/bin/python: can't open file
> '/grid/2/hadoop/yarn/local/usercache/yarn/appcache/application_1433776215383_0011/container_1433776215383_0011_01_02/app/install/apache-storm-0.9.3/bin/storm.py':
> [Errno 2] No such file or directory
> 
> 
> Before that, I was working with HDP slider-storm package (downloaded from
> http://public-repo-1.hortonworks.com/HDP/debian6/2.x/GA/2.2.0.0/slider-app-packages/storm/slider-storm-app-package-0.9.3.2.2.0.0-2041.zip)
> and everything was running fine. Do I need to make any change explicitly
> when I want to use apache distribution?
> 
> Because it is expecting storm.py (from slider) to be there inside storm
> distribution and hence failing.



now that is https://issues.apache.org/jira/browse/SLIDER-658 , "storm package 
cannot start storm 0.9.3; "storm.py" not found"

At some point in the storm development process, the storm launcher script 
changed from  bin/storm to a bin/storm.py. This is what you see in the storm 
master branch: https://github.com/apache/storm/blob/master/bin/storm.py

the app package script changed to the new one, which worked provided the storm 
release had the new script (which the HDP one clearly has, and which you get if 
you do a storm trunk release)

I'd thought I'd patched the ASF source to revert back to the old name, with 
what my colleagues were releasing internally branched to storm.py, but I don't 
see it theren.

If you apply the patch in SLIDER-658 everything should sync up again; later 
releases of Apache storm will be be back in sync.

-steve