Jump to content

xxxxx

Members
  • Posts

    82
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by xxxxx

  1. 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.

  2. 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..."

  3. 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.

  4.  

    - 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.

  5. 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 :D x is the best email address to get me on.

  6. [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

  7. 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.

  8. 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:

     

    http://www.blesta.com/forums/index.php?/topic/1805-there-are-one-or-more-cron-tasks-that-have-been-executing-for-more-than-60-minutes/

     

    http://www.blesta.com/forums/index.php?/topic/1052-system-status-there-are-one-or-more-cron-tasks-that-have-been-executing-for-more-than-60-minutes/

     

    Please can you take a look at this as soon as possible.

     

    Thank you, Daniel.

×
×
  • Create New...