doc: Write about --cmd in startup part

:h startup doesn't describe where the --cmd arguments are executed. Write about it.
Note:
The command line is parsed in command_line_scan() in main.c, then mch_init(), set_init_2() and some initializations are executed, then exe_pre_commands() executes the --cmd arguments.

:h startup doesn't describe where the --cmd arguments are executed.
Write about it.
Note:
The command line is parsed in command_line_scan() in main.c, then
mch_init(), set_init_2() and some initializations are executed, then
exe_pre_commands() executes the --cmd arguments.

I think it should be above the last line in that section:

Process the arguments
The options and file names from the command that start Vim are
inspected.
The |-V| argument can be used to display or log what happens next,
useful for debugging the initializations.
The |--cmd| arguments are executed.
Buffers are created for all files (but not loaded yet).

A few more things are happening, but we don't want too many details in
this overview.
--
From "know your smileys":
(X0||)   Double hamburger with lettuce and tomato
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Browbeat fails to install

ASK [install browbeat] ********************************************************************************************************************************************************************
fatal: [e23-h15-740xd.alias.bos.scalelab.redhat.com]: FAILED! => {"changed": true, "cmd": "ansible-playbook -i hosts install/browbeat.yml\n", "delta": "0:08:07.410400", "end": "2019-10-14 06:36:13.528007", "msg": "non-zero return code", "rc": 2, "start": "2019-10-14 06:28:06.117607", "stderr": " [WARNING]: Found both group and host with same name: undercloud", "stderr_lines": [" [WARNING]: Found both group and host with same name: undercloud"], "stdout": "\nPLAY [browbeat] ****************************************************************\n\nTASK [Gathering Facts] *********************************************************\nMonday 14 October 2019  06:28:07 +0000 (0:00:00.115)       0:00:00.115 ******** \nok: [localhost]\n\nTASK [common : Check external connectivity] ************************************\nMonday 14 October 2019  06:28:12 +0000 (0:00:05.415)       0:00:05.530 ******** \nchanged: [localhost]\n\nTASK [common : Add DNS record] *************************************************\nMonday 14 October 2019  06:28:15 +0000 (0:00:02.709)       0:00:08.240 ******** \nskipping: [localhost]\n\nTASK [browbeat : Check for supported distribution] *****************************\nMonday 14 October 2019  06:28:15 +0000 (0:00:00.104)       0:00:08.345 ******** \nskipping: [localhost]\n\nTASK [browbeat : Install dependencies for CentOS] ******************************\nMonday 14 October 2019  06:28:15 +0000 (0:00:00.104)       0:00:08.449 ******** \nchanged: [localhost] => (item=[u'gcc', u'gcc-c++', u'git', u'libffi-devel', u'libsemanage-python', u'openssl-devel', u'policycoreutils-python', u'python-devel'])\n\nTASK [browbeat : Install dependencies for RHEL8] *******************************\nMonday 14 October 2019  06:28:36 +0000 (0:00:21.064)       0:00:29.514 ******** \nskipping: [localhost] => (item=[]) \n\nTASK [browbeat : Install pip] **************************************************\nMonday 14 October 2019  06:28:36 +0000 (0:00:00.210)       0:00:29.725 ******** \nok: [localhost]\n\nTASK [browbeat : Update virtualenv and setuptools] *****************************\nMonday 14 October 2019  06:28:39 +0000 (0:00:02.807)       0:00:32.533 ******** \nchanged: [localhost] => (item={u'version': u'15.2.0', u'name': u'virtualenv'})\nchanged: [localhost] => (item={u'version': u'38.7.0', u'name': u'setuptools'})\n\nTASK [browbeat : Install virtualenv and setuptools- zuul user] *****************\nMonday 14 October 2019  06:28:51 +0000 (0:00:11.594)       0:00:44.127 ******** \nskipping: [localhost] => (item=virtualenv) \nskipping: [localhost] => (item=setuptools) \n\nTASK [browbeat : Determine if browbeat directory exists already] ***************\nMonday 14 October 2019  06:28:51 +0000 (0:00:00.119)       0:00:44.247 ******** \nok: [localhost]\n\nTASK [browbeat : debug] ********************************************************\nMonday 14 October 2019  06:28:53 +0000 (0:00:02.517)       0:00:46.764 ******** \nok: [localhost] => {\n    "msg": "Browbeat directory exists already."\n}\n\nTASK [browbeat : Clone browbeat on undercloud] *********************************\nMonday 14 October 2019  06:28:53 +0000 (0:00:00.135)       0:00:46.900 ******** \nskipping: [localhost]\n\nTASK [browbeat : Create browbeat virtualenv] ***********************************\nMonday 14 October 2019  06:28:53 +0000 (0:00:00.105)       0:00:47.006 ******** \nchanged: [localhost]\n\nTASK [browbeat : Setup browbeat-venv CA certificate path] **********************\nMonday 14 October 2019  06:29:01 +0000 (0:00:07.940)       0:00:54.946 ******** \nskipping: [localhost]\n\nTASK [browbeat : Determine if generate_tripleo_hostfile has been run] **********\nMonday 14 October 2019  06:29:02 +0000 (0:00:00.109)       0:00:55.055 ******** \nok: [localhost]\n\nTASK [browbeat : debug] ********************************************************\nMonday 14 October 2019  06:29:04 +0000 (0:00:02.330)       0:00:57.386 ******** \nok: [localhost] => {\n    "msg": "Hosts file is already generated."\n}\n\nTASK [browbeat : Generate hosts and ssh-config on Browbeat Machine - Default(stack)] ***\nMonday 14 October 2019  06:29:04 +0000 (0:00:00.138)       0:00:57.525 ******** \nskipping: [localhost]\n\nTASK [browbeat : Generate hosts and ssh-config on Browbeat Machine - Zuul] *****\nMonday 14 October 2019  06:29:04 +0000 (0:00:00.109)       0:00:57.634 ******** \nskipping: [localhost]\n\nTASK [browbeat : Move files to correct location] *******************************\nMonday 14 October 2019  06:29:04 +0000 (0:00:00.110)       0:00:57.745 ******** \nskipping: [localhost] => (item=hosts) \nskipping: [localhost] => (item=heat-admin-id_rsa) \n\nTASK [browbeat : Install requirements.txt into browbeat-venv] ******************\nMonday 14 October 2019  06:29:04 +0000 (0:00:00.120)       0:00:57.865 ******** \nchanged: [localhost]\n\nTASK [stockpile : Clone stockpile] *********************************************\nMonday 14 October 2019  06:30:16 +0000 (0:01:11.840)       0:02:09.706 ******** \nchanged: [localhost]\n\nTASK [browbeat-results : Install httpd] ****************************************\nMonday 14 October 2019  06:30:20 +0000 (0:00:04.257)       0:02:13.963 ******** \nok: [localhost]\n\nTASK [browbeat-results : Remove welcome.conf if it exists] *********************\nMonday 14 October 2019  06:30:23 +0000 (0:00:02.773)       0:02:16.736 ******** \nok: [localhost]\n\nTASK [browbeat-results : Setup browbeat.conf in /etc/httpd/conf.d] *************\nMonday 14 October 2019  06:30:26 +0000 (0:00:02.578)       0:02:19.315 ******** \nchanged: [localhost]\n\nTASK [browbeat-results : Set seboolean(httpd_read_user_content)] ***************\nMonday 14 October 2019  06:30:30 +0000 (0:00:04.379)       0:02:23.694 ******** \nchanged: [localhost]\n\nTASK [browbeat-results : Allow httpd to serve content in "/home/stack"] ********\nMonday 14 October 2019  06:30:33 +0000 (0:00:03.033)       0:02:26.728 ******** \nchanged: [localhost]\n\nTASK [browbeat-results : Allow httpd to listen to port (9001)] *****************\nMonday 14 October 2019  06:30:35 +0000 (0:00:02.313)       0:02:29.041 ******** \nchanged: [localhost]\n\nTASK [browbeat-results : Allow httpd to listen to port (9001) via add] *********\nMonday 14 October 2019  06:30:42 +0000 (0:00:06.285)       0:02:35.326 ******** \nskipping: [localhost]\n\nTASK [browbeat-results : Start httpd] ******************************************\nMonday 14 October 2019  06:30:42 +0000 (0:00:00.107)       0:02:35.434 ******** \nok: [localhost]\n\nTASK [firewall : Determine if firewalld is in use] *****************************\nMonday 14 October 2019  06:30:44 +0000 (0:00:02.504)       0:02:37.939 ******** \nfatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}\n...ignoring\n\nTASK [firewall : Determine if firewalld is active] *****************************\nMonday 14 October 2019  06:30:47 +0000 (0:00:02.310)       0:02:40.249 ******** \nfatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}\n...ignoring\n\nTASK [firewall : (shaker) Determine if TCP/5555 is already active] *************\nMonday 14 October 2019  06:30:49 +0000 (0:00:02.291)       0:02:42.541 ******** \nfatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}\n...ignoring\n\nTASK [firewall : (browbeat_results) Determine if TCP/9001 is already active] ***\nMonday 14 October 2019  06:30:51 +0000 (0:00:02.275)       0:02:44.817 ******** \nfatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}\n...ignoring\n\nTASK [firewall : (shaker) Add firewall rule for TCP/5555 (firewalld)] **********\nMonday 14 October 2019  06:30:54 +0000 (0:00:02.273)       0:02:47.090 ******** \nskipping: [localhost]\n\nTASK [firewall : (browbeat_results) Add firewall rule for TCP/9001 (firewalld)] ***\nMonday 14 October 2019  06:30:54 +0000 (0:00:00.115)       0:02:47.206 ******** \nskipping: [localhost]\n\nTASK [firewall : (shaker) check firewall rules for TCP/5555 (iptables-services)] ***\nMonday 14 October 2019  06:30:54 +0000 (0:00:00.112)       0:02:47.318 ******** \nchanged: [localhost]\n\nTASK [firewall : (browbeat_results) Check firewall rules for TCP/9001 (iptables-services)] ***\nMonday 14 October 2019  06:30:56 +0000 (0:00:02.298)       0:02:49.617 ******** \nchanged: [localhost]\n\nTASK [firewall : check if iptables rules exist] ********************************\nMonday 14 October 2019  06:30:58 +0000 (0:00:02.299)       0:02:51.917 ******** \nok: [localhost]\n\nTASK [firewall : (shaker) Add firewall rule for TCP/5555 (iptables-services)] ***\nMonday 14 October 2019  06:31:01 +0000 (0:00:02.289)       0:02:54.206 ******** \nchanged: [localhost]\n\nTASK [firewall : (browbeat_results) Add firewall rule for TCP/9001 (iptables-services)] ***\nMonday 14 October 2019  06:31:03 +0000 (0:00:02.524)       0:02:56.731 ******** \nchanged: [localhost]\n\nTASK [perfkitbenchmarker : Create perfkit virtualenv] **************************\nMonday 14 October 2019  06:31:06 +0000 (0:00:02.329)       0:02:59.060 ******** \nchanged: [localhost]\n\nTASK [perfkitbenchmarker : Setup perfkit-venv CA certificate path] *************\nMonday 14 October 2019  06:31:11 +0000 (0:00:05.683)       0:03:04.743 ******** \nskipping: [localhost]\n\nTASK [perfkitbenchmarker : Determine if PerfKitBenchmarker is already cloned] ***\nMonday 14 October 2019  06:31:11 +0000 (0:00:00.106)       0:03:04.850 ******** \nok: [localhost]\n\nTASK [perfkitbenchmarker : debug] **********************************************\nMonday 14 October 2019  06:31:14 +0000 (0:00:02.265)       0:03:07.116 ******** \nskipping: [localhost]\n\nTASK [perfkitbenchmarker : Clone PerfKitBenchmarker on undercloud] *************\nMonday 14 October 2019  06:31:14 +0000 (0:00:00.108)       0:03:07.224 ******** \nchanged: [localhost]\n\nTASK [perfkitbenchmarker : Install PerfKitBenchmarker requirements into perfkit-venv] ***\nMonday 14 October 2019  06:31:20 +0000 (0:00:05.944)       0:03:13.168 ******** \nchanged: [localhost]\n\nTASK [perfkitbenchmarker : Install PerfKitBenchmarker Openstack requirements into perfkit-venv] ***\nMonday 14 October 2019  06:31:41 +0000 (0:00:21.190)       0:03:34.359 ******** \nchanged: [localhost]\n\nTASK [perfkitbenchmarker : Fix requirements for (OSP11 Ocata) inside perfkit-venv] ***\nMonday 14 October 2019  06:32:00 +0000 (0:00:19.128)       0:03:53.487 ******** \nchanged: [localhost] => (item={u'version': u'0.9.17', u'name': u'openstacksdk'})\nchanged: [localhost] => (item={u'version': u'3.12.0', u'name': u'python-openstackclient'})\nchanged: [localhost] => (item={u'version': u'9.1.0', u'name': u'python-novaclient'})\n\nTASK [rally : Create rally virtualenv] *****************************************\nMonday 14 October 2019  06:32:15 +0000 (0:00:15.312)       0:04:08.799 ******** \nchanged: [localhost]\n\nTASK [rally : Rally Add browbeat to Python path] *******************************\nMonday 14 October 2019  06:32:21 +0000 (0:00:05.681)       0:04:14.481 ******** \nchanged: [localhost]\n\nTASK [rally : Setup rally-venv CA certificate path] ****************************\nMonday 14 October 2019  06:32:23 +0000 (0:00:02.315)       0:04:16.796 ******** \nskipping: [localhost]\n\nTASK [rally : Install Rally with OpenStack plugins into rally-venv] ************\nMonday 14 October 2019  06:32:23 +0000 (0:00:00.104)       0:04:16.901 ******** \nchanged: [localhost]\n\nTASK [rally : Install elasticsearch into rally-venv] ***************************\nMonday 14 October 2019  06:33:41 +0000 (0:01:17.803)       0:05:34.705 ******** \nchanged: [localhost]\n\nTASK [rally : Create rally configuration directory] ****************************\nMonday 14 October 2019  06:33:45 +0000 (0:00:04.238)       0:05:38.943 ******** \nchanged: [localhost]\n\nTASK [rally : Setup rally.conf] ************************************************\nMonday 14 October 2019  06:33:48 +0000 (0:00:02.384)       0:05:41.327 ******** \nchanged: [localhost]\n\nTASK [rally : Setup rally database] ********************************************\nMonday 14 October 2019  06:33:52 +0000 (0:00:04.072)       0:05:45.400 ******** \nchanged: [localhost]\n\nTASK [rally : Setup rally deployment] ******************************************\nMonday 14 October 2019  06:33:55 +0000 (0:00:03.433)       0:05:48.834 ******** \nchanged: [localhost]\n\nTASK [rally : Check Rally deployment] ******************************************\nMonday 14 October 2019  06:34:01 +0000 (0:00:05.235)       0:05:54.069 ******** \nfatal: [localhost]: FAILED! => {"changed": true, "cmd": ". /home/stack/browbeat/.rally-venv/bin/activate; . /home/stack/overcloudrc; rally deployment check", "delta": "0:02:10.216886", "end": "2019-10-14 06:36:13.067228", "msg": "non-zero return code", "rc": 1, "start": "2019-10-14 06:34:02.850342", "stderr": "2019-10-14 06:36:12.928 150266 WARNING keystoneauth.identity.generic.base [-] Failed to discover available identity versions when contacting http://<IP_ADDRESS>:5000//. Attempting to parse version from URL.: ConnectFailure: Unable to establish connection to http://<IP_ADDRESS>:5000//: HTTPConnectionPool(host='<IP_ADDRESS>', port=5000): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fbcccf92610>: Failed to establish a new connection: [Errno 110] Connection timed out',))\u001b[00m", "stderr_lines": ["2019-10-14 06:36:12.928 150266 WARNING keystoneauth.identity.generic.base [-] Failed to discover available identity versions when contacting http://<IP_ADDRESS>:5000//. Attempting to parse version from URL.: ConnectFailure: Unable to establish connection to http://<IP_ADDRESS>:5000//: HTTPConnectionPool(host='<IP_ADDRESS>', port=5000): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fbcccf92610>: Failed to establish a new connection: [Errno 110] Connection timed out',))\u001b[00m"], "stdout": "--------------------------------------------------------------------------------\nPlatform openstack:\n--------------------------------------------------------------------------------\n\nError while checking admin credentials:\n\tAuthenticationFailed: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Unable to establish connection to http://<IP_ADDRESS>:5000//", "stdout_lines": ["--------------------------------------------------------------------------------", "Platform openstack:", "--------------------------------------------------------------------------------", "", "Error while checking admin credentials:", "\tAuthenticationFailed: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Unable to establish connection to http://<IP_ADDRESS>:5000//"]}\n\nRUNNING HANDLER [browbeat-results : restart httpd] *****************************\nMonday 14 October 2019  06:36:13 +0000 (0:02:12.426)       0:08:06.496 ******** \n\nRUNNING HANDLER [firewall : restart iptables] **********************************\nMonday 14 October 2019  06:36:13 +0000 (0:00:00.000)       0:08:06.497 ******** \n\tto retry, use: --limit @/home/stack/browbeat/ansible/install/browbeat.retry\n\nPLAY RECAP *********************************************************************\nlocalhost                  : ok=42   changed=31   unreachable=0    failed=1   \n\nMonday 14 October 2019  06:36:13 +0000 (0:00:00.002)       0:08:06.500 ******** \n=============================================================================== \nrally : Check Rally deployment ---------------------------------------- 132.43s\nrally : Install Rally with OpenStack plugins into rally-venv ----------- 77.80s\nbrowbeat : Install requirements.txt into browbeat-venv ----------------- 71.84s\nperfkitbenchmarker : Install PerfKitBenchmarker requirements into perfkit-venv -- 21.19s\nbrowbeat : Install dependencies for CentOS ----------------------------- 21.06s\nperfkitbenchmarker : Install PerfKitBenchmarker Openstack requirements into perfkit-venv -- 19.13s\nperfkitbenchmarker : Fix requirements for (OSP11 Ocata) inside perfkit-venv -- 15.31s\nbrowbeat : Update virtualenv and setuptools ---------------------------- 11.59s\nbrowbeat : Create browbeat virtualenv ----------------------------------- 7.94s\nbrowbeat-results : Allow httpd to listen to port (9001) ----------------- 6.29s\nperfkitbenchmarker : Clone PerfKitBenchmarker on undercloud ------------- 5.94s\nperfkitbenchmarker : Create perfkit virtualenv -------------------------- 5.68s\nrally : Create rally virtualenv ----------------------------------------- 5.68s\nGathering Facts --------------------------------------------------------- 5.42s\nrally : Setup rally deployment ------------------------------------------ 5.24s\nbrowbeat-results : Setup browbeat.conf in /etc/httpd/conf.d ------------- 4.38s\nstockpile : Clone stockpile --------------------------------------------- 4.26s\nrally : Install elasticsearch into rally-venv --------------------------- 4.24s\nrally : Setup rally.conf ------------------------------------------------ 4.07s\nrally : Setup rally database -------------------------------------------- 3.43s", "stdout_lines": ["", "PLAY [browbeat] ****************************************************************", "", "TASK [Gathering Facts] *********************************************************", "Monday 14 October 2019  06:28:07 +0000 (0:00:00.115)       0:00:00.115 ******** ", "ok: [localhost]", "", "TASK [common : Check external connectivity] ************************************", "Monday 14 October 2019  06:28:12 +0000 (0:00:05.415)       0:00:05.530 ******** ", "changed: [localhost]", "", "TASK [common : Add DNS record] *************************************************", "Monday 14 October 2019  06:28:15 +0000 (0:00:02.709)       0:00:08.240 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Check for supported distribution] *****************************", "Monday 14 October 2019  06:28:15 +0000 (0:00:00.104)       0:00:08.345 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Install dependencies for CentOS] ******************************", "Monday 14 October 2019  06:28:15 +0000 (0:00:00.104)       0:00:08.449 ******** ", "changed: [localhost] => (item=[u'gcc', u'gcc-c++', u'git', u'libffi-devel', u'libsemanage-python', u'openssl-devel', u'policycoreutils-python', u'python-devel'])", "", "TASK [browbeat : Install dependencies for RHEL8] *******************************", "Monday 14 October 2019  06:28:36 +0000 (0:00:21.064)       0:00:29.514 ******** ", "skipping: [localhost] => (item=[]) ", "", "TASK [browbeat : Install pip] **************************************************", "Monday 14 October 2019  06:28:36 +0000 (0:00:00.210)       0:00:29.725 ******** ", "ok: [localhost]", "", "TASK [browbeat : Update virtualenv and setuptools] *****************************", "Monday 14 October 2019  06:28:39 +0000 (0:00:02.807)       0:00:32.533 ******** ", "changed: [localhost] => (item={u'version': u'15.2.0', u'name': u'virtualenv'})", "changed: [localhost] => (item={u'version': u'38.7.0', u'name': u'setuptools'})", "", "TASK [browbeat : Install virtualenv and setuptools- zuul user] *****************", "Monday 14 October 2019  06:28:51 +0000 (0:00:11.594)       0:00:44.127 ******** ", "skipping: [localhost] => (item=virtualenv) ", "skipping: [localhost] => (item=setuptools) ", "", "TASK [browbeat : Determine if browbeat directory exists already] ***************", "Monday 14 October 2019  06:28:51 +0000 (0:00:00.119)       0:00:44.247 ******** ", "ok: [localhost]", "", "TASK [browbeat : debug] ********************************************************", "Monday 14 October 2019  06:28:53 +0000 (0:00:02.517)       0:00:46.764 ******** ", "ok: [localhost] => {", "    "msg": "Browbeat directory exists already."", "}", "", "TASK [browbeat : Clone browbeat on undercloud] *********************************", "Monday 14 October 2019  06:28:53 +0000 (0:00:00.135)       0:00:46.900 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Create browbeat virtualenv] ***********************************", "Monday 14 October 2019  06:28:53 +0000 (0:00:00.105)       0:00:47.006 ******** ", "changed: [localhost]", "", "TASK [browbeat : Setup browbeat-venv CA certificate path] **********************", "Monday 14 October 2019  06:29:01 +0000 (0:00:07.940)       0:00:54.946 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Determine if generate_tripleo_hostfile has been run] **********", "Monday 14 October 2019  06:29:02 +0000 (0:00:00.109)       0:00:55.055 ******** ", "ok: [localhost]", "", "TASK [browbeat : debug] ********************************************************", "Monday 14 October 2019  06:29:04 +0000 (0:00:02.330)       0:00:57.386 ******** ", "ok: [localhost] => {", "    "msg": "Hosts file is already generated."", "}", "", "TASK [browbeat : Generate hosts and ssh-config on Browbeat Machine - Default(stack)] ***", "Monday 14 October 2019  06:29:04 +0000 (0:00:00.138)       0:00:57.525 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Generate hosts and ssh-config on Browbeat Machine - Zuul] *****", "Monday 14 October 2019  06:29:04 +0000 (0:00:00.109)       0:00:57.634 ******** ", "skipping: [localhost]", "", "TASK [browbeat : Move files to correct location] *******************************", "Monday 14 October 2019  06:29:04 +0000 (0:00:00.110)       0:00:57.745 ******** ", "skipping: [localhost] => (item=hosts) ", "skipping: [localhost] => (item=heat-admin-id_rsa) ", "", "TASK [browbeat : Install requirements.txt into browbeat-venv] ******************", "Monday 14 October 2019  06:29:04 +0000 (0:00:00.120)       0:00:57.865 ******** ", "changed: [localhost]", "", "TASK [stockpile : Clone stockpile] *********************************************", "Monday 14 October 2019  06:30:16 +0000 (0:01:11.840)       0:02:09.706 ******** ", "changed: [localhost]", "", "TASK [browbeat-results : Install httpd] ****************************************", "Monday 14 October 2019  06:30:20 +0000 (0:00:04.257)       0:02:13.963 ******** ", "ok: [localhost]", "", "TASK [browbeat-results : Remove welcome.conf if it exists] *********************", "Monday 14 October 2019  06:30:23 +0000 (0:00:02.773)       0:02:16.736 ******** ", "ok: [localhost]", "", "TASK [browbeat-results : Setup browbeat.conf in /etc/httpd/conf.d] *************", "Monday 14 October 2019  06:30:26 +0000 (0:00:02.578)       0:02:19.315 ******** ", "changed: [localhost]", "", "TASK [browbeat-results : Set seboolean(httpd_read_user_content)] ***************", "Monday 14 October 2019  06:30:30 +0000 (0:00:04.379)       0:02:23.694 ******** ", "changed: [localhost]", "", "TASK [browbeat-results : Allow httpd to serve content in "/home/stack"] ********", "Monday 14 October 2019  06:30:33 +0000 (0:00:03.033)       0:02:26.728 ******** ", "changed: [localhost]", "", "TASK [browbeat-results : Allow httpd to listen to port (9001)] *****************", "Monday 14 October 2019  06:30:35 +0000 (0:00:02.313)       0:02:29.041 ******** ", "changed: [localhost]", "", "TASK [browbeat-results : Allow httpd to listen to port (9001) via add] *********", "Monday 14 October 2019  06:30:42 +0000 (0:00:06.285)       0:02:35.326 ******** ", "skipping: [localhost]", "", "TASK [browbeat-results : Start httpd] ******************************************", "Monday 14 October 2019  06:30:42 +0000 (0:00:00.107)       0:02:35.434 ******** ", "ok: [localhost]", "", "TASK [firewall : Determine if firewalld is in use] *****************************", "Monday 14 October 2019  06:30:44 +0000 (0:00:02.504)       0:02:37.939 ******** ", "fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}", "...ignoring", "", "TASK [firewall : Determine if firewalld is active] *****************************", "Monday 14 October 2019  06:30:47 +0000 (0:00:02.310)       0:02:40.249 ******** ", "fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}", "...ignoring", "", "TASK [firewall : (shaker) Determine if TCP/5555 is already active] *************", "Monday 14 October 2019  06:30:49 +0000 (0:00:02.291)       0:02:42.541 ******** ", "fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}", "...ignoring", "", "TASK [firewall : (browbeat_results) Determine if TCP/9001 is already active] ***", "Monday 14 October 2019  06:30:51 +0000 (0:00:02.275)       0:02:44.817 ******** ", "fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": true}", "...ignoring", "", "TASK [firewall : (shaker) Add firewall rule for TCP/5555 (firewalld)] **********", "Monday 14 October 2019  06:30:54 +0000 (0:00:02.273)       0:02:47.090 ******** ", "skipping: [localhost]", "", "TASK [firewall : (browbeat_results) Add firewall rule for TCP/9001 (firewalld)] ***", "Monday 14 October 2019  06:30:54 +0000 (0:00:00.115)       0:02:47.206 ******** ", "skipping: [localhost]", "", "TASK [firewall : (shaker) check firewall rules for TCP/5555 (iptables-services)] ***", "Monday 14 October 2019  06:30:54 +0000 (0:00:00.112)       0:02:47.318 ******** ", "changed: [localhost]", "", "TASK [firewall : (browbeat_results) Check firewall rules for TCP/9001 (iptables-services)] ***", "Monday 14 October 2019  06:30:56 +0000 (0:00:02.298)       0:02:49.617 ******** ", "changed: [localhost]", "", "TASK [firewall : check if iptables rules exist] ********************************", "Monday 14 October 2019  06:30:58 +0000 (0:00:02.299)       0:02:51.917 ******** ", "ok: [localhost]", "", "TASK [firewall : (shaker) Add firewall rule for TCP/5555 (iptables-services)] ***", "Monday 14 October 2019  06:31:01 +0000 (0:00:02.289)       0:02:54.206 ******** ", "changed: [localhost]", "", "TASK [firewall : (browbeat_results) Add firewall rule for TCP/9001 (iptables-services)] ***", "Monday 14 October 2019  06:31:03 +0000 (0:00:02.524)       0:02:56.731 ******** ", "changed: [localhost]", "", "TASK [perfkitbenchmarker : Create perfkit virtualenv] **************************", "Monday 14 October 2019  06:31:06 +0000 (0:00:02.329)       0:02:59.060 ******** ", "changed: [localhost]", "", "TASK [perfkitbenchmarker : Setup perfkit-venv CA certificate path] *************", "Monday 14 October 2019  06:31:11 +0000 (0:00:05.683)       0:03:04.743 ******** ", "skipping: [localhost]", "", "TASK [perfkitbenchmarker : Determine if PerfKitBenchmarker is already cloned] ***", "Monday 14 October 2019  06:31:11 +0000 (0:00:00.106)       0:03:04.850 ******** ", "ok: [localhost]", "", "TASK [perfkitbenchmarker : debug] **********************************************", "Monday 14 October 2019  06:31:14 +0000 (0:00:02.265)       0:03:07.116 ******** ", "skipping: [localhost]", "", "TASK [perfkitbenchmarker : Clone PerfKitBenchmarker on undercloud] *************", "Monday 14 October 2019  06:31:14 +0000 (0:00:00.108)       0:03:07.224 ******** ", "changed: [localhost]", "", "TASK [perfkitbenchmarker : Install PerfKitBenchmarker requirements into perfkit-venv] ***", "Monday 14 October 2019  06:31:20 +0000 (0:00:05.944)       0:03:13.168 ******** ", "changed: [localhost]", "", "TASK [perfkitbenchmarker : Install PerfKitBenchmarker Openstack requirements into perfkit-venv] ***", "Monday 14 October 2019  06:31:41 +0000 (0:00:21.190)       0:03:34.359 ******** ", "changed: [localhost]", "", "TASK [perfkitbenchmarker : Fix requirements for (OSP11 Ocata) inside perfkit-venv] ***", "Monday 14 October 2019  06:32:00 +0000 (0:00:19.128)       0:03:53.487 ******** ", "changed: [localhost] => (item={u'version': u'0.9.17', u'name': u'openstacksdk'})", "changed: [localhost] => (item={u'version': u'3.12.0', u'name': u'python-openstackclient'})", "changed: [localhost] => (item={u'version': u'9.1.0', u'name': u'python-novaclient'})", "", "TASK [rally : Create rally virtualenv] *****************************************", "Monday 14 October 2019  06:32:15 +0000 (0:00:15.312)       0:04:08.799 ******** ", "changed: [localhost]", "", "TASK [rally : Rally Add browbeat to Python path] *******************************", "Monday 14 October 2019  06:32:21 +0000 (0:00:05.681)       0:04:14.481 ******** ", "changed: [localhost]", "", "TASK [rally : Setup rally-venv CA certificate path] ****************************", "Monday 14 October 2019  06:32:23 +0000 (0:00:02.315)       0:04:16.796 ******** ", "skipping: [localhost]", "", "TASK [rally : Install Rally with OpenStack plugins into rally-venv] ************", "Monday 14 October 2019  06:32:23 +0000 (0:00:00.104)       0:04:16.901 ******** ", "changed: [localhost]", "", "TASK [rally : Install elasticsearch into rally-venv] ***************************", "Monday 14 October 2019  06:33:41 +0000 (0:01:17.803)       0:05:34.705 ******** ", "changed: [localhost]", "", "TASK [rally : Create rally configuration directory] ****************************", "Monday 14 October 2019  06:33:45 +0000 (0:00:04.238)       0:05:38.943 ******** ", "changed: [localhost]", "", "TASK [rally : Setup rally.conf] ************************************************", "Monday 14 October 2019  06:33:48 +0000 (0:00:02.384)       0:05:41.327 ******** ", "changed: [localhost]", "", "TASK [rally : Setup rally database] ********************************************", "Monday 14 October 2019  06:33:52 +0000 (0:00:04.072)       0:05:45.400 ******** ", "changed: [localhost]", "", "TASK [rally : Setup rally deployment] ******************************************", "Monday 14 October 2019  06:33:55 +0000 (0:00:03.433)       0:05:48.834 ******** ", "changed: [localhost]", "", "TASK [rally : Check Rally deployment] ******************************************", "Monday 14 October 2019  06:34:01 +0000 (0:00:05.235)       0:05:54.069 ******** ", "fatal: [localhost]: FAILED! => {"changed": true, "cmd": ". /home/stack/browbeat/.rally-venv/bin/activate; . /home/stack/overcloudrc; rally deployment check", "delta": "0:02:10.216886", "end": "2019-10-14 06:36:13.067228", "msg": "non-zero return code", "rc": 1, "start": "2019-10-14 06:34:02.850342", "stderr": "2019-10-14 06:36:12.928 150266 WARNING keystoneauth.identity.generic.base [-] Failed to discover available identity versions when contacting http://<IP_ADDRESS>:5000//. Attempting to parse version from URL.: ConnectFailure: Unable to establish connection to http://<IP_ADDRESS>:5000//: HTTPConnectionPool(host='<IP_ADDRESS>', port=5000): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fbcccf92610>: Failed to establish a new connection: [Errno 110] Connection timed out',))\u001b[00m", "stderr_lines": ["2019-10-14 06:36:12.928 150266 WARNING keystoneauth.identity.generic.base [-] Failed to discover available identity versions when contacting http://<IP_ADDRESS>:5000//. Attempting to parse version from URL.: ConnectFailure: Unable to establish connection to http://<IP_ADDRESS>:5000//: HTTPConnectionPool(host='<IP_ADDRESS>', port=5000): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fbcccf92610>: Failed to establish a new connection: [Errno 110] Connection timed out',))\u001b[00m"], "stdout": "--------------------------------------------------------------------------------\nPlatform openstack:\n--------------------------------------------------------------------------------\n\nError while checking admin credentials:\n\tAuthenticationFailed: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Unable to establish connection to http://<IP_ADDRESS>:5000//", "stdout_lines": ["--------------------------------------------------------------------------------", "Platform openstack:", "--------------------------------------------------------------------------------", "", "Error while checking admin credentials:", "\tAuthenticationFailed: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Unable to establish connection to http://<IP_ADDRESS>:5000//"]}", "", "RUNNING HANDLER [browbeat-results : restart httpd] *****************************", "Monday 14 October 2019  06:36:13 +0000 (0:02:12.426)       0:08:06.496 ******** ", "", "RUNNING HANDLER [firewall : restart iptables] **********************************", "Monday 14 October 2019  06:36:13 +0000 (0:00:00.000)       0:08:06.497 ******** ", "\tto retry, use: --limit @/home/stack/browbeat/ansible/install/browbeat.retry", "", "PLAY RECAP *********************************************************************", "localhost                  : ok=42   changed=31   unreachable=0    failed=1   ", "", "Monday 14 October 2019  06:36:13 +0000 (0:00:00.002)       0:08:06.500 ******** ", "=============================================================================== ", "rally : Check Rally deployment ---------------------------------------- 132.43s", "rally : Install Rally with OpenStack plugins into rally-venv ----------- 77.80s", "browbeat : Install requirements.txt into browbeat-venv ----------------- 71.84s", "perfkitbenchmarker : Install PerfKitBenchmarker requirements into perfkit-venv -- 21.19s", "browbeat : Install dependencies for CentOS ----------------------------- 21.06s", "perfkitbenchmarker : Install PerfKitBenchmarker Openstack requirements into perfkit-venv -- 19.13s", "perfkitbenchmarker : Fix requirements for (OSP11 Ocata) inside perfkit-venv -- 15.31s", "browbeat : Update virtualenv and setuptools ---------------------------- 11.59s", "browbeat : Create browbeat virtualenv ----------------------------------- 7.94s", "browbeat-results : Allow httpd to listen to port (9001) ----------------- 6.29s", "perfkitbenchmarker : Clone PerfKitBenchmarker on undercloud ------------- 5.94s", "perfkitbenchmarker : Create perfkit virtualenv -------------------------- 5.68s", "rally : Create rally virtualenv ----------------------------------------- 5.68s", "Gathering Facts --------------------------------------------------------- 5.42s", "rally : Setup rally deployment ------------------------------------------ 5.24s", "browbeat-results : Setup browbeat.conf in /etc/httpd/conf.d ------------- 4.38s", "stockpile : Clone stockpile --------------------------------------------- 4.26s", "rally : Install elasticsearch into rally-venv --------------------------- 4.24s", "rally : Setup rally.conf ------------------------------------------------ 4.07s", "rally : Setup rally database -------------------------------------------- 3.43s"]}
PLAY RECAP *********************************************************************************************************************************************************************************
e23-h15-740xd.alias.bos.scalelab.redhat.com : ok=37   changed=9    unreachable=0    failed=1    skipped=2    rescued=0    ignored=2
localhost                  : ok=89   changed=46   unreachable=0    failed=0    skipped=19   rescued=0    ignored=0

https://gist.github.com/zulcss/5f576af5714bc1ca3407c01a8e9664dc

I don't see any routes for <IP_ADDRESS>/16 with "ip r" in undercloud. And "ip a" not showing "p7p2" up.
5: p7p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 3c:fd:fe:c1:6c:a1 brd ff:ff:ff:ff:ff:ff
13: p7p2.300@p7p2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 3c:fd:fe:c1:6c:a1 brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global p7p2.300
valid_lft forever preferred_lft forever
So I think we need to do ip link set dev p7p2 up along with
ip link set dev p7p2.300 up


feat(snippet): add friendly-snippets to native extra

I don't know if this is intentional but the extra for native snippet by default only expand the one return by LSP.
For some language like Python, relies exclusively on friendly-snippets so I propose to add them here, especially if LazyVim intend to use native snippets as default.

Great, thanks!


Update Wiki

This repo is growing too fast and getting very complex. Please update the wiki with additional information and tutorials.

Wiki seems to have been updated with no info. Issue has been resolved.


[BUG] Polling of metrics in custom plugins stops if an error is raised inside the mfa function for the metric

Describe the bug
Polling of metrics in custom plugins stops if an error is raised inside the mfa function for the metric.
To Reproduce
Steps to reproduce the behavior:

Clone this example repository: https://github.com/fedme/prom_ex_issue
The sample application defines a custom PromEx plugin here: https://github.com/fedme/prom_ex_issue/blob/main/lib/prom_ex_issue/custom_prom_ex_plugin.ex

Start the sample application with mix phx.server and look at the logs in the terminal

Observe the logs showing that the mfa function for the metric is called at every polling interval, you should see the following output:

  ######################################################################
MFA execute_ping_metrics called for the 1 time.
######################################################################

######################################################################
MFA execute_ping_metrics called for the 2 time.
######################################################################

[...]

The plugin is written so that the mfa function raises an error the 6th time it is polled, you should see something like the following output in the console:

[...]

######################################################################
MFA execute_ping_metrics called for the 4 time.
######################################################################

######################################################################
MFA execute_ping_metrics called for the 5 time.
######################################################################

[error] Error when calling MFA defined by measurement: PromExIssue.CustomPromExPlugin :execute_ping_metrics [#PID<0.676.0>]
Class=:error
Reason=%RuntimeError{
  message: "Something is not working correctly, I can't return the metrics right now!"
}
Stacktrace=[
  {PromExIssue.CustomPromExPlugin, :execute_ping_metrics, 1,
   [
     file: ~c"lib/prom_ex_issue/custom_prom_ex_plugin.ex",
     line: 48,
     error_info: %{module: Exception}
   ]},
  {:telemetry_poller, :make_measurement, 1,
   [
     file: ~c"/Users/fedme/code/prom_ex_issue/deps/telemetry_poller/src/telemetry_poller.erl",
     line: 336
   ]},
  {:telemetry_poller, :"-make_measurements_and_filter_misbehaving/1-lc$^0/1-0-",
   1,
   [
     file: ~c"/Users/fedme/code/prom_ex_issue/deps/telemetry_poller/src/telemetry_poller.erl",
     line: 332
   ]},
  {:telemetry_poller, :handle_info, 2,
   [
     file: ~c"/Users/fedme/code/prom_ex_issue/deps/telemetry_poller/src/telemetry_poller.erl",
     line: 354
   ]},
  {:gen_server, :try_handle_info, 3, [file: ~c"gen_server.erl", line: 1095]},
  {:gen_server, :handle_msg, 6, [file: ~c"gen_server.erl", line: 1183]},
  {:proc_lib, :init_p_do_apply, 3, [file: ~c"proc_lib.erl", line: 241]}
]

Notice that the metric is not polled anymore after the exception, no more logs in the console alerting us that the function is being polled.

Expected behavior
Even if the metric function raises an error at a certain poll invocation, the polling should not stop and rather keep going so that future values of the metric can be collected after the error (hopefully) goes away.
Environment
Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

Elixir 1.16.0 (compiled with Erlang/OTP 26)

Additional context
First raised on Slack.

Thanks for the detailed issue! I should be able to knock this out over the weekend. I'm currently working on another open source library....so I should be able to tackle this as well given I am in open source mode 😄

Thanks for the repro project. I was able to incorporate my additions to the Polling metric type in your repo and avoided having the MFA detached (specifically the detach_on_error: false option):
defmodule PromExIssue.CustomPromExPlugin do
   ...

    @impl true
    def polling_metrics(opts) do
      poll_rate = Keyword.get(opts, :poll_rate, @default_poll_rate)
      debug_agent = opts[:debug_agent]

    Polling.build(
      :custom_prom_ex_plugin_ping_metrics,
      poll_rate,
      {__MODULE__, :execute_ping_metrics, [debug_agent]},
      [
        last_value(
          [:custom, :prom_ex, :plugin, :metrics],
          event_name: @ping_event_name,
          measurement: :count,
          description: "Ping for debugging",
          tags: [:state]
        )
      ],
      detach_on_error: false
    )
  end

  ...
end

Should be cutting a release soon with these changes!

Closing this ticket for now as a release will be cut soon.


Is this maintained?

The toast messages look absolutely amazing! However, judging from the issues, I have a feeling it's no longer maintained. Especially this: https://github.com/kbrgl/svelte-french-toast/issues/61 Is it maintained?

FYI, I found a maintained version: https://github.com/jill64/svelte-toast

Hey @galaczi, this package is still maintained—most of the issues that roll in tend to be build issues or otherwise lower priority, but I’ll be fixing any higher priority bugs if any are reported.

Hey @galaczi, this package is still maintained—most of the issues that roll in tend to be build issues or otherwise lower priority, but I’ll be fixing any higher priority bugs if any are reported.

Hey @kbrgl JSYK -heads up- you have been making commits but not releasing/versioning them. So, when one installs french-toast they are unfortunately left to use whatever the last update was… which was in July of last year.
In particular, commit 509d6752fc is missing and is arguably essential. Because your package must be built to generate dist (which is by no means unusual), it is not possible for one to work around this dilemma by installing french-toast by version or tag (e.g., npm install svelte-french-toast@master. As a last resort one must resign to forking this package on npm in order to pull in code that you haven't versioned and created a release for.


Init project

@ashb @schnie PTAL

@andriisoldatenko @ashb does it make sense to replicate the directory structure of astronomer-fab-securitymanager for standardization? Would be cool of they looked pretty similar and were updated the same way.

@schnie i'm using +- same folder structure as astronomer-fab-securitymanager except src folder. i don’t see any reasons to have src.
@ashb could you please add note regarding src/ folder?

I don't know why I put everything in the 'src' folder in the security manager, but I now can't remember why I did (and it's not a very common pattern). Something to do with the tests/ folder getting picked up as a namespace package and installed in the wheel? But there may be a better way of fixing that


Not working

Nothing happen. It doesn't give even an error.

Hello @ChanukaSandeepa, I am not sure why you facing this issue.
Kindly update the current version, follow the usage guideline, and let us know if the issue persists.

Hello @ChanukaSandeepa, I am not sure why you facing this issue.
Kindly update the current version, follow the usage guideline, and let us know if the issue persists.

Hello @ChanukaSandeepa, I am not sure why you facing this issue.
Kindly update the current version, follow the usage guideline, and let us know if the issue persists.

Hello @ChanukaSandeepa, I am not sure why you facing this issue.
Kindly update the current version, follow the usage guideline, and let us know if the issue persists.


Add a putAll() function to Collection

I've added a function to Collection: putAll($collection)
The problem is that Collection::merge / Collection::union overrides every item in the original collection, which has the same index key ( for laravel Models, that means the primary key ).
Lets assume we have two collections of Model_A and Model_B
The database table could be something like:
Model A
| id | name    |
| 1  | 'foo'   |
| 2  | 'bar'   |

Model B
| id | name      |
| 1  | 'brown'   |
| 2  | 'fox'     |

Using Collection::merge
ModelA::take(2)->get()->merge(ModelB::take(2)->get())->all();
// [ 0 => 'foo', 1 => 'bar' ]

Using Collection::putAll
ModelA::take(2)->get()->putAll(ModelB::take(2)->get())->all();
// [ 0 => 'foo', 1 => 'bar', 2 => 'brown', 3 => 'fox']

If this cannot be merged, how about adding a $preserve_keys to the union method?
public function union($items, $preserve_keys = true)
{
    .....
}

@segadora I agree with you! 👍

You just need to call
ModelA::take(2)->get()->values()->merge(ModelB::take(2)->get()->values());

Not sure if it's worth adding a specific function when you can just call values() and achieve the same behavior.

@fernandobandeira I actually dont agree on that. I know its possible "to get around it", but its not a very convenient way to do it.
In my opinion the Collection class should provide the functionality of : adding, removing, sorting, merging etc. ; including merging of generic types.
You could always argue that everything is possible, if you just do it yourself.
I would go even further and say it could be ideal to implement in a more "haystack/neddle(s)" way.

the putAll(..) function would then take one or more Collections, as parameter and look something like:

public function putAll(Collection ...$collections)
{
    //
}

The design of the Collection class ; as i understand it - is not accepting that kind of behavior
so that why i decided to only accept one collection as parameter.

Now that would add something different and useful to the core, you see I wasn't complaining that it wasn't something needed, just that it wasn't worth adding something new just for that little thing, but being able to pass multiple collections too would then make the feature more complete... 😄

@fernandobandeira I didn't take it as a complain - no worries. I think its an interesting discussion 👍
I agree that the function would be more complete with the option of more collections, but i'm really not sure about that would follow the design of Collection.

For now will leave this up to be implemeneted as a macro.

Can be solved with concat now https://laravel.com/docs/5.5/collections#method-concat


Add empty controller for vm-import functionality

This is a first step to get vm-import functionality from kubevirt to forklift controller. The aim is to prepare mostly empty controller watching its CR. Reconcile loop should just output to log.

Why is this a separate controller?
What CR will this be reconciling?
Is there a design (at least high level) for this?

Why is this a separate controller?
What CR will this be reconciling?
Is there a design (at least high level) for this?

Thanks for feedback Jeff! The VMIO might need to be a separate project/repo (under Konveyor org, but close to current VMIO codebase, similar CR just updated to use migration toolkit shared concepts like Itinerary).
Sorry, I'm not sure at this moment, things are changing. Let's see (prepare high level design) after Monday call.

Thanks for feedback Jeff! The VMIO might need to be a separate project/repo (under Konveyor org, but close to current VMIO codebase, similar CR just updated to use migration toolkit shared concepts like Itinerary).
Sorry, I'm not sure at this moment, things are changing. Let's see (prepare high level design) after Monday call.

To answer the one open question, I don't think there's anything we'll need to keep from CreateImport. The secret it creates is just a requirement for VMIO which we will not need to worry about, since we won't need to retrieve anything from the source, and the inventory already has the credentials. I would expect the new steps to replace CreateImport entirely.
Validate:
I don't believe this will need to be a step in the itinerary. The Plan controller validates the resource mappings and VM references as part of the Plan reconcile, and I think validating that the source VM is migratable would fit there as well.
PrepareVM:
I think this will be able to be simplified greatly from VMIO. At this step we'd be pulling the VM representation out of the Forklift inventory and using that to create a Kubevirt VirtualMachine resource with no disks. We'll still have to have some provider specific code to map source VM properties to the destination, but hopefully a lot less since we're not going to need to go retrieve the VM properties like VMIO does. One open question here is whether or not we need to worry about Kubevirt templates. Hopefully we can just set the proper parameters on the Kubevirt VirtualMachine ourselves and skip the template entirely.
As an aside, VMIO uses resource names to keep track of resources that have been created for the import. Relying on names to identify resources requires the names to be deterministic or otherwise recorded somewhere on the parent resource, and tends to be flakey. Instead, we should use labels to identify resources we're creating (VM, datavolumes, etc).
WarmImport/ImportDisks:
These methods are huge in VMIO mostly due to the way that the reconcile runs, and we'll be able to simplfy them greatly.
Warm Import and Import Disks are very similar in that they're both creating a DataVolume, and waiting for that DataVolume to succeed. The difference is that during a warm import, the DataVolumes enter a paused state where they wait for their FinalCheckpoint value to be set to true, or for the next checkpoint to be added. Once this is done they go back to a running state. This can happen any number of times before the DataVolume eventually succeeds. A cold migration is effectively the same thing as a warm migration with no checkpoints. That being so, I think these can be streamlined together into one path. Probably one step would create the DataVolumes, and the next step would respond to the state changes by either waiting, creating the next checkpoint, or continuing to the next step once all DVs succeeded.
ConvertGuest/ConvertGuestCompleted:
This should be fairly simple to port in from VMIO. Mainly this is creating a configmap and a pod, and waiting for that pod to succeed. I think ConvertGuest is more descriptive of what it's doing than ConvertVM. (the virt-v2v pod is manipulating the guest OS filesystem to install drivers and such that are required to run in Kubevirt)


RFC: add strong_constrains on sysroot_{{ target_platform }}?

In https://github.com/conda-forge/libcxx-feedstock/pull/131, I noticed that setting c_stdlib_version to 2.17 (and being in a cos7 image) still leads to
$PREFIX/bin/x86_64-conda-linux-gnu-ld: $PREFIX/lib/libc++abi.so: undefined reference to<EMAIL_ADDRESS>$PREFIX/bin/x86_64-conda-linux-gnu-ld: $PREFIX/lib/libc++abi.so: undefined reference to<EMAIL_ADDRESS>
if sysroot_linux-64 2.17 is not available at test time.
It seems reasonable to me that when a package indicates it requires c_stdlib_version >=x, that we shouldn't allow pulling in older sysroots when building against that package?
conda-build has a similar feature like run-exports also for adding run_constrained: entries, which would do the job here IMO.
Thoughts @beckermr @isuruf?

Although I sympathize. I don't like this condition getting added to basically all compiled packages as a dependency.

This also makes sense only for packages that end up in build as there will be no sysroot_* package in host.

Although I sympathize. I don't like this condition getting added to basically all compiled packages as a dependency.

It would just be a constraint, not a dependency. I thought that kind of metadata was the point of the stdlib-infrastructure, i.e. it's obviously going to affect a lot of packages. Should we not strive for correct metadata? I guess the only mitigating factor is that we'll be moving to 2.17 globally soon, so it'll become the "ambient" expectation again.

This also makes sense only for packages that end up in build as there will be no sysroot_* package in host.

AFAICT we cannot know in advance whether a package is going to be used in a build environment, so then the alternative is people just run into the missing symbol errors, and document how to fix them?

Other than the test section, when will this ever help?

Anything where the dynamic linker looks for symbols from the newer glibc, so in principle anything built against 2.17 that gets executed (either in build or test env)?
Note that I said we can just document how to deal with the missing symbols, so this isn't black-and-white to me - I asked because I don't see the issue with adding the run-constraint, even if it gets added very broadly.

Anything where the dynamic linker looks for symbols from the newer glibc, so in principle anything built against 2.17 that gets executed (either in build or test env)?

Can you give an example recipe? I still don't understand.

Can you give an example recipe? I still don't understand.

In libcxx we failed during the testing phase while trying to load libc++abi.so, causing the linker to look for the required glibc symbols and not finding them. This goes away if we add the constraint on the sysroot, but should equally go away if we used the cos7 image, as that should provide a new enough glibc.
My point (to the degree that I'm not missing something) was that loading a library is not restricted to the test phase. If there's an executable called in the build environment that needs to load something (e.g. libc++abi.so in this case) that ends up requiring newer glibc, we're in the same situation - we'd fail to find the symbols, though this time in the build environment.
AFAICT we'll be in a similar situation with conda_2_28 / alma 8. Our images will be cos7-based, but people will eventually start depending on newer glibc. To get this to work without the constraint, dependent feedstocks then either need to add the sysroot manually or change the image version. I like the constraint because it minimizes changes in dependent feedstocks:

no changes necessary to meta.yaml
not necessary to change image version in conda-forge.yml

(there's a corner case where bumping the image version is still necessary, but I still think we'd cover a large percentage with the constraint.)

Whether this gets added by sysroot's run_exports or not, should packages that appear to have this requirement add the run_constrained themselves (e.g. openmpi)? Or is something else wrong?
I guess the constraint won't have the desired effect when the package is not in build, which means only cross-compiled openmpi dependents would be affected. Is that right?
How is a package meant to communicate that "to link against me, you must build with c_stdlib >= X"? Which appears to be the case in practice for openmpi. Or are all recipes that encounter missing glibc symbols linking openmpi doing something wrong?

I'm not sure this is the best Issue to discuss this, but is there a way for the "weighed down" c_stdlib_version to affect conda-forge infrastructure / conda-build, but not runtime installs? It is a bit surprising that 2.12 is installed when users to conda instal gcc. If that didn't happen, the situation for runtime compilation would be simpler, I think. Maybe when the c_stdlib_version migration finishes, it will make sense to remove whatever's causing the prefer-2.12-by-default in the solver rather than conda_build_config?

Maybe when the c_stdlib_version migration finishes, it will make sense to remove whatever's causing the prefer-2.12-by-default in the solver rather than conda_build_config?

Getting rid of the sysroot hack is indeed one of the goals of the whole stdlib effort. I'm not directly involved but I think it'll come after the switch to 2.17

Nice. I think that will solve the runtime compilation issues, so no other action on that front is probably required.

Yeah to be clear, once we remove the hacks @h-vetinari is referring to, conda will install the latest sysroot when a compiler is installed. That will be w/e the latest is at the time, which right now is 2.28 IIRC. It won't mean we ship the compiler without the sysroot.

Yeah, that's exactly what I would hope to happen. Looking forward to it!

Right. I am confused about multiple issues and how they relate, so it has been tough for me to follow. AFAIK we have ~3 things going on

What do we do about dependencies that build against a newer sysroot than the default in recipes? I think we've seen some issues about that but I am not 100% sure.

How much of the weighing down of sysroots do we still need to do now that we've moved to the explicit stdlib config?

What should the default be outside of conda-forge builds for external users? (The comment @minrk just made.)

These are all somewhat related at a technical level since implementations of some effect the others. However there are I think some policy / convention issues in the mix too, especially for the last item.
Thoughts?

What do we do about dependencies that build against a newer sysroot than the default in recipes? I think we've seen some issues about that but I am not 100% sure.

Yeah. I was working on that in https://github.com/conda-forge/conda-forge.github.io/pull/2206 . So far, every problem I've encountered there has been caused by:

not respecting $LDFLAGS, and/or
outdated sysroot installed at runtime

and either installing later sysroot or fixing ignored or missing $LDFLAGS (e.g. depending on gcc instead of c-compiler) fixed it.
I think 2 and 3 are related, because going forward (IIUC), weighing down should only affect packages that don't use c_stdlib pinning (i.e. not conda-forge packages). I'd argue that latest sysroot is the right default choice for user runtime envs, and other build environments that want to pin down for portability should follow conda-forge's example and pin down c_stdlib explicitly. To me, that suggests that weighing down should go away if/when c_stdlib is a reasonable expectation for conda-forge packages, and latest available sysroot should become the default install.

@minrk: I see comments about 'breaking non-conda-build' in conda-forge/conda-forge-pinning-feedstock#6070 , but that's exactly the situation I want to fix because weighing down outside conda-build is what causes all the breakages in my experience.

This piece of infrastructure largely precedes my involvement, but the understanding I had gotten was that we'd obviously like to get rid of the sysroot hack. When this was brought up in the PR you mention, Isuru pointed out some issues, though I believe they can be resolved (there's hasn't been an answer to my proposal there, so I'll summarize it below).

@beckermr: AFAIK we have ~3 things going on

There's actually 4-5 things AFAIU:

What do we do about dependencies that build against a newer sysroot than the default in recipes? I think we've seen some issues about that but I am not 100% sure.

That part is IMO the easiest - it's what {{ stdlib("c") }} tackled first and foremost. If a package builds against a newer sysroot, the __glibc part of the requirement spreads virally (in principle). As long as the build requires that bump, this is fine.
(1b) The one problem with this is that the sysroot requirement does not spread (which is what this issue is about), so packages that themselves need to get compiled against need to manually set that constraint (c.f. https://github.com/conda-forge/openmpi-feedstock/pull/160). This problem is mostly orthogonal to the sysroot hacks though (i.e. we'd still have it even if we get rid of them).

How much of the weighing down of sysroots do we still need to do now that we've moved to the explicit stdlib config?

If it's just for using the compilers, we can add the sysroot with our global baseline to the compilers feedstock. For people who use our production compilers (e.g. gcc_linux-64) directly, my response would be that it's their responsibility to similarly install an appropriate sysroot. The support situation for our production compilers is a grey area, but I think this is a fair ask for using something we don't explicitly support.

What should the default be outside of conda-forge builds for external users?

I tend to agree with @minrk here that the newest sysroot suitable for a users system would actually be a good default. Anyone else can explicitly install a specific version
The fourth point that Isuru brought up is that there are packages (like r-base) that depend on our compilers, and there we're somewhat boxed in. We cannot pin the sysroot to a single version in r-base (e.g. 2.17), because there would always be cases where you need the other (e.g. 2.28; or vice versa). However, I think this problem would be solvable if we provide two variants of r-base; one for each each of 2.17 & 2.28; that way there's always an appropriate build available, without requiring the sysroot hacks to select 2.17.
The feasibility of this approach depends a bit how many packages there are that would need such double variants (though note that it's not necessary to build twice; e.g. just one _r-base and then two r-base wrapper that carry the constraints). Overall this sounds feasible to me, and IMO preferable to keeping the hacks indefinitely.

@minrk: Is there a separate issue to track the removal of track_features on sysroot, or should I open one?

At this point I believe this would be a good thing to do...

Thanks. I don't really understand what's special about the r-base issue. I know R installations may compile things, but is this not the same "runtime compilation" situation we've already covered for mpicc, etc.? i.e. it would still be better for r-base to pull in latest sysroot by default for environments, and not the oldest sysroot. Or is that not what's happening? It is not true, as I understand it, that r-base needs to pin down sysroot except for building binaries to be redistributed. And I think at this point it is not the best experience to be preparing user environments for that task by default.

At this point I believe this would be a good thing to do...

Okay, I'll do that and try to summarize/link where this has been spread out so far

https://github.com/conda-forge/libcufile-feedstock/pull/24


bit.ly link 404

'Something's wrong here' when I click on your link.

Hi @tomByrer, sorry for that. I removed some more characters to make it even shorter. It's bit.ly/dmx-2022. Thanks for pointing this out.
There are still a couple more rough edges. Please don't take the slides too serious before next Wednesday. :-)


SpawnDefs and Lua Spawners

Summary
I had a great discussion with Nem regarding Spawners in response to some awesome stuff by @YellowAdder happening over in https://github.com/segs-community/cox-scripts/pull/17 and I wanted to throw it up here to provide some guidance for how we can structure spawners on the server side.
The end goal is to load what we can from the bins (which is hopefully complete) and then supplement with script AND/OR provide hooks for Lua to create spawners on it's own, leveraging the server code to make the scripting as simple as possible for Server Admins.
I'd really appreciate @Segs/scripters and @Segs/developers input here, as this is happening quickly and we'll want to try to implement best practices now, before 1000s of scripts have to be rewritten =(
Also, if anyone wants to pick this up, by all means jump in!

Ok, this is what [Nem] came up with ( will likely change after various reality checks )
SpawnDef
QString m_node_name - A name of the scenegraph node that contains this SpawnDef
std::vector<SpawnPoint> m_all_spawn_points lists all SpawnPoints that belong to this SpawnDef
QHash<QString,std::vector<SpawnPoint *> > m_spawn_point_map which binds SpawnDef's scenegraph child node names to SpawnPoints
SpawnConfiguration m_spawn_point_configurator that defines the way each SpawnPoint generates NPCs
QHash<SpawnPoint *,NpcGenerator> m_configured_generators this mapping is generated by m_spawn_point_configurator, given some parameters ( group strength/difficulty level/phase of the moon/etc)
SpawnPoint
QString m_name - A name of the bound scenegraph node, not that SpawnPoint names will repeat themselves.
glm::vec3 m_relative_position - A spawn point location relative to it's SpawnDef.
SpawnConfiguration
bool m_use_callback - when true, the SpawnConfiguration will call m_configuration_callback to produce NpcGenerators
QHash<QString,std::vector<NpcGenerator>> m_map_point_to_difficulty_level_generator_list for each spawn point name, carries a list of NpcGenerators of various difficulty levels
std::function<NpcGenerator (const QString &,void *)> m_configuration_callback allows scripts to define a SpawnConfiguration's that call LUA scripts to create special NpcGenerator instances
int getDifficultyLevel(const QString &name,void *spawn_parameter_object) called to convert bunch of arguments into difficulty ( basically D&D's CR :smiley: )
class NpcGenerator
{
    virtual void createNPC() = 0;
};

ListBasedNPCGenerator : public NpcGenerator
{
    std::vector<NPCDef> m_possible_npcs;
    void createNPC() { createEntity(m_possible_npcs[rand()%m_possible_npcs.size()-1]); }
};

I've had a brief chat with Nemerle to better understand the intent with the NPC generators, but it's worth rehashing a few things I discussed with him here at more length.
City of Heroes used a model that, at its heart, relied on hand-crafted templates for encounters, and they used simple but clever approaches to provide encounter variety and challenge in the game world. Their model is quite ingenious and we'd be smart to leverage what remains of the framework.
Encounters and NPCs
What we really want to do is spawn Encounters and not merely NPCs. (It's little surprise that they're literally called EncounterSpawners in the existing framework.) As such, we probably want both an Encounter generator and an NPC generator. That's server side.
Script side, for anyone who has looked at the prototype I made, you may have realized that 80% of the code would rarely or never be touched by most content creators. Much of that 80% is either tucked away in the server already, or should be. The remaining 20% is almost entirely within the Spawndef files. These provide information about the encounter's template (such as the layout for a purse snatch or a shady deal) and the encounter table that defines the types of critters we want to actually see spawn in the encounter.
What do I think should happen?
When a map loads, it should create an Encounter Generator for each encounter on the map. (When I say "encounter" I'm referring to each pre-defined group of spawn markers.) Each generator would obtain information from the Spawndef file about its current encounter table and template/variation.
The encounter generator would also have logic to test when it should generate its encounter. Examples include:

Are players too close?
Is another active encounter too close?
Can I generator my encounter at this time of the game day?

We also know that the server tracks (or did track) broader information would affect whether an Encounter Generator would be allowed to make its encounter. The Encounter Generator would therefore ask for permission, and the server might respond with a "no" because there are already too many other encounters or critters in the zone, too few players, or whatever other criteria it is tracking and managing encounters in a zone more broadly.
But if everything is okay locally and the server gives permission as well, the Encounter Generator would refer to its current Spawndef data, tap on the NPC generators and ZING -- out comes an encounter. "Give up the purse, lady!"
Going Forward
Notice that we haven't talked about how encounters or critters scale. Some of that is built into the Spawndef file by way of the "CanSpawnX" templates, which the original system, I believe, governed how many squads of baddies (and their composition) spawn overall. That's a whole other layer, most of the logic for which should reside server side with a configuration script or file to allow for tweaking by content creators. Let's save a discussion for scaling until later, mostly because we don't actually need to address it yet to see a functional spawn system at work.
Regardless, we're talking about a complex and layered system, and we're not going to get this right the first or even fifth time around. I suggest we start on a small scale, still mostly in scripting, and then test and experiment until things start behaving the way we like. Then we can move appropriate portions of the logic back into the server and iterate over the process as needed. I'm not sure if that's how Broxen, Nemerle and whomever else want the process to work, however.
Once we have a fix about which direction we're working from, I feel confident that we can make some quick and impressive progress on this.
One final note: We should codify the language we use about the spawn system components because it can be complex and we're going to cross wires if we don't.

Really useful input YellowAdder. Thank you!

Based on conversations around here, I revised the system I created earlier to now use encounter managers. Rather than write about the result, I thought it easier to show and explain with an in-game example. Have a look at this video if you're interested enough. The EMs would of course go into the server later in whatever form.
It looks like Zophar has made some progress on the server/data side of things as well, so we may be able to have a live data + managed encounter template system like CoH's in an actually functioning Outbreak soon? How exciting is that?

Fantastic video @YellowAdder . I like that approach. Makes perfect sense to have the "spawners" check with a manager for the entire zone as well as nearby spawners. I really need to cleanup my server side tests and see what parts of this we can implement and test.

I wanted to follow up with a couple of potential models for what we want to do, with a brief explanation about both.
These two models, I think, represent the general extremes we'd want to consider. We don't want the server to actually dictate the spawns because it quickly treads into copyright territory, and more important, we want scriptors to be able to manage encounter output, so Model A probably represents the base approach we should consider. Alternatively, Model B represents the most freeform but also the most time consuming and complex to create and run for both SEGS and content creators alike. For several reasons, I'm in "Camp A" so far as where we should aim.
Model A:

In this model, the server gets data from the scenegraph and parses the individual encounter spawners. This data has the definite position and orientation data for spawn markers, and holds other information relevant to spawning the encounter such as spawn probability and encounter group IDs. For each encounter discovered, the server generates a new encounter manager to do the work of monitoring and figuring out when the encounter should actually spawn/despawn and so on.
When it is time to spawn its personal encounter, an encounter manager refers to a Lua-based Spawn Definition (or Spawndef) made by a content creator. The Spawndef file describes the encounter in non-positional terms by providing what it suggests should spawn at each marker location, such as a victim at V_40 and a thug at S_31. It will also include information about what animations and dialog should be used for all stages of the encounter's events, such as the victim's cries for help and their later thanks for being saved.
In all, the Spawndef is mostly (or entirely) a referential file and content creators will do little to no scripting while controlling the main elements of an encounter's output.
The Encounter Manager then takes this data and carries out the actual spawning in the game world. Note that this approach assumes a scaling system will inject itself into the process, probably just after the Encounter Manager has referenced the data in the Spawndef file.
Model B:

Model B takes a different approach that is extremely flexible for scriptors but also increases the complexity unless a good script-based framework is provided. The framework would have to be extensive enough to enable most scripters to avoid having to handle the more precise encounter data and the various communications with the Encounter Manager during the spawning process.
When an Encounter Manager realizes it is time to spawn an encounter, instead of referring to a Spawndef file it instead hands off its encounter's data to an "Encounters" script. From there, scriptors can use a highly customized approach to generating the encounter, one that may not even utilize a Spawndef file if they prefer. It's presumed that scripters could handle the actual spawning of critters, but in reality, they should still probably use the Encounter Manager to effect the spawns. At minimum, they would have to interact with the Encounter Manager in the process as it needs to know about the spawned critters, and likely other elements.
Hypothetically, determined scriptors could use this approach to even bypass the existing spawners' position and data, but they're going to need a good understanding of the system and a willingness to do most of the lifting.
Note that it's possible that we could drop the pretense of the Encounter Manager as well, and simply have the server expose the data for encounters it discovers in the scenegraph. Scriptors would have to come up with their own system, or use whatever we provide as a framework, but they'd have near total control over the spawning and scaling system. I'm betting that very few admins will want to face that much work, at least in the absence of something to start with provided by the SEGS team.
Regardless, even under the Model B provided for above, this approach probably demands that either a scaling system be written in Lua, or that a server-side scaling system exposes most of its functionality to scriptors so their encounters can likewise be adjusted as they desire. (This might be a separate goal even outside the spawn system.)

This discussion is valuable, and I haven't had time to think through the implications of the two models you've presented YA, but I have a request.
Given that this process is going to take some time, and the systems will continue to evolve. Can we provide a roadmap for encounter support that somewhat tracks our release milestones? And more pressing, determine a target for encounter functionality to coincide with our next release (tentatively scheduled for early April)?
There are risk factors to releasing something still in development, but at the same time, I'd like to get this early framework into the hands of the community, as it may inform this discussion.
I'm open to pushing this back to v0.8 if it's simply not ready, but we've already teased it on Reddit and Twitter. It'd be nice to release some version of this in v0.7

I apologize -- I thought this was a thread intended for some of the "big picture" discussions about the spawning system. I didn't mean to throw the space off like this.
That said, Zophar and I have spoken a bit about this today. We should start with a very basic Spawndef file that the server can use to generate some encounters, and then iterate over its format a few times to get something suitable for people to play with in 0.7. It's completely doable though, quite fast for a starting system given what work Zophar just put into it.
I'd add that, if Zophar has accomplished what we think regarding walking the scenegraph, he's achieved so much more than might've been hoped this early on. It may not be a stretch to have basic spawning in any zone, if so. And I have an idea for a "game" that we might even be able to make in time for 0.7 that would allow people to help us test the spawn system and any management mechanisms we start to make thereafter.

No need to apologise. You are absolutely in the right place. I just wanted to help frame the discussion inside of our bigger develop roadmap.

By the way, the "game" idea I have requires the use of a timer and the ability to despawn NPCs, both things that @ZopharShinta previously developed. What a champion! He's making this too easy!

Here's a whiteboard I made to help explain the overall structure that we're heading for at the moment:
https://realtimeboard.com/app/board/o9J_kyb6FO0=/

Can we close this issue?


spin up --help does not print trigger options unless all Wasm files exist

Create a new Spin app:
spin new emptyish -t http-rust
cd emptyish

DO NOT BUILD IT.
Now run spin up --help.  It prints the up options but not the trigger options section (not even the generic trigger options).
Now do spin build and run spin up --help again.  It now does print the trigger options.
I think this is because the manifest load operation now fully materialises the app, which fails if a component source doesn't resolve (in this case, because the file hasn't been built).
It would be good to be able to see help regardless of build status - the Wasm files are not needed in order to to know what options are available.  (Although yes, this sort of multiple competing needs load pipeline is how the v1 loader got into the mess it did, so care is needed!)
It seems like this also happens if the manifest has no components in it (e.g. http-empty template), though I'm not sure I'm reproducing this consistently - first time I tried this seemed to give me the generic trigger options as I expected, now it gives me no trigger options at all.  So maybe it's not just missing Wasm files causing this - I've not dug into it yet.
Thanks to @tpmccallum for spotting the missing options!

Hmm yeah we should be able to shuffle things around a bit in up.rs to pull the trigger type out before loading.


Getting data from the client engine

So I was wondering what kind of stats I can get from the main engine. I'm asking because I'm designing a dashboard for my app and it would be cool to have some overall stats to put in the main dashboard.
If you could explain how to get the live data to a variable live, from the main ClientEngine, as i will also be doing the code later.
I would store non live data on a JSON file and do the serialize and deserialize every time I access it. For live data I would use a public parameter using a normal { get; set; } and then accessing it on loading the page.

You can get download/upload speeds, disk write rates, which pieces are downloaded, which are being downloaded, number of peers connected, and lots more.

Also is there a way to store in a variable which peers have the file. I'm thinking about getting the peers from dht as the system i'm, trying to build would use only dht.

I'm not sure what you mean. If you're asking "Can I cache the DHT table to make it bootstrap quicker" the answer is "yes!".
You can also add arbitrary ip/port combinations to a TorrentManager, however I would recommend against that in general. DHT and/or the trackers should be enough to get a fresh peer list quickly!

Closing this as there hasn't been a response in a while.


Add support for markdown documents

Markdown is the base format for tools like Obsidian or logseq. As a user, I would like to be able to ask question about all the notes I took.
Since we already support parsing plain .txt files with
https://github.com/Quansight/ragna/blob/4962665828c51bc6ef0f2d772574f08caec547a8/ragna/core/_document.py#L226-L231
we could just rename it to PlainTextDocumentHandler and add .md to the supported suffixes.

I'd like to help contribute to ragna. This seems like some low-hanging fruit as a first issue and to set up my development environment.


question about Capturing HTTP Requests with fiddler

I cat't get data with fiddler using the newest version(1.4.9),why?

Closing as duplicate of #971


Issue 5364 - Update URL config code block

Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines http://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? (http://docs.wagtail.io/en/latest/contributing/developing.html#testing)
Does the code comply with the style guide? (Run make lint from the Wagtail root)
For Python changes: Have you added tests to cover the new/fixed behaviour?
For front-end changes: Did you test on all of Wagtail’s supported browsers? Please list the exact versions you tested.
For new features: Has the documentation been updated accordingly?

Thanks for the explanation @loicteixeira
You can just use my GitHub handle ryanomor
Thanks!

Thanks @ryanomor  - this has been merged in
https://github.com/wagtail/wagtail/commit/6a6555eb191b32e64de656605f9f5521dff07083


insecure registries- i have followed the instructions for daemon.json, does not work

Description

Steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
(paste your output here)

Output of docker info:
(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.):

could you add some more info, as requested in the issue template, there's currently not enough information to look into your issue

I am running-
virtualbox on mac
on top, ubuntu 16.04
on top docker installed by docker.io
I did create damon.json but it does not help .
On Tue, Nov 22, 2016 at 4:08 PM, Sebastiaan van Stijn <
<EMAIL_ADDRESS>wrote:

could you add some more info, as requested in the issue template, there's
currently not enough information to look into your issue
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/28731#issuecomment-262403520,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWkkGdl1ohVgQC0tADVTbVzlBLBn4kG1ks5rA4PigaJpZM4K6DzP
.

please provide the info requested in the template, the exact steps you followed (e.g. did you restart the daemon after changing the file), and the content of your daemon.json
i'm closing this issue until there's enough information


use community codecov drone plugin

fix #12262

Codecov Report

Merging #12468 into master will decrease coverage by 0.07%.
The diff coverage is 36.52%.

@@            Coverage Diff             @@
##           master   #12468      +/-   ##
==========================================
- Coverage   43.88%   43.81%   -0.08%
==========================================
  Files         614      630      +16
  Lines       87607    69821   -17786
==========================================
- Hits        38449    30591    -7858
+ Misses      44421    34293   -10128
- Partials     4737     4937     +200

Impacted Files
Coverage Δ

cmd/doctor.go
0.00% <0.00%> (ø)

cmd/generate.go
0.00% <0.00%> (ø)

cmd/hook.go
0.00% <0.00%> (ø)

cmd/manager.go
0.00% <0.00%> (ø)

cmd/web.go
0.00% <0.00%> (ø)

models/consistency.go
55.30% <0.00%> (-1.63%)
:arrow_down:

models/context.go
40.00% <ø> (+0.71%)
:arrow_up:

models/migrations/migrations.go
4.66% <ø> (+1.16%)
:arrow_up:

models/migrations/v102.go
0.00% <0.00%> (ø)

models/migrations/v111.go
0.00% <0.00%> (ø)

... and 737 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25a6705...5e355f2. Read the comment docs.


CIS rules silently partial fail to be activated on Ubuntu

Cookbook version
2.3.4
Chef-client version
15
Platform Details
Ubuntu 18.04.3 LTS
Scenario:
Trying to apply cis.rules on Ubuntu
Steps to Reproduce:
include_recipe 'auditd::default'

auditd_ruleset 'cis.rules' do
  cookbook 'mitre-ipac-auditd'
end

Expected Result:
I expected cis.rules to work on Ubuntu
Actual Result:
The rules loaded are a partial set of cis.rules. I suspect everyone using this cookbook on Ubuntu, with the included cis.rules, is NOT auditing what they think!
m26560@ipac-ub18-tplt:~$ sudo auditctl -l
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-change
-a always,exit -F arch=b32 -S stime,settimeofday,adjtimex -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F key=time-change
-a always,exit -F arch=b32 -S clock_settime -F key=time-change
-w /etc/localtime -p wa -k time-change
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-a always,exit -F arch=b64 -S sethostname,setdomainname -F key=system-locale
-a always,exit -F arch=b32 -S sethostname,setdomainname -F key=system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
m26560@ipac-ub18-tplt:~$

My assessment is that this is because the next rule is "-w /etc/sysconfig/network -p wa -k system-locale" and this quietly fails (and short-circuits all further rule loading!) because /etc/sysconfig/network does not exist on an Ubuntu disk. There are certainly other issues further down the file.

Instead of /etc/sysconfig/network, the Ubuntu rule should be -w /etc/network -p wa -k system-locale per the CIS Benchmark for Ubuntu 18. However, as mentioned in the original issue above, there are other EL-centric issues further down the file related to rules in this cookbook's wholly EL-centric templates/default/cis.rules


Create MarkdownService, EmojisService, CodesOfConductService and MetaService

closes #2936
This moves all Client methods from misc.go to new services.
In every case but one, the original Client method was left in place and refactored to call the new method. The exception is Client.Markdown because the old method name is now the name of the service field.

@gmlewis I did the renaming you suggested and took it one further renaming EmojisService.ListEmojis to EmojisService.List.
I think you were right about renaming Markdown to Render. Even though the endpoint ends with /markdown` the description is "Render a Markdown document".

One more possibility while we are breaking things. Would it make sense to rename MetaService.APIMeta to MetaService.Get? I would think yes, but my hesitation is that meta is kind of a weird service in that it has functions that don't have anything to do with the metadata.

One more possibility while we are breaking things. Would it make sense to rename MetaService.APIMeta to MetaService.Get? I would think yes, but my hesitation is that meta is kind of a weird service in that it has functions that don't have anything to do with the metadata.

I like it.  Yes, please.

Hey @gmlewis, I see that the PR is waiting on a few test function renames.
Can I help in anyway to speed things up? I could raise a PR against WillAbide:nomisc with the required changes. @WillAbides
P.S., can this comment be resolved? I gather that the required changes are done.

P.S., can this comment be resolved? I gather that the required changes are done.

Thanks, @abhijit-hota - marked comment as resolved.
For the remaining items, I was interested in hearing what @WillAbides thinks about the ideas I toseed out, so let's please wait to hear.

Sorry for the late response. I lost track of this one somehow. @abhijit-hota I appreciate your willingness to step in.
@gmlewis Your suggestions make sense, so I added them. That reduced the code coverage a bit because the deprecated methods are no longer tested. IMO, there isn't a point in testing these anyway.

LGTM. =)

Thank you, @abhijit-hota !
Merging.


.cloudProvider.disableBundledCSIDrivers mandatoriness in docs/kubeone

What happened?
It may sound a bit pedantic, but we cannot wrap our head around correctly setting the API field .cloudProvider.disableBundledCSIDrivers, when upgrading clusters from kubeone versions prior 1.7.0.
A first upgrade on a cluster having that CSI drivers installed already succeeded without error. Expected, since there is no explicit hint in the upgrade notes to give special attention to this setting. However, according the docs this is (the one and only) mandatory field (required: true at https://docs.kubermatic.com/kubeone/v1.7/references/kubeone-cluster-v1beta2/).
Is this a bug in docs and the option is not really required or does kubeone just not complain about this mandatory field when it isn't being set? If latter, what is the default value (true or false)?
Expected behavior
Either

correct docs to have .cloudProvider.disableBundledCSIDrivers be optional, but with an expected default value (for me that would be false to follow behavior pre v1.7.0)
or
have kubeone fail with error, if the value is not present in kubeone.yml

How to reproduce the issue?
Run kubeone >=v1.7.0 without setting .cloudProvider.disableBundledCSIDrivers in kubeone.yml
What KubeOne version are you using?

./kubeone version
{
  "kubeone": {
    "major": "1",
    "minor": "7",
    "gitVersion": "1.7.0",
    "gitCommit": "1195366fd0cf11f314d194a3b29b6a782afde9a8",
    "gitTreeState": "",
    "buildDate": "2023-09-08T14:02:33Z",
    "goVersion": "go1.20.5",
    "compiler": "gc",
    "platform": "linux/amd64"
  },
  "machine_controller": {
    "major": "1",
    "minor": "57",
    "gitVersion": "v1.57.3",
    "gitCommit": "",
    "gitTreeState": "",
    "buildDate": "",
    "goVersion": "",
    "compiler": "",
    "platform": "linux/amd64"
  }
}

Provide your KubeOneCluster manifest here (if applicable)

apiVersion: kubeone.k8c.io/v1beta2
kind: KubeOneCluster
versions:
  kubernetes: '1.26.8'
cloudProvider:
  hetzner: {}
  external: true
clusterNetwork:
  kubeProxy:
    skipInstallation: true
  cni:
    cilium:
      enableHubble: true
      kubeProxyReplacement: strict
addons:
  enable: true
  addons:
  - name: default-storage-class

Hetzner
What operating system are you running in your cluster?
Ubuntu 20.04

Is this a bug in docs and the option is not really required or does kubeone just not complain about this mandatory field when it isn't being set? If latter, what is the default value (true or false)?

Field being required means that some value has to be provided, either true or false. If nothing is provided, it's defaulted by KubeOne, in this case to false.
If you enable this option for an existing cluster, you have to manually remove the CSI driver and volumes?
Does that help?

If you enable this option for an existing cluster, you have to manually remove the CSI driver and volumes?

We want bundled CSIs for existing and also future new clusters and keep this behavior with v1.7.0. In that matter we weren't sure if we are not required to set disableBundledCSIDrivers: false in kubeone.yml explicitly.

If nothing is provided, it's defaulted by KubeOne, in this case to false.

Thanks @xmudrii, exactly this last bit of information was missing, so we do not need to change our kubeone.yml.


exclude spec/huginn/ subtree from test_files

gem build obviously shouldn't include the spec/huginn/ subtree :-)
... this excludes it once and for all (so you don't have to manually rm -rf or move it away each time)

Thank you @stesie!

I just released 0.5.0 which includes your changes 😄


Missing visual focus on Search box

Should there be focus on the magnifying glass as well?

Tested on dev3.
chrome ✅
firefox ✅
safari ✅


Provide details when no instance connect endpoints are found

👋 currently this panics with the following error
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
main.runProxy(0x140001b4300, {0x140001b2350, 0x1, 0x1?})
        /home/runner/work/rdsconn/rdsconn/proxy.go:70 +0x8f0
github.com/spf13/cobra.(*Command).execute(0x140001b4300, {0x140001b2310, 0x1, 0x1})
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940 +0x5c8
github.com/spf13/cobra.(*Command).ExecuteC(0x140001b4000)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068 +0x35c
github.com/spf13/cobra.(*Command).Execute(...)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992
github.com/spf13/cobra.(*Command).ExecuteContext(...)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:985
main.main()
        /home/runner/work/rdsconn/rdsconn/main.go:28 +0x188

This updates to tell the user there's no instance connect endpoints in the vpc
panic: no instance connect endpoints found for vpc vpc-073xxxxxx

goroutine 1 [running]:
main.main()
        /Users/conor.mongey/workspace/Mongey/rdsconn/main.go:30 +0x1dc

This is a helpful change, thanks!


cla: accepted by racnan

Accepting CLA by racnan.

@racnan We'll merge this shortly.
Thank you for accepting the CLA and taking time to contribute!!
Welcome to the Ockam Community 🥳
If you have questions, as you explore, join us on the contributors discord channel https://discord.gg/bewvnm6zqS

@metaclips @etorreborre please enqueue this for merge when you get a chance.


stdenv: remove bash version compatibility hack

Motivation for this change
This removes a compatibility hack accross all version of bash prior to 4.4
In my understanding we won't be using older versions of bash anymore, so this is safe to remove.
For more informations check https://stackoverflow.com/questions/7577052/bash-empty-array-expansion-with-set-u
Note that there are other occurrences of this in the nixpkgs (notably in cargo-hooks) just search for the pattern Array+" to find them. I want to remove those at the same time, but I'm not sure those other occurrences can be safely removed.
I think this PR is uncontroversial
This is coming from https://github.com/NixOS/nixpkgs/pull/127736/commits/d685a680e74a65354d0700410877bfb350b2dca6
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Which version of bash is macos using again? Wasn't that 3.2? Does that matter for the stdenv?
(I don't know much about the stdenv, just some questions)

Thank you for the review!
I hadn't realised actually, but the default version of bash on macos is still 3.2 (it seems to be because of a licensing issue).
The stdenv being built with 4.4 so it shouldn't matter I think.
Inside the darwin stdenv there is an allowedRequisites part.
      allowedRequisites = (with pkgs; [
        xz.out
        xz.bin
        gmp.out
        gnumake
        findutils
        bzip2.out
        bzip2.bin
        zlib.out
        zlib.dev
        libffi.out
        coreutils
        ed
        diffutils
        gnutar
        gzip
        ncurses.out
        ncurses.dev
        ncurses.man
        gnused
        bash
        gawk
        gnugrep
        patch
        pcre.out
        gettext
        binutils.bintools
        darwin.binutils
        darwin.binutils.bintools
        curl.out
        openssl.out
        libssh2.out
        nghttp2.lib
        brotli.lib
        cc.expand-response-params
        libxml2.out
      ] ++ lib.optional haveKRB5 libkrb5
      ++ lib.optionals localSystem.isAarch64 [
        pkgs.updateAutotoolsGnuConfigScriptsHook
        pkgs.gnu-config
      ])
      ++ (with pkgs."${finalLlvmPackages}"; [
        libcxx
        libcxx.dev
        libcxxabi
        libcxxabi.dev
        llvm
        llvm.lib
        compiler-rt
        compiler-rt.dev
        clang-unwrapped
        libclang.dev
        libclang.lib
      ])
      ++ (with pkgs.darwin; [
        dyld
        Libsystem
        CF
        cctools
        ICU
        libiconv
        locale
        libtapi
      ] ++ lib.optional useAppleSDKLibs objc4
      ++ lib.optionals doSign [ postLinkSignHook sigtool signingUtils ]);

bash is included in there. That would make me think that stdenv ships with a shell and that we don't need to care about older version.
There might be more to it than my interpretation though, it would be good to know who we can ask more informations to.

@vcunat when you have a moment, I would like to see if that PR builds correctly.
(I've tried the build jobs on master and it worked). Last time even if the tests passed, it caused a regression, so I want to make sure I'm not breaking something with this PR.
When you have a moment, no rush. (once this PR is passed, I can have a go at the PR that introduced breakage with newline in flags).


added site name to the Navbar

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
this gives better look to the website
Describe the solution you'd like
A clear and concise description of what you want to happen.
Additional context
Add any other context or screenshots about the feature request here.
before

after

Can you please assign this issue to me #131?