provide updatable snapshot of previous releases

either a separate (virtual) host
releases.istio.io/v0.1
or under istio.io as a sub directory (could possibly be a submodule)
the goal is that there is a branch (like https://github.com/istio/istio.github.io/tree/release-0.1 ) or some otherway to easily update the snapshot of alpha docs (and ditto for 0.2 etc... later)
I tried to use forks (e.g. https://ldemailly.github.io/istio-0-1.github.io/ ) but it doesn't seem possible to fork inside the same org (I suppose we could create a istio-releases org but that seems heavy handed)
cc @mandarjog @ayj @geeknoid

I suggest the following:

We create a branch in istio.github.io for every release.

The active branch under development is called 'next'. The current release's branch is called 'current'.

When a release takes place, the 'current' branch is renamed to its explicit version number (V0.1), the next branch is renamed to current, and a new next branch is created.

We have an automated build process that takes all these branches, runs Jekyll for all of them, does whatever sed processing is necessary to patch URLs, and then dumps the resulting HTML into istio.github.io and checks that in as is. The versioned branches all get subdirectories, while the current branch is at the root.
istio.github.io/
istio.github.io/versions/V0.1
istio.github.io/versions/next

This seems like a composition of simple steps.

simplification proposal: we probably only need docs.istio.io to point to the last release (aka alpha and the release-0.1 branch for now) and istio.io to be current (master) and that's it for the next 3 months; after which we can also erase alpha docs and replace them by beta docs... we will only need to keep more than 1 after GA
And in master we add a link in the header to "0.1 release docs" and that's it

We're going to go with mandar's solution but for reference I got a very quick "github pages only, nothing else required" hack going with https://istio-releases.github.io/v0.1/docs/ by creating an org for releases and forking the site there

What  is Mandar's solution(tm) ?

What is Mandar's solution(tm) ?

linked above:  #368

See also #406, #407 and #379

all done except the post submit on release-0.1 is failing


Can't we run it on different machine instances with same bot id ?

I am getting this error while running it on a different instance with the same bot id.
[polling_error] {"code":"ETELEGRAM","message":"ETELEGRAM: 409 Conflict: terminated by other getUpdates request; make sure that only one bot instance is running"}

Hi @siddhant-rigi,
you can only run one instance per bot token. If you run more that one Telegram Bot API send you the polling_error


[Quest/eCBIS] - Configure Quest app to view measure report for Indicator 2 - Pregnancy Count

Reference Link: https://docs.google.com/spreadsheets/d/1Kfp0rRYlksrBoSIecAuovZ8Y3k8yH9mkmgHcpQbMtXI/edit#gid=446158820
Each household or a family is represented using a group resource as outlined below
{
  "resourceType": "Group",
  "id": "107759",
  "meta": {
    "versionId": "3",
    "lastUpdated": "2022-04-14T13:54:41.656+00:00",
    "source": "#2f77c0c4a5d11f1e"
  },
  "identifier": [ {
    "use": "official",
    "value": "7bb7fa82-59e4-4744-a6d2-96722afca23b"
  }, {
    "use": "secondary",
    "value": "656766"
  } ],
  "active": true,
  "type": "person",
  "code": {
    "coding": [ {
      "system": "https://www.snomed.org",
      "code": "35359004",
      "display": "Family"
    } ]
  },
  "name": "Kamwana Rao",
  "managingEntity": {
    "reference": "RelatedPerson/2e2c9d4e-b67f-4673-8e83-e3f576046296"
  },
  "member": [ {
    "entity": {
      "reference": "Patient/c535f2e6-a17a-4b2a-913e-30e8b42553d0",
      "display": "Rao Kamwana"
    },
    "inactive": false
  }, {
    "entity": {
      "reference": "Patient/d0612f01-01c3-467e-9fbc-4e6ebe8bf9e6",
      "display": "Magarita Rao"
    },
    "inactive": false
  } ]
}

Narrative

Count of all Female Patients enrolled on the app in each Households
Count of ANC Clients with active Pregnancies registered in the app, disaggregated by age and gender for each age group.

this will be via All patients with Pregnancy conditions and SNOMED code 77386006 as shown below
    "code": {
        "coding": [
            {
                "system": "http://snomed.info/sct",
                "code": "77386006",
                "display": "Pregnancy"
            }
        ],
        "text": "Pregnancy"
    },

Age disaggregation will be (15-49, 50+)

Pre-requisite

#700
Add a household registration encounter e.g http://hl7.org/fhir/encounter-example-home.json.html
#1233
https://github.com/google/android-fhir/pull/1280

Subtasks

[ ] 1. #1379

Acceptance Criteria

[ ] Create a measure for eCBIS Measure 2  -  Pregnancy Count
[ ] Add Measure Resource library to FHIR Core HAPI FHIR Server
[ ] List the measure in the Quest Reporting module
[ ] Trigger measure for Household Indicator filtered by Start and End date and for a given population using the Family group resource
[ ] View the measure report for eCBIS Indcator 2

OK, I think we need to update the narrative then, how this factors into the 2 indicators listed above is ambiguous.

Count of all Female Patients enrolled on the app in each Households

is this the overall count of female patients? or is this the count of households that include a female patient, or something else?

Count of ANC Clients with active Pregnancies registered in the app, disaggregated by age and gender for each age group.

do families not factor into this?

Age disaggregation will be (0-11, 1-5, 6-14, 15-49, 50+)

Is this a disaggregation of the age of the pregnant woman? If so, these ranges don't make sense, eg 1-5

@f-odhiambo

In all the registered household members, need to know the number of females. Of all the females how many are of reproductive age i.e. 15-49yrs. Of these RA women, the number is pregnant. Only the women of reproductive age can be used to compute the number of pregnant women.

It's still not clear how to calculate this, can you please list out each indicator we will need to show, and for each include an example of what the inputs would be and the formula to calculate it?

Done. Two PRs for fhir-resources and fhircore are following. (Condition extraction is under progress in other ticket by Fikri)
Household pregnancy by age group | Measure Report from Composition #1404
Cucumber testing module | Household pregnancy measure fhir-resources/94

Check on the Date filter
We should focus the date on the numerator count of interest thus if I add 1st to 31st January I should only get all ANC Clients enrolled in January


what does the pixel value of outputs meaning?

hello! thank you for your amazing job!
could you tell me what does the pixel value of outputs(before (pred-pred.max)/(pred.max - pred.min)) meaning?
I know this is relative depth, but i don't know how to calculate it and meaning of it.
assuming there are 2 pixels in ouput, one's value equals 3, the other one equals 21. Is that meaning the second one is far from the first one 21/3＝7times? If not, how to achieve this by ouput of depthanything?
thank you in advance!

Hi, in your case, the output values 3 and 21 do not mean the second pixel is 7x farther than the first pixel, for two reasons:

the output value denotes the disparity value, which can be deemed as the 1/depth. Thus, the first pixel is actually farther than the second pixel.
when converting the disparity to depth, the relative depth value is still correlated to real depth by an unknown scaling factor and an unknown shift value. Due to the existence of the shift, the two values can not be simply divided.

You may find our Section 3.1 helpful.

thank you!

Sorry to bother you again.
I read your paper, do the an unknown scaling factor and an unknown shift value mean focal length (f) and distance between stereo cameras (b)? Is that meaning disparity = f*b / depth?
And if it is right, if I get the real depth of one pixel of disparity map (for example, the value of one pixel of disparity map equals 3, and the real depth of this pixel equals 1 meter), can I calculate the real depth of all pixels by disparity = f*b / depth?
Thank you in advance, and sorry for my poor english.

There's a similar discussion on the MiDaS issue board.
The formula would be something like:
true depth = 1 / (A + B*depth_anything_result)
Where A and B are the unknown shift & scale factors, respectively.
Based on this formula, if you only have 1 pixel value, it won't be enough to figure out both unknowns. If you have 2 pixel values, I guess it could be enough, but it will likely be very error prone. That same issue references another post where someone was trying to do a least squares fit between a known depth map and the disparity map, which seems like a more robust approach.

Thank @heyoeyo for answering! The formula may be more precise if modified to:
true depth = A * (1 / depth_anything_output) + B

A is the unknown scaling factor and B is the unknown shift.
Just as @heyoeyo said, you need at least two true depth values to estimate A and B. Of course, more true depth values will bring more precise estimation of A and B.

Thank you @heyoeyo @LiheYoung You guys help me a lot!
Acorrding this,  the relative depth is disparity?

You can consider the relative depth as 1 / disparity.

ok
the A and B which you mention are only defined by camera? I mean, they are constast for a determine camera？not affect by angle, speed of camera , or sence of world?

ok
the A and B which you mention are only defined by camera? I mean, they are constast for a determine camera？not affect by angle, speed of camera , or sence of world?

How are we calculating A and B here ? Also metric_depth by DA different than relative depth ? @LiheYoung

Hi @LiheYoung, I am interested in your work and would like to know more about its output. Are the model's output values in meters or something like that?

@hoangtnm Only the metric model's (model finetuned on kitti dataset) output is metric, meaning in meters. The other models output relative disparity (inverse depth) upto an unknown scale and unknown shift which needs to be computed using GT for example

@Eyshika A & B can be calculated using the script here : https://gist.github.com/ranftlr/45f4c7ddeb1bbb88d606bc600cab6c8d. It is from the author of MiDAS if I am not wrong and they also predict relative disparity

Thank you guys! You did a great help! @heyoeyo @LiheYoung

@zhongqiu1245 In case you didn't get an answer to:

the A and B which you mention are only defined by camera? ...

For the formula:
true depth = 1 / (A + B*depth_anything_result)
If I understand the mapping correctly, then if you normalize the depth-anything result (between 0 and 1), the values for A and B should be something like:
A = 1 / max_true_depth
B = (1 / min true depth) - (1 / max true depth)
So the answer would be that the values are specific to individual images (in general). They are not directly related to the camera, but instead depend on the depth of the closest and farthest parts of the image (at least in theory).
You can find a more detailed explanation here:
https://github.com/heyoeyo/muggled_dpt/blob/main/results_explainer.md

Thank you！@heyoeyo

Thank @heyoeyo for answering! The formula may be more precise if modified to:
true depth = A * (1 / depth_anything_output) + B

A is the unknown scaling factor and B is the unknown shift.
Just as @heyoeyo said, you need at least two true depth values to estimate A and B. Of course, more true depth values will bring more precise estimation of A and B.

It seems that  the output of the model have not been normed，“depth_anything_output” you mentioned here should be the original output or its value after normed（d-dmin/dmax-dmin）？

“depth_anything_output” you mentioned here should be the original output or its value after normed

It would have to be normalized for those equations to work. The 'raw' output has an arbitrary scale/shift and it varies by model (i.e. the small/base/large variants), so it's hard to work with without normalization.

“depth_anything_output” you mentioned here should be the original output or its value after normed

It would have to be normalized for those equations to work. The 'raw' output has an arbitrary scale/shift and it varies by model (i.e. the small/base/large variants), so it's hard to work with without normalization.

Thanks.I've read your insights about the mapping here:https://github.com/heyoeyo/muggled_dpt/blob/main/.readme_assets/results_explainer.md and noticed that the mapping you understand is different from the author's.
Yours:
true depth = 1 / (A + B*depth_anything_result);
The author's:
true depth = A * (1 / depth_anything_output) + B
How do you think about the difference,which one may be more reasonable?

How do you think about the difference,which one may be more reasonable?

I originally figured the two equations were the same, but was corrected (on the MiDaS issue page).
The True Depth = (A/depth_anything) + B form looks a lot more elegant, but assuming the depth anything output is normalized, it doesn't make sense if the true depth is finite. More specifically, the maximum true depth value would be mapped an inverse value (after normalization) of 0, so you'd get:
Max true depth = (A / 0) + B
And there is no A, B that can make this work. So I tend to this the 1/(A + B*d) version is better. It also seems to properly reverse the equation used in the original MiDaS paper (eq. 6), which I assume is applicable to the depth_anything result.

Hi, in your case, the output values 3 and 21 do not mean the second pixel is 7x farther than the first pixel, for two reasons:

the output value denotes the disparity value, which can be deemed as the 1/depth. Thus, the first pixel is actually farther than the second pixel.
when converting the disparity to depth, the relative depth value is still correlated to real depth by an unknown scaling factor and an unknown shift value. Due to the existence of the shift, the two values can not be simply divided.

You may find our Section 3.1 helpful.

The paper says: Concretely, the depth value is first transformed into the disparity space by d = 1/t and then normalized to 0∼1 on each depth map.
but I am wondering, as affine-invariant loss is applied, is there any necessary to normalize the disparity  to 0-1?


Fix: Seed Job Failing To Run Due to confirmToProceed Condition In Seed Command

During our work with the package, we were attempting to create a new tenant via a artisan command we created.  We noticed that when we shifted to production it would hang and never complete, but only while the environment was set to production.  While digging into this, we noticed that it was getting caught here:
https://github.com/archtechx/tenancy/blob/3.x/src/Commands/Seed.php#L49
To resolve this, we added the force option when invoking the seed command from the job that AFAIK is only run upon standing up a tenant.  Not really sure when or why this behavior changed considering the blame says it's unchanged for years, so I can only assume it was a change in Laravel because we've used this package for years now without encountering this issue.
Side note, thanks for all the work you do on this!

It should work to just configure the args here (see the commented out --force): https://github.com/archtechx/tenancy/blob/30cdc9461e1a120834e8cdee39aef7a9ced9f863/assets/config.php#L195-L198
It's disabled by default for safety reasons but if you know you do want to use tenants:seed (even indirectly), you can just uncomment the line included for this.


[MINOR][CORE][SQL][FOLLOWUP] Add missing s prefix to enable string interpolation

What changes were proposed in this pull request?
Adds missing s prefix to enable string interpolation. Complements #38297.
Why are the changes needed?
Strings will not contain substituted values but variable names.
Does this PR introduce any user-facing change?
Log messages will change.
How was this patch tested?
Not tested.

@MaxGekk @itholic here are some more places
thanks @gaoyajun02

Can one of the admins verify this patch?

Can you retrigger tests? there was an unrelated build error earlier

Rebased with master, all green.

Merged to master.


Add an IMAGE_SVG constant

I need a svg mime type that can be referenced in constant expressions, so I propose adding IMAGE_SVG along with other mime-type constants here.
Since the correct mime type for svg is image/svg+xml, a plus position needed to be present in the declaration.  That meant I had to change the type of pieces in the macro from tt to expr.

The for_each thing failed on rustc 1.18, which isn't to surprising since for_each was added in version 1.21, released on 2017-10-12.

The first commit here is also submitted separately as #87 .

Thank you!

I don't really know, but with the tt designator, the macro would not accept Some(9) as a parameter (needed for the offset of the optional + sign present in image/svg+xml), and with expr it worked.


Additionnal step about copying PERSONAL_GITHUB_TOKEN in project Secrets

I think the documentation is missing the step where you copy your token to Secrets of your $LOGIN repo.
:heart: the project !

@arthurlogilab Do you think Now create a new secret in your repository's Settings and enter that token. is not clear enough?

Re-reading the documentation I realised the information was there. Maybe having two steps could make it clearer for people that don't use these types of settings everyday  ?

The visual alignment isn't great, but I feel like it's belonging to the second step where you generate the actual token. I'll see if I can improve that.


GH-21815: [JS] Add support for Duration type

Rationale for this change
The Duration type is currently not supported and trying to deserialize a Table containing the type (e.g. using tableFromIPC) fails with Unrecognized type error. This PR aims to fix that.
What changes are included in this PR?

definition of the Duration data type
updates to the visitor classes so that things like parsing work correctly
test coverage for the type
documentation update

Are these changes tested?
Yes, I extended the data generator with the new type so that the type is tested by the existing tests.
Are there any user-facing changes?
Yes, I've updated the documentation status page. I also noticed that it was outdated for JavaScript, i.e. there is already support for Decimal type so I updated this as well.
Closes: https://github.com/apache/arrow/issues/21815
Closes: https://github.com/apache/arrow/issues/35439

Closes: #21815

Hm, looking into this made me find a copy-paste bug I made.

@FrNecas good point, I forgot they were used in other places. I'm not sure if TS would accept the wider types without testing. Even if it does, that seems like the sort of rule-bending that TS likes to break across releases, so what you have now is fine with me.

@FrNecas Can you also update the integration skips here so that we make sure JS interops with other implementations?
https://github.com/apache/arrow/blob/b9453a2a33e935e26dc8358846ad671aefdcb4d0/dev/archery/archery/integration/datagen.py#L1685-L1691

The integration CI job has failed for disk space issues, I have restarted it in the hope that it'll pass this time.

Looks like the NodeJS / AMD64 Debian 11 NodeJS 18 (pull_request) check timed out? But tests seem to be passing it just takes quite long 🤔

Ok, the integration tests failed with the JS handling of intervals...
https://github.com/apache/arrow/actions/runs/5966046880/job/16185712960?pr=37341#step:7:16341

Hm, ok, in that case let's mark intervals as unsupported and skip that test again for now and maybe create a separate issue to look into this

Could someone please try to re-run the one failing job? There doesn't seem to be anything actionable (looks like a timeout) and I think I saw this one fail already but then it passed later when it was re-run.

@github-actions crossbow submit js

Hello, is there anything else that I need to do in order for this PR to get merged? It's been some time since it was approved so I am wondering if it didn't slip through the cracks.

@FrNecas I just resolved the merge conflicts. If CI passes I think we should be good to merge @domoritz.


#379 Add AZURE_FUNCTION_URL as appSetting parameter

Purpose
@ross-p-smith Fixes problem described in issue: https://github.com/Azure-Samples/chat-with-your-data-solution-accelerator/issues/379

@microsoft-github-policy-service agree


shared/7_vpn-server/ | Pritunl VPN server MongoDB to AWS DocumentDB

Describe the Feature
Add 7_vpn-server-document-db use case based on https://github.com/binbashar/le-tf-infra-aws/tree/master/shared/7_vpn-server where Pritunl server MongoDB is hosted in AWS DocumentDB (https://aws.amazon.com/documentdb/) recommended module to fork -> https://registry.terraform.io/modules/cloudposse/documentdb-cluster/aws/0.3.0
Expected Behavior
Pritunl VPN server deployed in AWS EC2 + Pritunl MongoDB deployed in AWS DocumentDB
Use Case
Improve Pritunl DB availability, reliability and performance.
Describe Ideal Solution
Pritunl VPN Server via TF and Ansible where its MongoDb lives in DocumentDB

@diego-ojeda-binbash OJ I'm closing this issue since we're progressively attending potential improvements and upgrades based on our ongoing implementations and customer requirements. In case it's needed we can re visit this feature request.
CC: @binbashar/leverage-ref-architecture-aws-dev @binbashar/leverage-ref-architecture-aws-admin


Misc: MQTT running but all sensors showing as "Unknown"

I have configured everything as per the instructions/docs, and all was working fine. Recently, I have installed an SSL certificate and cloudflare tunnel, and now all of the sensors are showing as "Unknown", despite MQTT showing as "running".

same here. perhaps its outdated. last update 2022. i fear the project is dead.

I have installed an SSL certificate and cloudflare tunnel, and now all of the sensors are showing as "Unknown", despite MQTT showing as "running".

Most likely  when you installed those addons,  you had to restart HA. HASS.agent cannot reconnect to HA (at least for me it )  after HA is restarted.
You need to restart the agent on your Windows PC each time HA itself is restarted. This is the most annoying issue with HASS.agent for me.
I also have Cloudflare on my HA. It makes no difference for HASS.agent assuming your Windows PC is on local network and you are connecting to HA directly via HTTP.
There is some further recent development work of HASS.agent (fork) happening here:
https://github.com/hass-agent/HASS.Agent
but sadly no lack with resolving the "agent reconnection after HA restart" issue so far....

Most likely when you installed those addons, you had to restart HA. HASS.agent cannot reconnect to HA (at least for me it ) after HA is restarted. You need to restart the agent on your Windows PC each time HA itself is restarted. This is the most annoying issue with HASS.agent for me.

How do I "restart the agent" on my Windows PC? Is it just a matter of restarting the actual application, or is there something else I have to do?

In any case get the latest version of Hass.Agent (fork) from here:
Click here to download the latest installer
as per my post above.
From my experience it seems more stable/robust and able to recover from (some) HA restarts.

I tried restarting as you mentioned above, and installing the latest version, but my of the sensors are still showing as "Unknown", despite MQTT showing as "running".
Separately, do you know of any alternatives to HASS.Agent?
Ps. thanks for your help thus far!


cloudflare_access_rule does not update value after v3 release

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.1.0
on linux_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.6.0

Affected resource(s)
cloudflare_access_rule
Terraform configuration files
resource "cloudflare_access_rule" "fw_whitelist" {
  mode  = "whitelist"
  configuration {
    target = "ip"
    value  = "<IP_ADDRESS>"
  }
}

Debug output
Terraform will perform the following actions:

  # cloudflare_access_rule.fw_whitelist will be updated in-place
  ~ resource "cloudflare_access_rule" "fw_whitelist" {
        id   = "08ed90275a3246019129200a5a69b1f2"
        # (1 unchanged attribute hidden)

      ~ configuration {
          ~ value  = "<IP_ADDRESS>" -> "<IP_ADDRESS>"
            # (1 unchanged attribute hidden)
        }
    }

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

terraform apply "geo.plan"
cloudflare_access_rule.fw_whitelist: Modifying... [id=08ed90275a3246019129200a5a69b1f2]
cloudflare_access_rule.fw_whitelist: Modifications complete after 6s [id=08ed90275a3246019129200a5a69b1f2]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Panic output
No response
Expected output
Initially IP address adds correctly to cloudflare_access_rule
Update of the resource shows successful status but does not apply changes
<IP_ADDRESS> => <IP_ADDRESS>
firewall/tools =>

Actual output

Steps to reproduce

Create and apply cloudflare_access_rule

resource "cloudflare_access_rule" "fw_whitelist" {
  mode  = "whitelist"
  configuration {
    target = "ip"
    value  = "<IP_ADDRESS>"
  }
}

Make changes to the IP and apply

resource "cloudflare_access_rule" "fw_whitelist" {
  mode  = "whitelist"
  configuration {
    target = "ip"
    value  = "<IP_ADDRESS>"
  }
}

Check actual status in CF console
Try to plan/apply again

Additional factoids
v2 of terraform-provider-cloudflare works well
References
No response

please provide the full TF_LOG=DEBUG output; this is missing the debug context to see what is happening.

Debug:
2021-12-28T15:26:50.446+0400 [INFO]  Terraform version: 1.1.0
2021-12-28T15:26:50.446+0400 [INFO]  Go runtime version: go1.17.2
2021-12-28T15:26:50.446+0400 [INFO]  CLI args: []string{"terraform", "apply"}
2021-12-28T15:26:50.446+0400 [DEBUG] Attempting to open CLI config file: /home/yury/.terraformrc
2021-12-28T15:26:50.446+0400 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2021-12-28T15:26:50.446+0400 [DEBUG] checking for credentials in "/home/yury/.terraform.d/plugins"
2021-12-28T15:26:50.446+0400 [DEBUG] checking for credentials in "/home/yury/.terraform.d/plugins/linux_amd64"
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] will search for provider plugins in /home/yury/.terraform.d/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory /home/yury/.local/share/terraform/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory /usr/share/ubuntu-xorg/terraform/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory /usr/local/share/terraform/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory /usr/share/terraform/plugins
2021-12-28T15:26:50.446+0400 [DEBUG] ignoring non-existing provider search directory /var/lib/snapd/desktop/terraform/plugins
2021-12-28T15:26:50.446+0400 [INFO]  CLI command args: []string{"apply"}
2021-12-28T15:26:50.447+0400 [DEBUG] New state was assigned lineage "387f1401-768c-e53c-7136-849bab25dc22"
2021-12-28T15:26:50.509+0400 [DEBUG] checking for provisioner in "."
2021-12-28T15:26:50.510+0400 [DEBUG] checking for provisioner in "/usr/local/bin"
2021-12-28T15:26:50.510+0400 [DEBUG] checking for provisioner in "/home/yury/.terraform.d/plugins"
2021-12-28T15:26:50.510+0400 [DEBUG] checking for provisioner in "/home/yury/.terraform.d/plugins/linux_amd64"
2021-12-28T15:26:50.510+0400 [INFO]  backend/local: starting Apply operation
2021-12-28T15:26:50.512+0400 [DEBUG] created provider logger: level=debug
2021-12-28T15:26:50.512+0400 [INFO]  provider: configuring client automatic mTLS
2021-12-28T15:26:50.526+0400 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0]
2021-12-28T15:26:50.526+0400 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15437
2021-12-28T15:26:50.526+0400 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0
2021-12-28T15:26:50.533+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: configuring server automatic mTLS: timestamp=2021-12-28T15:26:50.533+0400
2021-12-28T15:26:50.549+0400 [DEBUG] provider.terraform-provider-cloudflare_v3.6.0: plugin address: network=unix address=/tmp/plugin3116822727 timestamp=2021-12-28T15:26:50.549+0400
2021-12-28T15:26:50.549+0400 [DEBUG] provider: using plugin: version=5
2021-12-28T15:26:50.576+0400 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2021-12-28T15:26:50.577+0400 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15437
2021-12-28T15:26:50.577+0400 [DEBUG] provider: plugin exited
2021-12-28T15:26:50.577+0400 [DEBUG] Building and walking validate graph
2021-12-28T15:26:50.577+0400 [DEBUG] ProviderTransformer: "cloudflare_access_rule.fw_whitelist" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:50.577+0400 [DEBUG] ProviderTransformer: "data.cloudflare_zone.main" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: [var.cloudflare_account_id]
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "cloudflare_access_rule.fw_whitelist" references: []
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "data.cloudflare_zone.main" references: [var.domain_zone]
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "var.domain" references: []
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "var.cloudflare_account_id" references: []
2021-12-28T15:26:50.577+0400 [DEBUG] ReferenceTransformer: "var.domain_zone" references: []
2021-12-28T15:26:50.578+0400 [DEBUG] Starting graph walk: walkValidate
2021-12-28T15:26:50.578+0400 [DEBUG] created provider logger: level=debug
2021-12-28T15:26:50.578+0400 [INFO]  provider: configuring client automatic mTLS
2021-12-28T15:26:50.591+0400 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0]
2021-12-28T15:26:50.592+0400 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15453
2021-12-28T15:26:50.592+0400 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0
2021-12-28T15:26:50.598+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: configuring server automatic mTLS: timestamp=2021-12-28T15:26:50.597+0400
2021-12-28T15:26:50.611+0400 [DEBUG] provider.terraform-provider-cloudflare_v3.6.0: plugin address: address=/tmp/plugin4267451803 network=unix timestamp=2021-12-28T15:26:50.611+0400
2021-12-28T15:26:50.611+0400 [DEBUG] provider: using plugin: version=5
2021-12-28T15:26:50.643+0400 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2021-12-28T15:26:50.644+0400 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15453
2021-12-28T15:26:50.644+0400 [DEBUG] provider: plugin exited
2021-12-28T15:26:50.644+0400 [INFO]  backend/local: apply calling Plan
2021-12-28T15:26:50.644+0400 [DEBUG] Building and walking plan graph for NormalMode
2021-12-28T15:26:50.645+0400 [DEBUG] ProviderTransformer: "data.cloudflare_zone.main (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:50.645+0400 [DEBUG] ProviderTransformer: "cloudflare_access_rule.fw_whitelist (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: [var.cloudflare_account_id]
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "cloudflare_access_rule.fw_whitelist (expand)" references: []
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "data.cloudflare_zone.main (expand)" references: [var.domain_zone]
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "var.domain_zone" references: []
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "var.domain" references: []
2021-12-28T15:26:50.645+0400 [DEBUG] ReferenceTransformer: "var.cloudflare_account_id" references: []
2021-12-28T15:26:50.645+0400 [DEBUG] Starting graph walk: walkPlan
2021-12-28T15:26:50.645+0400 [DEBUG] created provider logger: level=debug
2021-12-28T15:26:50.645+0400 [INFO]  provider: configuring client automatic mTLS
2021-12-28T15:26:50.658+0400 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0]
2021-12-28T15:26:50.658+0400 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15466
2021-12-28T15:26:50.658+0400 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0
2021-12-28T15:26:50.663+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: configuring server automatic mTLS: timestamp=2021-12-28T15:26:50.663+0400
2021-12-28T15:26:50.676+0400 [DEBUG] provider.terraform-provider-cloudflare_v3.6.0: plugin address: address=/tmp/plugin724123362 network=unix timestamp=2021-12-28T15:26:50.676+0400
2021-12-28T15:26:50.676+0400 [DEBUG] provider: using plugin: version=5
2021-12-28T15:26:50.706+0400 [WARN]  ValidateProviderConfig from "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" changed the config value, but that value is unused
2021-12-28T15:26:50.707+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [INFO] Cloudflare Client configured for user:: timestamp=2021-12-28T15:26:50.707+0400
2021-12-28T15:26:50.707+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [INFO] Using specified account id c967910d169b331b6bd6459df38255eb in Cloudflare provider: timestamp=2021-12-28T15:26:50.707+0400
2021-12-28T15:26:50.707+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [INFO] Cloudflare Client configured for user:: timestamp=2021-12-28T15:26:50.707+0400
2021-12-28T15:26:50.707+0400 [INFO]  ReferenceTransformer: reference not found: "var.domain_zone"
2021-12-28T15:26:50.707+0400 [DEBUG] ReferenceTransformer: "data.cloudflare_zone.main" references: []
2021-12-28T15:26:50.709+0400 [DEBUG] ReferenceTransformer: "cloudflare_access_rule.fw_whitelist" references: []
cloudflare_access_rule.fw_whitelist: Refreshing state... [id=ef221374949a4bbc9ea8bc53ffe7dce3]
2021-12-28T15:26:50.713+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [DEBUG] Reading Zones: timestamp=2021-12-28T15:26:50.712+0400
2021-12-28T15:26:50.713+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/zones?name=yurets.pro&per_page=50 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.0 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.6.0
Authorization: Bearer some_token
Content-Type: application/json
Accept-Encoding: gzip

