The example internal-client.conf (and expirer and reconciler historically) does to have `account_autocreate = true` which means it takes the default account_autocreate = false
Which sounds weird/bad - we *also* have the auto_create_account_prefix option which defaults to . - and a lot of the places we *use* internal-client.conf (and it's cousins object-expirer.conf, container-reconciler.conf) operate on these allegedly "auto-created magic dot-accounts"
... but it's not possible to create dot account using InternalClient/internal-client.conf unless you turn on the `account_autocreate = true` config option (i.e. the default config doesn't "work")
... except it *does* work. I mean... my *production* object-expirer.conf and container-reconciler.conf don't have account_autocreate = true and it's not all horribly broken?
But in my reading this is at least half on accident.
As near as I can tell for a few reasons the object-expirer and container-reconciler end up creating their .expiring_objects and .misplaced_object accounts via direct container PUTs - the container server special cases dot accounts and the container-updater creates the accounts.
Then there's a little gem in proxy.controllers.base that lets get_container_info return a container's cache info before the container-updater has auto-vivified the account when that is needed (a PUT to a container in an auto-created account head of the container-updater).
But you definately can *not* create containers and upload objects into "auto created" dot-accounts using InternalClient/internal-client.conf unless you set `account_autocreate = true` (or happen to only create these "auto-created" .account/container's using direct container requests to the back-end storage)
Seems like the default example config should be more conducive to getting stuff done?
/me shurgs
The container sharder uses internal client to create shard clients and needs account_