upgrade 5 to 6: is not an entity value type, skipping...

[hkais]

on the last step of the upgrade I did get this error:

Code: Select all

Warning: Ticket::SearchIndexModule is not an entity value type, skipping...
Warning: Ticket::StorageModule is not an entity value type, skipping...

Ticket::Type::Default is invalid, select one of the choices below:
    [1] default

Your choice: 1

Deployment successful.

Following settings were not fixed:
  - Ticket::SearchIndexModule,
  - Ticket::StorageModule

Please use console command (bin/otrs.Console.pl Admin::Config::Update --help) or GUI to fix them.

Trying to do the settings from command line:

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Read --setting-name Ticket::SearchIndexModule
Gathering setting value...

Setting: Ticket::SearchIndexModule
Kernel::System::Ticket::ArticleSearchIndex::RuntimeDB

Done.

Now updating to what was found in forums, but still unclear why this cannot be handled well by migration? Or have I missed something in documentation?

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Update --setting-name Ticket::SearchIndexModule --value Kernel::System::Ticket::ArticleSearchIndex::DB
Updating setting value...

ERROR: OTRS-otrs.Console.pl-Admin::Config::Update-10 Perl: 5.30.0 OS: linux Time: Tue Feb 15 08:23:52 2022

 Message: Setting Ticket::StorageModule Effective value is not correct: Kernel::System::Ticket::ArticleStorageDB doesn't satisfy ValueFilter(Kernel/System/Ticket/ArticleStorage*.pm)!

 Traceback (26325):
   Module: Kernel::System::SysConfig::ConfigurationDeploy Line: 3486
   Module: Kernel::System::Console::Command::Admin::Config::Update::Run Line: 234
   Module: (eval) Line: 461
   Module: Kernel::System::Console::BaseCommand::Execute Line: 455
   Module: Kernel::System::Console::InterfaceConsole::Run Line: 81
   Module: bin/otrs.Console.pl Line: 37

Error: Deployment failed!

crap manually not possible.
Trying to start apache to login, but login is not possible at all. Since login screen looks odd and also login is not getting accepted.
Recheck settings:

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Read --setting-name Ticket::SearchIndexModule
Gathering setting value...

Setting: Ticket::SearchIndexModule
Kernel::System::Ticket::ArticleSearchIndex::DB

Seems setting where taken over, even if error occured?
Setting seems to be set even if previously named it telling me something else

Strange. Okay lets go on, even my gut tells me to stop here

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Read --setting-name Ticket::StorageModule
Gathering setting value...

Setting: Ticket::StorageModule
Kernel::System::Ticket::ArticleStorageDB

Done.

lets try...

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Update --setting-name Ticket::Ticket::StorageModule --value Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB
ERROR: OTRS-otrs.Console.pl-Admin::Config::Update-10 Perl: 5.30.0 OS: linux Time: Tue Feb 15 08:41:35 2022

 Message: Setting Ticket::Ticket::StorageModule is invalid!

 Traceback (27788): 
   Module: Kernel::System::SysConfig::SettingGet Line: 191
   Module: Kernel::System::Console::Command::Admin::Config::Update::PreRun Line: 79
   Module: (eval) Line: 447
   Module: Kernel::System::Console::BaseCommand::Execute Line: 447
   Module: Kernel::System::Console::InterfaceConsole::Run Line: 81
   Module: bin/otrs.Console.pl Line: 37

Error: setting-name is invalid! at /opt/otrs/Kernel/System/Console/Command/Admin/Config/Update.pm line 84.

crap again

Code: Select all

sudo -u otrs bin/otrs.Console.pl Admin::Config::Read --setting-name Ticket::StorageModule
Gathering setting value...

Setting: Ticket::StorageModule
Kernel::System::Ticket::ArticleStorageDB

Done.

Looks for me there are multiple preconditions not checked by migration or not documented what to do.
This is really annoying. Stopping migration, going to backup and consider the upgrade once ore as failed (now the approach number 5 which failed)

[hkais]

Did rollback to backup.
See if where was a issue in the past, but looks all fine from perspective of an admin:

Screenshot_02674.png

and

Screenshot_02675.png

It is very annoying and unclear where all this issues come from.

[skullz]

Try manually (after update to 6.0.x) change it at /opt/otrs/Kernel/Config/Files/ZZZAAuto.pm

Code: Select all

(-) $Self->{'Ticket::SearchIndexModule'} =  'Kernel::System::Ticket::ArticleSearchIndex::StaticDB';
(+) $Self->{'Ticket::SearchIndexModule'} =  'Kernel::System::Ticket::ArticleSearchIndex::DB';

