Jira (PDB-4893) Migration User check fails for Azure based postgresql servers

[Jonathan Law (Jira)]

Jonathan Law created an issue

PuppetDB / PDB-4893 Migration User check fails for Azure based postgresql servers Issue Type: Bug Affects Versions: PDB 6.12.0 Assignee: Unassigned Components: PuppetDB Created: 2020/09/15 7:30 AM Priority: Normal Reporter: Jonathan Law Due to the way the Azure Postgresql server usernames work the migration user check always fails. user in config file is of the format "username@hostname" the actual user in postgresql is "username", therefore the jdbc user and the config user will never match. clojure.lang.ExceptionInfo: Connected to database as "puppetdb", not migrator "puppetdb@servername" at puppetlabs.puppetdb.cli.services$require_db_connection_as.invokeStatic(services.clj:532) at puppetlabs.puppetdb.cli.services$require_db_connection_as.invoke(services.clj:527) at puppetlabs.puppetdb.cli.services$init_with_db$fn__37137.invoke(services.clj:577) at puppetlabs.puppetdb.cli.services$init_with_db.invokeStatic(services.clj:575) at puppetlabs.puppetdb.cli.services$init_with_db.invoke(services.clj:539) at puppetlabs.puppetdb.cli.services$start_puppetdb.invokeStatic(services.clj:830) at puppetlabs.puppetdb.cli.services$start_puppetdb.invoke(services.clj:791) at puppetlabs.puppetdb.cli.services$start_puppetdb_or_shutdown$fn__37359.invoke(services.clj:911) at puppetlabs.puppetdb.cli.services$start_puppetdb_or_shutdown.invokeStatic(services.clj:909) at puppetlabs.puppetdb.cli.services$start_puppetdb_or_shutdown.invoke(services.clj:904) at puppetlabs.puppetdb.cli.services$reify__37475$service_fnk__19248__auto___positional$reify__37486$fn__37489.invoke(services.clj:1016) at puppetlabs.puppetdb.utils$call_unless_shutting_down.invokeStatic(utils.clj:461) at puppetlabs.puppetdb.utils$call_unless_shutting_down.invoke(utils.clj:458) at puppetlabs.puppetdb.cli.services$reify__37475$service_fnk__19248__auto___positional$reify__37486.start(services.clj:1011) at puppetlabs.trapperkeeper.services$fn__19085$G__19066__19088.invoke(services.clj:9) at puppetlabs.trapperkeeper.services$fn__19085$G__19065__19092.invoke(services.clj:9) at puppetlabs.trapperkeeper.internal$fn__19580$run_lifecycle_fn_BANG___19587$fn__19588.invoke(internal.clj:196) at puppetlabs.trapperkeeper.internal$fn__19580$run_lifecycle_fn_BANG___19587.invoke(internal.clj:179) at puppetlabs.trapperkeeper.internal$fn__19609$run_lifecycle_fns__19614$fn__19615.invoke(internal.clj:229) at puppetlabs.trapperkeeper.internal$fn__19609$run_lifecycle_fns__19614.invoke(internal.clj:206) at puppetlabs.trapperkeeper.internal$fn__20225$build_app_STAR___20234$fn$reify__20246.start(internal.clj:605) at puppetlabs.trapperkeeper.internal$fn__20273$boot_services_for_app_STAR__STAR___20280$fn__20281$fn__20283.invoke(internal.clj:631) at puppetlabs.trapperkeeper.internal$fn__20273$boot_services_for_app_STAR__STAR___20280$fn__20281.invoke(internal.clj:629) at puppetlabs.trapperkeeper.internal$fn__20273$boot_services_for_app_STAR__STAR___20280.invoke(internal.clj:623) at clojure.core$partial$fn__5841.invoke(core.clj:2630) at puppetlabs.trapperkeeper.internal$fn__19654$initialize_lifecycle_worker__19665$fn__19666$fn__19816$state_machine__12357__auto____19841$fn__19844.invoke(internal.clj:249) at puppetlabs.trapperkeeper.internal$fn__19654$initialize_lifecycle_worker__19665$fn__19666$fn__19816$state_machine__12357__auto____19841.invoke(internal.clj:249) at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973) at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:972) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:977) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:975) at clojure.core.async$ioc_alts_BANG_$fn__12572.invoke(async.clj:384) at clojure.core.async$do_alts$fn__12512$fn__12515.invoke(async.clj:253) at clojure.core.async.impl.channels.ManyToManyChannel$fn__7176$fn__7177.invoke(channels.clj:95) at clojure.lang.AFn.run(AFn.java:22) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)   Ideally this check should be configurable or ignorable. Add Comment

This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)

[Zachary Kent (Jira)]

Zachary Kent updated an issue

PuppetDB / PDB-4893 Migration User check fails for Azure based postgresql servers

Change By: Zachary Kent Fix Version/s: PDB 6.12.1

Add Comment

[Zachary Kent (Jira)]

Zachary Kent commented on PDB-4893

Re: Migration User check fails for Azure based postgresql servers Hey Jonathan Law,  Thanks for raising this issue. We looked into it a bit this morning and read a little about the Azure PostgreSQL username requirements. We're thinking we might add a config option which allows people to disable the migration checks as a possible work around. We still want to look into the possibility of making the username configurable to handle Azure's Postgres username format, but aren't exactly sure what we want there yet. Our next scheduled FOSS release is at the end of October so any solution we come up with will likely be released then. I'll update this ticket when we start work on the issue. Thanks again!

Add Comment

[Austin Blatt (Jira)]

Austin Blatt updated an issue

PuppetDB / PDB-4893

Migration User check fails for Azure based postgresql servers

Change By: Austin Blatt Fix Version/s: PDB 6.12.1 Fix Version/s: PDB 6.13.0

Add Comment

[Austin Blatt (Jira)]

Austin Blatt updated an issue

PuppetDB / PDB-4893 Migration User check fails for Azure based postgresql servers

Change By: Austin Blatt Fix Version/s: PDB 6.13.0 Fix Version/s: PDB 6.14.0

Add Comment