Does autoprovisioning work in the PHP service?

[gpierre42]

When starting a PHP service, I see the following message in the manager log:

014-06-22 15:21:44,583 DEBUG conpaas.core.manager STATE INIT: 2014-06-22 15:21:44,584 INFO conpaas.core.manager Provisioning Manager can not be initialized: No module named statsmodels.api 2014-06-22 15:22:11,924 DEBUG conpaas.core.manager STATE PROLOGUE: Starting up

If this message means what I think it means, autoprovisioning won't be working in this service :-(

[hectorj2f]

Hi @gpierre42

This package needs to be install in the image prior to the execution of the script. It is used to analyze the monitoring data and calculate some performance predictions.

Hector

[gpierre42]

In this case the installation of this package should be added in the image creation scripts in the git repository (this belongs in file conpaas-services/scripts/create_vm/scripts/501-php I presume).

[hectorj2f]

Sorry, my mistake I was now checking the code.

I believe you could find a workaround to install the package statmodels on the latests Debian distro. Besides this package is installed in the following script:

$CONPAAS_REPO/conpaas-services/src/conpaas/services/webservers/manager/autoscaling/configure_autoscaling.sh

You had a README in the following path: $CONPAAS_REPO/conpaas-services/src/conpaas/services/webservers/manager/autoscaling/prediction/README.txt

[hectorj2f]

To sum up, there is not need to install this package during the image creation.

[hectorj2f]

@gpierre42 I'll verify with which Linux distribution and version are working my AWS and OpenNebula images.

[gpierre42]

If this piece of software is necessary to correctly run the PHP service, then it is better to install it directly in the image. Installing a package on the fly upon instance creation can only be a workaround: it means that every new VM instance will need to download and install this package during its boot sequence, which slows down the creation of instances.

Could someone please try adding an "apt-get install python-statsmodels" in the image creation script and make sure it works properly before closing this issue?

Thanks @hectorj2f for your help!

[gpierre42]

The image should normally be a Debian Squeeze. By the way, if any other packages are necessary to get autoprovisioning to work, then we should also add them there.

[hectorj2f]

The packages required in the README are only installed in the Manager VM. But, I think it would be quick and easier to install them in the used image.

README path: $CONPAAS_REPO/conpaas-services/src/conpaas/services/webservers/manager/autoscaling/prediction/README.txt

[gpierre42]

Actually, the statsmodels package is already supposed to be installed in the image (line 20 of https://github.com/ConPaaS-team/conpaas/blob/dev/conpaas-services/scripts/create_vm/scripts/501-php#L20 ). But somehow this doesn't seem to work correctly.

[gpierre42]

Hello, Now that the WordPress manifest has been fixed I tried to set autoscaling on and to stress-test it. I imposed a very high load such that response times were constantly in the 5-10 seconds range, for at least 10 minutes. But nothing happened.

One possible explanation could be found in the PHP manager log: 2014-10-15 07:59:51,115 INFO conpaas.core.manager Provisioning Manager can not be initialized: cannot import name factorial

@tcrivat , I would suggest to either:

• Identify which package is missing in the VM image and make sure autoprovisioning works
• or disable autoprovisioning in the frontend for the time being

[tcrivat]

There doesn't seem to be any missing package, however the scipy version that is installed by default in the ConPaaS image has a bug. The bug was corrected in scipy in this commit: scipy/scipy@a832954af5fc3eaca26926d66ce5fe8eff14c97d.

We have two options: force the installation of a newer version of scipy during the ConPaaS image creation process or fix the bug on the fly during the image creation process (preferable) or even during the VM start-up.

[tcrivat]

After commits 8995d1c32ffbd81085f66efadd793b65fbfa632a and 457b9483e6f5cd7f435e87d7d6d47e69c49e81d5 and updating the image, autoprovisioning now works on the Amazon EC2 deployment.

On my local OpenNebula deployment, it fails because the VMs do not have public IPs and public domain names and it seems that the Ganglia system uses the local hostname which is not unique and not usable outside the VM. Anyway, this is a different issue, so this probably can be closed.