Re: Administrative Emails
Christian,
We did some testing and it appears that the error is caused when a call is
made to the Web API and passes a blank password. Setting the password to an
invalid password appear to work correctly. This curl command triggers the
issue.
curl -u "username":"" https://reviewboard.domain/api/review-requests//
-Chris
On Tuesday, June 6, 2017 at 4:44:04 PM UTC-4, Christian Hammond wrote:
>
> Hi Chris,
>
> I'm afraid the changes I talked about were limited to the LDAP support,
> not Active Directory. The newer version won't fix your problem.
>
> I think it's important to figure out why this is failing in the first
> place, though. We perform a bind every time we go to authenticate a user.
> We know that's succeeding because we then immediately go to perform a
> search (which wouldn't happen if the bind failed), and that's where this is
> failing. It sounds like this only happens periodically, and not every time
> someone authenticates?
>
> Christian
>
> On Tue, Jun 6, 2017 at 12:33 PM, Chris Eagan <cea...@gmail.com
> > wrote:
>
>> I am planning to upgrade our version soon so hopefully that resolves the
>> problem, but either way, here is the traceback from the email in case you
>> would like to take a look.
>>
>> Traceback (most recent call last):
>>
>> File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py",
>> line 112, in get_response
>> response = wrapped_callback(request, *callback_args,
>> **callback_kwargs)
>>
>> File
>> "/usr/lib/python2.7/site-packages/django/views/decorators/cache.py", line
>> 52, in _wrapped_view_func
>> response = view_func(request, *args, **kwargs)
>>
>> File
>> "/usr/lib/python2.7/site-packages/django/views/decorators/vary.py", line
>> 19, in inner_func
>> response = func(*args, **kwargs)
>>
>> File
>> "/usr/lib/python2.7/site-packages/djblets/webapi/resources/base.py", line
>> 135, in __call__
>> auth_result = check_login(request)
>>
>> File
>> "/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/__init__.py",
>> line 87, in check_login
>> result = auth_backend_cls().authenticate(request)
>>
>> File
>> "/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/base.py",
>> line 84, in authenticate
>> result = self.login_with_credentials(request, **credentials)
>>
>> File
>> "/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/base.py",
>> line 141, in login_with_credentials
>> user = auth.authenticate(**credentials)
>>
>> File
>> "/usr/lib/python2.7/site-packages/django/contrib/auth/__init__.py", line
>> 49, in authenticate
>> user = backend.authenticate(**credentials)
>>
>> File
>> "/usr/lib/python2.7/site-packages/reviewboard/accounts/backends.py", line
>> 792, in authenticate
>> userdomain)
>>
>> File
>> "/usr/lib/python2.7/site-packages/reviewboard/accounts/backends.py", line
>> 641, in search_ad
>> filterstr=filterstr)
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 552,
>> in search_s
>> return
>> self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 546,
>> in search_ext_s
>> return self.result(msgid,all=1,timeout=timeout)[1]
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458,
>> in result
>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462,
>> in result2
>> resp_type, resp_data, resp_msgid, resp_ctrls =
>> self.result3(msgid,all,timeout)
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469,
>> in result3
>> resp_ctrl_classes=resp_ctrl_classes
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476,
>> in result4
>> ldap_result =
>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
>>
>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99,
>> in _ldap_call
>> result = func(*args,**kwargs)
>>
>> OPERATIONS_ERROR: {'info': '04DC: LdapErr: DSID-0C090752, comment:
Re: Administrative Emails
I am planning to upgrade our version soon so hopefully that resolves the
problem, but either way, here is the traceback from the email in case you
would like to take a look.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py",
line 112, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python2.7/site-packages/django/views/decorators/cache.py",
line 52, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/django/views/decorators/vary.py",
line 19, in inner_func
response = func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/djblets/webapi/resources/base.py",
line 135, in __call__
auth_result = check_login(request)
File
"/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/__init__.py",
line 87, in check_login
result = auth_backend_cls().authenticate(request)
File
"/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/base.py",
line 84, in authenticate
result = self.login_with_credentials(request, **credentials)
File
"/usr/lib/python2.7/site-packages/djblets/webapi/auth/backends/base.py",
line 141, in login_with_credentials
user = auth.authenticate(**credentials)
File "/usr/lib/python2.7/site-packages/django/contrib/auth/__init__.py",
line 49, in authenticate
user = backend.authenticate(**credentials)
File "/usr/lib/python2.7/site-packages/reviewboard/accounts/backends.py",
line 792, in authenticate
userdomain)
File "/usr/lib/python2.7/site-packages/reviewboard/accounts/backends.py",
line 641, in search_ad
filterstr=filterstr)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 552,
in search_s
return
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 546,
in search_ext_s
return self.result(msgid,all=1,timeout=timeout)[1]
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458,
in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462,
in result2
resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469,
in result3
resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476,
in result4
ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
result = func(*args,**kwargs)
OPERATIONS_ERROR: {'info': '04DC: LdapErr: DSID-0C090752, comment: In
order to perform this operation a successful bind must be completed on the
connection., data 0, v2580', 'desc': 'Operations error'}
On Monday, June 5, 2017 at 5:52:51 PM UTC-4, Christian Hammond wrote:
>
> Hi Chris,
>
> I'm surprised you're getting e-mails for this, but I'd have to see the
> entirety of the e-mail, probably. If it's an exception traceback e-mail,
> then likely this particular failure wasn't getting caught and handled
> gracefully, leading to a HTTP 500 being shown to the user who tried to log
> in. Generally speaking, you should only get such e-mails if we have a crash
> bug.
>
> I did a bunch of work to improve the LDAP support in 2.5.12, which should
> also better catch exceptions. Upgrading might prevent those errors from
> showing up.
>
> Do you have a full traceback shown in there?
>
> Christian
>
> On Mon, Jun 5, 2017 at 12:04 PM, Chris Eagan <cea...@gmail.com
> > wrote:
>
>> Sometimes our Review Board server sends emails to the Administrator email
>> account to report errors. I don't see a setting anywhere to control what
>> gets sent to the administrators, but some of these issues are ones that we
>> aren't particularly interested in receiving. For instance, the following
>> error gets sent whenever someone mistypes their password when attempting to
>> login to Review Board.
>>
>> OPERATIONS_ERROR: {'info': '04DC: LdapErr: DSID-0C090752, comment:
>> In order to perform this operation a successful bind must be completed on
>> the connection., data 0, v2580', 'desc': 'Operations error'}
>>
>> It is a little odd because we can see other ERROR level log entries from
>> today, but we didn't get emails for all of them so the emails don't appear
>> to be related to the log level of the error. It
Administrative Emails
Sometimes our Review Board server sends emails to the Administrator email
account to report errors. I don't see a setting anywhere to control what
gets sent to the administrators, but some of these issues are ones that we
aren't particularly interested in receiving. For instance, the following
error gets sent whenever someone mistypes their password when attempting to
login to Review Board.
OPERATIONS_ERROR: {'info': '04DC: LdapErr: DSID-0C090752, comment: In
order to perform this operation a successful bind must be completed on the
connection., data 0, v2580', 'desc': 'Operations error'}
It is a little odd because we can see other ERROR level log entries from
today, but we didn't get emails for all of them so the emails don't appear
to be related to the log level of the error. It might be useful to let the
user customize the log level threshold for which emails are sent to the
Administrator, including turning off the automated emails completely.
Is there anything we can do to customize what gets sent to the
Administrator email account? We are currently running Review Board 2.5.9.
--
Supercharge your Review Board with Power Pack:
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons:
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Form Data Custom Payload
That worked, thanks!
On Wednesday, April 5, 2017 at 4:37:44 PM UTC-4, Chris Eagan wrote:
>
> I am trying to trigger a Jenkins Job using WebHooks in Review Board and I
> need to submit a custom payload as form data. After installing the
> https://plugins.jenkins.io/build-token-root plugin, I tried using the
> following settings.
>
> URL:
> https://jenkins.example.com/buildByToken/buildWithParameters?job=FolderName/JobName
> Events: Review request published
> Apply to: Only review requests on selected repositories
> Repositories: Example
> Encoding: Form Data
> Use custom payload content: Enabled
> Custom content:
>
> token=secret
>
> review.url={{review_request.absolute_url}}
>
>
> Unfortunately, this doesn't appear to trigger the job. I cam able to
> trigger the job using curl with the following command and it works.
>
> curl "
> https://jenkins.example.com/buildByToken/buildWithParameters?job=FolderName/JobName;
>
> -d token=secret -d review.url="https://reviewboard.example.com/r/12345/;
>
>
> Am I using the custom content section incorrectly with respect to Form
> Data? There are no examples on the Review Board documentation yet for this
> use case.
>
--
Supercharge your Review Board with Power Pack:
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons:
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Form Data Custom Payload
I am trying to trigger a Jenkins Job using WebHooks in Review Board and I
need to submit a custom payload as form data. After installing
the https://plugins.jenkins.io/build-token-root plugin, I tried using the
following settings.
URL:
https://jenkins.example.com/buildByToken/buildWithParameters?job=FolderName/JobName
Events: Review request published
Apply to: Only review requests on selected repositories
Repositories: Example
Encoding: Form Data
Use custom payload content: Enabled
Custom content:
token=secret
review.url={{review_request.absolute_url}}
Unfortunately, this doesn't appear to trigger the job. I cam able to
trigger the job using curl with the following command and it works.
curl
"https://jenkins.example.com/buildByToken/buildWithParameters?job=FolderName/JobName;
-d token=secret -d review.url="https://reviewboard.example.com/r/12345/;
Am I using the custom content section incorrectly with respect to Form
Data? There are no examples on the Review Board documentation yet for this
use case.
--
Supercharge your Review Board with Power Pack:
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons:
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Bugzilla Authentication
We recently migrated from Review Board 2.0.x to 2.5.x and I noticed that there is a new feature for loading information from Bugzilla using the Bugzilla API. We require authentication on our Bugzilla instance and we are seeing a lot of errors in our Review Board logs related to Bugzilla connection attempts. Is there someplace in the Admin panel where we can set the credentials or API Key for Review Board to use when connecting to Bugzilla? Unable to fetch bugzilla data from https://bugzilla.example.com/rest/bug/12405: HTTP Error 401: Authorization Required -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database Upgrade Error
I found another discussion about this issue on this forum [forum post <https://groups.google.com/forum/#!topic/reviewboard/N8Z652ccb6M>] and sure enough, my database dump shows that the tables are using MyISAM. I converted the database dump to specify InnoDB instead using the following command and did a new import followed by an rb-site upgrade. sed 's/) ENGINE=MyISAM/) ENGINE=InnoDB/g' reviewboard.sql > reviewboard2.sql This took a really long time to import, so be sure you get it right before you try the import. I added wait_timeout = 31536000 to the [server] section of /etc/my.cnf.d/server.cnf and restarted MariaDB to ensure that the import had time to complete. Also, make sure you have enough free disk space to complete the import. Ultimately, this appears to have worked and given us successful migration of the database. Hopefully, this thread helps someone else. :) On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote: > > When attempting to perform an rb-site upgrade from version 2.0.18 to > 2.5.9, I get the following output, ending in an error. If I continue, > further table creation issues occur and the result is a corrupted database. > I do have a backup of the database, which I have been using to restore and > test the migrations. > > Rebuilding directory structure > Upgrading site settings_local.py > Updating database. This may take a while. > > > The log output below, including warnings and errors, > can be ignored unless upgrade fails. > > > -- -- > Creating tables ... > Creating table attachments_fileattachmenthistory > Creating table diffviewer_rawfilediffdata > Creating table notifications_webhooktarget_repositories > > > [!] There was an error synchronizing the database. Make sure the > database is created and has the appropriate permissions, and then > continue. > [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3' > (errno: 150)") > > > Press Enter to continue > > > The permissions are correct and I even tried running the command by > specifying the root user of the database and their password. Some Googling > makes this seem like it could be due to Foreign key issues where the new > databases are being created out of order. I am wondering if disabling > Foreign Key Checks globally, performing the migration, and then enabling > the checks again would help and if it would be safe with respect to > ReviewBoard itself. > > Something like: > > SET GLOBAL FOREIGN_KEY_CHECKS=0; > > > Run the rb-site upgrade. > > > > SET GLOBAL FOREIGN_KEY_CHECKS=1; > > > Thoughts? Recommendations? > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database Upgrade Error
I found another discussion about this issue on this forum [forum post <https://groups.google.com/forum/#!topic/reviewboard/N8Z652ccb6M>] and sure enough, my database dump shows that the tables are using MyISAM. I converted the database dump to specify InnoDB instead using the following command and did a new import followed by an rb-site upgrade. sed 's/) ENGINE=MyISAM/) ENGINE=InnoDB/g' reviewboard.sql > reviewboard2.sql This took a really long time to import, so be sure you get it right before you try the import. I added wait_timeout = 31536000 to the [server] section of /etc/my.cnf.d/server.cnf and restarted MariaDB to ensure that the import had time to complete. Also, make sure you have enough free disk space to complete the import. Ultimately, this appears to have worked and given us successful migration of the database. Hopefully, this thread helps someone else. :) On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote: > > When attempting to perform an rb-site upgrade from version 2.0.18 to > 2.5.9, I get the following output, ending in an error. If I continue, > further table creation issues occur and the result is a corrupted database. > I do have a backup of the database, which I have been using to restore and > test the migrations. > > Rebuilding directory structure > Upgrading site settings_local.py > Updating database. This may take a while. > > > The log output below, including warnings and errors, > can be ignored unless upgrade fails. > > > -- -- > Creating tables ... > Creating table attachments_fileattachmenthistory > Creating table diffviewer_rawfilediffdata > Creating table notifications_webhooktarget_repositories > > > [!] There was an error synchronizing the database. Make sure the > database is created and has the appropriate permissions, and then > continue. > [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3' > (errno: 150)") > > > Press Enter to continue > > > The permissions are correct and I even tried running the command by > specifying the root user of the database and their password. Some Googling > makes this seem like it could be due to Foreign key issues where the new > databases are being created out of order. I am wondering if disabling > Foreign Key Checks globally, performing the migration, and then enabling > the checks again would help and if it would be safe with respect to > ReviewBoard itself. > > Something like: > > SET GLOBAL FOREIGN_KEY_CHECKS=0; > > > Run the rb-site upgrade. > > > > SET GLOBAL FOREIGN_KEY_CHECKS=1; > > > Thoughts? Recommendations? > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Database Upgrade Error
I went ahead and tested this and the upgrade finished without errors. I was able to login to Review Board but attempts to access existing review requests resulted in the following error: IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`reviewboard`.`reviews_reviewrequest_file_attachment_histories`, CONSTRAINT `reviewrequest_id_refs_id_fe050f91` FOREIGN KEY (`reviewrequest_id`) REFERENCES `reviews_reviewrequest` (`id`))') This makes sense since there were clearly Foreign Key issues previously during the upgrade so it looks like my workaround doesn't work. This installation is on CentOS 7 and Review Board was installed with EPEL packages. The installation appears to be using acceptable versions of all the dependencies and is running on Python 2.7.5. It is worth trying to perform the upgrades via older releases of Review Board between the two releases I am trying to install? On Friday, March 24, 2017 at 9:16:05 AM UTC-4, Chris Eagan wrote: > > When attempting to perform an rb-site upgrade from version 2.0.18 to > 2.5.9, I get the following output, ending in an error. If I continue, > further table creation issues occur and the result is a corrupted database. > I do have a backup of the database, which I have been using to restore and > test the migrations. > > Rebuilding directory structure > Upgrading site settings_local.py > Updating database. This may take a while. > > > The log output below, including warnings and errors, > can be ignored unless upgrade fails. > > > -- -- > Creating tables ... > Creating table attachments_fileattachmenthistory > Creating table diffviewer_rawfilediffdata > Creating table notifications_webhooktarget_repositories > > > [!] There was an error synchronizing the database. Make sure the > database is created and has the appropriate permissions, and then > continue. > [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3' > (errno: 150)") > > > Press Enter to continue > > > The permissions are correct and I even tried running the command by > specifying the root user of the database and their password. Some Googling > makes this seem like it could be due to Foreign key issues where the new > databases are being created out of order. I am wondering if disabling > Foreign Key Checks globally, performing the migration, and then enabling > the checks again would help and if it would be safe with respect to > ReviewBoard itself. > > Something like: > > SET GLOBAL FOREIGN_KEY_CHECKS=0; > > > Run the rb-site upgrade. > > > > SET GLOBAL FOREIGN_KEY_CHECKS=1; > > > Thoughts? Recommendations? > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Database Upgrade Error
When attempting to perform an rb-site upgrade from version 2.0.18 to 2.5.9, I get the following output, ending in an error. If I continue, further table creation issues occur and the result is a corrupted database. I do have a backup of the database, which I have been using to restore and test the migrations. Rebuilding directory structure Upgrading site settings_local.py Updating database. This may take a while. The log output below, including warnings and errors, can be ignored unless upgrade fails. -- -- Creating tables ... Creating table attachments_fileattachmenthistory Creating table diffviewer_rawfilediffdata Creating table notifications_webhooktarget_repositories [!] There was an error synchronizing the database. Make sure the database is created and has the appropriate permissions, and then continue. [!] Details: (1005, "Can't create table 'reviewboard.#sql-64a_3' (errno: 150)") Press Enter to continue The permissions are correct and I even tried running the command by specifying the root user of the database and their password. Some Googling makes this seem like it could be due to Foreign key issues where the new databases are being created out of order. I am wondering if disabling Foreign Key Checks globally, performing the migration, and then enabling the checks again would help and if it would be safe with respect to ReviewBoard itself. Something like: SET GLOBAL FOREIGN_KEY_CHECKS=0; Run the rb-site upgrade. SET GLOBAL FOREIGN_KEY_CHECKS=1; Thoughts? Recommendations? -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.6.11 to 1.7.6 Upgrade Issue
Christian, Is it possible for me to make manual changes to the database that would allow this operation to complete? If I understood more about what the error is describing, I might be able to make some direct changes to work around it. -Chris On Monday, April 8, 2013 2:45:23 PM UTC-4, Chris Eagan wrote: I ran the command and got the following output. Despite the error message, I restarted memcached and apache2 and went to the site. Instead of the big django explosion I got before, I now see the Review Board is taking a nap message. ~# rb-site manage /var/lib/reviewboard evolve -- --hint --execute You have requested a database evolution. This will alter tables and data currently in the 'default' database, and may result in IRREVERSABLE DATA LOSS. Evolutions should be *thoroughly* reviewed prior to execution. Are you sure you want to execute the evolutions? Type 'yes' to continue, or 'no' to cancel: yes Error: Error applying evolution: (1060, Duplicate column name 'diff_base64') On Monday, April 8, 2013 2:38:08 PM UTC-4, Christian Hammond wrote: Sorry about that.. We hit some rough bugs in Django Evolution (or rather, introduced scenarios it wasn't prepared for), but I do think that going forward, these issues should be mostly gone. So I don't normally advise this, but here's what I'd recommend in this case: 1) Back up your database 2) Run: rb-site manage /path/to/site evolve -- --hint --execute Clear your memcached and make sure that your review requests are still working properly. The --hint --execute tells Django Evolution to just make the database match the current schema. Given the situation here where those should already be in the database, I don't know what it'll do to add them (hopefully just update your schema history). If all fails, you can restore the database backup and we can try again. Christian -- Christian Hammond - chi...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Mon, Apr 8, 2013 at 11:17 AM, Chris Eagan cea...@gmail.com wrote: Yes, each server used it's own independent database. They exist on fully distinct virtual machines. This is only the second time this server has been upgraded. The first upgrade attempt I did today was run with the older version of django_evolution. That might be why the upgrade wasn't successful and why some evolutions were already applied. Unfortunately, I was over-confident and didn't back up the database prior to my upgrade attempt because the first server had upgraded fine. The first server had the newer version of django_evolution installed and I failed to check that the second server did prior to the upgrade. I have a backup of the database after the first upgrade attempt. I did not downgrade or wipe any evolutions. -Chris On Monday, April 8, 2013 2:11:02 PM UTC-4, Christian Hammond wrote: When you mentioned different servers, were these each with their own database? It's complaining about fields that already existed in 1.6.11, which shouldn't be correct. It's also showing that those evolutions were already applied. At any point did you ever downgrade or wipe an evolution? Christian On Apr 8, 2013, at 10:59, Chris Eagan cea...@gmail.com wrote: I think my last answer was wrong. I tried to upgrade and got this: ~# easy_install -U django_evolution Searching for django-evolution Reading http://downloads.reviewboard.**org/releases/ReviewBoard/1.6/http://downloads.reviewboard.org/releases/ReviewBoard/1.6/ Reading http://pypi.python.org/simple/**django_evolution/http://pypi.python.org/simple/django_evolution/ Reading http://code.google.com/p/**django-evolution/http://code.google.com/p/django-evolution/ Best match: django-evolution 0.6.9 Processing django_evolution-0.6.9-py2.6.**egg django-evolution 0.6.9 is already the active version in easy-install.pth Using /usr/local/lib/python2.6/dist-**packages/django_evolution-0.6.** 9-py2.6.egg Processing dependencies for django-evolution Finished processing dependencies for django-evolution On Monday, April 8, 2013 1:57:20 PM UTC-4, Christian Hammond wrote: Try upgrading to 0.6.9. There were a lot of fixes that went in since your version. Christian On Apr 8, 2013, at 10:53, Chris Eagan cea...@gmail.com wrote: 0.6.7-py2.6 On Monday, April 8, 2013 1:46:57 PM UTC-4, Christian Hammond wrote: Hi Chris, What version of the django_evolution module is installed? Christian -- Christian Hammond - chi...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Mon, Apr 8, 2013 at 8:35 AM, Chris Eagan cea...@gmail.com wrote: I attempted to perfom an upgrade of one of our ReviewBoard installations and I have run into a problem. The first server upgraded fine, but this one is not working. I folloed some of the recommendations in another post, but I
Re: 1.6.11 to 1.7.6 Upgrade Issue
~# rb-site manage /var/lib/reviewboard evolve -- --hint
#- Evolution for auth
from django_evolution.mutations import DeleteModel
MUTATIONS = [
DeleteModel('Message')
]
#--
#- Evolution for accounts
from django_evolution.mutations import AddField
from django.db import models
MUTATIONS = [
AddField('Profile', 'timezone', models.CharField, initial=u'UTC',
max_length=20),
AddField('Profile', 'open_an_issue', models.BooleanField, initial=True)
]
#--
#- Evolution for diffviewer
from django_evolution.mutations import AddField, DeleteField
from django.db import models
from djblets.util.fields import Base64Field
MUTATIONS = [
AddField('DiffSetHistory', 'last_diff_updated', models.DateTimeField,
null=True),
AddField('FileDiff', 'diff_hash', models.ForeignKey, null=True,
related_model='diffviewer.FileDiffData'),
AddField('FileDiff', 'parent_diff_hash', models.ForeignKey, null=True,
related_model='diffviewer.FileDiffData'),
AddField('FileDiff', 'diff64', Base64Field, initial='',
db_column='diff_base64'),
AddField('FileDiff', 'parent_diff64', Base64Field, initial='',
db_column='parent_diff_base64'),
DeleteField('FileDiff', 'parent_diff'),
DeleteField('FileDiff', 'diff')
]
#--
#- Evolution for reviews
from django_evolution.mutations import AddField, DeleteField
from django.db import models
from djblets.util.fields import JSONField
MUTATIONS = [
AddField('FileAttachmentComment', 'extra_data', JSONField, null=True),
AddField('ReviewRequest', 'last_review_activity_timestamp',
models.DateTimeField, null=True, db_column='last_review_timestamp'),
DeleteField('ReviewRequest', 'last_review_timestamp')
]
#--
#- Evolution for scmtools
from django_evolution.mutations import AddField
from django.db import models
from djblets.util.fields import JSONField
MUTATIONS = [
AddField('Repository', 'extra_data', JSONField, null=True),
AddField('Repository', 'hosting_account', models.ForeignKey, null=True,
related_model='hostingsvcs.HostingServiceAccount')
]
#--
Trial evolution successful.
Run './manage.py evolve --hint --execute' to apply evolution.
On Tuesday, April 9, 2013 2:07:36 PM UTC-4, Christian Hammond wrote:
Hi Chris,
That looks like it's trying to re-add a very, very old field that you
absolutely already have. So something is clearly quite wrong.
Can you run that with evolve --hint (no --execute) and paste the results
to me?
Christian
--
Christian Hammond - chi...@chipx86.com javascript:
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
On Tue, Apr 9, 2013 at 6:16 AM, Chris Eagan cea...@gmail.comjavascript:
wrote:
Christian,
Is it possible for me to make manual changes to the database that would
allow this operation to complete? If I understood more about what the error
is describing, I might be able to make some direct changes to work around
it.
-Chris
On Monday, April 8, 2013 2:45:23 PM UTC-4, Chris Eagan wrote:
I ran the command and got the following output. Despite the error
message, I restarted memcached and apache2 and went to the site. Instead of
the big django explosion I got before, I now see the Review Board is
taking a nap message.
~# rb-site manage /var/lib/reviewboard evolve -- --hint --execute
You have requested a database evolution. This will alter tables
and data currently in the 'default' database, and may result in
IRREVERSABLE DATA LOSS. Evolutions should be *thoroughly* reviewed
prior to execution.
Are you sure you want to execute the evolutions?
Type 'yes' to continue, or 'no' to cancel: yes
Error: Error applying evolution: (1060, Duplicate column name
'diff_base64')
On Monday, April 8, 2013 2:38:08 PM UTC-4, Christian Hammond wrote:
Sorry about that.. We hit some rough bugs in Django Evolution (or
rather, introduced scenarios it wasn't prepared for), but I do think that
going forward, these issues should be mostly gone.
So I don't normally advise this, but here's what I'd recommend in this
case:
1) Back up your database
2) Run: rb-site manage /path/to/site evolve -- --hint --execute
Clear your memcached and make sure that your review requests are still
working properly.
The --hint --execute tells Django Evolution to just make the database
match the current schema. Given the situation here where those should
already be in the database, I don't know what it'll do to add them
(hopefully just update your schema history). If all fails, you can restore
the database backup and we can try again.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
On Mon, Apr 8, 2013 at 11:17 AM, Chris Eagan cea...@gmail.com wrote:
Yes, each server used it's own independent database. They exist on
fully distinct virtual
1.6.11 to 1.7.6 Upgrade Issue
I attempted to perfom an upgrade of one of our ReviewBoard installations and I have run into a problem. The first server upgraded fine, but this one is not working. I folloed some of the recommendations in another post, but I was not successful. Thank you for any help you can provide. ~$ sudo rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Upgrading site settings_local.py Updating database. This may take a while. The log output below, including warnings and errors, can be ignored unless upgrade fails. -- begin log output -- Creating tables ... Creating table extensions_registeredextension Creating table diffviewer_filediffdata Upgrading Review Board from 1.6.11 to 1.7.6 There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Adding baseline version for new models Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automati* *cally.* ~$ sudo -i ~# mysqldump -p reviewboard reviewboard.sql ~# rb-site manage /var/lib/reviewboard dumpdata django_evolution django_evolution.json ~# sudo easy_install -U django_evolution ~# rb-site manage /var/lib/reviewboard list-evolutions Applied evolutions for 'sessions': session_expire_date_db_index Applied evolutions for 'accounts': is_private Applied evolutions for 'changedescs': fields_changed_longtext Applied evolutions for 'diffviewer': add_parent_diffs filediff_filenames_1024_chars diffset_basedir filediff_status Applied evolutions for 'reviews': change_descriptions last_review_timestamp shipit_count default_reviewer_repositories null_repository localsite group_incoming_request_count group_invite_only group_visible default_reviewer_local_site add_issues_to_comments file_attachments Applied evolutions for 'scmtools': bugzilla_url_charfield repository_raw_file_url repository_visible repository_path_length_255 localsite repository_access_control group_site repository_hosting_accounts repository_extra_data_null ~# rb-site manage /var/lib/reviewboard shell Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. (InteractiveConsole) exit() ~# rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Updating database. This may take a while. The log output below, including warnings and errors, can be ignored unless upgrade fails. -- begin log output -- Creating tables ... There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automatically.* -Chris Eagan -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en --- You received this message because you are subscribed to the Google Groups reviewboard group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6.11 to 1.7.6 Upgrade Issue
0.6.7-py2.6 On Monday, April 8, 2013 1:46:57 PM UTC-4, Christian Hammond wrote: Hi Chris, What version of the django_evolution module is installed? Christian -- Christian Hammond - chi...@chipx86.com javascript: Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Mon, Apr 8, 2013 at 8:35 AM, Chris Eagan cea...@gmail.comjavascript: wrote: I attempted to perfom an upgrade of one of our ReviewBoard installations and I have run into a problem. The first server upgraded fine, but this one is not working. I folloed some of the recommendations in another post, but I was not successful. Thank you for any help you can provide. ** ** ~$ sudo rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Upgrading site settings_local.py Updating database. This may take a while. ** ** The log output below, including warnings and errors, can be ignored unless upgrade fails. ** ** -- begin log output -- Creating tables ... Creating table extensions_registeredextension Creating table diffviewer_filediffdata Upgrading Review Board from 1.6.11 to 1.7.6 There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Adding baseline version for new models Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. ** ** The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automati* *cally.* ~$ sudo -i ~# mysqldump -p reviewboard reviewboard.sql ~# rb-site manage /var/lib/reviewboard dumpdata django_evolution django_evolution.json ~# sudo easy_install -U django_evolution ~# rb-site manage /var/lib/reviewboard list-evolutions Applied evolutions for 'sessions': session_expire_date_db_index ** ** Applied evolutions for 'accounts': is_private ** ** Applied evolutions for 'changedescs': fields_changed_longtext ** ** Applied evolutions for 'diffviewer': add_parent_diffs filediff_filenames_1024_chars diffset_basedir filediff_status ** ** Applied evolutions for 'reviews': change_descriptions last_review_timestamp shipit_count default_reviewer_repositories null_repository localsite group_incoming_request_count group_invite_only group_visible default_reviewer_local_site add_issues_to_comments file_attachments ** ** Applied evolutions for 'scmtools': bugzilla_url_charfield repository_raw_file_url repository_visible repository_path_length_255 localsite repository_access_control group_site repository_hosting_accounts repository_extra_data_null ** ** ~# rb-site manage /var/lib/reviewboard shell Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information.*** * (InteractiveConsole) exit() ~# rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Updating database. This may take a while. ** ** The log output below, including warnings and errors, can be ignored unless upgrade fails. ** ** -- begin log output -- Creating tables ... There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. ** ** The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automatically
Re: 1.6.11 to 1.7.6 Upgrade Issue
I think my last answer was wrong. I tried to upgrade and got this: ~# easy_install -U django_evolution Searching for django-evolution Reading http://downloads.reviewboard.org/releases/ReviewBoard/1.6/ Reading http://pypi.python.org/simple/django_evolution/ Reading http://code.google.com/p/django-evolution/ Best match: django-evolution 0.6.9 Processing django_evolution-0.6.9-py2.6.egg django-evolution 0.6.9 is already the active version in easy-install.pth Using /usr/local/lib/python2.6/dist-packages/django_evolution-0.6.9-py2.6.egg Processing dependencies for django-evolution Finished processing dependencies for django-evolution On Monday, April 8, 2013 1:57:20 PM UTC-4, Christian Hammond wrote: Try upgrading to 0.6.9. There were a lot of fixes that went in since your version. Christian On Apr 8, 2013, at 10:53, Chris Eagan cea...@gmail.com javascript: wrote: 0.6.7-py2.6 On Monday, April 8, 2013 1:46:57 PM UTC-4, Christian Hammond wrote: Hi Chris, What version of the django_evolution module is installed? Christian -- Christian Hammond - chi...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Mon, Apr 8, 2013 at 8:35 AM, Chris Eagan cea...@gmail.com wrote: I attempted to perfom an upgrade of one of our ReviewBoard installations and I have run into a problem. The first server upgraded fine, but this one is not working. I folloed some of the recommendations in another post, but I was not successful. Thank you for any help you can provide. ** ** ~$ sudo rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Upgrading site settings_local.py Updating database. This may take a while. ** ** The log output below, including warnings and errors, can be ignored unless upgrade fails. ** ** -- begin log output -- Creating tables ... Creating table extensions_registeredextension Creating table diffviewer_filediffdata Upgrading Review Board from 1.6.11 to 1.7.6 There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Adding baseline version for new models Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. ** ** The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automati* *cally.* ~$ sudo -i ~# mysqldump -p reviewboard reviewboard.sql ~# rb-site manage /var/lib/reviewboard dumpdata django_evolution django_evolution.json ~# sudo easy_install -U django_evolution ~# rb-site manage /var/lib/reviewboard list-evolutions Applied evolutions for 'sessions': session_expire_date_db_index ** ** Applied evolutions for 'accounts': is_private ** ** Applied evolutions for 'changedescs': fields_changed_longtext ** ** Applied evolutions for 'diffviewer': add_parent_diffs filediff_filenames_1024_chars diffset_basedir filediff_status ** ** Applied evolutions for 'reviews': change_descriptions last_review_timestamp shipit_count default_reviewer_repositories null_repository localsite group_incoming_request_count group_invite_only group_visible default_reviewer_local_site add_issues_to_comments file_attachments ** ** Applied evolutions for 'scmtools': bugzilla_url_charfield repository_raw_file_url repository_visible repository_path_length_255 localsite repository_access_control group_site repository_hosting_accounts repository_extra_data_null ** ** ~# rb-site manage /var/lib/reviewboard shell Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information.** ** (InteractiveConsole) exit() ~# rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Updating database. This may take a while. ** ** The log output below, including warnings and errors, can be ignored unless upgrade fails. ** ** -- begin log output
Re: 1.6.11 to 1.7.6 Upgrade Issue
Yes, each server used it's own independent database. They exist on fully distinct virtual machines. This is only the second time this server has been upgraded. The first upgrade attempt I did today was run with the older version of django_evolution. That might be why the upgrade wasn't successful and why some evolutions were already applied. Unfortunately, I was over-confident and didn't back up the database prior to my upgrade attempt because the first server had upgraded fine. The first server had the newer version of django_evolution installed and I failed to check that the second server did prior to the upgrade. I have a backup of the database after the first upgrade attempt. I did not downgrade or wipe any evolutions. -Chris On Monday, April 8, 2013 2:11:02 PM UTC-4, Christian Hammond wrote: When you mentioned different servers, were these each with their own database? It's complaining about fields that already existed in 1.6.11, which shouldn't be correct. It's also showing that those evolutions were already applied. At any point did you ever downgrade or wipe an evolution? Christian On Apr 8, 2013, at 10:59, Chris Eagan cea...@gmail.com javascript: wrote: I think my last answer was wrong. I tried to upgrade and got this: ~# easy_install -U django_evolution Searching for django-evolution Reading http://downloads.reviewboard.org/releases/ReviewBoard/1.6/ Reading http://pypi.python.org/simple/django_evolution/ Reading http://code.google.com/p/django-evolution/ Best match: django-evolution 0.6.9 Processing django_evolution-0.6.9-py2.6.egg django-evolution 0.6.9 is already the active version in easy-install.pth Using /usr/local/lib/python2.6/dist-packages/django_evolution-0.6.9-py2.6.egg Processing dependencies for django-evolution Finished processing dependencies for django-evolution On Monday, April 8, 2013 1:57:20 PM UTC-4, Christian Hammond wrote: Try upgrading to 0.6.9. There were a lot of fixes that went in since your version. Christian On Apr 8, 2013, at 10:53, Chris Eagan cea...@gmail.com wrote: 0.6.7-py2.6 On Monday, April 8, 2013 1:46:57 PM UTC-4, Christian Hammond wrote: Hi Chris, What version of the django_evolution module is installed? Christian -- Christian Hammond - chi...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com On Mon, Apr 8, 2013 at 8:35 AM, Chris Eagan cea...@gmail.com wrote: I attempted to perfom an upgrade of one of our ReviewBoard installations and I have run into a problem. The first server upgraded fine, but this one is not working. I folloed some of the recommendations in another post, but I was not successful. Thank you for any help you can provide. ** ** ~$ sudo rb-site upgrade /var/lib/reviewboard Rebuilding directory structure Upgrading site settings_local.py Updating database. This may take a while. ** ** The log output below, including warnings and errors, can be ignored unless upgrade fails. ** ** -- begin log output -- Creating tables ... Creating table extensions_registeredextension Creating table diffviewer_filediffdata Upgrading Review Board from 1.6.11 to 1.7.6 There are unapplied evolutions for auth. There are unapplied evolutions for accounts. There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. Adding baseline version for new models Project signature has changed - an evolution is required Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) *The stored evolutions do not completely resolve all model changes.* Run `./manage.py evolve --hint` to see a suggestion for the changes required. ** ** The following are the changes that could not be resolved: In model scmtools.Repository: Field 'extra_data' has been added Field 'hosting_account' has been added *Error: Your models contain changes that Django Evolution cannot resolve automati* *cally.* ~$ sudo -i ~# mysqldump -p reviewboard reviewboard.sql ~# rb-site manage /var/lib/reviewboard dumpdata django_evolution django_evolution.json ~# sudo easy_install -U django_evolution ~# rb-site manage /var/lib/reviewboard list-evolutions Applied evolutions for 'sessions': session_expire_date_db_index ** ** Applied evolutions for 'accounts': is_private ** ** Applied evolutions for 'changedescs': fields_changed_longtext ** ** Applied evolutions for 'diffviewer': add_parent_diffs filediff_filenames_1024_chars diffset_basedir filediff_status ** ** Applied evolutions for 'reviews
