[
https://issues.apache.org/jira/browse/BIGTOP-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120704#comment-14120704
]
Alex Newman commented on BIGTOP-1422:
-------------------------------------
I have been instructed that such a system is the preferred methodology of
rolling out custom builds. Also cloudera lays out the clear advantage of
systems like this
>From
>http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM4Ent/4.5.1/Cloudera-Manager-Enterprise-Edition-User-Guide/cmeeug_topic_7_11.html
" Among other benefits, parcels provide a mechanism for performing upgrades to
the packages installed on a cluster with minimal disruption. "
>From
>http://blog.cloudera.com/blog/2013/05/faq-understanding-the-parcel-binary-distribution-format/
Simplified distribution: As a parcel is a single file, it’s much easier to
move around than the dozens of packages that make up CDH. This is especially
useful when managing a cluster that isn’t connected to the Internet.
Internal consistency: By distributing CDH as a single parcel, we can help
ensure that all CDH components are properly matched and that there isn’t a
danger of different parts coming from different versions of CDH.
Installation outside of /usr: In some IT environments, Hadoop admins do not
have privileges to install system packages. In the past, these admins had to
fall back to CDH tarballs, which deprived them of a lot of infrastructure that
packages provide. With parcels, admins can install to /opt or anywhere else
without having to step through all the additional manual steps of regular
tarballs.
Installation of CDH without sudo: Parcel installation is handled by the CM
Agent already running as root so it’s possible to install CDH without needing
sudo, which can be very helpful.
Decoupling of distribution from activation: Thanks to side-by-side install
capabilities delivered by parcels, it is now possible to stage a new version of
CDH across the cluster in advance of switching over to it. This allows the
longest running part of an upgrade to be done ahead of time without affecting
cluster operations, consequently reducing upgrade downtime.
Rolling upgrades: With the new version staged side-by-side, switching to a
new minor version is simply a matter of changing which version of CDH is used
when restarting each process. It then becomes practical to do upgrades with
rolling restarts, where service roles are restarted in the right order to
switch over to the new version with minimal service interruption. Note that
major version upgrades (CDH3 -> CDH4) require full service restarts due to the
substantial changes between the versions.
Easy downgrades: With the old version still available, moving back to it
can be as simple as upgrading. (Note that some CDH components may require
explicit additional steps due to things like schema upgrades.)
> Introduce Universal Packaging System for Hadoop distribution
> ------------------------------------------------------------
>
> Key: BIGTOP-1422
> URL: https://issues.apache.org/jira/browse/BIGTOP-1422
> Project: Bigtop
> Issue Type: New Feature
> Components: build, deployment
> Affects Versions: 0.8.0
> Reporter: Konstantin Boudnik
> Priority: Blocker
> Fix For: 1.0.0
>
>
> Looks like the time comes where Bigtop needs to step up and champion new
> revolutionary format for packaging of the Hadoop.
> New UPS provides completely relocatable archive-like media of distribution
> for the content and the services alike. Preparation of an UPS deliverables
> shouldn't require any special development tools nor particular SDL: only
> cross-platform archives and widely available command-line interpreters would
> be a per-requisite for the creation and installation.
> In our opinion, the separation of the services and content of the
> applications, e.g. .deb and .rpm, are an outdated paradigm, which complicates
> the deployment processes, upgrades, and overall system orchestration.
> Architectural proposal will follow shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
