t; > have
> > > > > > > > >>> two
> > > > > > > > >>>>> stacks:
> > > > > > > > >>>>> - StackA (with usual set of components), currently
> > > installed on a
> > >
t; > > have
> > > > > > > > >>> two
> > > > > > > > >>>>> stacks:
> > > > > > > > >>>>> - StackA (with usual set of components), currently
> > > installed on a
> >
> contains
> > > > > > > > > >>>>>> the required services/components, but this new stack
> > > > definition
> > > > > > > > would
> > > > > > > > > >>>>> need
> > >
> > > > > > > have
> > > > > > > > >>> two
> > > > > > > > >>>>> stacks:
> > > > > > > > >>>>> - StackA (with usual set of components), currently
> > > i
= StackA + ComponentX
> > > > > > > >>>>> So, if I add StackB definition to the Ambari server and
> > restart it,
> > > > > > > >>> will I
> > > > > > > >>>>> be
> > > > > > > >>>>> able
> >>> will I
> > > > > > > >>>>> be
> > > > > > > >>>>> able to switch from StackA to StackB _without_
> > resintalling the
> > > > > > > >>> cluster,
> > > >
's service?
> > > > > > >>>>>
> > > > > > >>>>> If my depiction is correct then it might be an acceptable
> > > > > workaround
> > > > > > >>> in the
> > > > > > >&g
t;>>>> more
> > > > > >>>>> extensible
> > > > > >>>>>> and dynamic as additional stack definitions are created. Some
> > > > > >>>>>> of
> > > > the
> > > &
ail exchange, pointed me to
> > > AMBARI-7175
> > > > >>> and
> > > > >>>>> AMBARI-7201, which is seemingly going into the right direction,
> > > > >>>>> but
> > > > >>> still
> > &
if I read it right.
> > > >>>>>
> > > >>>>>> This is actually the second time that this scenario has came up
> > for
> > > >>> me
> > > >>>>>> today so it would be nice to get
; > >>>>> Cos
> > >>>>>
> > >>>>>> -John
> > >>>>>>
> > >>>>>> On Tue, Dec 2, 2014 at 2:00 PM, Konstantin Boudnik <
> c...@apache.org>
> > >>>>> wrote:
> > >
; >>> have
> >>>>>>> dynamic
> >>>>>>> extensibility for services? For instance, Cloudera Manager has this
> >>>>>>> concept of
> >>>>>>> Custom Services. And while it was done as an ad
t;>>> state of the whole Hadoop ecosystem.
>>>>>>>
>>>>>>> It seems that this functionality, if desired, is going to be brand
>>> new
>>>>> and
>>>>>>> as
>>>>>>> such require not
> > > > either of them without a concern of which one is ahead or behind
> > of the
> > > > > > rest
> > > > > > as they are equal. Essentially this solves some major issues that
> > > > pester
> > > > > >
ust Linux
> daemons
> > > > > (although
> > > > > Ambari tries to hide the fact for whatever reason that is). However
> > > this
> > > > > presents the core of the very issue: Ambari isn't aware about
> services
> > > > > i
o
> > figure
> > > > out
> > > > what can be done in this regards to have this dynamism.
> > > >
> > > > With regards,
> > > > Cos
> > > >
> > > > On Tue, Dec 02, 2014 at 08:41AM, Erin Boyd wrote:
> > >
you mentioned through the creation of a stack
> with the
> > > > services definition defined within in. I also don't believe we
> currently
> > > > support multiple masters on the same cluster. How would one
> > > deferientiate
> > > > which master it
t; deferientiate
> > > which master it should be using in such an environment?
> > >
> > > Of course services can be installed independent of Ambari on the hosts
> > > inside the cluster...but I don't think that is what you are getting at.
> > Are
> > > you expecting
environment?
> >
> > Of course services can be installed independent of Ambari on the hosts
> > inside the cluster...but I don't think that is what you are getting at.
> Are
> > you expecting the services to have a presence on the UI though installed
> > outsid
ce on the UI though installed
> outside of Ambari?
>
> Erin
>
> - Original Message -
> From: "Konstantin Boudnik"
> To: dev@ambari.apache.org
> Sent: Monday, December 1, 2014 6:42:30 PM
> Subject: About extensibility of Ambari stacks (not inheritance)
>
> Gu
outside of
Ambari?
Erin
- Original Message -
From: "Konstantin Boudnik"
To: dev@ambari.apache.org
Sent: Monday, December 1, 2014 6:42:30 PM
Subject: About extensibility of Ambari stacks (not inheritance)
Guys,
I am looking into possible stack extensibility properties
Guys,
I am looking into possible stack extensibility properties of Ambari (not to be
confused with inheritance), but haven't been able to derive any final
conclusions just yet. Hence, I'd appreciate the input from the people behind
the system.
I have a few questions about current state of the Amb
22 matches
Mail list logo
