if post_date is within fifteen minutes of current time, use Medium time

Hello @amyquispe, @benmedium, @mikkot,
Please review the following commits I made in branch 'huckphin/fix-cross-post'.
e77628e2b9d19832800ec8c69e737b914ac303a1 (2016-07-28 13:50:07 -0700)
if post_date is within fifteen minutes of current time, use Medium time
There were reports of publishing with a cross-post failing. It turns out
that if you are even a second ahead of the Medium servers, the post will
fail to cross-post due to "posting in the future". If the post_date is
within 15 minutes of current time, remove the "publishedAt" attribute in
the POST body, and just use Medium server time for the actual post datetime.
Fixes https://github.com/Medium/medium-wordpress-plugin/issues/106
R=@amyquispe
R=@benmedium
R=@mikkot

lgtm


Set cwd on babel-loader

Fixes #5125

Talked with @loganfsmyth and came to the conclusion that adding cwd: dir is the way to go for making babel resolve the root correctly.


[PE-D] Target user and problem not clearly defined in UG

The target user for the product and/or the value proposition is not specified clearly.

Labels: type.DocumentationBug severity.Low
original: bernardwan/ped#9

DG


Add version: JetBrains.Kotlin.Compiler version 1.8.20

Pull request has been created with Komac v1.9.1 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116167&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Executable-Error


Update maturin

Description
We can now use the latest version of maturin (with this pre-release).
Affected Dependencies
maturin==0.8.2 -> maturin==0.11.4b5
How has this been tested?
This was tested locally.
Checklist

[x] I have followed the Contribution Guidelines and Code of Conduct
[x] I have commented my code following the OpenMined Styleguide
[x] I have labeled this PR with the relevant Type labels
[x] My changes are covered by tests

Probably unnecessary for now since Maturin 0.8.2 works fine. But feel free to reopen a PR if Maturin has a stable release that is clearly better than 0.8.2 :slightly_smiling_face:


Capture memory profile and eliminate unnecessary allocations

We should look at our primary scenarios, perhaps those defined for our TE-style benchmarks https://github.com/microsoft/reverse-proxy/issues/40, and capture a memory profile so we can eliminate unnecessary allocations and improve performance.

I've started collecting memory profiles. So far, most of the allocations are more-or-less what we expected. A lot of string and dictionary entry allocations related to copying headers back and forth. Initially, there's also a lot of byte[] allocations as the memory pool grows to facilitate response body stream copying.
The most surprising allocation that I've noticed at this point is Kestrel allocating byte arrays via System.Text.Encoding.GetBytes() to generate HTTP status reason phrases. Normally, Kestrel would not call GetBytes() for reason phrases and instead use a cached default value corresponding with the response's status code. YARP, explicitly sets the reason phrase however, which bypasses this optimization.
It probably makes sense for YARP to set the reason phrase if it's not the default for the returned status code, but it could skip the allocation otherwise by just not specifying the reason phrase when it the default for the returned status code which should be the vast majority of cases.
I'll look at submitting a PR to address this.

Memory profile screenshots

It probably makes sense for YARP to set the reason phrase if it's not the default for the returned status code, but it could skip the allocation otherwise by just not specifying the reason phrase when it the default for the returned status code which should be the vast majority of cases.

That sounds like an optimization for Kestrel, not YARP. YARP is doing a blind copy of the response structure, it can't tell if the destination server actually specified a reason phrase or if it's returning a default value. That would require it to know which values were considered defaults for both HttpResponseMessage and Kestrel (they might not even align).
Kestrel should check for values that it has pre-encoded replacements for before invoking the encoder.

How should we be thinking about the impact of the allocations?
33 allocations for the bodies are half the memory - but the 33 count is low, so it seems to not be churning them.
For things like string where there are hundreds of thousands of allocations - presumably we want to see the count and if something can be done to reduce those?

Both YARP or Kestrel could do the same lookup to see and elide the allocation if the custom-set reason phrase is the default value for status code, but I feel it would be wasteful for Kestrel to do in non-proxy scenarios. I cannot think of any reason to manually set the default reason phrase in addition to just setting the response status code outside of proxying. That being said, setting a reason phrase at all is a niche scenario, so it's not like the extra lookup in Kestrel would affect our plaintext and json benchmarks.

How should we be thinking about the impact of the allocations?

I would mostly ignore the byte[] allocations that are renting from a memory pool like the 33 allocations for response body copying.
Normally, I would start collecting traces after a warmup to ignore these allocations, but VS forces you to start collecting at process start. I think I still messed up though, because I could have selected the post-warmup section of the benchmark timeline before digging into the allocations.

Maybe the better question is what are the allocation counts on a per request basis. How many requests does your tracing cover? Is there a way of breaking it down further to what are the costs per header for example?

I should have recorded the output from bombardier which would tell you the number of request.
Still, you can infer the number of requests from the memory profile. In the first screenshot, you see a lot of objects were allocated exactly 19,866 times. Those are objects that were allocated once per request. So there were ~20,000 requests measured.

Is there a way of breaking it down further to what are the costs per header for example?

If we want to do that, I would probably compare memory profiles from a scenario with 4 request headers and 8 request headers of similar sizes. We could do the same thing for response headers.

@halter73 did you use the number of requests feature of bombardier? 😄

No. I just did the following which defaults to sending requests as fast as possible (without pipelining) for 10 seconds:
> bombardier-windows-amd64.exe -c 256 http://localhost:5000/api/dump

bombardier-windows-amd64.exe --help
> bombardier-windows-amd64.exe --help
usage: F:\Downloads\bombardier-windows-amd64.exe [<flags>] <url>

Fast cross-platform HTTP benchmarking tool

Flags:
      --help                  Show context-sensitive help (also try --help-long
                              and --help-man).
      --version               Show application version.
  -c, --connections=125       Maximum number of concurrent connections
  -t, --timeout=2s            Socket/request timeout
  -l, --latencies             Print latency statistics
  -m, --method=GET            Request method
  -b, --body=""               Request body
  -f, --body-file=""          File to use as request body
  -s, --stream                Specify whether to stream body using chunked
                              transfer encoding or to serve it from memory
      --cert=""               Path to the client's TLS Certificate
      --key=""                Path to the client's TLS Certificate Private Key
  -k, --insecure              Controls whether a client verifies the server's
                              certificate chain and host name
  -H, --header="K: V" ...     HTTP headers to use(can be repeated)
  -n, --requests=[pos. int.]  Number of requests
  -d, --duration=10s          Duration of test
  -r, --rate=[pos. int.]      Rate limit in requests per second
      --fasthttp              Use fasthttp client
      --http1                 Use net/http client with forced HTTP/1.x
      --http2                 Use net/http client with enabled HTTP/2.0
  -p, --print=<spec>          Specifies what to output. Comma-separated list of
                              values 'intro' (short: 'i'), 'progress' (short:
                              'p'), 'result' (short: 'r'). Examples:

                                * i,p,r (prints everything)
                                * intro,result (intro & result)
                                * r (result only)
                                * result (same as above)
  -q, --no-print              Don't output anything
  -o, --format=<spec>         Which format to use to output the result. <spec>
                              is either a name (or its shorthand) of some format
                              understood by bombardier or a path to the
                              user-defined template, which uses Go's
                              text/template syntax, prefixed with 'path:' string
                              (without single quotes), i.e.
                              "path:/some/path/to/your.template" or
                              "path:C:\some\path\to\your.template" in case of
                              Windows. Formats understood by bombardier are:

                                * plain-text (short: pt)
                                * json (short: j)

Args:
  <url>  Target's URL

NP, this profile is great (@halter73 shared it with me). There's SO much low hanging fruit which is good news.  Regardless, now we have a baseline

The bad news is a bunch of it might be because of API design

@davidfowl care to share a some of the highlights?

@sebastienros is this a task you can take over from Stephen? I think we're ready to do a first pass on the main request pipeline.

Sure. Do you want me to do it or is there someone in the team that wants to try it and just needs me to show how to

get a trace
do changes and see progress
repeat

Can you take a first pass at some of the middleware components?
https://github.com/microsoft/reverse-proxy/tree/master/src/ReverseProxy/Middleware

@alnikola @MihaZupan this issue tracks some of your current perf tasks.

@MihaZupan is there anything left here?


bosh agent reports unresponsive when monit crashes

Describe the bug
When monit is not running, bosh instances reports the agent as unresponsive.
Examining the logs, the agent tries 20 times to connect to monit, writes {"state":"unknown"} to /var/vcap/instance/health.json and sends an hm heartbeat, but does not respond to the director get_state request.
To Reproduce

Create a bosh release with a syntax error in the monit file
Deploy job to a VM
bosh instances -fp returns "unresponsive agent"

