You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Janne Valkealahti <ja...@gmail.com> on 2016/11/17 13:57:49 UTC
Upgrade mpack stack addon service
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
RE: Upgrade mpack stack addon service
Posted by Steve Varnau <st...@esgyn.com>.
Jonathon,
Thanks for the pointers. I'll investigate using extensions.
--Steve
> -----Original Message-----
> From: Jonathan Hurley [mailto:jhurley@hortonworks.com]
> Sent: Monday, January 23, 2017 6:16 AM
> To: Ambari <de...@ambari.apache.org>
> 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
> <sv...@apache.org>> wrote:
>
>
>
> On 2016-11-21 01:46 (-0800), Janne Valkealahti
> <ja...@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<ma...@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"
> <ja...@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
>
>
>
>
Re: Upgrade mpack stack addon service
Posted by Jonathan Hurley <jh...@hortonworks.com>.
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 <sv...@apache.org>> wrote:
On 2016-11-21 01:46 (-0800), Janne Valkealahti <ja...@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<ma...@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" <ja...@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
Re: Upgrade mpack stack addon service
Posted by Steve Varnau <sv...@apache.org>.
On 2016-11-21 01:46 (-0800), Janne Valkealahti <ja...@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> 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" <ja...@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
> >
> >
>
Re: Upgrade mpack stack addon service
Posted by Janne Valkealahti <ja...@gmail.com>.
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" <ja...@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
>
>
Re: Upgrade mpack stack addon service
Posted by Alejandro Fernandez <af...@hortonworks.com>.
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" <ja...@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