ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Valkealahti <janne.valkeala...@gmail.com>
Subject Re: Upgrade mpack stack addon service
Date Mon, 21 Nov 2016 09:46:14 GMT
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 <
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>
> 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
>
>

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