We just randomly throw around PROVISION_x_ERROR, but they don't have much meaning at the moment.

They should be mapped against the platform requirements, so that if an error gets flagged we can see what needs to be fixed.

CommentFileSizeAuthor
#5 hosting_error_strings.diff5.93 KBadrian

Comments

anarcat’s picture

anarcat commented
Title: Meaningful error statuses » More meaningful error statuses
anarcat’s picture

anarcat commented
Priority: Normal » Critical
Status: Active » Postponed (maintainer needs more info)

Is this still relevant? How does this related to the discussion we had about not depending too much on integers for status but instead return full error messages?

Marking as priority for 0.2.

adrian’s picture

adrian commented

This is the front end work related to http://drupal.org/node/374797

When drush_set_error gets in, the return value for the errors generated in provision change.

It will now return an associative array of errors. These errors need to be stored in a database table associated to the node the task is generated on.

This could also go a long way towards helping us with the site status issues, as we can see that the site has an inactive database, etc.

The index keys could also be used to map against the HELP documentation to fix this specific error, which will make the contextual help far cleaner and provide the support for multiple platforms / multiple db servers / multiple web servers, instead of just assuming all the help is on the master platform.

anarcat’s picture

anarcat commented
Status: Postponed (maintainer needs more info) » Needs work

So we're moving towards a consensus where we think the bitmaps probably have to go. We basically need to store three things:

1. is the task in the queue inqueue
2. did the task generate an error in last run status (a bit redundant: if inqueue is 0, then status should always be 0)
3. the actual errors (which are probably a json string)

adrian’s picture

adrian commented
Status: Needs work » Needs review
StatusFileSize
new hosting_error_strings.diff5.93 KB

This is dependent on http://drupal.org/node/414058

anarcat’s picture

anarcat commented
Version: 5.x-0.1-alpha1 »
Status: Needs review » Needs work

That patch has been committed, and I did some more work to cleanup the error codes (transform them into strings because we #414058: ditch the "status bitmaps").

However, some work still remains:

./platform/install.provision.inc:  if (!(drush_get_error() & PROVISION_SITE_INSTALLED)) {

This is the only instance I could find, but it's clearly wrong. I can't figure out right now what drush_get_error() returns... After that we'll be pretty much done.

anarcat’s picture

anarcat commented
Version: » 5.x-0.2-alpha1
Status: Needs work » Fixed

I committed a fix changing that last call. http://drupal.org/cvs?commit=206764

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 48aec57 on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_716166_apache_conf, dev_dns, dev_server_verify, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x authored by anarcat: 
    remove last remaining status cruft

Closes: #275511