-----------------------------------------------------: timestamp=2021-12-28T15:26:50.713+0400
2021-12-28T15:26:50.964+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:50 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/accounts/c967910d169b331b6bd6459df38255eb/firewall/access_rules/rules/ef221374949a4bbc9ea8bc53ffe7dce3 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.0 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.6.0
Authorization: Bearer some_token
Content-Type: application/json
Accept-Encoding: gzip

-----------------------------------------------------: timestamp=2021-12-28T15:26:50.964+0400
2021-12-28T15:26:51.809+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:51 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6c4a6f9fed1ba816-IST
Content-Type: application/json
Date: Tue, 28 Dec 2021 11:26:51 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Expires: Sun, 25 Jan 1981 05:00:00 GMT
Pragma: no-cache
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhfE5PcBd8VJd; SameSite=Lax; path=/; expires=Tue, 28-Dec-21 13:56:52 GMT; HttpOnly
Set-Cookie: __cfruid=c42a87279a406f05fbdcdb349cdfb67c952d49ac-1640690811; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Strict-Transport-Security: max-age=31536000
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

{
 "result": [
  {
   "id": "198eb32d53f5c6a37b2acad091bdf6d9",
   "name": "yurets.pro",
   "status": "active",
   "paused": false,
   "type": "full",
   "development_mode": -37317629,
   "name_servers": [
    "abby.ns.cloudflare.com",
    "houston.ns.cloudflare.com"
   ],
   "original_name_servers": [
    "dns1.registrar-servers.com",
    "dns2.registrar-servers.com"
   ],
   "original_registrar": "namecheap, inc (id: 1068)",
   "original_dnshost": null,
   "modified_on": "2020-09-27T11:46:11.875141Z",
   "created_on": "2020-01-24T11:22:56.113819Z",
   "activated_on": "2020-01-24T11:30:30.853084Z",
   "meta": {
    "step": 2,
    "wildcard_proxiable": false,
    "custom_certificate_quota": 0,
    "page_rule_quota": 3,
    "phishing_detected": false,
    "multiple_railguns_allowed": false
   },
   "owner": {
    "id": "a8a8787a9ac632504fb8856c60dde6ac",
    "type": "user",
    "email"<EMAIL_ADDRESS>   },
   "account": {
    "id": "c967910d169b331b6bd6459df38255eb",
    "name"<EMAIL_ADDRESS>   },
   "permissions": [
    "#access:edit",
    "#access:read",
    "#analytics:read",
    "#app:edit",
    "#auditlogs:read",
    "#billing:edit",
    "#billing:read",
    "#cache_purge:edit",
    "#dns_records:edit",
    "#dns_records:read",
    "#image:edit",
    "#image:read",
    "#lb:edit",
    "#lb:read",
    "#legal:edit",
    "#legal:read",
    "#logs:edit",
    "#logs:read",
    "#member:edit",
    "#member:read",
    "#organization:edit",
    "#organization:read",
    "#ssl:edit",
    "#ssl:read",
    "#stream:edit",
    "#stream:read",
    "#subscription:edit",
    "#subscription:read",
    "#teams:edit",
    "#teams:pii",
    "#teams:read",
    "#teams:report",
    "#waf:edit",
    "#waf:read",
    "#webhooks:edit",
    "#webhooks:read",
    "#worker:edit",
    "#worker:read",
    "#zone:edit",
    "#zone:read",
    "#zone_settings:edit",
    "#zone_settings:read"
   ],
   "plan": {
    "id": "0feeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
    "name": "Free Website",
    "price": 0,
    "currency": "USD",
    "frequency": "",
    "is_subscribed": false,
    "can_subscribe": false,
    "legacy_id": "free",
    "legacy_discount": false,
    "externally_managed": false
   }
  }
 ],
 "result_info": {
  "page": 1,
  "per_page": 50,
  "total_pages": 1,
  "count": 1,
  "total_count": 1
 },
 "success": true,
 "errors": [],
 "messages": []
}
-----------------------------------------------------: timestamp=2021-12-28T15:26:51.808+0400
2021-12-28T15:26:52.322+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:52 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6c4a6fa17b0db02f-IST
Content-Type: application/json; charset=UTF-8
Date: Tue, 28 Dec 2021 11:26:52 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhfPn4czSd6a9; SameSite=Lax; path=/; expires=Tue, 28-Dec-21 13:56:53 GMT; HttpOnly
Set-Cookie: __cfruid=4cbe1e09fccc1c1eb5b5b4bb290daf8a20c377eb-1640690812; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 2

