gcp 3-node site output fails

Successfully deployed 3-node ingress-egress GCP site using branch 0.11.21 , but fails because data.tf google_compute_instance fails to regex the instance name. I guess it is only working for single node sites so far.
I worked around it by simply disabling output relying on instance:
$ git diff output.tf
diff --git a/f5xc/site/gcp/output.tf b/f5xc/site/gcp/output.tf
index c855b29..042a2ef 100644
--- a/f5xc/site/gcp/output.tf
+++ b/f5xc/site/gcp/output.tf
@@ -3,11 +3,11 @@ output "gcp_vpc" {
     id            = volterra_gcp_vpc_site.site.id
     name          = volterra_gcp_vpc_site.site.name
     region        = volterra_gcp_vpc_site.site.gcp_region
-    slo_ip        = data.google_compute_instance.instance.network_interface.0.network_ip
-    sli_ip        = var.f5xc_gcp_ce_gw_type == var.f5xc_nic_type_multi_nic ? data.google_compute_instance.instance.network_interface.1.network_ip : ""
+    # slo_ip        = data.google_compute_instance.instance.network_interface.0.network_ip
+    # sli_ip        = var.f5xc_gcp_ce_gw_type == var.f5xc_nic_type_multi_nic ? data.google_compute_instance.instance.network_interface.1.network_ip : ""
     params        = volterra_tf_params_action.gcp_vpc_action
-    public_ip     = data.google_compute_instance.instance.network_interface.0.access_config.0.nat_ip
+    # public_ip     = data.google_compute_instance.instance.network_interface.0.access_config.0.nat_ip
     instance_name = regex(local.f5xc_gcp_instance_name_pattern, volterra_tf_params_action.gcp_vpc_action.tf_output)[0]
     instance_type = volterra_gcp_vpc_site.site.instance_type
   }
-}
\ No newline at end of file
+}

module "gcp1" {
  source                            = "./modules/f5xc/site/gcp"
  f5xc_tenant                       = var.f5xc_tenant
  f5xc_api_url                      = var.f5xc_api_url
  f5xc_gcp_cred                     = var.f5xc_gcp_cred
  f5xc_api_token                    = var.f5xc_api_token
  f5xc_namespace                    = "system"
  f5xc_gcp_region                   = "europe-west6"
  f5xc_gcp_site_name                = format("%s-gcp1", var.project_prefix)
  f5xc_gcp_zone_names               = ["europe-west6-a", "europe-west6-b"]
  f5xc_gcp_ce_gw_type               = "multi_nic"
  f5xc_gcp_node_number              = 3
  f5xc_gcp_outside_network_name     = format("%s-gcp1-outside", var.project_prefix)
  f5xc_gcp_outside_subnet_name      = format("%s-gcp1-outside", var.project_prefix)
  f5xc_gcp_inside_network_name      = format("%s-gcp1-inside", var.project_prefix)
  f5xc_gcp_inside_subnet_name       = format("%s-gcp1-inside", var.project_prefix)
  f5xc_gcp_outside_primary_ipv4     = "<IP_ADDRESS>/24"
  f5xc_gcp_inside_primary_ipv4      = "<IP_ADDRESS>/24"
  f5xc_gcp_default_ce_sw_version    = true
  f5xc_gcp_default_ce_os_version    = true
  f5xc_gcp_default_blocked_services = true
  ssh_public_key                    = var.ssh_public_key
  providers = {
    google = google.europe-west6
  }
}

output "gcp1" {
  value = module.gcp1.gcp_vpc
}

$ terraform output
gcp1 = {
  "id" = "8215075c-0664-4015-a680-e5bb660ed171"
  "instance_name" = "vela-gcp1-6tsj\",\"vela-gcp1-cnjp\",\"vela-gcp1-zr1p"
  "instance_type" = "n1-standard-4"
  "name" = "vela-gcp1"
  "params" = {
    "action" = "apply"
    "id" = "21db4ac6-4d66-4741-a9da-cb64d2c4630d"
    "ignore_on_update" = false
    "site_kind" = "gcp_vpc_site"
    "site_name" = "vela-gcp1"
    "tf_output" = <<-EOT
    master_public_ip_address = {"vela-gcp1-6tsj":"<IP_ADDRESS>","vela-gcp1-cnjp":"<IP_ADDRESS>","vela-gcp1-zr1p":"<IP_ADDRESS>"}
    gcp_object_name = "vwb6733qhf"
    instance_names = ["vela-gcp1-6tsj","vela-gcp1-cnjp","vela-gcp1-zr1p"]
    master_private_ip_address = {"vela-gcp1-6tsj":"<IP_ADDRESS>","vela-gcp1-cnjp":"<IP_ADDRESS>","vela-gcp1-zr1p":"<IP_ADDRESS>"}

    EOT
    "wait_for_action" = true
  }
  "region" = "europe-west6"
}

