Jonathon, Thanks for the pointers. I'll investigate using extensions.
--Steve > -----Original Message----- > From: Jonathan Hurley [mailto:[email protected]] > Sent: Monday, January 23, 2017 6:16 AM > To: Ambari <[email protected]> > Subject: Re: Upgrade mpack stack addon service > > 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 > > > >