{
  "result": {
    "id": "ef221374949a4bbc9ea8bc53ffe7dce3",
    "paused": false,
    "modified_on": "2021-12-28T11:26:31.767649Z",
    "allowed_modes": [
      "whitelist",
      "block",
      "challenge",
      "js_challenge",
"managed_challenge"
    ],
    "mode": "whitelist",
    "notes": "",
    "configuration": {
      "target": "ip",
      "value": "<IP_ADDRESS>"
    },
    "scope": {
      "id": "a8a8787a9ac632504fb8856c60dde6ac",
      "email"<EMAIL_ADDRESS>      "type": "user"
    },
    "created_on": "2021-12-28T11:25:49.79785613Z"
  },
  "success": true,
  "errors": [],
  "messages": []
}

-----------------------------------------------------: timestamp=2021-12-28T15:26:52.321+0400
2021-12-28T15:26:52.322+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:52 [DEBUG] accessRuleResponse: &cloudflare.AccessRuleResponse{Result:cloudflare.AccessRule{ID:"ef221374949a4bbc9ea8bc53ffe7dce3", Notes:"", AllowedModes:[]string{"whitelist", "block", "challenge", "js_challenge", "managed_challenge"}, Mode:"whitelist", Configuration:cloudflare.AccessRuleConfiguration{Target:"ip", Value:"<IP_ADDRESS>"}, Scope:cloudflare.AccessRuleScope{ID:"a8a8787a9ac632504fb8856c60dde6ac"<EMAIL_ADDRESS>Name:"", Type:"user"}, CreatedOn:time.Date(2021, time.December, 28, 11, 25, 49, 797856130, time.UTC), ModifiedOn:time.Date(2021, time.December, 28, 11, 26, 31, 767649000, time.UTC)}, Response:cloudflare.Response{Success:true, Errors:[]cloudflare.ResponseInfo{}, Messages:[]cloudflare.ResponseInfo{}}, ResultInfo:cloudflare.ResultInfo{Page:0, PerPage:0, TotalPages:0, Count:0, Total:0, Cursor:"", Cursors:cloudflare.ResultInfoCursors{Before:"", After:""}}}: timestamp=2021-12-28T15:26:52.322+0400
2021-12-28T15:26:52.323+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:52 [DEBUG] accessRuleResponse error: <nil>: timestamp=2021-12-28T15:26:52.322+0400
2021-12-28T15:26:52.323+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:52 [DEBUG] Cloudflare Access Rule read configuration: &cloudflare.AccessRuleResponse{Result:cloudflare.AccessRule{ID:"ef221374949a4bbc9ea8bc53ffe7dce3", Notes:"", AllowedModes:[]string{"whitelist", "block", "challenge", "js_challenge", "managed_challenge"}, Mode:"whitelist", Configuration:cloudflare.AccessRuleConfiguration{Target:"ip", Value:"<IP_ADDRESS>"}, Scope:cloudflare.AccessRuleScope{ID:"a8a8787a9ac632504fb8856c60dde6ac"<EMAIL_ADDRESS>Name:"", Type:"user"}, CreatedOn:time.Date(2021, time.December, 28, 11, 25, 49, 797856130, time.UTC), ModifiedOn:time.Date(2021, time.December, 28, 11, 26, 31, 767649000, time.UTC)}, Response:cloudflare.Response{Success:true, Errors:[]cloudflare.ResponseInfo{}, Messages:[]cloudflare.ResponseInfo{}}, ResultInfo:cloudflare.ResultInfo{Page:0, PerPage:0, TotalPages:0, Count:0, Total:0, Cursor:"", Cursors:cloudflare.ResultInfoCursors{Before:"", After:""}}}: timestamp=2021-12-28T15:26:52.322+0400
2021-12-28T15:26:52.323+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:52 [DEBUG] read configuration: []interface {}{map[string]interface {}{"target":"ip", "value":"<IP_ADDRESS>"}}: timestamp=2021-12-28T15:26:52.322+0400
2021-12-28T15:26:52.331+0400 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_access_rule.fw_whitelist, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .notes: planned value cty.StringVal("") for a non-computed attribute
2021-12-28T15:26:52.333+0400 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2021-12-28T15:26:52.337+0400 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15466
2021-12-28T15:26:52.337+0400 [DEBUG] provider: plugin exited

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cloudflare_access_rule.fw_whitelist will be updated in-place
  ~ resource "cloudflare_access_rule" "fw_whitelist" {
        id   = "ef221374949a4bbc9ea8bc53ffe7dce3"
        # (1 unchanged attribute hidden)

      ~ configuration {
          ~ value  = "<IP_ADDRESS>" -> "<IP_ADDRESS>"
            # (1 unchanged attribute hidden)
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.
2021-12-28T15:26:52.338+0400 [DEBUG] command: asking for input: "\nDo you want to perform these actions?"

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

2021-12-28T15:26:59.013+0400 [INFO]  backend/local: apply calling Apply
2021-12-28T15:26:59.013+0400 [DEBUG] Building and walking apply graph for NormalMode plan
2021-12-28T15:26:59.015+0400 [DEBUG] ProviderTransformer: "data.cloudflare_zone.main (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:59.015+0400 [DEBUG] ProviderTransformer: "cloudflare_access_rule.fw_whitelist" (*terraform.NodeApplyableResourceInstance) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:59.015+0400 [DEBUG] ProviderTransformer: "cloudflare_access_rule.fw_whitelist (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "cloudflare_access_rule.fw_whitelist" references: []
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: [var.cloudflare_account_id]
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "cloudflare_access_rule.fw_whitelist (expand)" references: []
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "data.cloudflare_zone.main (expand)" references: []
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "var.domain_zone" references: []
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "var.domain" references: []
2021-12-28T15:26:59.016+0400 [DEBUG] ReferenceTransformer: "var.cloudflare_account_id" references: []
2021-12-28T15:26:59.017+0400 [DEBUG] pruneUnusedNodes: data.cloudflare_zone.main (expand) is no longer needed, removing
2021-12-28T15:26:59.019+0400 [DEBUG] Starting graph walk: walkApply
2021-12-28T15:26:59.020+0400 [DEBUG] created provider logger: level=debug
2021-12-28T15:26:59.020+0400 [INFO]  provider: configuring client automatic mTLS
2021-12-28T15:26:59.056+0400 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0]
2021-12-28T15:26:59.057+0400 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15518
2021-12-28T15:26:59.057+0400 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0
2021-12-28T15:26:59.064+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: configuring server automatic mTLS: timestamp=2021-12-28T15:26:59.064+0400
2021-12-28T15:26:59.076+0400 [DEBUG] provider.terraform-provider-cloudflare_v3.6.0: plugin address: address=/tmp/plugin203915624 network=unix timestamp=2021-12-28T15:26:59.076+0400
2021-12-28T15:26:59.076+0400 [DEBUG] provider: using plugin: version=5
2021-12-28T15:26:59.109+0400 [WARN]  ValidateProviderConfig from "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" changed the config value, but that value is unused
2021-12-28T15:26:59.110+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:59 [INFO] Cloudflare Client configured for user:: timestamp=2021-12-28T15:26:59.109+0400
2021-12-28T15:26:59.110+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:59 [INFO] Using specified account id c967910d169b331b6bd6459df38255eb in Cloudflare provider: timestamp=2021-12-28T15:26:59.110+0400
2021-12-28T15:26:59.110+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:59 [INFO] Cloudflare Client configured for user:: timestamp=2021-12-28T15:26:59.110+0400
2021-12-28T15:26:59.112+0400 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_access_rule.fw_whitelist, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .notes: planned value cty.StringVal("") for a non-computed attribute
cloudflare_access_rule.fw_whitelist: Modifying... [id=ef221374949a4bbc9ea8bc53ffe7dce3]
2021-12-28T15:26:59.113+0400 [INFO]  Starting apply for cloudflare_access_rule.fw_whitelist
2021-12-28T15:26:59.113+0400 [DEBUG] cloudflare_access_rule.fw_whitelist: applying the planned Update change
2021-12-28T15:26:59.114+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:26:59 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
PATCH /client/v4/accounts/c967910d169b331b6bd6459df38255eb/firewall/access_rules/rules/ef221374949a4bbc9ea8bc53ffe7dce3 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.0 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.6.0
Content-Length: 154
Authorization: Bearer some_token
Content-Type: application/json
Accept-Encoding: gzip

{
 "mode": "whitelist",
 "configuration": {
  "target": "ip",
  "value": "<IP_ADDRESS>"
 },
 "scope": {},
 "created_on": "0001-01-01T00:00:00Z",
 "modified_on": "0001-01-01T00:00:00Z"
}
-----------------------------------------------------: timestamp=2021-12-28T15:26:59.114+0400
2021-12-28T15:27:00.614+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:00 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6c4a6fd47aa7a7ec-IST
Content-Type: application/json; charset=UTF-8
Date: Tue, 28 Dec 2021 11:27:00 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhgjPSjSzZxiH; SameSite=Lax; path=/; expires=Tue, 28-Dec-21 13:57:01 GMT; HttpOnly
Set-Cookie: __cfruid=c681664d9a043e5215a04646de8b6be237e88803-1640690820; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 108

{
  "result": {
    "id": "ef221374949a4bbc9ea8bc53ffe7dce3",
    "paused": false,
    "modified_on": "2021-12-28T11:26:31.767649Z",
    "allowed_modes": [
      "whitelist",
      "block",
      "challenge",
      "js_challenge",
"managed_challenge"
    ],
    "mode": "whitelist",
    "notes": "",
    "configuration": {
      "target": "ip",
      "value": "<IP_ADDRESS>"
    },
    "scope": {
      "id": "a8a8787a9ac632504fb8856c60dde6ac",
      "email"<EMAIL_ADDRESS>      "type": "user"
    },
    "created_on": "2021-12-28T11:25:49.79785613Z"
  },
  "success": true,
  "errors": [],
  "messages": []
}

-----------------------------------------------------: timestamp=2021-12-28T15:27:00.614+0400
2021-12-28T15:27:00.614+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:00 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/accounts/c967910d169b331b6bd6459df38255eb/firewall/access_rules/rules/ef221374949a4bbc9ea8bc53ffe7dce3 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.0 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.6.0
Authorization: Bearer some_token
Content-Type: application/json
Accept-Encoding: gzip

-----------------------------------------------------: timestamp=2021-12-28T15:27:00.614+0400
2021-12-28T15:27:02.047+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:02 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6c4a6fddcdf7a7f2-IST
Content-Type: application/json; charset=UTF-8
Date: Tue, 28 Dec 2021 11:27:01 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU56Rb8iNWZVUvXhgu67kFp4Zyo; SameSite=Lax; path=/; expires=Tue, 28-Dec-21 13:57:02 GMT; HttpOnly
Set-Cookie: __cfruid=86a63566eb5a8a93ca996e26e04b2796b061da95-1640690821; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 2

{
  "result": {
    "id": "ef221374949a4bbc9ea8bc53ffe7dce3",
    "paused": false,
    "modified_on": "2021-12-28T11:27:00.275853Z",
    "allowed_modes": [
      "whitelist",
      "block",
      "challenge",
      "js_challenge",
"managed_challenge"
    ],
    "mode": "whitelist",
    "notes": "",
    "configuration": {
      "target": "ip",
      "value": "<IP_ADDRESS>"
    },
    "scope": {
      "id": "a8a8787a9ac632504fb8856c60dde6ac",
      "email"<EMAIL_ADDRESS>      "type": "user"
    },
    "created_on": "2021-12-28T11:25:49.79785613Z"
  },
  "success": true,
  "errors": [],
  "messages": []
}

-----------------------------------------------------: timestamp=2021-12-28T15:27:02.047+0400
2021-12-28T15:27:02.048+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:02 [DEBUG] accessRuleResponse: &cloudflare.AccessRuleResponse{Result:cloudflare.AccessRule{ID:"ef221374949a4bbc9ea8bc53ffe7dce3", Notes:"", AllowedModes:[]string{"whitelist", "block", "challenge", "js_challenge", "managed_challenge"}, Mode:"whitelist", Configuration:cloudflare.AccessRuleConfiguration{Target:"ip", Value:"<IP_ADDRESS>"}, Scope:cloudflare.AccessRuleScope{ID:"a8a8787a9ac632504fb8856c60dde6ac"<EMAIL_ADDRESS>Name:"", Type:"user"}, CreatedOn:time.Date(2021, time.December, 28, 11, 25, 49, 797856130, time.UTC), ModifiedOn:time.Date(2021, time.December, 28, 11, 27, 0, 275853000, time.UTC)}, Response:cloudflare.Response{Success:true, Errors:[]cloudflare.ResponseInfo{}, Messages:[]cloudflare.ResponseInfo{}}, ResultInfo:cloudflare.ResultInfo{Page:0, PerPage:0, TotalPages:0, Count:0, Total:0, Cursor:"", Cursors:cloudflare.ResultInfoCursors{Before:"", After:""}}}: timestamp=2021-12-28T15:27:02.047+0400
2021-12-28T15:27:02.048+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:02 [DEBUG] accessRuleResponse error: <nil>: timestamp=2021-12-28T15:27:02.047+0400
2021-12-28T15:27:02.048+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:02 [DEBUG] Cloudflare Access Rule read configuration: &cloudflare.AccessRuleResponse{Result:cloudflare.AccessRule{ID:"ef221374949a4bbc9ea8bc53ffe7dce3", Notes:"", AllowedModes:[]string{"whitelist", "block", "challenge", "js_challenge", "managed_challenge"}, Mode:"whitelist", Configuration:cloudflare.AccessRuleConfiguration{Target:"ip", Value:"<IP_ADDRESS>"}, Scope:cloudflare.AccessRuleScope{ID:"a8a8787a9ac632504fb8856c60dde6ac"<EMAIL_ADDRESS>Name:"", Type:"user"}, CreatedOn:time.Date(2021, time.December, 28, 11, 25, 49, 797856130, time.UTC), ModifiedOn:time.Date(2021, time.December, 28, 11, 27, 0, 275853000, time.UTC)}, Response:cloudflare.Response{Success:true, Errors:[]cloudflare.ResponseInfo{}, Messages:[]cloudflare.ResponseInfo{}}, ResultInfo:cloudflare.ResultInfo{Page:0, PerPage:0, TotalPages:0, Count:0, Total:0, Cursor:"", Cursors:cloudflare.ResultInfoCursors{Before:"", After:""}}}: timestamp=2021-12-28T15:27:02.047+0400
2021-12-28T15:27:02.048+0400 [INFO]  provider.terraform-provider-cloudflare_v3.6.0: 2021/12/28 15:27:02 [DEBUG] read configuration: []interface {}{map[string]interface {}{"target":"ip", "value":"<IP_ADDRESS>"}}: timestamp=2021-12-28T15:27:02.048+0400
2021-12-28T15:27:02.048+0400 [WARN]  Provider "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" produced an unexpected new value for cloudflare_access_rule.fw_whitelist, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .configuration[0].value: was cty.StringVal("<IP_ADDRESS>"), but now cty.StringVal("<IP_ADDRESS>")
cloudflare_access_rule.fw_whitelist: Modifications complete after 3s [id=ef221374949a4bbc9ea8bc53ffe7dce3]
2021-12-28T15:27:02.060+0400 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2021-12-28T15:27:02.062+0400 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.6.0/linux_amd64/terraform-provider-cloudflare_v3.6.0 pid=15518
2021-12-28T15:27:02.062+0400 [DEBUG] provider: plugin exited

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Seems like DEBUG shows the root cause:
 [WARN]  Provider "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" produced an unexpected new value for cloudflare_access_rule.fw_whitelist, but we are tolerating it because it is using the legacy plugin SDK.

that line is unrelated; the issue is that for some reason the correct configuration is sent, however, it is not updating the correct rule in the API. you can see this by the fact we sent <IP_ADDRESS> but get back <IP_ADDRESS> again. can you delete the rule in the UI and Terraform and recreate the rule only using Terraform?

Nothing is done in UI
All steps are terraform only

Wouldn't the following in the PATCH API call cause problems because they don't match?
 "created_on": "0001-01-01T00:00:00Z",
 "modified_on": "0001-01-01T00:00:00Z"

I think the question is where those are coming from ...

Up

Trying to update IP address via API (https://api.cloudflare.com/#account-level-firewall-access-rule-update-access-rule) but without luck.
Can update only "notes".
Seems this is API limitation.


Misc. test cleanup

Followup to #14834
No need to create a server, guid, zone
The name of the method being tested should be displayed
Expect :has_attribute?, it's important

Thanks @isimluk I thought I had verified that.  Since it feels important, I added it back as an expect.

Fine backport details:
$ git log -1
commit 1d1ead8dca51419410563d9d577f947be863151f
Author: Šimon Lukašík<EMAIL_ADDRESS>Date:   Wed Apr 26 12:05:58 2017 +0200

    Merge pull request #14869 from bdunne/cleanup_test

    Misc. test cleanup
    (cherry picked from commit 2cd30b6aa9180b164d7385ab1ef0deb9f9851eae)


Adding direction to overscanIndicesGetter

Fixes #627 by adding direction to the overscanIndicesGetter

Mind updating the docs as well to list the new parameter? 😄

Like that?

Thanks, but not quite. Update the section below that the hyperlink refers to (#overscanindicesgetter)

Im sorry, I dont understand. Im happy to make a change if you can elaborate.

I was just clarifying that- by enabling horizontal scrolling- you're using List in a way it's not intended to be used. It's great that everything works (excepting this). I just wanted that clarification.
The reference I made about width being 100% is here.

Brian, I think we got our conversations mixed. This pull request is for my upgrade to the overscanIndicesGetter. Your last comment seems like it was meant for issue #630.   Im happy to update this pull request with better documentation of you can elaborate on what changes you want me to make.

lol yes sorry. I was responding via email client and I assumed your response was to my most recent comment on the issue. Sorry!
Go look at the Grid props docs. Specifically, the overscanIndicesGetter property doesn't defines its interface inline b'c it's hard to read. Instead it links to a separate section. I was requesting you put the interface/params list there. This is similar to how other props (eg cellRenderer) are done. 😄

👍  Thanks

9.4.0 was just released with this feature. Thank you for your contribution! I listed you in the 9.4.0 release notes.


hub makes --help impossible

hub seems to mask some common git functionality, e.g. showing the man pages using --help:
$ hub --version
git version 2.2.1
hub version 2.2.0-rc1-gfd6e2e3

$ hub apply --help
fatal: can't open patch 'help': No such file or directory

While this obviously works:
$ git apply --help   # shows man page

Thanks!


add spellChecker

finding candidates for misspelled words

what will you do with false positives?
I t think this is a great feature,. but for another tool/checker...

this would be a nice feature for a sonarqube plugin...
btw: this is already on my docToolchain feature list among with features like a readability and sentence complexity score...

in my opinion "sanity" includes various aspects, and "spelling" or other linguistic stuff can be seen among those.
You're perfectly right - it's gonna be really difficult, and imho will require enhancing the possible checking results (as spellchecks produce more suggestions or hints than errors...)

absolutly, sanity is also spellcheck. my comment was more about the type of check we currently have - which is basically unit testing.
maybe the spellcheck could be a sonarqube plugin hosted under the htmlsanitychecker umbrella?

one idea could be to provide a separate repo/project for the SonarQube plugin, which utilizes the HtmlSanityChecker "business logic"...