Added support for 3 node site in 0.11.21 tree.

Tried latest 0.11.21, but plan fails with this:

Plan: 9 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + workload = {}
╷
│ Error: Invalid count argument
│
│   on modules/f5xc/site/gcp/data.tf line 3, in data "google_compute_instance" "node0":
│    3:   count      = length(local.f5xc_instance_names)
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the
│ resources that the count depends on.
╵
╷
│ Error: Invalid count argument
│
│   on modules/f5xc/site/gcp/data.tf line 10, in data "google_compute_instance" "node1":
│   10:   count      = var.f5xc_gcp_node_number > 1 ? length(local.f5xc_instance_names) : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the
│ resources that the count depends on.
╵
╷
│ Error: Invalid count argument
│
│   on modules/f5xc/site/gcp/data.tf line 17, in data "google_compute_instance" "node2":
│   17:   count      = var.f5xc_gcp_node_number > 1 ? length(local.f5xc_instance_names) : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the
│ resources that the count depends on.
╵

Suggestion (worked for me):
$ git diff f5xc/site/gcp/data.tf
diff --git a/f5xc/site/gcp/data.tf b/f5xc/site/gcp/data.tf
index 4537a11..14acc4e 100644
--- a/f5xc/site/gcp/data.tf
+++ b/f5xc/site/gcp/data.tf
@@ -1,20 +1,20 @@
 data "google_compute_instance" "node0" {
   depends_on = [module.site_wait_for_online]
-  count      = length(local.f5xc_instance_names)
+  count      = var.f5xc_gcp_node_number
   name       = local.f5xc_instance_names[count.index]
   zone       = element(var.f5xc_gcp_zone_names, 0)
 }

 data "google_compute_instance" "node1" {
   depends_on = [module.site_wait_for_online]
-  count      = var.f5xc_gcp_node_number > 1 ? length(local.f5xc_instance_names) : 0
+  count      = var.f5xc_gcp_node_number > 1 ? var.f5xc_gcp_node_number : 0
   name       = local.f5xc_instance_names[count.index]
   zone       = element(var.f5xc_gcp_zone_names, 1)
 }

 data "google_compute_instance" "node2" {
   depends_on = [module.site_wait_for_online]
-  count      = var.f5xc_gcp_node_number > 1 ? length(local.f5xc_instance_names) : 0
+  count      = var.f5xc_gcp_node_number > 1 ? var.f5xc_gcp_node_number : 0
   name       = local.f5xc_instance_names[count.index]
   zone       = element(var.f5xc_gcp_zone_names, 2)

Committed suggestion to 0.11.21

Thanks. All set. Closing issue as resolved.


Fix broken pydocstyle regex and address RtD documentation build errors

Pull Request Checklist:

[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #xyz

[ ] Tests for the changes have been added (for bug fixes / features)

[ ] (If applicable) Documentation has been added / updated (for bug fixes / features)

[x] HISTORY.rst has been updated (with summary of main changes)

[x] Link to issue (:issue:number) and pull request (:pull:number) has been added

[x] bumpversion patch has been called on this branch
[x] The relevant author information has been added to .zenodo.json

What kind of change does this PR introduce?

Sets all linting functions for pydocstyle to refer to setup.cfg
Adds a workaround for the broken regex used in pydocstyle
Fixes many docstrings and references that were not conformant with good practices
Added nbsphinx to environment.yml, removed pytest-runner

Does this PR introduce a breaking change?
Not really. pytest-runner was removed as a dependency, but it was never needed.
Other information:
The regex used for selectively including files and selectively excluding directories used by pydocstyle has been broken for some time. This PR implements a workaround using only matching via filename. Errors have not been raised for quite some time, so effort is needed to deal with the existing failures.
This also sets the pydocstyle configuration for all linting commands to use setup.cfg
See many issues in: https://github.com/PyCQA/pydocstyle/issues

Coverage increased (+0.007%) to 91.678% when pulling dd178c8d37d4a623348a691e4b8aa9d92f24b948 on fix_pydocstyle into 16eaac32eb89d27323949049cc5473851f5825af on master.

I think I may have gotten autodoc working finally:

I see! Makes sense now, thanks.

@juliettelavoie I've added some directions on building the docs. Please let me know if there are any issues with them.

I've made two little comments, but it works, thanks!


Defaults value for CONFIG_MIN_SESSION_CONNECTION_INTERVAL is too low for reliable TCP stream

Hi,
I believe the default value for CONFIG_MIN_SESSION_CONNECTION_INTERVAL is too low.
By default, CONFIG_MIN_SESSION_CONNECTION_INTERVAL is 1 (ms) and CONFIG_MAX_SESSION_CONNECTION_ATTEMPTS is 12. This means that a XRCE client may try up to 12 times to create a session, with the maximum waiting period beginning from 1ms.
The sequence would be like this, assuming a successful transmission takes place and no response is received within the window:
1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048
If a message is received but is not a correct response, then it gets worse because the client will continue to wait for only 1ms.
However, depending on the speed of the client, the agent and the order of execution,  the agent might get multiple CREATE SESSION messages from the client. This could be dangerous, if the agent successfully resets a reliable stream repeatedly, after at least one (reply) message has been sent. Resetting a reliable output stream after the session has been created, could result in a communications breakdown with no recovery, due to the sequence numbers going wrong.
The line in question is here:
                {
                    client->session().reset();
                }

If you add print statements/set a breakpoint before this line, it is possible to occasionally observe a session getting reset multiple times, for a client.
Across the Internet, it is possible for the RTT to be more than even 5ms. If TCP is used and Nagle is enabled, then the message could be delayed for up to 250ms, particularly if it is a small message.
In my opinion, I think increasing CONFIG_MIN_SESSION_CONNECTION_INTERVAL to a larger value like 500 could help reduce the odds of the agent receiving duplicate CREATE SESSION requests.
In exchange, CONFIG_MIN_SESSION_CONNECTION_INTERVAL could be reduced to 5, to prevent the timeout period from increasing to huge values.

Hi @sp193,
We appreciate your piece of advice. We will take it into account this as the default configuration for new releases. Thanks.

Hi @sp193 this has been addressed in https://github.com/eProsima/Micro-XRCE-DDS-Client/pull/110.


⚠ Fortnite has degraded performance

In 5eb9ef6, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1648 ms

Resolved: Fortnite performance has improved in 291197a.


introduce general musl support

This is a draft PR that will remain open while we work on a general fix for musl version issues.

[x] demonstrate the issue from #434 and #372 in the CI suite
[ ] upgrade to a version of rake-compiler-dock with musl support (see https://github.com/rake-compiler/rake-compiler-dock/issues/75)
[ ] update installation docs to reflect first-class musl support in native gems

Fixes #434
Fixes #372

This went green using rake-compiler-dock 1.5.0.rc1!

Found a pretty significant blocker this weekend. We probably cannot release this unless https://github.com/rubygems/rubygems/issues/7432 is addressed in bundler or rubygems.
And even then, we probably need additional documentation to help people resolve issues.
Putting this on hold until we know more.

Picking this back up again since the fix to the rubygems issue mentioned above was released in bundler 2.5.6.

OK, proceeding carefully here after an exploration revealed some versions of rubygems and bundler aren't going to work well, see https://github.com/rake-compiler/rake-compiler-dock/issues/117
Planning to cut a release candidate this week.


fixing the color of colorcolumn

I like to use this particular setting for vim
set colorcolum=80
but currently it looks like this.

I don't know if this red color is intentional or not. But it is not really pleasant to look at.


Documents --target and updates possible compile platforms documentation.

fixes issue https://github.com/spark/particle-cli/issues/204

@monkbroc Can we merge this in?

Thanks for putting this explanation together Harrison.