ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hurley <jhur...@hortonworks.com>
Subject Re: Upgrade mpack stack addon service
Date Mon, 23 Jan 2017 14:16:07 GMT
Ambari 3.0 is being targeted for allowing patch and service upgrades (independent of the rest
of the cluster). This would also include the ability to upgrade a service which was deployed
in an mpack. Currently, there is no way to include an mpack service in an Ambari-orchestrated
upgrade. Ambari, however, does allow for an extension service to participate in an upgrade.
These services are dropped into Ambari in the existing stacks directory, as opposed to mpacks
which are deployed to their own location away from the stack.

Here are some relevant Jiras on extension services:
https://issues.apache.org/jira/browse/AMBARI-12885
https://issues.apache.org/jira/browse/AMBARI-15388
https://issues.apache.org/jira/browse/AMBARI-17465

The last one, AMBARI-17465 should allow an mpack to install an extension service which can
participate in an upgrade.

On Jan 20, 2017, at 6:29 PM, Steve Varnau <svarnau@apache.org<mailto:svarnau@apache.org>>
wrote:



On 2016-11-21 01:46 (-0800), Janne Valkealahti <janne.valkealahti@gmail.com<mailto:janne.valkealahti@gmail.com>>
wrote:
Ok thanks, is there any jiras I could follow or generic timeline for these
enhancements? I understand that if you control a stack you could possible
pump up versions there but having an addon service you may not have
anything to upgrade on a stack level.


+1 on this. I have a nice service addon Mpack that allows me to install a service that is
compatible with HDP2.3, 2.4, and 2.5.  However, I cannot figure out how to set up a second
version of that service that can be used to upgrade.

Is the intent is to install a new version of the mpack to be installed along side of the first?
That does not seem right, as there would be two versions of the service per stack. Using the
upgrade-mpack command wipes out the current mpack and ambari forgets all about the currently
installed service!

Even if that worked, the version registration is another problem, as Janne pointed out.

Any plans when this will get fleshed out?

-Steve

If your plan is to support patch upgrades within an existing stack(given
that mpacks are enhanced to support this), do you think a new repo could be
defined for a patched versions. We've now served minor versions(Spring
Cloud Data Flow) 1.0.x from a same yum repo(so ambari picks latest one) but
I've been thinking to start publishing every version into its own repo.
This was the moment when I realised that mpack addon service cannot be
upgraded once it is installed.

On Fri, Nov 18, 2016 at 11:47 PM, Alejandro Fernandez <
afernandez@hortonworks.com<mailto:afernandez@hortonworks.com>> wrote:

Hi Janne,

Management Packs are indeed meant to support new stacks, or custom
services on top of existing stacks.
We are still working on a story of how to do upgrades of a Management
Pack. Today, a Management Pack supports its own repo, so the eventual goal
is to be able to perform a Patch Upgrade (i.e., upgrade of a subset of the
services).

Thanks,
Alejandro

On 11/17/16, 5:57 AM, "Janne Valkealahti" <janne.valkealahti@gmail.com<mailto:janne.valkealahti@gmail.com>>
wrote:

I've been playing with adding a new service via mpack atop of a HDP stack.
All good on that front thought info in
cwiki.apache.org/confluence/display/AMBARI/Management+Packs+-+2.4.0<http://cwiki.apache.org/confluence/display/AMBARI/Management+Packs+-+2.4.0>
is
just
wrong (pdf in AMBARI-14854 seem to contain more accurate instructions).

What I really don't understand is that how these addon services can be
upgraded. Say that I have MYSERVICE-1.0.0 which is added to stack HDP-2.5.
If I create a new version MYSERVICE-2.0.0, docs just mention that this
should be linked to newer stack version(with upgraded mpack tarball) which
naturally doesn't exists.

Janne






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message