Dedicated container for database

[nadvornik]

What does this PR change?

This PR adds a dedicated postgres container.
The script uyuni-postgres-config.sh replaces smdba system-check autotuning functionality.

GUI diff

No difference.

• DONE

Documentation

TBD

Test coverage

ℹ️ If a major new functionality is added, it is strongly recommended that tests for the new functionality are added to the Cucumber test suite

• No tests: already covered

• DONE

Links

Part of https://github.com/SUSE/spacewalk/issues/25363

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

Before you merge

Check How to branch and merge properly!

[aaannz]

I am not sure about this part. I discussed this at length with @nadvornik and @rjmateus, but I am still not convinced.

The rotational check simply does not work in VM scenarios. virt-io driver always report rotational true, so everyone using VM will use worse config.

Which is not regression as everyone is using this worse config currently, but seems to me like a lost opportunity.

I had a brief chat with virtualization people and seems like there is simply no way how to determine if underlying VM storage is a ssd, hdd or something completely else.
We agreed that underlying scheduler should be able to deal even with higher i/o settings.

[mcalmer]

I agree. Smdba had a commandline option to set isSSD. You cannot detect it.
I would suggest we start to expect SSD and get rid of this case

[rjmateus]

@aaannz I also agree with the topic. Database disk should be fast, and we are advising to use SSD for it, so I don't see any reason to keep it (even more if we cannot detect it properly)
Get rid of HDD stuff, and assume SSD. Then in documentation, we can add a note that the database configuration is optimized to SSD, and if the users don't have it, then they should change the configuration. We can even give some hints, or have a page of how to configure for slower disks.

[nadvornik]

OK, I have changed the script. Now ssd is the default and can be changed if the script is run again with --hdd option.

[aaannz]

Related to the discussion above.

Personally I would get rid of this check and use

Suggested change

	if [ "$IS_SSD" -eq 1 ]; then
	postgres_reconfig "random_page_cost" "1.1"
	postgres_reconfig "effective_io_concurrency" "200"
	else
	postgres_reconfig "random_page_cost" "4"
	postgres_reconfig "effective_io_concurrency" "2"
	fi
	if [ "$IS_SSD" -eq 1 ]; then
	postgres_reconfig "random_page_cost" "1.1"
	postgres_reconfig "effective_io_concurrency" "20"

BTW. random_page_cost 1.1 is recommended by postgresql config for SSD disks and this value influences how likely planner is to select index scan instead of sequential scan.
Default sequential scan cost is 1.

BTW 2. Both of these options can also be overridden per table.

[rjmateus]

agree, move forward with ssd only.