Re: email issue creation not in sync

I am making progress...  I think I needed to restart the web interface to
have the error go away.  In my case I changed the wsgi config file to point
to the non-upgraded version of my tracker.  And then I changed it back to
the upgraded version.  The web interface is working now.  I think I could
have accomplished the restarting of the web interface by restarting Apache
as an alternative method.

I am also figuring out what is happening with the emails.  I had neglected
to configure roundup-mailgw to run on the new server and it was still
running on the old server.  This resulted in my issues being created in the
old server.

I should be well on my way now.

On Tue, Feb 26, 2019 at 2:07 PM Tonu Mikk <[email protected]> wrote:

> I attempted to got through the migration and tracker upgrade steps and run
> into a problem.
>
> I first ran "roundup-admin export" on my Roundup tracker running 1.5.0.
> When attempting this I got a message that I was missing required parameters:
>  Usage: export [[-]class[,class]] export_dir
>
> I didn't know how to interpret this command in terms of adding all the
> classes and so I attempted:
> roundup-admin export * export_dir
> which seemed to work and it created a folder with lots of files and
> folders in it.
>
> I then moved the tracker home directory to the new server and removed the
> db directory from the home directory.
> Then I ran the command
> roundup-admin -i tracker_home import export_dir
>
> This too seemed to work ... It showed a message on the console: setting
> file 574, setting issue 522 etc.
>
> I then made changes to the config.ini and html/page.html file as indicated
> in the upgrade documentation from 1.5.1 to 1.6.0.
>
> When I attempted to access the tracker web interface, I get a message:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 534,
> in inner_main
>     self.determine_user()
>   File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 831,
> in determine_user
>     self.clean_up()
>   File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 724,
> in clean_up
>     self.session_api.clean_up()
>   File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 192,
> in clean_up
>     self.session_db.clean()
>   File
> "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py", line
> 151, in clean
>     for sessid in self.list():
>   File
> "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py", line
> 101, in list
>     db = self.opendb('r')
>   File
> "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py", line
> 132, in opendb
>     return dbm.open(path, mode)
>   File "/usr/lib64/python2.7/dbhash.py", line 18, in open
>     return bsddb.hashopen(file, flag, mode)
>   File "/usr/lib64/python2.7/bsddb/__init__.py", line 364, in hashopen
>     d.open(file, db.DB_HASH, flags, mode)
> DBNoSuchFileError: (2, 'No such file or directory')
>
> I also tried roundup-admin migrate command on the new server, which gave
> me a message:
> "No migration action required".
>
> What could be causing this error?
>
> The documentation talks about stopping the web interface.  When running
> the tracker with mod_python or mod_wsgi is this still required?  And if it
> is, how to accomplish it?
>
> Thank you!
>
> On Tue, Feb 26, 2019 at 10:01 AM Tonu Mikk <[email protected]> wrote:
>
>> Thanks for the advice!  I see that I messed up in couple of places when
>> moving the tracker.
>>
>>    1. I was using Roundup v 1.5.0 on the old server and I am now using
>>    Roundup 1.6.1 on the new server.  That means I need to go through the
>>    upgrade steps.
>>    2. I am using the Sqlite database.  I did not do anything special for
>>    migrating the tracker backend.  I simply copied my tracker directory that
>>    included the db directory. I completely missed the migrating backends
>>    <http://www.roundup-tracker.org/docs/admin_guide.html#migrating-backends> in
>>    the Administration guide.  I will now try migrating again and this time by
>>    following the steps.
>>
>>
>> On Fri, Feb 22, 2019 at 4:36 AM Ralf Schlatterbeck <[email protected]>
>> wrote:
>>
>>> Tonu, you describe only that you copied the data of the tracker
>>> directory. You do not mention how you migrated the database. Also
>>> interesting would be what your database backend is.
>>>
>>> If you incorrectly migrate the database it can happen that the counters
>>> for issues (in the DB) are not correctly set to the highest issue
>>> number. This would mean that on creation you would (try to) overwrite an
>>> existing issue. The description of your problem looks somewhat like
>>> this, but since it doesn't seem to happen via the web-interface I'm not
>>> sure.
>>>
>>> This looks like the problem described above:
>>> > When attempting to create a new issue by emailing the email address
>>> that
>>> > the tracker checks, the new issue did not created.  However the tracker
>>> > replied that the issue did get created, but the link in the message
>>> > references an incorrect issue.  In this email below issue #519 is
>>> something
>>> > entirely different - https://www.screencast.com/t/n0qBOH2Om7vC .
>>> > When replying to tracker generated email I got response from the
>>> tracker:
>>> > The node specified by the designator in the subject of your message
>>> > ("521") does not exist.
>>> >
>>> > Subject was: "Re: [issue521] Another issue for testing email"
>>> >
>>> > When in fact the issue #521 does exist - see image at
>>> > https://www.screencast.com/t/rpfFp4Bi .
>>>
>>> Are you sure this problem (that your tracker tries to overwrite an
>>> already-existing issue when you try to create a new one) does *not*
>>> happen when you create an issue via the web-interface?
>>>
>>> There were several changes between 1.5.X and 1.6 that you should find
>>> documented in doc/upgrading.txt
>>> One change that is relevant here is the change how backends are
>>> configured. This has moved from a file in the db directory to a
>>> configuration item in config.ini.
>>>
>>> But I don't think this is the reason for the behaviour you're seeing
>>> because everything seems to work via the web interface.
>>>
>>> When processing a change to an issue (or creation of a new one) roundup
>>> has a two-stage process where first auditors from the detectors
>>> directory are run, then detectors. One detector for example is
>>> responsible for sending out nosy emails.
>>>
>>> Now one would expect that after the auditors are run, the database
>>> commit happens. This is not the case for historical reasons. So it can
>>> happen that *after* the nosy reactor is run (which sends out email)
>>> something bad happens (a traceback) and the issue, although mail was
>>> sent for it, is never created/changed and the changes are rolled back in
>>> the database.
>>>
>>> I think this is happening here.
>>>
>>> You should be able to debug this by running the roundup-mailgw on the
>>> command line and observing if a traceback occurs.
>>>
>>> >    2. The roundup versions could be different between the old server
>>> and
>>> >    the new server.  Roundup on the new server is running version 1.6.
>>> Roundup
>>> >    on the old server was installed about 1.5 years ago and could be
>>> running
>>> >    Roundup version 1.5.  Is there a way to verify which version of
>>> roundup I
>>> >    am running?  Could not find this in Roundup documentation, sorry!
>>>
>>> You can find out the version of roundup and python used with
>>> roundup-admin -v
>>>
>>> Ralf
>>> --
>>> Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
>>> Open Source Consulting                  www:   http://www.runtux.com
>>> Reichergasse 131, A-3411 Weidling       email: [email protected]
>>>
>>>
>>> _______________________________________________
>>> Roundup-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/roundup-users
>>>
>>
>>
>> --
>> Tonu Mikk
>> Adaptive Technologist | Disability Resource Center |
>> diversity.umn.edu/disability
>> University of Minnesota | umn.edu
>> [email protected] | 612-625-3307
>>
>
>
> --
> Tonu Mikk
> Adaptive Technologist | Disability Resource Center |
> diversity.umn.edu/disability
> University of Minnesota | umn.edu
> [email protected] | 612-625-3307
>


-- 
Tonu Mikk
Adaptive Technologist | Disability Resource Center |
diversity.umn.edu/disability
University of Minnesota | umn.edu
[email protected] | 612-625-3307

_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users