You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@slider.apache.org by Sumit Mohanty <sm...@hortonworks.com> on 2014/08/21 23:12:48 UTC
Few changes/improvements to the packaging structure
There are some changes to the packaging structure based on some of the
recent JIRA fixes. Let me know if you have any suggestions/objections
regarding these and I will incorporate them before moving the change to
"develop".
1. Ability to get the default configuration from the supplied default
config file (SLIDER-338) - *Not a breaking change*
1. Now you can only specify the configuration that needs to be changed
from default in appConfig.json as the config property bag will be
initialized with the values from the default config file.
2. Ability to supply a folder with files that will be used as is
(SLIDER-316) - *Not a breaking change*
1. If there are config files that are not supported by a Slider
packages yet then you can supply the config files as an input
(provide the
location of the folder containing files) and the files will be available
locally in the container. Its up to the package author to decide what to
do. For example, the packages for HBase and Storm copy the
supplied config
files as is but the files that are explicitly created overwrite any
supplied file.
3. Ability to provide the full content for files such as log4j or
env.sh (SLIDER-315) - *Not a breaking change*
1. The difference between this and the above is that you can still
supply a template as the file content and have the template
materialized by
the scripts based on other config properties. Useful, if you want to
provide a custom env.sh file but still retain the ability to
auto-fill some
properties
4. Metainfo explicitly defines the config files needed by the
application instance (SLIDER-346) - *breaking change*
1. Its a breaking change because "config_types" property in
appConfig.json is no longer referred to for finding out which config
property types are expected by the app command scripts. Instead, the
metainfo is read for the list of supported config types.
Close to the next release (post 0.50 RC that is out now), I will modify the
doc on application configuration to add these details.
-Sumit
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Few changes/improvements to the packaging structure
Posted by Sumit Mohanty <sm...@hortonworks.com>.
On Thu, Aug 21, 2014 at 2:50 PM, Jon Maron <jm...@hortonworks.com> wrote:
>
> On Aug 21, 2014, at 5:12 PM, Sumit Mohanty <sm...@hortonworks.com>
> wrote:
>
> > There are some changes to the packaging structure based on some of the
> > recent JIRA fixes. Let me know if you have any suggestions/objections
> > regarding these and I will incorporate them before moving the change to
> > "develop".
> >
> >
> > 1. Ability to get the default configuration from the supplied default
> > config file (SLIDER-338) - *Not a breaking change*
> > 1. Now you can only specify the configuration that needs to be changed
> > from default in appConfig.json as the config property bag will be
> > initialized with the values from the default config file.
> >
> > 2. Ability to supply a folder with files that will be used as is
> > (SLIDER-316) - *Not a breaking change*
> > 1. If there are config files that are not supported by a Slider
> > packages yet then you can supply the config files as an input
> > (provide the
> > location of the folder containing files) and the files will be
> available
> > locally in the container. Its up to the package author to decide
> what to
> > do. For example, the packages for HBase and Storm copy the
> > supplied config
> > files as is but the files that are explicitly created overwrite any
> > supplied file.
>
> Just to be clear: that’s a folder in the app package tar?
>
No this is outside and is an input. Lets say the scenario is that
log4j.properties file is not supported by a package as in its not
configurable. User can still supply a log4j.properties file that will be
copied to the conf folder.
>
> >
> > 3. Ability to provide the full content for files such as log4j or
> > env.sh (SLIDER-315) - *Not a breaking change*
> > 1. The difference between this and the above is that you can still
> > supply a template as the file content and have the template
> > materialized by
> > the scripts based on other config properties. Useful, if you want to
> > provide a custom env.sh file but still retain the ability to
> > auto-fill some
> > properties
> >
> > 4. Metainfo explicitly defines the config files needed by the
> > application instance (SLIDER-346) - *breaking change*
> > 1. Its a breaking change because "config_types" property in
> > appConfig.json is no longer referred to for finding out which config
> > property types are expected by the app command scripts. Instead, the
> > metainfo is read for the list of supported config types.
>
> Is “no config types found in metainfo” an error condition with a message
> that will alert users? Or are apps with no config types supported and
> therefore this error message can’t really be generated? Perhaps the
> existence of the property in appConfig should trigger an error (or does it
> already)?
>
> No config is OK as some applications may not have any config files. I will
make the change to throw unsupported config error.
> >
> > Close to the next release (post 0.50 RC that is out now), I will modify
> the
> > doc on application configuration to add these details.
> >
> > -Sumit
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Few changes/improvements to the packaging structure
Posted by Jon Maron <jm...@hortonworks.com>.
On Aug 21, 2014, at 5:12 PM, Sumit Mohanty <sm...@hortonworks.com> wrote:
> There are some changes to the packaging structure based on some of the
> recent JIRA fixes. Let me know if you have any suggestions/objections
> regarding these and I will incorporate them before moving the change to
> "develop".
>
>
> 1. Ability to get the default configuration from the supplied default
> config file (SLIDER-338) - *Not a breaking change*
> 1. Now you can only specify the configuration that needs to be changed
> from default in appConfig.json as the config property bag will be
> initialized with the values from the default config file.
>
> 2. Ability to supply a folder with files that will be used as is
> (SLIDER-316) - *Not a breaking change*
> 1. If there are config files that are not supported by a Slider
> packages yet then you can supply the config files as an input
> (provide the
> location of the folder containing files) and the files will be available
> locally in the container. Its up to the package author to decide what to
> do. For example, the packages for HBase and Storm copy the
> supplied config
> files as is but the files that are explicitly created overwrite any
> supplied file.
Just to be clear: that’s a folder in the app package tar?
>
> 3. Ability to provide the full content for files such as log4j or
> env.sh (SLIDER-315) - *Not a breaking change*
> 1. The difference between this and the above is that you can still
> supply a template as the file content and have the template
> materialized by
> the scripts based on other config properties. Useful, if you want to
> provide a custom env.sh file but still retain the ability to
> auto-fill some
> properties
>
> 4. Metainfo explicitly defines the config files needed by the
> application instance (SLIDER-346) - *breaking change*
> 1. Its a breaking change because "config_types" property in
> appConfig.json is no longer referred to for finding out which config
> property types are expected by the app command scripts. Instead, the
> metainfo is read for the list of supported config types.
Is “no config types found in metainfo” an error condition with a message that will alert users? Or are apps with no config types supported and therefore this error message can’t really be generated? Perhaps the existence of the property in appConfig should trigger an error (or does it already)?
>
> Close to the next release (post 0.50 RC that is out now), I will modify the
> doc on application configuration to add these details.
>
> -Sumit
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.