Expected behavior
bosh instances -fp should indicate that the job is not running and/or that monit is not running. More broadly, the agent should be able to report an informative status when monit is unable to (e.g. due to pre-start failures, monit erb error, invalid monit syntax, or monit not running)
Logs
Bosh agent logs:
2019-05-14_15:48:54.97376 [monitJobSupervisor] 2019/05/14 15:48:54 DEBUG - Getting monit status
2019-05-14_15:48:54.97380 [http-client] 2019/05/14 15:48:54 DEBUG - status function called
2019-05-14_15:48:54.97380 [http-client] 2019/05/14 15:48:54 DEBUG - Monit request: url='http://<IP_ADDRESS>:2822/_status2?format=xml' body=''
2019-05-14_15:48:54.97381 [attemptRetryStrategy] 2019/05/14 15:48:54 DEBUG - Making attempt #0 for *httpclient.RequestRetryable
2019-05-14_15:48:54.97381 [clientRetryable] 2019/05/14 15:48:54 DEBUG - [requestID=ab163774-1ef0-462e-7cc7-5bc96359d19b] Requesting (attempt=1): Request{ Method: 'GET', URL: 'http://<IP_ADDRESS>:2822/_status2?format=xml' }
2019-05-14_15:48:55.97431 [attemptRetryStrategy] 2019/05/14 15:48:55 DEBUG - Making attempt #1 for *httpclient.RequestRetryable
... attempts 2-19 ...
2019-05-14_15:49:13.98485 [clientRetryable] 2019/05/14 15:49:13 DEBUG - [requestID=ab163774-1ef0-462e-7cc7-5bc96359d19b] Requesting (attempt=20): Request{ Method: 'GET', URL: 'http://<IP_ADDRESS>:2822/_status2?format=xml' }
2019-05-14_15:49:14.98639 [agent] 2019/05/14 15:49:14 DEBUG - Building heartbeat
2019-05-14_15:49:14.98642 [File System] 2019/05/14 15:49:14 DEBUG - Checking if file exists /var/vcap/bosh/spec.json
2019-05-14_15:49:14.98642 [File System] 2019/05/14 15:49:14 DEBUG - Stat '/var/vcap/bosh/spec.json'
2019-05-14_15:49:14.98643 [File System] 2019/05/14 15:49:14 DEBUG - Reading file /var/vcap/bosh/spec.json
2019-05-14_15:49:14.98643 [File System] 2019/05/14 15:49:14 DEBUG - Read content
2019-05-14_15:49:14.98643 ********************
... job properties ...
2019-05-14_15:49:14.98646 ********************
2019-05-14_15:49:14.98647 [File System] 2019/05/14 15:49:14 DEBUG - Writing /var/vcap/instance/health.json
2019-05-14_15:49:14.98647 [File System] 2019/05/14 15:49:14 DEBUG - Making dir /var/vcap/instance with perm 0777
2019-05-14_15:49:14.98647 [File System] 2019/05/14 15:49:14 DEBUG - Write content
2019-05-14_15:49:14.98647 ********************
2019-05-14_15:49:14.98647 {"state":"unknown"}
2019-05-14_15:49:14.98647 ********************
2019-05-14_15:49:14.98648 [NATS Handler] 2019/05/14 15:49:14 INFO - Sending hm message 'heartbeat'
2019-05-14_15:49:14.98648 [NATS Handler] 2019/05/14 15:49:14 DEBUG - Message Payload
2019-05-14_15:49:14.98649 ********************
2019-05-14_15:49:14.98649 {"deployment":"thing2","job":"oscap_1","index":1,"job_state":"unknown","vitals":{"cpu":{"sys":"0.6","user":"0.2","wait":"0.0"},"disk":{"ephemeral":{"inode_percent":"1","percent":"4"},"system":{"inode_percent":"37","percent":"54"}},"load":["0.00","0.00","0.00"],"mem":{"kb":"360276","percent":"10"},"swap":{"kb":"0","percent":"0"},"uptime":{"secs":4471}},"node_id":"0d0fdaed-dd55-482b-8235-574109c64a8b"}
2019-05-14_15:49:14.98649 ********************
2019-05-14_15:49:14.98649 [Cmd Runner] 2019/05/14 15:49:14 DEBUG - Running command 'route -n'
2019-05-14_15:49:14.98744 [Cmd Runner] 2019/05/14 15:49:14 DEBUG - Successful: true (0)

monit summary
/var/vcap/monit/job/0001_job.monitrc:4: Error: syntax error 'uid'
task debug logs
Using environment 'https://<IP_ADDRESS>:25555' as client 'admin'

Task 104

