On 7/29/14, 2:02 AM, Lahiru Sandaruwan wrote:
Hi Vanson,
On Mon, Jul 28, 2014 at 9:44 PM, Vanson Lim <v...@cisco.com
<mailto:v...@cisco.com>> wrote:
Apache Stratos developers,
Is there a way to adjust the timeout value for a cartridge to become active
in apache stratos 4.0.0?
I've observed that Stratos Manager managing Openstack based VMs, will
restart the VM 15 minutes after launching it, if it does not
hear from the cartridge agent.
For our cartridges, we are starting with a blank VM (ie ubuntu/redhat cloud
image), package installation is happening as a part of
the startup process, and cartridge agent start is delayed until after
package/patch installation/configuration completes.
I am noticing that as the number of packages/patches to be applied
increases and when the system gets busy I am getting very close to
the timeout, sometimes exceeding it.
Is there a better approach for this? Ideally, a tunable timeout per subscription seems like the best approach.
I think timeout per cartridge type is a better control level. This can be
recorded in a Jira as a an improvement.
We've filed this enhancement requests.
I think per cartridge type might be too restrictive as there might be cases were you want to use a base cartridge but configure it for
completely different roles via the subscription, each role possibly taking a different amount of time to initialize.
https://issues.apache.org/jira/browse/STRATOS-724
We experimented with driving the package installation off the
instance-started.sh extension but this never worked well as we had
some cases were we needed to reboot the server after package installation,
and stratos doesn't handle well the case were the
cartridge agent goes silent for a few minutes as the VM is rebooting.
Another approach considered was to pre-bake some of the functionality into the base
cartridges to shorten the "installation" time,
but this complicates the management of the VM so we would like to avoid
this.
Do you mean management of Image? What we can do is install common software that
are required and keep.
Yes, I meant managing the base image. If we create base images consisting of third party rpms and the role specific software install,
then we will end up having to update the cartridge definitions and subscriptions each time we make new base images. We can redeploy the
cartridge definition but would need a new subscription to make use of the new image. In our case we make use of a rhel6.5 image, we have
just for one use case 7 different server types, each requiring different third party rpms and installation binaries, patch bundles.
RIght now, it's just easier to have a single rhel 6.5 base image and use and install script to configure the entire VM as a part of startup.
-Vanson
Thanks.
-Vanson
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahi...@wso2.com <mailto:lahi...@wso2.com> cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
