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
>
> <raviha...@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
> >
> > <raviha...@wso2.com> wrote:
> > > Hi Shaheed,
> > >
> > > On Mon, May 19, 2014 at 2:55 AM, Shaheedur Haque (shahhaqu)
> > >
> > > <shahh...@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