Then try,

Code: Select all

shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild --cleanup"
shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild"
shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Sync"

good luck

[root]

Looks for me there are multiple preconditions not checked by migration or not documented what to do.
This is really annoying. Stopping migration, going to backup and consider the upgrade once ore as failed (now the approach number 5 which failed)

Hi,

I don't know your system in detail but I fix these warning at the end. By otrs.Console.pl or via the GUI. But what I really not understand is why do you need to rollback? have you ever tried a test migration? It's mandatory for us, because of the many possible settings and add-ons no one can ever see what's coming. Adn we're doing about 10-20 migrations every month.

- Roy

[root]

Hi,

One question: have you executed the command
'bin/otrs.Console.pl Dev::Tools::Migrate::ConfigXMLStructure --source-directory Kernel/Config/Files'?

- Roy

[hkais]

Hi,

One question: have you executed the command
'bin/otrs.Console.pl Dev::Tools::Migrate::ConfigXMLStructure --source-directory Kernel/Config/Files'?

- Roy

yes did this step as of documentation
the only odd thing is, that the old and the new version files are still at the location.
Means the new files under Files/XML and the old Files/
Shall the old files be deleted manually?

[hkais]

Try manually (after update to 6.0.x) change it at /opt/otrs/Kernel/Config/Files/ZZZAAuto.pm

Code: Select all

(-) $Self->{'Ticket::SearchIndexModule'} =  'Kernel::System::Ticket::ArticleSearchIndex::StaticDB';
(+) $Self->{'Ticket::SearchIndexModule'} =  'Kernel::System::Ticket::ArticleSearchIndex::DB';

Then try,

Code: Select all

shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild --cleanup"
shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild"
shell > su -m otrs -c "/opt/otrs/bin/otrs.Console.pl Maint::Config::Sync"

good luck

for me it is not clear what shall be done here?
Try manually (after update to 6.0.x) change it at /opt/otrs/Kernel/Config/Files/ZZZAAuto.pm

Let me try to repeat in clearer instructions:

- run scripts/DBUpdate-to-6.pl
- after failure modify /opt/otrs/Kernel/Config/Files/ZZZAAuto.pm

now it is unclear what is next?

- rerun scripts/DBUpdate-to-6.pl

- and afterwards the Rebuilds?

[root]

yes did this step as of documentation
the only odd thing is, that the old and the new version files are still at the location.
Means the new files under Files/XML and the old Files/
Shall the old files be deleted manually?

Hi,

And this is exactly the main problem. Not reading and understanding the documentation:

2022-02-15 at 10.31 PM.png

It's only intended for custom XML files, not for the one the framework brings.

- Roy

[hkais]

yes did this step as of documentation
the only odd thing is, that the old and the new version files are still at the location.
Means the new files under Files/XML and the old Files/
Shall the old files be deleted manually?

And this is exactly the main problem. Not reading and understanding the documentation:
2022-02-15 at 10.31 PM.png

It's only intended for custom XML files, not for the one the framework brings.

Hmm checking what I may have done wrong.
I have executed this:

Code: Select all

bin/otrs.Console.pl Dev::Tools::Migrate::ConfigXMLStructure --source-directory Kernel/Config/Files

But the original files are not deleted afterwards, so now a bit confused

[root]

Hi,

This command converts version 5 XML files into the version 6 format, the intended use is ONLY for custom files. By ignoring the note in the manual you converting the version 5 files which have the same name like the one from version 6 which leads to overwritten files. This is the reason for messed up migration, e.g. the article storage backends have new names, the OTRSTimeZone setting is not anymore in the XML files because it's overwritten.

I'll stop here because asking for better documentation also requires thorough reading

- Roy

[hkais]

This command converts version 5 XML files into the version 6 format, the intended use is ONLY for custom files. By ignoring the note in the manual you converting the version 5 files which have the same name like the one from version 6 which leads to overwritten files. This is the reason for messed up migration, e.g. the article storage backends have new names, the OTRSTimeZone setting is not anymore in the XML files because it's overwritten.

I'll stop here because asking for better documentation also requires thorough reading

rechecked once more the documentation to see what I am doing wrong. We talk both about the same doc?
https://doc.znuny.org/doc/manual/admin/ ... ating.html
right?

Screenshot_02678.png

and

Screenshot_02679.png

I am willing to identify myself as an issue in the migration process. But I cannot see the instructions that I have to handle standard vs custom files or that I have to be careful of moving or deleting them. I am simply executing the commands like mentioned.

