first, a note that this whole block will only run on the server defined in `solr_cloud_leader`, which in [our case](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L23) is mb-solrcloud-1... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/hoFHDgPhaqLiVUdjSzFWClyL>)
hmm, i think i see part of the problem here
in that this task, even if it could successfully run, is not pulling in the latest work in mbssss; it's pulling in an old commit
s/mbssss/mbsssss/
if we look [one level above the local directory we want to pull config directories from], we'll see that its copy of the mbssss dir is pulling in [mbsssss @ e2e630a](https://github.com/metabrainz/mbsssss/tree/e2e630a8eac72457ad085d735043e787c9b076e0), which is nearly a year old... the submodule has not been updated in metabrainz-ansible for some time
* if we look [one level above the "local" (to the ansible control node) directory that task wants to pull config directories from](https://github.com/metabrainz/metabrainz-ansible/tree/main/files/solr_cluster_servers), we'll see that its copy of the mbssss dir is pulling in [mbsssss @ e2e630a](https://github.com/metabrainz/mbsssss/tree/e2e630a8eac72457ad085d735043e787c9b076e0), which is nearly a year old... the submodule has not been
updated in metabrainz-ansible for some time
bitmap[m]
indeed, nice find, I'll open a PR to update that
julian45[m]
so, absent my concern about the copy_links and links params potentially stepping on each other, that task should run at this time, though it will likely not produce desired results due to the outdated submodule
* so, absent my concern about the copy_links and links params potentially stepping on each other, that task seems like it should run at this time, though it will likely not produce desired results due to the outdated submodule
* so, absent my concern about the copy_links and links param values potentially stepping on each other, that task seems like it should run at this time, though it will likely not produce desired results due to the outdated submodule
bitmap[m]: fwiw, yvanzo had opened a PR to update all of the submodules in metabrainz-ansible ~1 month ago, but that still wouldn't have caught the work done in the past few weeks
* first, a note that this whole block will only run on the server defined in `solr_cloud_leader`, which in [our case](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L23) is mb-solrcloud-1... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/BUYPoWljJYzhSmetWtXcYdLZ>)
bitmap[m]
yeah, looks like we need to update the .jar file (solr_shared_libraries) too
julian45[m]
oh yes, and have solr_shared_libraries point to metabrainz/mb-solr rather than yvanzo's fork
bitmap[m]
I guess the intent of his previous PR was to only update the roles/ anyway (but conveniently there were no mbsssss changes at the time, that's the only non-role submodule)
julian45[m]
yeah, looks like it
oh, and solr_version should be 9.7.0, right?
* oh, and we're targeting solr version 9.7.0, right?
if so, we need to update `solr_version` in [here](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml), as well as the checksum for the download
this only does the last task you mentioned AFAICT though
julian45[m]
yeah afaict the only net-new commits on that branch besides that would update the submodules for the solr and zookeeper roles to a commit that's newer than they may currently be, but still older than where they need to be
s/commits/commit/
LupinIII joined the channel
i anticipate there will be little major movement here until yvanzo wakes up anyway, so i will brb shortly then proceed with deciphering the next task in the block yvanzo specified
* first, a note that this whole block that yvanzo has asked about will only run on the server defined in `solr_cloud_leader`, which in [our case](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L23) is mb-solrcloud-1... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/PsyVyhacibCrlyfifZpAVoyc>)
finally, the last top-level task within yvanzo's requested block, labeled "Create and reload Solr collections", is itself a block of three tasks that do some api calls. i'll break each of them down below.
* api calls, all of which run as the `solr` user (again, default of `solr_user`) on the target server. i'll
mrnelgin is now known as nelgin
* finally, the last top-level task within yvanzo's requested block, labeled "Create and reload Solr collections", is itself a block of three tasks that do some api calls, all of which run as the `solr` user (again, default of `solr_user`) on the target server. i'll break each of them down below.
documentation for the `ansible.builtin.uri` module used in this block can be found [here](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/uri_module.html).
the first subtask in the block, "List Solr collections", makes a GET request to a variably-defined url that _should_ resolve to `http://127.0.0.1:8983/api/cluster` (again, relative to the target server) based on [these defaults](https://github.com/metabrainz/ansible-role-solr/blob/main/defaults/main.yml#L123-129).... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/UtMSjdRAcCOJUeXhrOXACrBS>)
* in that this task, even if it could successfully run, is not pulling in the latest work in mbsssss; it's pulling in an old commit
* first, a note that this whole block that yvanzo has asked about will only run on the server defined in `solr_cloud_leader`, which in [our case](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L23) is mb-solrcloud-1... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/McJdbYQfMzRhhPqzcVFTzDIw>)
* so, absent my concern about the copy_links and links param values potentially stepping on each other, that task seems like it should run at this time, though it will likely not produce desired results due to the outdated submodule
next, "Create Solr collections" loops through [`solr_collections`](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L107-L187) and, for each top-level collection definition within the dict that was NOT part of the collections returned by the server in the previous subtask... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/...>)
* next, "Create Solr collections" loops through [`solr_collections`](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L107-L187) and, for each top-level collection definition within the dict that was NOT part of the collections returned by the server in the previous subtask,... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/...>)
* next, "Create Solr collections" loops through [`solr_collections`](https://github.com/metabrainz/metabrainz-ansible/blob/main/group_vars/solr_servers/solr.yml#L107-L187) and, for each top-level collection definition within the dict that was NOT part of the collections returned by the server in the previous subtask,... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/...>)
finally, the subtask named "Reload Solr collections" will loop through `_solr_configset_sync` (this is the output of the very first task in yvanzo's block, remember) and, for each collection that had a change as a result of the rsync task loop, will trigger a reload of that connection by calling out to `http://127.0.... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/...>)
