> On April 15, 2015, 10:39 a.m., Emil Anca wrote:
> > ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/package/scripts/kerberos_client.py,
> >  line 27
> > <https://reviews.apache.org/r/33201/diff/1/?file=929438#file929438line27>
> >
> >     Not necessarely related to this particular patch but I think you could 
> > use the in-place install mechanism that retrieves the package list on 
> > install from the command JSON that comes from the server - 
> > ['hostLevelParams']['package_list'] - if possible, instead of hardcoding 
> > the packages at this level.
> >     
> >     Otherwise, looks good.

That package list is not an inclusion list, but an exclustion list.  The 
`install_packages` function probably already uses the list of packages from 
`['hostLevelParams']['package_list']`; however in this case I dont want to 
install _all_ packages since they include the KDC packages and they shouldn't 
be installed for the Kerberos client component.

Historically the Kerberos service was to install a KDC component as well.  All 
the code exists to do this, hence the KDC packages in the package list; however 
this functionaly has been _hidden_.  The code has not been removed since we may 
allow for Ambari to manage a KDC in the future(?).  **Note:** there is no way 
in the stack definion to specify component-specific packages... only one set 
per OS per service.


- Robert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33201/#review80183
-----------------------------------------------------------


On April 15, 2015, 9:19 a.m., Robert Levas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33201/
> -----------------------------------------------------------
> 
> (Updated April 15, 2015, 9:19 a.m.)
> 
> 
> Review request for Ambari, Andrew Onischuk, Emil Anca, Jaimin Jetly, and 
> Yusaku Sako.
> 
> 
> Bugs: AMBARI-10483
>     https://issues.apache.org/jira/browse/AMBARI-10483
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> In some environments, the Kerberos Client packages are already installed on 
> the machines and the operator does not want to install the OS kerberos client 
> packages.
> 
> Ambari should provide an option in the Enable Kerberos Wizard to not install 
> Kerberos Clients on the machines.
> 
> Under the Advanced krb.conf section, at the bottom, expose this checkbox for 
> this option:
> 
> ```
> [ ] Do not install Kerberos Client packages
> ```
> 
> After enabling Kerberos, this configuration option should be visible under 
> the Services > Kerberos > Configs.
> 
> This would instruct Ambari to not install the Kerberos Client packages when 
> installing the Kerberos Client component. We can still have Ambari install 
> the Kerberos Client component, just circumvent the install packages.
> 
> **Note:** If selected, it is assumed that the user will install packages 
> containing executables compatible with the MIT Kerberos 5 version 1.10.3
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/configuration/kerberos-env.xml
>  6d2bc56 
>   
> ambari-server/src/main/resources/common-services/KERBEROS/1.10.3-10/package/scripts/kerberos_client.py
>  a05d64c 
>   ambari-web/app/data/HDP2/site_properties.js 733e0ac 
> 
> Diff: https://reviews.apache.org/r/33201/diff/
> 
> 
> Testing
> -------
> 
> Manually tested.
> 
> No unit tests updated since lifecycle install_packages method is mocked.
> 
> Local ambari-server python tests passed:
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 59.685s
> [INFO] Finished at: Tue Apr 14 20:24:19 EDT 2015
> [INFO] Final Memory: 62M/1587M
> [INFO] 
> ------------------------------------------------------------------------
> 
> 
> Thanks,
> 
> Robert Levas
> 
>

Reply via email to