stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaheed Haque <shahh...@cisco.com>
Subject Re: Cartridge Agent Extension Points
Date Sat, 31 May 2014 19:36:24 GMT

Good to know about the future plans.

However, for now, I have been played and I think there is a bug in the extension model, 
namely that the "start_servers.sh" and "clean.sh" extensions do not block. The problems 
with that are:
     *   The conceptual difference between "started.sh" and "activated.sh" should, I 
suggest, be that the application thinks it is operational in some sense. Otherwise, what's

the point of the separate extensions...the agent simply rattles through then in quick 
succession.
     *  Worse, it makes the grouping/dependency work useless. The whole point there is 
to start up VMs in some given order.
     *  "clean.sh" should also, possibly, be synchronous

In other words, I think the spec (based on the current extension names) should be:


Extension
Async

instance-started.sh
Y
Notification that Stratos published the start of the VM.
start-servers.sh
N
Callout requesting the the VM to startup. When
this returns, Stratos will understand it has activated.
instance-activated.sh
Y
Notification that Stratos published the activation of the VM.
artifacts-updated.sh
Y
Notification of ADC update.
clean.sh
N
Callout requesting the the VM to shutdown. When
this returns, Stratos will understand it has stopped.


Even though I'd argue against, I could understand that there might be concern over 
backward-compatibility. If so, then maybe we could have new synchronous extensions 
for the two points mentioned?

Assuming this is agreed, is adding a new a new supporting synchronous function to 
CommandUtils.java enough, or would stalling the Java thread here (possibly for minutes) 
cause issues elsewhere?

Thanks, Shaheed


On Tuesday 20 May 2014 21:30:43 Lakmal Warusawithana wrote:
> Yes, We should have python based agent in 4.1.0 release.
> 
> 
> On Tue, May 20, 2014 at 6:14 PM, Akila Ravihansa Perera
> 
> <ravihansa@wso2.com>wrote:
> > Hi all,
> > 
> > AFAIK, the Stratos community has decided to put effort in writing a
> > new cartridge-agent using Python. In that case, Java based agent will
> > become deprecated and all DevOps level extensions will have to be done
> > using Python. But until then we can use this shell script based model.
> > 
> > I'll update the thread once I've finished writing documentation for
> > agent extension points.
> > 
> > Thanks.
> > 
> > On Tue, May 20, 2014 at 6:07 PM, Akila Ravihansa Perera
> > 
> > <ravihansa@wso2.com> wrote:
> > > Hi Shaheed,
> > > 
> > > On Mon, May 19, 2014 at 2:55 AM, Shaheedur Haque (shahhaqu)
> > > 
> > > <shahhaqu@cisco.com> wrote:
> > >> Is there any documentation on how this works form the scripter's point
> > 
> > of view? Specifically:
> > > I'm working on writing documentation content for cartridge-agent
> > > extension points. Also planning to publish some articles on cartridge
> > > deployment use cases (for eg - clustering MongoDB) in which these
> > > extensions are being used.
> > > 
> > >> - For the old events (i.e. the non-toplogy events hooked via the
> > 
> > /extensions directory), is the new code backwards compatible with scripts
> > using the /extensions mechanism?
> > 
> > > There will be no changes done for previous non-topology events. The
> > > new code will use the same /extensions directory mechanism. Only the
> > > shell scripts' file names for each extension point will be passed as
> > > parameters to the cartridge-agent.
> > > 
> > >> - Specifically,  (I'm not familiar with the JavaProcessBuilder), can
> > 
> > you confirm if environment variables set before the JVM is invoked will
> > still be visible to the shell scripts?
> > 
> > > I've tested and confirmed that environment variables set before the
> > > JVM is invoked are visible to the shell scripts. On the side note, the
> > > JavaProcessBuilder will only append our custom parameters to the shell
> > > script process environment block. This is same as writing to
> > > /proc/<pid>/environ (pid - shell script process pid) in Linux. Pl note
> > > that these env variables set by the cartridge-agent are *not* shared
Mime
View raw message