But honestly, if a migration documentation requires knowledge of "standard" and "custom" configurations, this is knowledge of developers.
Also if there are different handling for "standard" config files. Why the hack are they not properly handled by the migration script itself? Who knows better the "standard" config files? The developers or some admins, who try to do their job on handling software updates?

Please let me know what specifically I shall do here? As written I have only executed

Code: Select all

sudo -u otrs /opt/otrs/bin/otrs.Console.pl Dev::Tools::Migrate::ConfigXMLStructure --source-directory Kernel/Config/Files

but it looks like that I should have done more, e.g. deleting converted standard files or deleting original files. Or maybe something totally different

[root]

Hi,

At least if you don't know if something ist custom you should ask.

- Roy

[hkais]

Roy, it reads to me that you are somehow annoyed.
We both invest time here to fix issues. I invest the time here to help to evolve Znuny doc or better the migration scripts. You help the users, in this case me. I think it would be better to keep the emotions out.
If it helps you, you can consider me as a DAU, I am fine with it, since good documentations or better the software shall try to handle such cases.

Going back to logical operation:
- if I have to ask an development expert first what to do, a migration documentation is senseless of the point of view to be able to easily handle a migration. Please consider this.
To take a comparission: do you want to ask first a microsoft or linux developer what you shall care of, before you upgrade the corresponding software? I do not think this is a good basement of a good documentation or good software migration paths.

Anyway, I am still not clear what I am doing wrong. Can you please let me know?
What is the final location of the new config files?
Kernel/Config/Files/XML/
or
Kernel/Config/Files/

and do the new config files have to be at the final location before starting the
scripts/DBUpdate-to-6.pl ?

[root]

What is the final location of the new config files?
Kernel/Config/Files/XML/
or
Kernel/Config/Files/

and do the new config files have to be at the final location before starting the
scripts/DBUpdate-to-6.pl ?

Hi,

The XML file fov version 6 belong to Kernel/Config/Files/XML and they are already in place when the archive (.tar.gz, .zip, etc.) is extracted. So, it's obvious they are already there before scripts/DBUpdate-to-6.pl is executed.

- Roy

[hkais]

okay in this case I am having the files on the right location.
But following still unclear:

Screenshot_02680.png

1. this is the location like required in OTRS5 and in old format
2. this is the "new" XML location, which have been converted by Dev::Tools::Migrate::ConfigXMLStructure
3. this are the old format files
4. this are the ZZZ config files

To clarify my issues here:
to 3) do I need to delete these files if the format was (like in my case) converted to folder XML?
to 4) do I need to convert them too? Or do I need to copy them to XML folder? Or is it already correct like they are located here?

fyi: otrs-znunyUpgradePreparedMissingDBupgrade is a backup copy of the prepared sources, which I move to /opt/otrs before starting the migration. So the migration runs always from /opt/otrs like all previous version have been installed too on centos via rpm

[reneeb]

The ClientReplied.xml and the Support.xml seem to be customized XML files (or may be delivered with some addons). If those files are your own files you have to migrate them. The other XML files are Core configuration files and they are shipped with Znuny.

So: Delete the .xml files in the Kernel/Config/Files directory (you can keep the two custom xml files for reference purposes), Keep all the *.pm files in Kernel/Config/Files, restore the Core configuration files in Kernel/Config/Files/XML.

[reneeb]

- if I have to ask an development expert first what to do, a migration documentation is senseless of the point of view to be able to easily handle a migration. Please consider this.

Usually you don't have to ask the any developer that you do not have hired... The "standard" files shouldn't be in the Kernel/Config/Files directory (did you copy them to that folder during migration?) Config files shipped with addons shouldn't be there either. Addons for the new version should ship their config files in the correct directory.

So you should just see custom XML files there (what custom is, should be documented on your side).

[zzz]

Sorry, I lost track of your current problem, but you did not fix your SearchIndexModule issue.
Skullz gave a good hint. Try this first:

Code: Select all

/opt/otrs/bin/otrs.Console.pl Admin::Config::Update --setting-name Ticket::SearchIndexModule --value 'Kernel::System::Ticket::ArticleSearchIndex::DB'

And check your logs for errors when you try to log in to the system. The second issue I see is that you're having a wrongly configured 'Ticket::StorageModule' setting, which can/should not be possible as this setting does not exist in version 6.

— Emin

[hkais]

Finally I got support and could fix my issues. In a few days the steps will be provided for the community

Thx so far for all support!