-
Posts
82 -
Joined
-
Last visited
-
Days Won
1
Posts posted by xxxxx
-
-
You know what'd be awesome? To be able to be able to sell Linux containers.
Containers are becoming increasingly popular, and orchestration frameworks with simple REST API's are coming out of the woodwork such as Google's Kubernetes (kubernetes.io).
I know this is gonna be a while of...but one to think about.
-
-
Now that Digital Ocean's v2 API is stable, it'd be great to have an official module to allow our customers to spin up custom-branded Droplets.
-
Guys, any plans to possibly add this to the feature list?
-
I've just experienced the same issue in 3.3.1.
Adding the service manually via the Enom module also threw the registered_for error forcing me too add the service not via module and register it manually via the Enom site.
-
As to the 1). Where's this other one which you said "There is a 3rd party (paid) module but it seems sketchy to say the least"?
If you google Blesta+Digital+Ocean+Module you only get this thread, ModulesBakery's, and competitors...
"...never stated it was necessarily a public module..."
-
Hi Danny,
1) As far as i know there is only one DO module for Blesta.... Which is ours.... so obviously....
2) Am i misunderstanding what you said below?
3) I replied to this thread only because you've pointed to the 3rd party's DO module anyways.
Not that I wish to drag this out, but...
1) As far as "you" know ... you don't know everything, and I never stated it was necessarily a public module. Don't assume things.
2) Yes, you are missing something. "Hold off" referring to holding off the feature implementation, and the second part was simply stating a fact.
3) See 1.
-
- I am sure you're talking about our module, but Huh? sketchy? all of the available methods through DigitalOcean APIv2 have been included in that module, let me know what made you think it is sketchy??
- I know APIv2 is still in Beta however, developing a module based on an API v1 which will be deprecated soon, is not a good option too, another thing that made me feel comfortable about developing the module with API v2 that before starting on that module i have sent a message to DigitalOcean's support and they recommended me to use the API V2 (attached a screen shot of their reply), so with such reply, not sure why i would use the API v1 instead.
1) I didn't specify whose module I was speaking out.
2) Never once did I say that the V1 API should be used, quite the opposite actually.
3) This is a request for an official module.
4) If I want support with your module, whichever that is, I'll contact you, but don't hold your breath.
-
If anyone else is interested in this please +1. There is a 3rd party (paid) module but it seems sketchy to say the least. The V2 API is in Beta so obviously they devs may wish to hold off, the the V1 API is stable and established.
-
If anyone else is interested please +1. This would allow us to be dynamically competitive on domain pricing with no effort.
-
Awesome. Thanks for taking the request on-board Paul.
-
The V1 API is stable and well established, but I understand the holding off until V2 is out of beta. They've not released the Droplet MetaData API which is pretty cool.
-
They've released a Public Beta of the new API. It looks super easy to use: https://developers.digitalocean.com/
-
It looks like everyone is up for this. Any plans to implement please?
-
-
On 8/12/2014 at 7:50 PM, Paul said:
Ok, looks like the client theme Venustas and the staff theme WHMBlesta have won the contest! I'll be reaching out to both of you guys shortly so we can get you the Amazon.com gift cards.
Thanks to everyone who participated in submitting themes and voting!
Woo, thanks x is the best email address to get me on.
-
Awesome, winning on Client Theme so far. Any votes appreciated Can we vote on out own theme given it's genuinely our favourite (I haven't btw)?
-
More the price for me than anything. I'd struggle to resell VPS.net even at their Reseller prices. DigitalOcean are overall better in my opinion. I'd love the module.
-
-
Hi guys,
DigitalOcean would be a better alternative to VPS.net for a lot of us. They have an API so this would be a great module:
-
[26-Feb-2013 15:00:01 US/Central] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/imagick.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/imagick.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 07:55:02 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 07:55:02 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 08:00:01 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 08:00:01 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 08:05:01 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo.so: cannot open shared object file: No such file or directory in Unknown on line 0
[17-Aug-2013 08:05:01 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
-
Okay, so I've had my reseller host make the changes you suggested in terms of PHP config, etc, however I'm still having the problem. I've noticed the job only fails when there's an email in the inbox. If it's empty, there are no issues.
-
Thanks for your quick reply, Paul.
- I don't think the messages are too large, there's generally only one message per cron job, if that, and it tends to be a couple of lines.
- I can't imagine connectivity to the mail server or the credentials are the problem either, I have other mail clients hooked up to these accounts and mail is delivered fine.
- That leaves me with looking in to increasing the timeout or memory limit, but I'll try dig around for PHP logs as suggested and get back to you.
-
Hi,
I know this issue has been brought to light a few times, but the solution has usually been to manually do some SQL and this is happening far too often for that to be a suitable fix for me.
Version:
Blesta 3.2.0 with all Plugins up-to-date.
The problem:
You can see there is an issue when logging in to the Admin Dashboard and looking at the System Status widget:
"There are one or more cron tasks that have been executing for more than 60 minutes. View Automated Tasks."
On digging in to the Tasks, the "Download Tickets" job is the issue. The spinner graphic continuously spins. The mail server and credentials are fine.
How often:
It happened once or twice previously, but since upgrading to 3.2.0 this has happened on either a weekly or sometimes daily basis. Sometimes the issue seems to fix itself (I know the lock file clears after 6 hours) but sometimes it's not suitable to wait this long and we are forced to use fixes detailed in the below threads.
Hacky fixes used so far:
Please can you take a look at this as soon as possible.
Thank you, Daniel.
Module For Selling Linux Containers (Kubernetes Api?)
in Feature Requests
Posted
The awesome thing about having a 'Kubernetes Module' would be that it'd be a single API end-point for Blesta to hook in to, with no other knowledge or orchestration required by Blesta. Kubernetes offers the abstraction. I'll be publishing a paper on Kubernetes (and various other alternatives such as the CoreOS stack) shortly and I'm more than happy to help out where required. Some pointers on the API can be found here, although still in Beta:
http://kubernetes.io/third_party/swagger-ui/#!/v1beta3/createPod
It's worth noting that Kubernetes only currently supports the likes of Docker and Rocket containers, although there is interest in LXC/LXD runtime support it may take a while to come.