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.
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]> 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]> > 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 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 > >