I, [2019-05-14T15:26:34.017370 #16] [0x3fac4c195734]  INFO -- TaskHelper: Director Version: 268.6.0
I, [2019-05-14T15:26:34.017439 #16] [0x3fac4c195734]  INFO -- TaskHelper: Enqueuing task: 104
I, [2019-05-14T15:26:34.697751 #12941] []  INFO -- DirectorJobRunner: Looking for task with task id 104
D, [2019-05-14T15:26:34.700718 #12941] [] DEBUG -- DirectorJobRunner: (0.000377s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "tasks" WHERE "id" = 104
I, [2019-05-14T15:26:34.701926 #12941] []  INFO -- DirectorJobRunner: Found task #<Bosh::Director::Models::Task @values={:id=>104, :state=>"processing", :timestamp=>2019-05-14 15:26:34 UTC, :description=>"retrieve vm-stats", :result=>nil, :output=>"/var/vcap/store/director/tasks/104", :checkpoint_time=>2019-05-14 15:26:34 UTC, :type=>"vms", :username=>"admin", :deployment_name=>"thing2", :started_at=>nil, :event_output=>"", :result_output=>"", :context_id=>""}>
I, [2019-05-14T15:26:34.702002 #12941] []  INFO -- DirectorJobRunner: Running from worker 'worker_3' on director/d8a42d2a-65c4-4470-47d6-3dafab3d74bf (<IP_ADDRESS>)
I, [2019-05-14T15:26:34.702040 #12941] []  INFO -- DirectorJobRunner: Starting task: 104
I, [2019-05-14T15:26:34.702104 #12941] [task:104]  INFO -- DirectorJobRunner: Creating job
D, [2019-05-14T15:26:34.702670 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000219s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "tasks" WHERE "id" = 104
D, [2019-05-14T15:26:34.703501 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000177s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "tasks" WHERE "id" = 104
I, [2019-05-14T15:26:34.707627 #12941] [task:104]  INFO -- DirectorJobRunner: Performing task: #<Bosh::Director::Models::Task @values={:id=>104, :state=>"processing", :timestamp=>2019-05-14 15:26:34 UTC, :description=>"retrieve vm-stats", :result=>nil, :output=>"/var/vcap/store/director/tasks/104", :checkpoint_time=>2019-05-14 15:26:34 UTC, :type=>"vms", :username=>"admin", :deployment_name=>"thing2", :started_at=>nil, :event_output=>"", :result_output=>"", :context_id=>""}>
D, [2019-05-14T15:26:34.708461 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000069s) (conn:<PHONE_NUMBER>1140) BEGIN
D, [2019-05-14T15:26:34.710227 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000421s) (conn:<PHONE_NUMBER>1140) UPDATE "tasks" SET "state" = 'processing', "timestamp" = '2019-05-14 15:26:34.707682+0000', "description" = 'retrieve vm-stats', "result" = NULL, "output" = '/var/vcap/store/director/tasks/104', "checkpoint_time" = '2019-05-14 15:26:34.707934+0000', "type" = 'vms', "username" = 'admin', "deployment_name" = 'thing2', "started_at" = '2019-05-14 15:26:34.707849+0000', "event_output" = '', "result_output" = '', "context_id" = '' WHERE ("id" = 104)
D, [2019-05-14T15:26:34.711768 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.001334s) (conn:<PHONE_NUMBER>1140) COMMIT
D, [2019-05-14T15:26:34.713622 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.001051s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "instances" WHERE ("deployment_id" = 2)
D, [2019-05-14T15:26:34.713878 #12941] [task:104] DEBUG -- DirectorJobRunner: Creating new thread
D, [2019-05-14T15:26:34.714066 #12941] [task:104] DEBUG -- DirectorJobRunner: Creating new thread
D, [2019-05-14T15:26:34.715802 #12941] [task:104] DEBUG -- DirectorJobRunner: Creating new thread
D, [2019-05-14T15:26:34.715960 #12941] [task:104] DEBUG -- DirectorJobRunner: All threads are currently busy, queuing action
D, [2019-05-14T15:26:34.716034 #12941] [task:104] DEBUG -- DirectorJobRunner: All threads are currently busy, queuing action
D, [2019-05-14T15:26:34.716090 #12941] [task:104] DEBUG -- DirectorJobRunner: Waiting for tasks to complete
D, [2019-05-14T15:26:34.719072 #12941] [] DEBUG -- DirectorJobRunner: (0.000542s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "vms" WHERE (("instance_id" = 52) AND ("active" IS TRUE)) LIMIT 1
D, [2019-05-14T15:26:34.722237 #12941] [] DEBUG -- DirectorJobRunner: (0.000442s) (conn:<PHONE_NUMBER>6460) SET standard_conforming_strings = ON
D, [2019-05-14T15:26:34.722795 #12941] [] DEBUG -- DirectorJobRunner: (0.000286s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "instances" WHERE "id" = 52
D, [2019-05-14T15:26:34.722957 #12941] [] DEBUG -- DirectorJobRunner: (0.000623s) (conn:<PHONE_NUMBER>6460) SET client_min_messages = 'WARNING'
D, [2019-05-14T15:26:34.723096 #12941] [] DEBUG -- DirectorJobRunner: (0.000082s) (conn:<PHONE_NUMBER>6460) SET DateStyle = 'ISO'
D, [2019-05-14T15:26:34.728979 #12941] [] DEBUG -- DirectorJobRunner: (0.005794s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "vms" WHERE (("instance_id" = 53) AND ("active" IS TRUE)) LIMIT 1
D, [2019-05-14T15:26:34.726829 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.81c0b6b2-f284-4c43-9dc6-deeed8cf481b {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.81c0b6b2-f284-4c43-9dc6-deeed8cf481b.162e66fc-82d7-482d-b6ea-aaf2f83db46f"}
D, [2019-05-14T15:26:34.738630 #12941] [] DEBUG -- DirectorJobRunner: (0.000406s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "instances" WHERE "id" = 53
D, [2019-05-14T15:26:34.739171 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.509dc7ee-76fb-42a8-b658-61b6d84497f2 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.509dc7ee-76fb-42a8-b658-61b6d84497f2.daf23c86-fad5-4f68-ad54-e245457b03a6"}
D, [2019-05-14T15:26:34.739453 #12941] [] DEBUG -- DirectorJobRunner: (0.009702s) (conn:<PHONE_NUMBER>8680) SET standard_conforming_strings = ON
D, [2019-05-14T15:26:34.741144 #12941] [] DEBUG -- DirectorJobRunner: (0.001589s) (conn:<PHONE_NUMBER>8680) SET client_min_messages = 'WARNING'
D, [2019-05-14T15:26:34.741328 #12941] [] DEBUG -- DirectorJobRunner: (0.000098s) (conn:<PHONE_NUMBER>8680) SET DateStyle = 'ISO'
D, [2019-05-14T15:26:34.742570 #12941] [] DEBUG -- DirectorJobRunner: (0.001123s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "vms" WHERE (("instance_id" = 55) AND ("active" IS TRUE)) LIMIT 1
D, [2019-05-14T15:26:34.744115 #12941] [] DEBUG -- DirectorJobRunner: (0.000792s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "instances" WHERE "id" = 55
D, [2019-05-14T15:26:34.744587 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.c7a4646f-dbc7-4bf5-8097-59cd8c620908 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.c7a4646f-dbc7-4bf5-8097-59cd8c620908.dafb2966-4655-4e39-abae-e9018db2d43f"}
D, [2019-05-14T15:26:39.727277 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.81c0b6b2-f284-4c43-9dc6-deeed8cf481b {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.81c0b6b2-f284-4c43-9dc6-deeed8cf481b.4a3aba39-fb87-423d-bd62-806466c45357"}
D, [2019-05-14T15:26:39.739650 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.509dc7ee-76fb-42a8-b658-61b6d84497f2 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.509dc7ee-76fb-42a8-b658-61b6d84497f2.4e46b593-d06a-4e28-adc8-40d8920407bd"}
D, [2019-05-14T15:26:39.744900 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.c7a4646f-dbc7-4bf5-8097-59cd8c620908 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.c7a4646f-dbc7-4bf5-8097-59cd8c620908.8d7f7493-586b-4813-85a9-435e21dec058"}
D, [2019-05-14T15:26:44.727764 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.81c0b6b2-f284-4c43-9dc6-deeed8cf481b {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.81c0b6b2-f284-4c43-9dc6-deeed8cf481b.b1db7267-800a-4100-9616-ce80ea37a363"}
D, [2019-05-14T15:26:44.739991 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.509dc7ee-76fb-42a8-b658-61b6d84497f2 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.509dc7ee-76fb-42a8-b658-61b6d84497f2.821ea3cc-3400-4336-817c-bcc23f9cf721"}
D, [2019-05-14T15:26:44.746529 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.c7a4646f-dbc7-4bf5-8097-59cd8c620908 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.c7a4646f-dbc7-4bf5-8097-59cd8c620908.fac8ac4c-5a12-4d51-8ecd-8dc3694fcbf3"}
D, [2019-05-14T15:26:49.731612 #12941] [] DEBUG -- DirectorJobRunner: (0.000611s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE (("active" IS TRUE) AND ("name" = '') AND ("persistent_disks"."instance_id" = 52)) LIMIT 1
D, [2019-05-14T15:26:49.733439 #12941] [] DEBUG -- DirectorJobRunner: (0.000385s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "persistent_disks" WHERE ("persistent_disks"."instance_id" = 52)
D, [2019-05-14T15:26:49.734901 #12941] [] DEBUG -- DirectorJobRunner: (0.000454s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "ip_addresses" WHERE ("ip_addresses"."vm_id" = 58)
D, [2019-05-14T15:26:49.736278 #12941] [] DEBUG -- DirectorJobRunner: (0.000053s) (conn:<PHONE_NUMBER>8680) BEGIN
D, [2019-05-14T15:26:49.737730 #12941] [] DEBUG -- DirectorJobRunner: (0.000963s) (conn:<PHONE_NUMBER>8680) UPDATE "tasks" SET "result_output" = ("result_output" || '{"vm_cid":"vm-30739d56-c9ab-4976-5bfc-b1b2f05e2926","active":true,"vm_created_at":"2019-05-14T14:35:02Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"81c0b6b2-f284-4c43-9dc6-deeed8cf481b","job_name":"oscap-store","index":0,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"95656008-500a-479e-8280-50d8a8663ad5","bootstrap":true,"ignore":false}
') WHERE ("id" = 104)
D, [2019-05-14T15:26:49.739099 #12941] [] DEBUG -- DirectorJobRunner: (0.001229s) (conn:<PHONE_NUMBER>8680) COMMIT
D, [2019-05-14T15:26:49.741638 #12941] [] DEBUG -- DirectorJobRunner: (0.000200s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE (("active" IS TRUE) AND ("name" = '') AND ("persistent_disks"."instance_id" = 53)) LIMIT 1
D, [2019-05-14T15:26:49.742404 #12941] [] DEBUG -- DirectorJobRunner: (0.000363s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "persistent_disks" WHERE ("persistent_disks"."instance_id" = 53)
D, [2019-05-14T15:26:49.744322 #12941] [] DEBUG -- DirectorJobRunner: (0.000463s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "ip_addresses" WHERE ("ip_addresses"."vm_id" = 60)
D, [2019-05-14T15:26:49.745256 #12941] [] DEBUG -- DirectorJobRunner: (0.000047s) (conn:<PHONE_NUMBER>1140) BEGIN
D, [2019-05-14T15:26:49.746003 #12941] [] DEBUG -- DirectorJobRunner: (0.000376s) (conn:<PHONE_NUMBER>1140) UPDATE "tasks" SET "result_output" = ("result_output" || '{"vm_cid":"vm-b6a4c22c-bd42-4a4e-49db-87ca845f60ff","active":true,"vm_created_at":"2019-05-14T14:35:18Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"509dc7ee-76fb-42a8-b658-61b6d84497f2","job_name":"oscap_1","index":0,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"a57cb8eb-485f-43df-9353-543b3af02eb3","bootstrap":true,"ignore":false}
') WHERE ("id" = 104)
D, [2019-05-14T15:26:49.742575 #12941] [] DEBUG -- DirectorJobRunner: (0.002825s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "vms" WHERE (("instance_id" = 54) AND ("active" IS TRUE)) LIMIT 1
D, [2019-05-14T15:26:49.748247 #12941] [] DEBUG -- DirectorJobRunner: (0.000169s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE (("active" IS TRUE) AND ("name" = '') AND ("persistent_disks"."instance_id" = 55)) LIMIT 1
D, [2019-05-14T15:26:49.748732 #12941] [] DEBUG -- DirectorJobRunner: (0.000119s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE ("persistent_disks"."instance_id" = 55)
D, [2019-05-14T15:26:49.749206 #12941] [] DEBUG -- DirectorJobRunner: (0.000145s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "ip_addresses" WHERE ("ip_addresses"."vm_id" = 61)
D, [2019-05-14T15:26:49.749958 #12941] [] DEBUG -- DirectorJobRunner: (0.003835s) (conn:<PHONE_NUMBER>1140) COMMIT
D, [2019-05-14T15:26:49.750555 #12941] [] DEBUG -- DirectorJobRunner: (0.000053s) (conn:<PHONE_NUMBER>8680) BEGIN
D, [2019-05-14T15:26:49.751437 #12941] [] DEBUG -- DirectorJobRunner: (0.000232s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "vms" WHERE (("instance_id" = 56) AND ("active" IS TRUE)) LIMIT 1
D, [2019-05-14T15:26:49.751977 #12941] [] DEBUG -- DirectorJobRunner: (0.001088s) (conn:<PHONE_NUMBER>8680) UPDATE "tasks" SET "result_output" = ("result_output" || '{"vm_cid":"vm-aabbce2f-7737-4dc7-56a3-563f37d7e956","active":true,"vm_created_at":"2019-05-14T14:35:54Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"c7a4646f-dbc7-4bf5-8097-59cd8c620908","job_name":"oscap_1","index":2,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"8382758f-33b2-457b-84e7-5ebdc6d1cac1","bootstrap":false,"ignore":false}
') WHERE ("id" = 104)
D, [2019-05-14T15:26:49.752561 #12941] [] DEBUG -- DirectorJobRunner: (0.000280s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "instances" WHERE "id" = 56
D, [2019-05-14T15:26:49.753152 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.f99592dd-b314-48ee-93c9-a617b3504a85 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.f99592dd-b314-48ee-93c9-a617b3504a85.c6cc178e-f2be-4f68-8fa7-d4d51632e63e"}
D, [2019-05-14T15:26:49.753931 #12941] [] DEBUG -- DirectorJobRunner: (0.001836s) (conn:<PHONE_NUMBER>8680) COMMIT
D, [2019-05-14T15:26:49.754075 #12941] [] DEBUG -- DirectorJobRunner: Thread is no longer needed, cleaning up
D, [2019-05-14T15:26:49.758238 #12941] [] DEBUG -- DirectorJobRunner: (0.003537s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "instances" WHERE "id" = 54
D, [2019-05-14T15:26:49.758775 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f.a3e2118d-ee17-4e04-b78c-bf4ba0607ef0"}
D, [2019-05-14T15:26:54.753692 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.f99592dd-b314-48ee-93c9-a617b3504a85 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.f99592dd-b314-48ee-93c9-a617b3504a85.5a01703c-84de-4a02-b58b-00987dfd5c58"}
D, [2019-05-14T15:26:54.759199 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f.3333b369-887c-4bd9-8c53-2f1afcefdde8"}
D, [2019-05-14T15:26:59.754014 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.f99592dd-b314-48ee-93c9-a617b3504a85 {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.f99592dd-b314-48ee-93c9-a617b3504a85.7fa31f27-04a1-419a-9e15-c5e916e975f3"}
D, [2019-05-14T15:26:59.759416 #12941] [] DEBUG -- DirectorJobRunner: SENT: agent.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f {"protocol":3,"method":"get_state","arguments":["full"],"reply_to":"director.0b67b358-7399-475e-956c-c3741eb3e504.4d4d8db4-ee18-4478-8f4d-e9aedc7e955f.626fd8cc-e2e3-48ef-ad12-6d31a893687e"}
D, [2019-05-14T15:27:04.712896 #12941] [task:104-checkpoint] DEBUG -- DirectorJobRunner: (0.000057s) (conn:<PHONE_NUMBER>8680) BEGIN
D, [2019-05-14T15:27:04.714352 #12941] [task:104-checkpoint] DEBUG -- DirectorJobRunner: (0.000761s) (conn:<PHONE_NUMBER>8680) UPDATE "tasks" SET "checkpoint_time" = '2019-05-14 15:27:04.710818+0000' WHERE ("id" = 104)
D, [2019-05-14T15:27:04.715674 #12941] [task:104-checkpoint] DEBUG -- DirectorJobRunner: (0.001142s) (conn:<PHONE_NUMBER>8680) COMMIT
D, [2019-05-14T15:27:04.756625 #12941] [] DEBUG -- DirectorJobRunner: (0.000335s) (conn:<PHONE_NUMBER>1140) SELECT * FROM "persistent_disks" WHERE (("active" IS TRUE) AND ("name" = '') AND ("persistent_disks"."instance_id" = 56)) LIMIT 1
D, [2019-05-14T15:27:04.757383 #12941] [] DEBUG -- DirectorJobRunner: (0.000177s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE ("persistent_disks"."instance_id" = 56)
D, [2019-05-14T15:27:04.758320 #12941] [] DEBUG -- DirectorJobRunner: (0.000498s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "ip_addresses" WHERE ("ip_addresses"."vm_id" = 62)
D, [2019-05-14T15:27:04.768019 #12941] [] DEBUG -- DirectorJobRunner: (0.000091s) (conn:<PHONE_NUMBER>1140) BEGIN
D, [2019-05-14T15:27:04.769894 #12941] [] DEBUG -- DirectorJobRunner: (0.001372s) (conn:<PHONE_NUMBER>1140) UPDATE "tasks" SET "result_output" = ("result_output" || '{"vm_cid":"vm-7a57e9b2-9aa4-44a5-5061-e745a33a2e23","active":true,"vm_created_at":"2019-05-14T14:35:59Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"f99592dd-b314-48ee-93c9-a617b3504a85","job_name":"oscap_1","index":3,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"8049a820-ffc5-4d32-a683-0bcc98c288aa","bootstrap":false,"ignore":false}
') WHERE ("id" = 104)
D, [2019-05-14T15:27:04.770554 #12941] [] DEBUG -- DirectorJobRunner: (0.000335s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "persistent_disks" WHERE (("active" IS TRUE) AND ("name" = '') AND ("persistent_disks"."instance_id" = 54)) LIMIT 1
D, [2019-05-14T15:27:04.771054 #12941] [] DEBUG -- DirectorJobRunner: (0.001043s) (conn:<PHONE_NUMBER>1140) COMMIT
D, [2019-05-14T15:27:04.771175 #12941] [] DEBUG -- DirectorJobRunner: Thread is no longer needed, cleaning up
D, [2019-05-14T15:27:04.771576 #12941] [] DEBUG -- DirectorJobRunner: (0.000197s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "persistent_disks" WHERE ("persistent_disks"."instance_id" = 54)
D, [2019-05-14T15:27:04.772106 #12941] [] DEBUG -- DirectorJobRunner: (0.000158s) (conn:<PHONE_NUMBER>6460) SELECT * FROM "ip_addresses" WHERE ("ip_addresses"."vm_id" = 59)
D, [2019-05-14T15:27:04.772988 #12941] [] DEBUG -- DirectorJobRunner: (0.000045s) (conn:<PHONE_NUMBER>1140) BEGIN
D, [2019-05-14T15:27:04.773743 #12941] [] DEBUG -- DirectorJobRunner: (0.000383s) (conn:<PHONE_NUMBER>1140) UPDATE "tasks" SET "result_output" = ("result_output" || '{"vm_cid":"vm-5f6825b1-1932-4627-4bc0-ca057092b1c5","active":true,"vm_created_at":"2019-05-14T14:35:10Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"4d4d8db4-ee18-4478-8f4d-e9aedc7e955f","job_name":"oscap_1","index":1,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"0d0fdaed-dd55-482b-8235-574109c64a8b","bootstrap":false,"ignore":false}
') WHERE ("id" = 104)
D, [2019-05-14T15:27:04.774754 #12941] [] DEBUG -- DirectorJobRunner: (0.000899s) (conn:<PHONE_NUMBER>1140) COMMIT
D, [2019-05-14T15:27:04.774878 #12941] [] DEBUG -- DirectorJobRunner: Thread is no longer needed, cleaning up
D, [2019-05-14T15:27:04.774978 #12941] [task:104] DEBUG -- DirectorJobRunner: Shutting down pool
I, [2019-05-14T15:27:04.775036 #12941] [task:104]  INFO -- DirectorJobRunner: Done
D, [2019-05-14T15:27:04.775702 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000246s) (conn:<PHONE_NUMBER>8680) SELECT * FROM "tasks" WHERE "id" = 104
D, [2019-05-14T15:27:04.776836 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000044s) (conn:<PHONE_NUMBER>6460) BEGIN
D, [2019-05-14T15:27:04.778434 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.001048s) (conn:<PHONE_NUMBER>6460) UPDATE "tasks" SET "state" = 'done', "timestamp" = '2019-05-14 15:27:04.776357+0000', "description" = 'retrieve vm-stats', "result" = '', "output" = '/var/vcap/store/director/tasks/104', "checkpoint_time" = '2019-05-14 15:27:04.710818+0000', "type" = 'vms', "username" = 'admin', "deployment_name" = 'thing2', "started_at" = '2019-05-14 15:26:34.707849+0000', "event_output" = '', "result_output" = '{"vm_cid":"vm-30739d56-c9ab-4976-5bfc-b1b2f05e2926","active":true,"vm_created_at":"2019-05-14T14:35:02Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"81c0b6b2-f284-4c43-9dc6-deeed8cf481b","job_name":"oscap-store","index":0,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"95656008-500a-479e-8280-50d8a8663ad5","bootstrap":true,"ignore":false}
{"vm_cid":"vm-b6a4c22c-bd42-4a4e-49db-87ca845f60ff","active":true,"vm_created_at":"2019-05-14T14:35:18Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"509dc7ee-76fb-42a8-b658-61b6d84497f2","job_name":"oscap_1","index":0,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"a57cb8eb-485f-43df-9353-543b3af02eb3","bootstrap":true,"ignore":false}
{"vm_cid":"vm-aabbce2f-7737-4dc7-56a3-563f37d7e956","active":true,"vm_created_at":"2019-05-14T14:35:54Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"c7a4646f-dbc7-4bf5-8097-59cd8c620908","job_name":"oscap_1","index":2,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"8382758f-33b2-457b-84e7-5ebdc6d1cac1","bootstrap":false,"ignore":false}
{"vm_cid":"vm-7a57e9b2-9aa4-44a5-5061-e745a33a2e23","active":true,"vm_created_at":"2019-05-14T14:35:59Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"f99592dd-b314-48ee-93c9-a617b3504a85","job_name":"oscap_1","index":3,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"8049a820-ffc5-4d32-a683-0bcc98c288aa","bootstrap":false,"ignore":false}
{"vm_cid":"vm-5f6825b1-1932-4627-4bc0-ca057092b1c5","active":true,"vm_created_at":"2019-05-14T14:35:10Z","cloud_properties":{"zone":"us-east1-b","machine_type":"n1-standard-1","root_disk_size_gb":10,"root_disk_type":"pd-ssd"},"disk_cid":null,"disk_cids":[],"ips":["<IP_ADDRESS>"],"dns":[],"agent_id":"4d4d8db4-ee18-4478-8f4d-e9aedc7e955f","job_name":"oscap_1","index":1,"job_state":"unresponsive agent","state":"started","resource_pool":"default","vm_type":"default","vitals":null,"processes":[],"resurrection_paused":false,"az":"z1","id":"0d0fdaed-dd55-482b-8235-574109c64a8b","bootstrap":false,"ignore":false}
', "context_id" = '' WHERE ("id" = 104)
D, [2019-05-14T15:27:04.779424 #12941] [task:104] DEBUG -- DirectorJobRunner: (0.000836s) (conn:<PHONE_NUMBER>6460) COMMIT
I, [2019-05-14T15:27:04.779621 #12941] []  INFO -- DirectorJobRunner: Task took 30.077470177 seconds to process.

Task 104 done

Succeeded

Versions (please complete the following information):

Infrastructure: GCP
BOSH version 268.6.0
BOSH CLI version 5.4.0-891ff634-2018-11-14T00:21:14Z
Stemcell version ubuntu-xenial/250.9

Deployment info:
Create a bosh release containing one job with an invalid monit file:
check process scanner
  with pidfile /var/vcap/sys/run/scanner.pid
  start program "/var/vcap/jobs/config_scanner/bin/scanner_ctl start" with timeout 60 seconds
  	as uid vcap and gid vcap
  stop program "/var/vcap/jobs/config_scanner/bin/scanner_ctl stop" with timeout 60 seconds
    as uid vcap and gid vcap
  group vcap

Hey @xtreme-conor-nosal thanks for this. We'll keep this feedback in mind when we're doing work around the CLI and/or monit.
We'll close this for the time being, feel free to reopen if needed!


Remove unnecessary slot mappings for

As demonstrated by this Yasgui query, the triplestore contains triples in the form:
<http://purl.obolibrary.org/obo/RO_0002313> <http://cam.renci.org/biolink_slot> <https://w3id.org/biolink/vocab/affects>
<http://purl.obolibrary.org/obo/RO_0002313> <http://cam.renci.org/biolink_slot> <https://w3id.org/biolink/vocab/affects_transport_of>
<http://purl.obolibrary.org/obo/RO_0002313> <http://cam.renci.org/biolink_slot> <https://w3id.org/biolink/vocab/related_to>

This makes mapping RO relations to Biolink predicates particularly complicated. Instead, I think we should only have biolink_slot annotations that are exact matches (in this case, to https://w3id.org/biolink/vocab/affects_transport_of) and let us use the Biolink and RO hierarchies to imply the other relations.

We did that originally, then added this property to store the result of using the Biolink and RO hierarchies—it is a query performance optimization. Property paths in SPARQL queries are expensive. So I suggest using this property when you want to access the hierarchy closure, and use an exact match property to get exact matches. Is there something lacking in the existing skos:exactMatch links? Keep in mind we also include skos:narrowMatch in mappings as well.


Double slabs texture bugged when using shaders

The double slabs textures are not working when I'm using any shaders, I did two tests:
That's with SEUS renewed (on/off)

And that's with BSL 7.2 (on/off)

I'm also getting the OpenGl Error: 1281(invalid value)
All my drivers and mods are up to date.

Apologies for the delayed response but I believe this is fixed in the latest version! For now it is only for 1.16 but I will be backporting to older versions as soon as I can :) Thank you for your patience


Remove the through2 dependency in favor of the built-in Node.js stream.Transform

The through2 dependency got introduced over four years ago in #11325 to replace the unmaintained gulp-transform dependency. However, sadly the same holds for through2 since the last release was also four years ago.
Fortunately the through2 dependency can trivially be replaced with the built-in Node.js stream.Transform API nowadays. In fact, the through2 dependency mentions themselves in their README already that they are "a tiny wrapper around Node.js streams.Transform". The stream.Transform API is available in all Node.js versions we support, and in Node.js 6 already the simplified constructor approach for stream.Transform got introduced to simplify creating custom stream transformers; see https://nodejs.org/docs/latest-v6.x/api/stream.html#stream_new_stream_transform_options.
This commit therefore replaces through2 by switching to the stream.Transform API directly so we don't need any wrappers anymore. Note that for our case the only change we have to make is to enable object mode, see https://nodejs.org/api/stream.html#object-mode, because we pass in VinylFile objects instead of e.g. regular Buffer objects.
I have confirmed in two ways that this is indeed a drop-in replacement:

Running the Gulp targets that call the transform function and diffing the resulting build folder before/after this patch, with diff -r build-old/ build-new/, to ensure that there are no unexpected changes in the output.
Changing the Gulpfile to, instead of UTF-8, transform the files to ASCII, and diffing the resulting build folder to confirm that the transformation logic works and produces different results, such as:

diff build/lib/core/standard_fonts.js build-ascii/lib/core/standard_fonts.js
284c284
<   t["Trinité"] = true;
---
>   t["Trinit�"] = true;

For reviewing I recommend to use the ?w=1 flag since it makes the diff even shorter.

/botio-linux preview

/botio integrationtest


New REST API parentlocks; new WMStats CP thread for resolving parentage

Fixes #7651
Replaces #9540
Status
In development
Description
Since Alan is enjoying vacation, I picked the commits from his PR #9540 and added some additional required pieces.

an updated filter to only query active datasets requesting parent datasets
a check for an empty data cache which returns a 503 error

This PR provides the following:

a new wmstatsserver REST API parentlocks, which should return a list of active parent datasets in the system
a new WMStats CherryPy thread BuildParentLock. Responsable for parsing the active data cached in WMStats, and running the DBS parentage discovery
an extra DataCache property to store a list of parent datasets, to be served through the REST parentlocks

What deserves extra work are those corner cases where the data cache might be empty.
In other words, for WMStats unavailability and/or redeployment, there is a small time window that we would not have data populated in the cache, thus yielding an empty result for either the parentlocks or the globallocks REST API.
In addition to that, I also think we should extend the globallocks to consider workflows sitting in assignment-approved status. (done)
Is it backward compatible (if not, which system it affects?)
No, it's new!
Related PRs
none
External dependencies / deployment changes
It requires these deployment changes:
https://github.com/dmwm/deployment/pull/850

I tested the empty data cache scenarios a couple ways:
1.) I removed the data cache task from the reqmon config so the cache never gets created. Queries to the API return the expected 503 error and an exception log is made in the reqmon log file.
[egough@lxplus754 ~]$ curl --key /tmp/x509up_u33175 --cert /tmp/x509up_u33175 -k -D - https://esg-dmwm-dev1.cern.ch/wmstatsserver/data/parentlocks
HTTP/1.1 503 Service Unavailable
Date: Fri, 21 Feb 2020 15:57:04 GMT
Server: CherryPy/17.4.0
Set-Cookie: cms-auth=09d5ba3eafd7746cbda28d3eded540aa01123e051b0bbe53f65c68e4815167879ee299ae862af389;path=/;secure;httponly;expires=Thu, 01-Jan-1970 00:00:01 GMT
X-Error-Http: 503
X-Rest-Time: 2903.938 us
X-Error-Detail: Database unavailable
X-Error-Id: 04c618c2e2979318af78c4683ef96000
X-Rest-Status: 200
Content-Type: text/html;charset=utf-8
CMS-Server-Time: D=24190 t=1582300624676517
Connection: close
Transfer-Encoding: chunked

2.) I re-enabled the data cache thread and only started the frontend and reqmon. The data cache thread errored because it couldn't talk to couchdb. I again got the expected error message.
[egough@lxplus754 ~]$ curl --key /tmp/x509up_u33175 --cert /tmp/x509up_u33175 -k -D - https://esg-dmwm-dev1.cern.ch/wmstatsserver/data/parentlocks
HTTP/1.1 503 Service Unavailable
Date: Fri, 21 Feb 2020 16:16:34 GMT
Server: CherryPy/17.4.0
Set-Cookie: cms-auth=fd8acf74393bf18f1a3972361c93a7f88cb4d11d16c46116d093749dba73112e29fb00543179d0a6;path=/;secure;httponly;expires=Thu, 01-Jan-1970 00:00:01 GMT
X-Error-Http: 503
<snip>

Then I started the rest of the services and waited a bit for the data cache and parent threads to run.
INFO:dataCacheTasks:DataCache is updated: 13
INFO:parentLock:Executing parent lock cherrypy thread
INFO:parentLock:Found 0 unique datasets requiring the parent dataset
INFO:parentLock:Parentage lookup complete and cache renewed

Queries to the API worked as expected.
[egough@lxplus754 ~]$ curl --key /tmp/x509up_u33175 --cert /tmp/x509up_u33175 -k -D - https://esg-dmwm-dev1.cern.ch/wmstatsserver/data/parentlocks
HTTP/1.1 200 OK

I re-used a DatabaseUnavailable exception for this. I could make a data cache specific rest exception if necessary.

Those two pylint errors are from code in the REST Errors.py I did not change.


i54: add truncation warning for customer objects

The current implementation only fetches up to 10 subscriptions and 10 payment sources per customer. This change issues a warning message if it is detected that not all information has been copied from stripe.

Tested three scenarios:

customer(s) have more than 10 payment sources
customer(s) have more than 10 subscriptions
customer(s) have more than 10 payment sources and more than 10 subscriptions


I am using protractor with jasmine for test our application, it is a combination of both angular and non-angular page in the application. For handling the timeout issue using wait for AngularEnabled(true). but wait for AngularEnabled(true) is too slow when compare to browser.sleep(10000). how to make the execution fast?

Hi there!
Thanks for submitting an issue to Protractor.
To help us help you better, please do the following before submitting an issue:

Review the questions section of CONTRIBUTING.md.
Make sure you are not asking a usage or debugging question. If you are, use StackOverflow, Google Group discussion list, or Gitter to get help.
Provide a minimally reduced test case. This makes it much more likely that your bug will be fixed. Protractor has a test Angular application available at http://www.protractortest.org/testapp which you can use for the reproducible test case.
Fill in the information that corresponds to your type of issue below.
Delete this intro and any unrelated text :smile: (if you do not we'll assume you haven't read these instructions and automatically close the issue.)

Bug report

Node Version: ``
Protractor Version: ``
Angular Version: ``
Browser(s): ``
Operating System and Version ``
Your protractor configuration file
A relevant example test
Output from running the test
Steps to reproduce the bug
The URL you are running your tests against (if relevant)

Feature Request

Reasons for adopting new feature
Is this a breaking change? (How will this affect existing functionality)

Hi! This looks like a support question. Please ask your support questions on StackOverflow, Google Group discussion list, or Gitter. For more information please reference https://github.com/angular/protractor/blob/master/CONTRIBUTING.md#questions
Thank you!


Adding some Evaluation to the Demos

The notebook examples/demos are awesome! 🥳
Can we add some basic evaluation to these demos, which also motivate the work we're doing here? I'm thinking of adding the PIT, for example, of the true PDFs that are simulated in this document ?

Sorry for the delay @AngusWright! There are demos for evaluation in the branch for #4 right now, but I agree that it would be better if they used the output of the demos for the other subpackages. #54 has not yet been finalized (just waiting on unit tests), so you're welcome to make this change in its demo notebook. Interested?


Jm/channel

PR created for ongoing review

A general comment.

I think we should put code like:

    def model_dump(self, **kwargs: dict[str, Any]) -> dict:
        d = super().model_dump(**kwargs)
        d["TelemetryName"] = self.TelemetryName.value
        return d

    @classmethod
    def type_name_value(cls) -> str:
        return "data.channel.gt"

into a base class rather than using code generation to inject them into each class. Here's an example:
class Gt(BaseModel):
    TypeName: Literal["component.gt"] = "component.gt"
    Version: Literal["000"] = "000"

    model_config = ConfigDict(use_enum_values=True)

    @classmethod
    @cached_property
    def model_type_name(cls) -> str:
        return cls.model_config["TypeName"]

Then all the message classes, ComponentGt and CacGt inherit from this. (Confirm model_type_name does what we want). (Also, I thought I had put use_enum_values in, but I don't see it and I'm not sure why the tests are passing on dev.

I don't think we should override model_dump(). I think it should be doing what we want, and if not we should investigatem and in general i don't think it's the recommended approach until you prove to yourself you need it.

More general comment:
3. I think we should investigate use of config options arbitrary_types_allowed=True and extra="allow". I'm not sure we need any of them except in special cases (e.g. AnyComponent and AnyEvent knows they represent something unrecognized but with a recognized base, so they need extra="allow" to avoid losing fields)?

Additional specific comments:

I don't see why hardware_layout.py would break things. I'll follow up with you later.
Can we add a variant of Batched readings which doesn't have FSM info in it, just as a message? My sense was that the FSM stuff wasn't fully worked out yet, or maybe I don't recall that correctly.
If we did add Batched readings, A simpler structure might be:class ChannelReadings(DataChannelGt):
  ChannelId: UUID4Str
  ValueList: List[ReallyAnInt]
  ScadaReadTimeUnixMsList: List[UTCMilliseconds]
  TypeName: Literal["channel.readings"] = "channel.readings"
  Version: Literal["000"] = "000"

Then you could remove DataChannelList from BatchedReadings and you wouldn't have to keep track of indices.

I think we can use StrictInt for ReallyAnInt if we want to.

I took your suggestions re strict int, ChannelReadings and the reduced BatchedReadings. See this pr


white screen is coming after opening the app

I installed the app on mac , after installing when i opened the app , a white screen is coming nothing works seems , any config i need to do ?

Same here.
$ lsb_release -a
No LSB modules are available.
Distributor ID:	LinuxMint
Description:	Linux Mint 18 Sarah
Release:	18
Codename:	sarah
$ uname -r
4.4.0-21-generic

same here on OSX.
MacBook-Pro.local 16.6.0 Darwin Kernel Version 16.6.0: Mon Apr 17 17:15:27 PDT 2017; root:xnu-3789.60.24~21/RELEASE_X86_64 x86_64

I ran into this as well, if it helps I fixed my issue by turning off my connection to a default tmux session on start which I had setup in my ~/.zshrc file.

I was able to fix this by commenting out my entire .bash_profile and re-enabling it line-by-line to find the problematic command (it was a "read -s" in my case.)

For me (on OS X), the problem seems to have be caused by multiline aliases. I get a blank white screen when my .zshrc contains only the following:
alias lol='echo lol;
           echo haha'

It works fine when I delete that.

@patbl Same here, really doesn't like multiline aliases...

I got this problem when I use https://github.com/fish-shell/fish-shell as shell.
Have using exec fish in .bash_profile on Arch, installed package from AUR.


Do not work 'auto'.

Do not work 'auto' in new version. In old version its work.

jQuery(function($) {
var autoplay[+id+] = $('#[+id+]').lightSlider({
autoWidth: true,
addClass: '[+addClass+]',
adaptiveHeight: true,
item: [+items+],
slideMargin: 10,
mode: '[+mode+]',
useCSS: true,
auto: false,
slideEndAnimatoin: false,
keyPress: true,
controls: true,
prevHtml: '[+prev+]',
nextHtml: '[+next+]',
pager: true,
enableTouch: true,
enableDrag: true,
freeMove: true,
loop: true,
slideMove: 1,
easing: 'cubic-bezier(0.25, 0, 0.25, 1)',
speed: 400,
pause: 4000
});
});
// ]]>

Hi vvp24,
change
      auto: false
         //into
      auto: true

I am sorry this is a typo. Test with auto: true

I've encountered the same issue. Setting auto to true has no effect. I've solved it by using myLightSLider.play() on document ready.

Do not work

This might be fixed by doing https://github.com/sachinchoolur/lightslider/issues/143

Thanks

The issue has been fixed. Thanks guys :)


[BUG] Volumes Stuck in Attach/Detach Loop when running on OpenShift/OKD

I see a few active Issues, relating too: "attaching/detaching loop with error", so this issue may be a duplicate, but I am not seeing the same errors in my logs.
Might be Related too: https://github.com/longhorn/longhorn/issues/2241, but it seems to be that iSCSI is installed and functional.
I don't necessarily think this is a Longhorn issue.
Describe the bug (🐛 if you encounter this issue)
A clear and concise description of what the bug is.
(block device frontend)

Regular Attach Mode: Volumes Stuck in Attach/Detach Loop

(All Volumes, new and existing)

Maintenance Attach Mode: No Issues

ISCSI Front End Seems to Attach Fine Maintenance/Normal
To Reproduce
Upgraded from 4.11.0-0.okd-2022-11-19-050030 -> 4.11.0-0.okd-2022-12-03-100655
Or incept a cluster at or newer.
https://amd64.origin.releases.ci.openshift.org/releasestream/4-stable/release/4.11.0-0.okd-2022-12-02-145640
Install Longhorn, apply RBAC tweaks for OCP/OKD
Steps to reproduce the behavior:

Attach New or Existing Volume

Log or Support bundle
Attached Support Bundle
longhorn-support-bundle_00e45f14-1554-4313-bb2b-27dbf74ab4c7_2022-12-03T18-25-20Z.zip
Logs Should be relatively Clean, "grafana" was the volume I was testing after rebooting everything.
Environment

Longhorn version: v1.3.2
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Kubectl

Note: RBAC Modifications for OpenShift/OKD: https://github.com/ArthurVardevanyan/HomeLab/tree/production/kubernetes/longhorn/components/okd/rbac.yaml

Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:  4.11.0-0.okd-2022-12-03-100655 (v1.24.6+5658434)

https://amd64.origin.releases.ci.openshift.org/releasestream/4-stable/release/4.11.0-0.okd-2022-12-02-145640

Number of management node in the cluster: 3
Number of worker node in the cluster: 6
Node config

OS type and version: Fedora CoreOS 36  (Fedora CoreOS 411.36.4)
CPU per node: 4
Memory per node: ~13GB
Disk type(e.g. SSD/NVMe): NVME
Network bandwidth between the nodes: 1Gigabit Across "Zones", NVME Disk Speed in Same "Zone"

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): KVM
Number of Longhorn volumes in the cluster: 50

Additional context
Previous Working Version:
https://amd64.origin.releases.ci.openshift.org/releasestream/4-stable/release/4.11.0-0.okd-2022-11-19-050030
I have also tried upgrading longhorn to the latest commit on the master branch:

https://github.com/longhorn/longhorn/commit/0e56cd1e9ae71182bd248ddeb535194815034d1b

This didn't help either
I was able to reproduce the issue on a new Sandbox Cluster.
It appears that:

OKD 4.12.0-0.okd-2022-12-04-090858
Kubernetes 1.25.2
Fedora CoreOS 37.20221116.10
Longhorn 1.4.0-dev

works fine, so that may be an alternative solution when 1.4 is released.

Hi @ArthurVardevanyan,
Thanks for reporting.
There is a waring log FAIL to discover due to <nil> in instance-manager-e-a931c2ec/engine-manager.log, and it might show it can not discover the target.
Could you login instance-manager-e-a931c2ec and show the information by command iscsiadm -m node -T iqn.2019-10.io.longhorn:grafana-repo1 -p <IP_ADDRESS> with user root?

I'm not finding any docs on how to log into the Instance Manager.
I did kubectl exec, but not able to find the iscsiadm binary within the pod.
The Binary is on the host, should I SSH into the host and run the commands?

#1831

@ArthurVardevanyan sorry about the wrong info.
In pod instance-manager-e-xxx, use the command tgtadm --lld iscsi --op show --mode target
and on the volume attached node, use the command iscsiadm -m discovery -t sendtargets -p <IP_ADDRESS> and iscsiadm -m node -T iqn.2019-10.io.longhorn:grafana-repo1 -p <IP_ADDRESS>
yeah as mentioned at #1831, we do not support it completly yet.

@ArthurVardevanyan sorry about the wrong info. In pod instance-manager-e-xxx, use the command tgtadm --lld iscsi --op show --mode target and on the volume attached node, use the command iscsiadm -m discovery -t sendtargets -p <IP_ADDRESS> and iscsiadm -m node -T iqn.2019-10.io.longhorn:grafana-repo1 -p <IP_ADDRESS> yeah as mentioned at #1831, we do not support it completly yet.

No Worries.
Was doing so more testing and rebuilt my sandbox
Updated Bundle:
longhorn-support-bundle_8684db96-ab85-457f-885a-3eabcccec963_2022-12-06T18-29-12Z.zip
NOTE: After Running sudo iscsiadm -m discovery -t sendtargets -p <IP_ADDRESS>, the pending volume attaches.

From instance-manager-e-64aa96e4

tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:test
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 21475 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-test.sock
            Backing store flags:
    Account information:
    ACL information:
        ALL

ssh -i ~/.ssh/id_ed25519<EMAIL_ADDRESS>From the Node where Volume is being attached (Hosted on worker-2, attached to worker-0)

sudo iscsiadm -m discovery -t sendtargets -p <IP_ADDRESS>
<IP_ADDRESS>:3260,1 iqn.2019-10.io.longhorn:test

sudo iscsiadm -m node -T iqn.2019-10.io.longhorn:test -p <IP_ADDRESS>
# BEGIN RECORD 2.1.4

node.name = iqn.2019-10.io.longhorn:test
node.tpgt = 1
node.startup = automatic
node.leading_login = No
iface.iscsi_ifacename = default
iface.net_ifacename = <empty>
iface.ipaddress = <empty>
iface.prefix_len = 0
iface.hwaddress = <empty>
iface.transport_name = tcp
iface.initiatorname = <empty>
iface.state = <empty>
iface.vlan_id = 0
iface.vlan_priority = 0
iface.vlan_state = <empty>
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
iface.bootproto = <empty>
iface.subnet_mask = <empty>
iface.gateway = <empty>
iface.dhcp_alt_client_id_state = <empty>
iface.dhcp_alt_client_id = <empty>
iface.dhcp_dns = <empty>
iface.dhcp_learn_iqn = <empty>
iface.dhcp_req_vendor_id_state = <empty>
iface.dhcp_vendor_id_state = <empty>
iface.dhcp_vendor_id = <empty>
iface.dhcp_slp_da = <empty>
iface.fragmentation = <empty>
iface.gratuitous_arp = <empty>
iface.incoming_forwarding = <empty>
iface.tos_state = <empty>
iface.tos = 0
iface.ttl = 0
iface.delayed_ack = <empty>
iface.tcp_nagle = <empty>
iface.tcp_wsf_state = <empty>
iface.tcp_wsf = 0
iface.tcp_timer_scale = 0
iface.tcp_timestamp = <empty>
iface.redirect = <empty>
iface.def_task_mgmt_timeout = 0
iface.header_digest = <empty>
iface.data_digest = <empty>
iface.immediate_data = <empty>
iface.initial_r2t = <empty>
iface.data_seq_inorder = <empty>
iface.data_pdu_inorder = <empty>
iface.erl = 0
iface.max_receive_data_len = 0
iface.first_burst_len = 0
iface.max_outstanding_r2t = 0
iface.max_burst_len = 0
iface.chap_auth = <empty>
iface.bidi_chap = <empty>
iface.strict_login_compliance = <empty>
iface.discovery_auth = <empty>
iface.discovery_logout = <empty>
node.discovery_address = <IP_ADDRESS>
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 8
node.session.xmit_thread_priority = -20
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.nr_sessions = 1
node.session.auth.authmethod = None
node.session.auth.username = <empty>
node.session.auth.password = <empty>
node.session.auth.username_in = <empty>
node.session.auth.password_in = <empty>
node.session.auth.chap_algs = MD5
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.tgt_reset_timeout = 30
node.session.err_timeo.host_reset_timeout = 60
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.session.scan = auto
node.session.reopen_max = 0
node.conn[0].address = <IP_ADDRESS>
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No

# END RECORD

@ArthurVardevanyan Do you have also the following error message in your dmesg?
[Sat Dec 10 18:52:01 2022] audit: type=1400 audit(1670698321.515:7214): avc:  denied  { dac_override } for  pid=231579 comm="iscsiadm" capability=1  scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:system_r:iscsid_t:s0 tclass=capability permissive=0
[Sat Dec 10 18:52:01 2022] audit: type=1300 audit(1670698321.515:7214): arch=c000003e syscall=83 success=no exit=-13 a0=55b9035185c0 a1=1f8 a2=ffffffffffffff00 a3=0 items=0 ppid=231163 pid=231579 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iscsiadm" exe="/usr/sbin/iscsiadm" subj=system_u:system_r:iscsid_t:s0 key=(null)
[Sat Dec 10 18:52:01 2022] audit: type=1327 audit(1670698321.515:7214): proctitle=697363736961646D002D6D00646973636F76657279002D740073656E6474617267657473002D700031302E3133312E312E31363

Happening after upgraded from 4.11.0-0.okd-2022-11-19-050030 to 4.11.0-0.okd-2022-12-02-145640
Seems like some selinux permissions are not correct, however Longhorn didn't changed.

@netwarex I do see the same thing in my dmesg, even on the latest CI Build, 4.11.0-0.okd-2022-12-10-085957.
The latest build of, 4.12.0-0.okd-2022-12-10-034646, seems to be working out of the box, so my current plan is to wait for Longhorn 1.4.0 then jump to  4.12 / 1.25.

@ArthurVardevanyan @netwarex
What's the version of your open-iscsi on the worker nodes?
Can you help check iscsiadm -V? Thank you.

@derekbit
# iscsiadm -V
iscsiadm version <IP_ADDRESS>

Also I was able to add the dac_override capability using a local CIL via MachineConfig, it seems to make this work now.

@netwarex
Thank you for the information.
Yes, adding dac_override is a workaround for this issue. (cc @ArthurVardevanyan)
iscsi-initiator-utils <IP_ADDRESS> is based on open-iscsi 2.1.4. This issue appears to be caused by the permissions of the directories. It has been fixed in https://github.com/open-iscsi/open-iscsi/pull/244 and is included in open-iscsi 2.1.4.
Is your system is created by an older open-iscsi version prior to 2.1.4? If yes, you can check of the directories in the PR and correct their permissions to see if it can be fixed. It looks there is nothing that Longhorn can do to help with this issue from a Longhorn perspective.
What Longhorn can imporve is to stop the attach-detach loop and provide the appropriabe error message (ref: https://github.com/longhorn/longhorn/issues/5001).
Addtionally, we need a domain knowledge for the workaround.
cc @innobead

@derekbit

iscsi-initiator-utils <IP_ADDRESS> is based on open-iscsi 2.1.4. This issue appears to be caused by the permissions of the directories. It has been fixed in open-iscsi/open-iscsi#244 and is included in open-iscsi 2.1.4.

Yes, I ran into the same Github issue first, I didn't very yet the version, however this would be a regression as the 2 weeks before release with older FCOS does not have this issue, it worked just fine.
This could be the case, that they had the dac_override in the policies, but then they applied the fix and removed the policy... I currently don't have the time to reinstall an older version but this would make sense and would answer the issue.
However I'm not sure which folder is this to check, because I may just able to fix this manually with chmod, could you give a hint?

However I'm not sure which folder is this to check, because I may just able to fix this manually with chmod, could you give a hint?

Check the permissions of the folders such as LOCK_DIR and IFACE_CONFIG_DIR.
But, I think it is fine with the workaround adding dac_override.

It is still interesting that is is able to mount using maintenance mode, but not regular mode.
@netwarex Do you have that yaml for the dac_override handy?
Some Additional Details below, unless I am checking the wrong process, it appears to have the dac_override already.
4.11.0-0.okd-2022-11-19-050030 (Working)
https://amd64.origin.releases.ci.openshift.org/releasestream/4-stable/release/4.11.0-0.okd-2022-11-19-050030
[core@worker-6 ~]$ iscsiadm -V
iscsiadm version <IP_ADDRESS>

[core@worker-6 ~]$ systemctl status iscsid.service
[core@worker-6 ~]$ cat /proc/14827/status | grep Cap

CapInh:<PHONE_NUMBER>000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:<PHONE_NUMBER>000000

[core@worker-6 ~]$ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

[core@worker-6 ~]$ ls -lsah /var/lib/iscsi/nodes/
total 4.0K
4.0K drwxr-xr-x. 7 root root 4.0K Dec 10 17:00 .
   0 drwxr-xr-x. 8 root root   90 Nov  2 20:41 ..
   0 drw-------. 3 root root   33 Dec 10 16:00 iqn.2019-10.io.longhorn:prometheus-k8s-db-prometheus-k8s-0

4.11.0-0.okd-2022-12-02-145640 (Not Working)
https://amd64.origin.releases.ci.openshift.org/releasestream/4-stable/release/4.11.0-0.okd-2022-12-02-145640
[core@worker-0 ~]$ iscsiadm -V
iscsiadm version <IP_ADDRESS>

[core@worker-0 ~]$ systemctl status iscsid.service
[core@worker-0 ~]$ cat /proc/31881/status | grep Cap
CapInh:<PHONE_NUMBER>000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:<PHONE_NUMBER>000000

[core@worker-0 ~]$ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

# Doesn't Mount, still shows up.
[core@worker-0 ~]$ ls -lsah /var/lib/iscsi/nodes/
total 0
0 drwxr-xr-x. 5 root root 116 Dec 11 14:52 .
0 drwxr-xr-x. 8 root root  90 Dec 11 14:24 ..
0 drw-------. 2 root root   6 Dec 11 14:52 iqn.2019-10.io.longhorn:stuck

4.12.0-0.okd-2022-12-10-034646 (Working)
https://amd64.origin.releases.ci.openshift.org/releasestream/4.12.0-0.okd/release/4.12.0-0.okd-2022-12-10-034646
[core@worker-2 ~]$  iscsiadm -V
iscsiadm version <IP_ADDRESS>

[core@worker-2 ~]$ systemctl status iscsid.service
[core@worker-2 ~]$ cat /proc/22197/status | grep Cap
CapInh:<PHONE_NUMBER>000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:<PHONE_NUMBER>000000

[core@worker-2 ~]$ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

[core@worker-2 ~]$ ls -lsah /var/lib/iscsi/nodes/
total 0
0 drwxr-xr-x. 5 root root 186 Dec 11 13:53 .
0 drwxr-xr-x. 8 root root  90 Dec 10 14:31 ..
0 drw-------. 3 root root  31 Dec 11 13:53 iqn.2019-10.io.longhorn:pvc-391ad221-81ea-4059-8b5e-2f060e527317

@ArthurVardevanyan Sure, here it is:
https://gist.github.com/netwarex/5186be148560f99b5ac22759299e5407
Also can you please share the output of the policies on the same environments?
This is how you can extract as CIL:
cd /var/tmp
semodule -c -E iscsi
cat iscsi.cil

@ArthurVardevanyan Sure, here it is:
https://gist.github.com/netwarex/5186be148560f99b5ac22759299e5407
Also can you please share the output of the policies on the same environments?
This is how you can extract as CIL:
cd /var/tmp
semodule -c -E iscsi
cat iscsi.cil

Thank you for the commands:
4.11.0-0.okd-2022-11-19-050030.log
4.11.0-0.okd-2022-12-02-145640.log
4.12.0-0.okd-2022-12-11-164611.log
I don't see a difference, however, my 4.11.0-0.okd-2022-12-02 Log is during a 4.11->4.12 Upgrade, but before the MCP Rollout.
I'll need to repave my sandbox later in the week, but I don't see dac_override with this command on either of the 3 versions.

@ArthurVardevanyan Thanks for the logs. Then it's really a mistery how it went wrong... Maybe other policies somehow made this possible.

OKD Refs:
https://github.com/okd-project/okd/discussions/1430
https://github.com/okd-project/okd/issues/1438

@ChanYiLin could you help with this knowledge page as per https://github.com/longhorn/longhorn/issues/4988#issuecomment-1345476349? If any questions, feel free to check with @derekbit . Thanks.

Closing because the KB has been published. https://longhorn.io/kb/troubleshooting-volumes-stuck-in-attach-detach-loop-when-using-longhorn-on-okd/

Closing because the KB has been published. https://longhorn.io/kb/troubleshooting-volumes-stuck-in-attach-detach-loop-when-using-longhorn-on-okd/

Looks like the fixed version is no longer valid for point 1.
Nightlies were using a different base OS from Stable when 4.12 was released.

https://github.com/longhorn/longhorn/pull/5004/commits/027ecca77d08b0eb6f3a4b1ac374d48a3758d16e
https://github.com/okd-project/okd/issues/1438#issuecomment-1399317214

@ArthurVardevanyan thanks for the update.

I have posted an article on this possible fix options, especially for the MachineConfig: https://ioflair.com/blog/fix-longhorn-volumes-stuck-in-attach-detach-loop-on-openshift-okd/

Seems to be fixed in: 4.12.0-0.okd-2023-03-05-022504


Automatic code style

Our style guide is currently silent on some formatting issues around import statements. This pull request adds a configuration for stylish-haskell which applies some simple alignment rules to import statements and alphabetizes them within their groups. A few other simple formatting rules are applied, such as removing trailing whitespace and aligning LANGUAGE pragmas. I would like to suggest that the style guide recommend running stylish-haskell for the issues it can handle; the formatting is fairly good, but most importantly: it is automatic.
Reviewer checklist

[ ] Test coverage: stack test --coverage
[ ] Public API documentation: stack haddock
[ ] Style conformance

I am closing this pull request. I am still working on the ticket to merge the language-kore and matching-logic. Because that ticket also involves making tree-wide changes, I am going to make all the tree-wide changes at once.


The Az CLI commands work only when resources are deployed in 'eastus' region!

The 'az network create ...' command is missing the '--location' parameter/flag.  When the 'LOC' shell variable is set to a different region other than 'eastus', the 'az network firewall create ...' command fails as it is unable to locate the VNET in the correct region.
 Please make sure that the referenced resource exists, and that both resources are in the same region.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a38439d0-0125-3445-1c0a-a03b940e315d
Version Independent ID: c6436a35-94b9-6396-3b13-9291f0a17b21
Content: Restrict egress traffic in Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/limit-egress-traffic.md
Service: container-service
GitHub Login: @palma21
Microsoft Alias: jpalma

Hey @ganrad ,
Thanks for the issue. I've gone ahead and opened a PR to fix this. I will close this issue now, if you need anything else just leave a comment down below.


How to get value of $ref field from Context.api ?

I am trying to create a custom rule where I want to get all properties which uses $ref to refer some other object. I want to get the value of $ref field and also the property name.
If the latter, could you post a piece of code showing what you want to do?


Key and value intuition of transformer in FEAT

Transformer in FEAT model compares query image feature vector with all support set feature vector. I got the idea that query image is Q of the transformer. So what is the key and value, I think support set are key or value. I wanted to understand which component of FSL is key, and what is value for Transformer? Or key and value are same in this case?

Hi,
Transformer uses the self-attention module. The key and value are the same, i.e., the embeddings of the support set.

Correct me if I am wrong, I think key and value are not the same. Looks like key is 'feature' and V is 'class'. Can you please clarify if they are same or my assumption is correct?


How to forward DNS requests to tun interface?

I use Sing-Box to proxy my local area network environment. Sing-Box creates a tun interface to intercept all traffic and intercepts DNS requests through sniffing. My Unbound is already configured, and computers both locally and in the LAN can resolve DNS queries normally. However, now I want to forward all DNS requests obtained by Unbound to Sing-Box for processing. What should I do now?
Network
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet <IP_ADDRESS>/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:83:33:b9 brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe83:33b9/64 scope link
valid_lft forever preferred_lft forever
3: ztr4nvqcky: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 7e:0e:fa:87:99:37 brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global ztr4nvqcky
valid_lft forever preferred_lft forever
inet6 fe80::580a:acff:fec9:7ca7/64 scope link
valid_lft forever preferred_lft forever
16: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet <IP_ADDRESS>/30 brd <IP_ADDRESS> scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::9142:3842:4a64:50c1/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Resolvect Status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
resolv.conf mode: uplink
Current DNS Server: <IP_ADDRESS>
DNS Servers: <IP_ADDRESS>
Link 2 (enp1s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
Link 3 (ztr4nvqcky)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
Link 16 (tun0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
Current DNS Server: <IP_ADDRESS>
DNS Servers: <IP_ADDRESS>
DNS Domain: ~.
Unbound Config
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
server:
qname-minimisation: yes
interface: enp1s0
interface: <IP_ADDRESS>
prefer-ip4: yes
access-control: <IP_ADDRESS>/8 allow
access-control: <IP_ADDRESS>/16 allow

I can successfully retrieve DNS resolution records by using dig @<IP_ADDRESS> google.com. However, after configuring a forward-zone and setting forward-addr in Unbound, all domain names cannot be resolved.

I need Sing-Box to intercept and use a proxy to resolve certain specific domain names, so I need to forward Unbound's DNS requests to Sing-Box.

You can specify the outgoing interface in unbound with outgoing-interface: in the server: section. In your example that would be:
server:
    ...
    outgoing-interface: <IP_ADDRESS>
    ...

Maybe that solves your issue?

This option does not solve my problem. After disabling DNSSEC, I used a forward-zone to forward all DNS requests to <IP_ADDRESS>, and now it works.

Glad that it works now for you, closing.


Release cost management microsoft.cost management 2022 10 01

Information about the changes in this PR
We are adding a new stable version 2022-10-01 for the RP Cost management. We worked on the shared branch https://github.com/Azure/azure-rest-api-specs/tree/release-cost-management-Microsoft.CostManagement-2022-10-01
We got all the commits reviewed and signed off from the ARM before merging them to our shared branch.
This is PR is to simply to merge these already reviewed and signed off changes/commits to the main branch.
Here are the links to the signed off PRs:
https://github.com/Azure/azure-rest-api-specs/pull/20776
https://github.com/Azure/azure-rest-api-specs/pull/21364
https://github.com/Azure/azure-rest-api-specs/pull/20958
https://github.com/Azure/azure-rest-api-specs/pull/21036
https://github.com/Azure/azure-rest-api-specs/pull/20964
ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

breaking changes approved in https://github.com/Azure/azure-rest-api-specs/pull/20958


Refactor JavaScript code

Problems

hard coded the content
variable names are not correct
a lot of bad design patterns

Solution
Refactor and fix the issues

homepage (index.html)

remove root index.html (it is not in use)
Refactor:

replace button with 'a'

replace nav and a with H1

PS: Refactor CSS too.

/src/task/index.html

do not have class and id name same. Remove or refactor:

do not create a class name with an HTML tag name. Refactor from input to some generic name:

use generic class name not notEditing

never ever use class as class name

do not use BR. Use CSS to manage the spacing

for should be normalcase not camelCase

Validate if the element having ID and class is really needed? Can we remove either of them?

CSS refactoring is required: consistency on units, color values is missing.

JavaScript:

Design pattern is required. As of now, all methods are running at the load time. Introduce a pattern such as a singleton to give structure to the code.
Move out all the constants to the constant file
Have global CSS, JavaScript, Constant, utils files rather than in each folder
Please check my notes in the General chat or other issues

Introduce a structure to the project. As of now, we have a separate folder for every page. Basically, we are missing the architecture of the project.
So, we should have:

pages folder

HTML pages
there will be only 1 index.html
rest of the page's names should be as per their task

style folder
image folder
script folder

helper
constant
script

env file
tests

As this is vanilla code, there shouldn't have any SRC folder and index.html of the root should be the entry point

Consistency is missing:

constant: should be uppercase and separated by  '_' eg: API_TEST_HELLO

variable name:

should be clear. Eg: avoid using submitEvt. It should be submitEvent

the longer name should be understandable. Hence, use camelCase

use meaningful variable names. Here is what result means. result of what?

flag of what?

Class name patterns:
Use one way of writing class names either BME or camelCase

If possible, kindly assign this to me. I would like to work on this. @Pavangbhat

JavaScript:

Move all the DOM elements accessing and assigning to the const to the top of the function:

move the mock data to a separate file or if it's a constant then move to the constant file

Do not add events on the DOM. When working with the JavaScript use addEventListener to append the events

investigate why the option is hidden here? Why we can't remove it?

HTML:

remove inline CSS in DOM

why 2 css?

Remove DIV and use semantic tag - HTML

Never disable text-decoration (accessibility will be impacted)

Never disable outline

Use CSS variables

Consistency is missing:
Either use hexacode or name of the color

Why are we using NAV?

Why are we not using constants for the text?

return errors or handle errors in the UI notifications instead of alert

Do not remove curly brackets

What are we returning from here?

These are not utils at all. utils mean to make the method generic. Instead of  hardcoded tags, and classnames

border style can be optimized here

Consistency missing: Have one way of including JS in HTML files or across applications:

Naming convention:
There is nothing like old and new; replace them with prev/updated or current

Server.JS is not required here.
We can get rid of it. It is a Normal HTML page and can we run on the browser directly:

Mock data for testing:
Move the mock data to the constant:

Responsive:
The application is not responsive.

UX/UI of the app:

Why there are NO input fields next to the labels?

User exp. of clicking on Edit link doesn't make any sense. No default values are visible on Title, purpose, feature URL, links, etc. Preferred UI should be:

Have a label and below it the input box. Put an edit button global to edit the form details.  (please reach out to me to discuss this in detail)

Have the global style for:

heading

button

labels

notifications

section

input etc.


Issue

If typewriter.start() is called while the typewriter is already running, it prints out the message again, then throws phaser's group index out of bounds error.

Ok thanks I will try to patch it up.

Patched up.


[Windows] save TSNEEmbedding to binary, Directory error

Expected behaviour
On Windows OS, when trying to save the TSNEEmbedding  object, or affinities, tried to save it with
pickle.dump(embeddings,open(os.path.join(self.models_path,"tsne_global_embeddings.sav"),"wb"))
or also tried to save as array to reconstruct the object later using numpy.save("file.npy",affinities)
These lines both work just fine under linux distributions what I tried.
But loading them back on Windows breaks with the same error as on the save methods, both scenario.
Actual behaviour
Windows OS can't find/create the temporary directory/files when trying to touch the file. unfortunately I haven't had more time to look deeper into it yet, what could cause this behaviour.
*** NotADirectoryError: [WinError 267] The directory name is invalid: 'C:\\Users\\tomcs\\AppData\\Local\\Temp\\tmp7biujwdz\\tmp.ann
Steps to reproduce the behavior
opentsne==0.6.2
I think this would be the same with most settings. although I am using the following settings to train before trying to save.
affinities = openTSNE.affinity.PerplexityBasedNN(             X,             perplexity=500,             n_jobs=32,             random_state=0,         )
init = openTSNE.initialization.pca(X,n_components=3, random_state=42)
tsne = openTSNE.TSNE(3,             exaggeration=None,             n_jobs=16,             verbose=True,             negative_gradient_method ="bh"         )
embeddings = tsne.fit(affinities=affinities, initialization=init)
pickle.dump(embeddings,open("tsne_global_embeddings.sav","wb"))

I've been having the same issue. After downgrading to openTSNE==0.6.0 I was able to both save and load the fitted model.
The example data from the README however works for both 0.6.0, 0.6.1 and 0.6.2 for me. This could possibly have something to do with number of observations and/or the resulting model size?
import pickle
import openTSNE
from openTSNE import TSNE
from sklearn import datasets
print(openTSNE.__version__)

iris = datasets.load_iris()
x, y = iris["data"], iris["target"]

embedding = TSNE().fit(x)

with open('iris.pkl', 'wb') as f:
    pickle.dump(embedding, f)

with open('iris.pkl', 'rb') as f:
    embedding = pickle.load(f)

embedding.transform(x)

In v0.6.2, I fixed the pickling behaviour so it works as one would expect. Annoy, which is used to find nearest neighbors, is not picklable, but uses its own internal file structure. So in previous versions, the annoy nearest neighbor index was saved to a separate file. So, pickling a TSNEEmbedding object actually produced two files, an annoy file and a pickle file. This was very fragile and there were just a ton of problems if you wanted to move files around.
In v0.6.2, I got rid of this and just included everything in the one pickle file. What happens now is that the annoy file is still saved to disk, but in a temporary directory (this is the reason for the C:\\Users\\tobia\\AppData\\Local\\Temp\\tmpvvo0p0t8\\tmp.ann directory). This file is then serialized into a binary string and saved to the pickle. When unpickling, we then write this binary string into another temporary file, which annoy can then read.
As to your problem: Would it be possible that you don't have permission to write to the Windows tmp directory? I don't have a windows machine, so I can't really test this out. There doesn't seem to be anything wrong with the actual path to the temporary file.
I'll close this for now, but if this problem persists, please reopen this issue.

Something is still causing problems with this temporary annoy file on windows. See #210. Why are you saving to disk anyways? Can it not be written to memory, like a byte buffer (io.BytesIO)?

This is still an ongoing problem and limited to Windows. I'm not sure if it could be written to a byte buffer, but my feeling is that it would be difficult.
Currently, we depend on Annoy for nearest neighbor search, but, since Annoy is not available on conda-forge (or wasn't when I was incorporating it), so we have the code in the openTSNE/dependencies directory. The thing is that Annoy has it's own saving functions, which we use, but these only support saving to a file on disk.
I'm sure we could go tinker around with their source code to support this, but this would make upgrading Annoy to newer versions a nightmare, since my current approach is to simply copy/paste their implementation. I'm also not familiar with their codebase, nor that proficient in C++ in general, so I really don't want have to change the annoy implementation at all. This would make maintenance very difficult.
I don't have access to a windows machine, so debugging this is very difficult for me. I'm not really sure why this would be happening in any case, since the problem seems to be that we're just creating a temporary directory, which should be supported by the standard Python library.
If anyone has any idea on how to tackle this, I'd be very grateful.

The same problems were reported in #244 and #260.
I am moving the discussion here, so it's all in one spot.

This seems highly relevant, from #244
I'm experiencing a similar issue when working on Ubuntu with NFS as the openTSNE file system.
What we see is that nearest_neighbors is trying to delete a file located on the NFS, a file that is still in use by the process it self.
The error we see is (opentsne==1.0.0):
File "/usr/local/lib/python3.10/dist-packages/openTSNE/nearest_neighbors.py", line 358, in __setstate__
    with tempfile.TemporaryDirectory() as dirname:
2024-04-16T13:27:42.383059144Z   File "/usr/lib/python3.10/tempfile.py", line 1008, in __exit__
2024-04-16T13:27:42.383061357Z     self.cleanup()
2024-04-16T13:27:42.383062548Z   File "/usr/lib/python3.10/tempfile.py", line 1012, in cleanup
2024-04-16T13:27:42.383063695Z     self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
2024-04-16T13:27:42.383064831Z   File "/usr/lib/python3.10/tempfile.py", line 994, in _rmtree
2024-04-16T13:27:42.383066005Z     _rmtree(name, onerror=onerror)
2024-04-16T13:27:42.383067058Z   File "/usr/lib/python3.10/shutil.py", line 731, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
2024-04-16T13:27:42.383069274Z   File "/usr/lib/python3.10/shutil.py", line 729, in rmtree
2024-04-16T13:27:42.383070790Z     os.rmdir(path)
2024-04-16T13:27:42.383072030Z OSError: [Errno 39] Directory not empty: '/tmp/tmp9zxbbwwq'

My assumption is that the code "works" without issues on standard unix/linux based systems due to the delete on last close practice-
A practice in Unix/Linux, where an application has a file open but issues a delete (unlink) on that file anyway.
In a native Linux file system (as opposed to NFS and of course, Windows OS), this will result in the file becoming invisible to other processes, even though it still exists and is still open.
Perhaps I'm wrong but this makes sense to me, especially after reading this comment in issue #210
Originally posted by @shmulikah in https://github.com/pavlin-policar/openTSNE/issues/244#issuecomment-2059878936

could you provide me with some pointers to annoys saving functions that are used, so I can have a look?

Thanks for digging into this! Unfortunately, I don't have access to a windows machine, so I can't test this out. So, if I understand correctly, a potential fix is to replace the temporary directory with this tempfile.NamedTemporaryFile with delete_on_close=True?


On Click | On Hover Function

Hey,
Is there a function that is called when I click on a seat, or when I hover/unhover over it in JavaScript?
Best Regards,
Niclas

hi @bylioxdev, you can do something like this:
  const svg = d3
    .create("svg")
    .attr("width", width)
    .attr("height", width / 2);

  svg
    .append("g")
    .call(
      d3ParliamentChart
        .parliamentChart()
        .width(width)
        .aggregatedData(parliamentSeats)
    )
    .selectAll("circle")
    .on("mouseover", function (d, i) {
      // Add your handler code here
      d3.select(this).transition().duration("50").attr("opacity", ".85");
    });

thank you

@bylioxdev sorry, the placement of the circles is completely automated and there is no way to control how many circles show up in a specific row.


CI: Use pip cache.

The Windows build takes more than 6 minutes to install the depdencies---longer than a Linux makes takes the run end-to-end sometimes. Apparently v4 of the setup-python GH Action supports pip caching. I hope that will help.

The seems to have worked. The Windows build now takes only 4 minutes.