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 <[email protected]<mailto:[email protected]>> wrote: On 2016-11-21 01:46 (-0800), Janne Valkealahti <[email protected]<mailto:[email protected]>> 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 < [email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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
