In T620#10892, @nrwahl2 wrote:

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

Running a command that generates XML on demand (which is our main goal anyway), and then parsing that, is probably easier than parsing the C code.

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

In T620#10727, @nrwahl2 wrote:

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

This is reasonable as a stylistic choice and as a reminder to update the meta-data when we add an option. However, it doesn't seem either necessary or sufficient in order to guarantee we have one comprehensive list.

In T620#10726, @nrwahl2 wrote:

I feel like internationalization might be easier if we store all the options (with their descriptions, etc.) in C files. Then we can generate XML on demand.

This may also reduce duplication: we can use bit flags for options that are applicable to more than one type of object. It looks like we could do this by referencing an XML entity. However, that strikes me as less intuitive, and it would make the XML files harder to parse. (Parsability by external tools seems like the main advantage of using a static XML file as the source of truth.)

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

It might even be worthwhile to keep the OCF-like metadata in XML files to be used as the definitive list, with the sysconfig file, ReST files for the books, and C and Python data files created from it automatically via make targets. Alternatively, we could install the XML files, and C and Python APIs could parse them.

For pcmk__designated_controller(), it seems reasonable to just ask the local controller for controld_globals.dc_name, using that as the source of truth instead of broadcasting a ping.

• If it's NULL when there is in fact a DC somewhere, that should be a very temporary state, and "no DC" is still "true" from the local perspective.
• If it's set when the DC has gone offline or something, then similar to above.
• If it's possible for multiple nodes to transiently see themselves as DC, then that already complicates the "ping the DC and wait for a response" approach we use now. There's no obviously correct answer in that case.

All of this stems from dropping the mainloops in pcmk_cluster_queries.c. We replaced them with sync when the timeout is 0 in a6ec43e3. We replaced them with poll when the timeout is greater than 0 in 8771565f. The sync change is causing this problem. It's unclear if the poll change has caused or will cause any problems; that seems less likely, but it's possible.

This is now: