Improve standard user default permissions

If I'm reading this right, it is allowing the restricted-admin-user role to create secrets
The user-role had its broad secret creation rule removed, but it can now create secrets in cattle-global-data, this change necessitated some new functionality to allow the builder to create namespaced rules, this is a nice clean change.


IOS: Disconnect an active call if application is about to close

Thank you, published on npm<EMAIL_ADDRESS>


DeepSpeed3 Multi-GPU Tokenizing But Not Training

I am facing an issue with the below configuration (was working yesterday and for the last week) where the model loads and dataset is tokenized but then the script hangs (GPU utilization spikes to 100% for all GPUs) but no training starts. Only change was previously I wasn't required to use template but now the CLI forces me to add it.
Terminal log output attached.
log_output.txt
pip install --upgrade huggingface_hub
huggingface-cli login --token $HF_TOKEN

setup.sh
git clone https://github.com/hiyouga/LLaMA-Efficient-Tuning.git
cd LLaMA-Efficient-Tuning
pip install -r requirements.txt
pip install bitsandbytes>=0.39.0
pip install scipy
pip install -U git+https://github.com/huggingface/transformers.git
pip install -U git+https://github.com/huggingface/peft.git
pip install deepspeed

Accelerate Config
This Machine
multi-GPU
1 node
No torch dynamo
Deepspeed yes
No config file
Deepspeed Zero3
no offload optimizer
no offload parameters
4 grad accumulation steps
no grad clipping
no deepspeed.zero.Init
6 GPUS (A100-80GB)
FP16

config.yaml

compute_environment: LOCAL_MACHINE
deepspeed_config:
  gradient_accumulation_steps: 4
  offload_optimizer_device: none
  offload_param_device: none
  zero3_init_flag: false
  zero_stage: 2
distributed_type: DEEPSPEED
downcast_bf16: 'no'
machine_rank: 0
main_training_function: main
mixed_precision: fp16
num_machines: 1
num_processes: 6
rdzv_backend: static
same_network: true
tpu_env: []
tpu_use_cluster: false
tpu_use_sudo: false
use_cpu: false

Run command
accelerate launch src/train_bash.py     --stage sft     --model_name_or_path meta-llama/Llama-2-7b-hf     --do_train     --dataset webqa     --finetuning_type lora     --output_dir /workspace/webqa-test     --overwrite_cache     --per_device_train_batch_size 4     --gradient_accumulation_steps 4     --lr_scheduler_type cosine     --logging_steps 10     --save_steps 50     --learning_rate 2e-5     --num_train_epochs 1.0     --plot_loss     --fp16  --quantization_bit 4 --template llama2

Currently DeepSpeed ZeRO-3 may be incompatible with 4-bit training, consider using fp16 training instead.
BTW, we do not recommend using a non-English corpus to fine-tune the LLaMA-2 models.

DeepSpeed Zero-2 should work no? And yeah, just selected webqa to demonstrate the issue - we're using English dataset for actual training.

DeepSpeed ZeRO-2 should be compatible with QLoRA.

@aldrinc  do you sloved the problem? I meet a same problem

@hiyouga  which  parameter do you say?  Do you say mixed_precision should use fp16?

but  utilization is 0 for all gpus

@zhangjunyi111 FP16 is required

@zhangjunyi111 I did.
FP16 like @hiyouga said worked for me.
Share your config if you still can't solve your issue.

I am confusing . I understand  your command ,accelerate launch src/train_bash.py     --stage sft     --model_name_or_path meta-llama/Llama-2-7b-hf     --do_train     --dataset webqa     --finetuning_type lora     --output_dir /workspace/webqa-test     --overwrite_cache     --per_device_train_batch_size 4     --gradient_accumulation_steps 4     --lr_scheduler_type cosine     --logging_steps 10     --save_steps 50     --learning_rate 2e-5     --num_train_epochs 1.0     --plot_loss     --fp16  --quantization_bit 4 --template llama2, has required fp16.

I sloved my problem by updating my pytorch from 1.3.1 to 2.0.2

Unfortunity, Today  I use tow nodes with 13 gpus to run ,i find one is normal ,but the other hangs . But ,when i use 16 gpus, the result is normal ,And  i can get the model.

where is config.yaml?


bump_version step of release workflow failed to increment version after updates

Description
Updated workflow for release with new bump version automated PR message didn't work:
See: https://github.com/whylabs/whylogs/actions/runs/4548089239/jobs/8018771703
Resorting to manually updating after this release, need to fix so this is automated.

[x] I have reviewed the Guidelines for Contributing and the Code of Conduct.

fixed with https://github.com/whylabs/whylogs/pull/1189


1.4.0. fails to initialise after 1.5.0 has been installed

If I install v1.4.0 in a directory on my system, and v.1.5.0 in a different directory then 1.4.0 fails to run after 1.5.0 has been run.
When running:
~/<v1.4.0_directory>/bacalhau version
I get the error:
failed to setup repo: failed to reconcile repo: failed to initialize repo: failed to initialize repo: failed to create user key: user key file already exists at path: /Users/<my_username>/.bacalhau/user_id.pem
1.5.0 runs as expected, but 1.4.0 fails to output the version number after 1.4.0 has been run.

Resolved. Needed to pass --repo <PATH_TO_DATA_DIR> in order for each version to behave itself.


Smoke test all formatting rule wrappers

Current coverage doesn't actually execute every rule, and changes to config options on ktlint side is sometimes made between releases which doesn't get picked up in the existing tests.
This simply runs every rule on a fully compliant piece of code. This means missing configuration parameters in wrappers will be identified by this test before ktlint updates are merged.

Warnings

:warning:
This PR is approved with no milestone set. If merged, it won't appear in the detekt release notes.

  Generated by :no_entry_sign: dangerJS against bc03149850da4f920870ce399f83e94c2033602b


Segmentation ground truths missing?

Hi,
I am not able to see where to access the segmentation ground truths for the data set.
is this possible?

The answer is in #3


Report retention

Hi, thx for this project.
This is kind a feature request for storage retention.
In my opinion u can make such retention options:

time base, delete reports older that x-days
storage base, delete old reports to free space according to % of free space in data directory
report path base, delete reports older that x-days for specific path. As option add ability to path report retention policy with report payload.

Thx.

https://github.com/kochetkov-ma/allure-server/blob/master/README.md#cleanup-features-since-1100


Release v227

To pick up:

#1412
#1413

$ make publish
Deploy as version: v227 [y/n]? y

Tagging commit b307d64bea990c88a99130e690d815b54ee37787 with v227...
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/heroku/heroku-buildpack-python
 * [new tag]         v227 -> v227

Publishing to the buildpack registry...
Two-factor code: ********************************************
Publishing buildpack heroku/python... done
Publishing buildpack was successful

Version  Released At               Status
───────  ────────────────────────  ─────────
227      2023-02-20T12:20:14.893Z  published


Support for RP2040

Support Raspberry Pi Pico Arduino core, for all RP2040 boards (Earle Philhower's Arduino core)

Blocked via https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/issues/280

this was done!


feat: Support install in windows

Error! Failed to load module 'elixir' because it cannot be found. Make sure that the module name is correct and
that its .beam file is in the code path.
Runtime terminating during boot ({undef,[{init,start_it,1,[{file,"init.erl"},{line,1216}]},{init,start_em,1,[{file,"init.erl"},{line,1182}]},{init,do_boot,3,[{file,"init.erl"},{line,871}]}]})
Crash dump is being written to: erl_crash.dump...done

I was able to reproduce the error renaming the directory C:\Program Files\Elixir\lib\elixir\ebin to C:\Program Files\Elixir\lib\elixir\bin. It seems that erl.exe cannot find this directory.


Remove "stars" ratings from each page.

This removes the stars rating that appears on the bottom of each page.
Doing so also required the update the "a.issue" css that correctly
aligns the "Create Issue" button and "Edit this Page" button on the
bottom of the page.

This change is

@cdrage why remove the stars?

@kubernetes/docs @janetkuo
talked to the maintainers at the dev summit and it's agreed that there's not much use coming out of it. instead, it'd be beneficial to add a "last updated" date instead to the bottom rather than the star functionality.

LGTM.


Thread safety

IMHO, using
attr_accessor :current_tenant

is not thread-safe. You should use
Thread.current[:current_tenant]

instead.

Hi! Is anyone still maintaining this gem? I really think it is thread-safe and anyone using it in production in multi-threaded env should be warned. Here is a quick test:
https://gist.github.com/HakubJozak/b00d577f1703ba28dc3cff1aec514626

hey @HakubJozak, thanks for putting together the demo script and I'd be happy to fix any known issues.  would you be interested in putting together a pull request to close this issue?

@wireframe PR to make multitenant thread-safe https://github.com/wireframe/multitenant/pull/19


DCV-2432 change custom_callbacks to notifications using Airflow Notifiers

This PR changes the custom_callbacks YML-dag structure for a notifiers one based on newer Airflow Notifiers

what if the user needs to generate dags for Airflow 2.3? Shouldn't we support both versions?

what if the user needs to generate dags for Airflow 2.3? Shouldn't we support both versions?

with this approach, we support it.
This new callbacks (previously custom-callbacks) means you can pass any from some.module import class/method and a series of args, be it kwargs or non-kw.


Mast: Blacklist delhi[\W_]*+escorts

Mast requests the blacklist of the keyword delhi[\W_]*+escorts. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

delhi[\W_]*+escorts has been seen in 28 true positives, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Show error when there are save_tos in a repeat, simplify entities tests

Closes #633
Addresses part of #632
Why is this the best possible solution? Were any other approaches considered?
I decided to clean up entities tests here as suggested by @lindsay-stevens to make it easier to identify what test coverage there currently is.
It took me a little bit to decide how to check whether a row is in a repeat. There was no such functionality at that level (e.g. survey_element has it) and it's only needed in one place so I did it with an inline expression. I think it's easy enough to read and to test from the outside.
What are the regression risks?
This doesn't touch any existing logic. The worst case is probably that if my "in repeat" check is wrong we could be rejecting forms incorrectly.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:

[x] included test cases for core behavior and edge cases in tests
[x] run nosetests and verified all tests pass
[x] run black pyxform tests to format code
[x] verified that any code or assets from external sources are properly credited in comments

maybe if there was a group inside the repeat? Or the bound item wasn't the first in the repeat?

Good cases to consider. I tried those as an extra sanity check and confirmed they're ok but don't think they're worth adding to the test suite.

Thank you so much, @lindsay-stevens 🎉


API endpoints shouldn't be exposed in the config file

I don't believe there is a reason for a normal user to change the API endpoints they are using. As such, I believe we should remove them from the config file and default them in the code. However we should still  attempt to read the values from the file so that we have the ability to override them for the bootstrap process, hitting staging, etc.

Seems like a slippery slope since each customer is going to have a unique application manager (AM) URL.  Secondly, if they have more than one pool, how do we discern one AM from the other?  I think in code, file, and command line override are all useful in their own respect.

Once AM is ripped out, there is only 1. There will not be one per customer


Visual testing POC with Percy.io

JIRA issue: https://digital-engagement.atlassian.net/browse/SDPA-
Changed

Screenshots

closing this as we havent made a decision on visual testing provider yet and this will likely be out of date


Use only relative paths in extenstion README.md

Imagine that:

Work with vscode behind a proxy, there is no connection to the public Internet area
Implement vscode extension without git repository and set relative path to images in README.md (There is no way to set absolute url due absence of image hosting and git repository)
Successfully build custom vscode extension
Want to check how custom extension's README.md is look in vscode
Install custom extension in vscode
See no image, but warning:
[Embedded Page] Refused to load the image 'file:///C:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/parts/html/browser/images/custom_extension_image.png' because it violates the following Content Security Policy directive: "img-src https:".

So question is how to use relative paths in extensions README.md?

What does image reference in the README.md look like? Just ![](path/to/img.png) or similar?

Yes, relative to root of extension package.

I feel this is out of scope. If you were to publish that extension to the marketplace, the images also would not show up. The fix for this would only apply to vsixs that have been manually installed and are not using github or similar for image hosting. The added complexity of addressing this properly does not seem worth it


Add PSGet and Chocolatey support

https://github.com/psget/psget/wiki/How-to-add-your-module-to-the-directory

PSget ended up being quite annoying. Will come back to it when the PackageManagement module for windows server gets more mature.
Chocolatey working now!


Improve Spring Batch Support

This PR updates and improves the built-in support for MyBatis Spring Batch integration. This is a breaking change, but the new support is far more flexible than in the previous version.

coverage: 100.0%. remained the same
when pulling cfb47bce398b6592851be7b0cb4a2568a72c2e30 on jeffgbutler:rework-spring-batch
into f3b07251b0c058df815b7c01535134e627f5e391 on mybatis:master.


TextField widget can't show mac keyboard

My Flutter app have a problem,textfield widget can't use mac system keyboard,only use iphone simulator。

Hello @javalin-zz. Thank you for filing this issue. Can you provide the information below:

Output of flutter doctor -v
A video demonstrating the issue
Does other apps work? For example, try launching Safari and test if the keyboard is working.

Hello @javalin-zz. Thank you for filing this issue. Can you provide the information below:

Output of flutter doctor -v

A video demonstrating the issue
when click command+shift+k change keyboad,system board can't show textfile inside
Does other apps work? For example, try launching Safari and test if the keyboard is working.
yes other app work,

@javalin-zz Could you provide the rest of the information as well, please?


need help / tcmu-runner performance very slow

Hello together,
we are testing since some weeks ceph and iscsi ...
i have a big iscsi/vmware performance problem and need some help with the tcmu-runner
if i use a linux vm and map over rbd a image then i have a speed 350>550 mb/s
if i use iscsi with the tcmu-runner then i have a max speed of 50>100mb/s
we use as os ubuntu 20.04 and ceph v16.2.5 with kernel 5.4.0-81-generic
tcmu-runner v1.5.2
some infos about the hardware and setup:

we have 3 pyhsical nodes as osd ...each node has 20hdds (5.5tb)  4ssd (1tb) and 1nvme (1tb) and build drive groups with lvm/bluestores for high io for the block/rock.db/wal.db etc.
antoher 3 physical nodes as monitors and two physical nodes as iscsi gateway
everything is connected to a 10Gbit network with bond0 and balanced-rr interfaces
all physical nodes have min 16>32 cores and 64gb>128GB ram

at the moment we connected a vmware esxi host hp dl385gen10 to this storage with esxi6.7 for testing luns and performance
can somebody tell me what else i can do to tweak the tcmu-runner to get the same performance like rbd?
i already eperimented with:
1.)
/iscsi-target...ceph.iscsi-gw> info
Target Iqn     .. iqn.2003-01.com.ceph.iscsi-gw
Auth
- mutual_password ..
- mutual_password_encryption_enabled .. False
- mutual_username ..
- password ..
- password_encryption_enabled .. False
- username ..
Control Values
**- cmdsn_depth .. 512 (override)**
- dataout_timeout .. 20
- first_burst_length .. 262144
- immediate_data .. yes
- initial_r2t .. yes
- max_burst_length .. 524288
- max_outstanding_r2t .. 1
- max_recv_data_segment_length .. 262144
- max_xmit_data_segment_length .. 262144
- nopin_response_timeout .. 5
- nopin_timeout .. 5

2.)
hw_max_sectors 1024 or 2048 ot 4096

max_data_area_mb 8 or 32 or 128

but i gain only 10% of speed :-(
thx a lot in advance for some hints and tips

There has one old issue to track a similar issue https://github.com/open-iscsi/tcmu-runner/issues/543, please check could this help ?

And also this one https://github.com/open-iscsi/tcmu-runner/issues/359.

Hello lxbsz
yes thank you, i already read that posts and i tried those settings like node.cmd on client host and cmd.depth on the target.
we use vmware esxi and i can see that the max scsi command are by default set to 128
i already set the target to 128 but the speed is worst
see screenshots

i also trying to find the optimal parameter with the max_data_area_mb and hw_max_sectors
and image objekt size from 4mb to 1mb
but speed is not ging better
see screenshots

something elese i could do?

can somebody tell me what else i can do to tweak the tcmu-runner to get the same performance like rbd?

In theory the tcmu-runner should always have slower performance than krbd. Because the IO path is much longer than that in krbd.
BTW, could you check the tcmu-runner logs and is there any frequent lock switching logs for the same image ?  Such as in case you are using the Round Robin Path Selection Policy, someone also report that sometimes even they used the Most Recently Used policy they could see the EXSI was switching the paths frequently. When doing the active path switching it will affect the performance much too.

BTW, what's your test script ? Are u using the fio ? If so what's your parameters ? Have u ever compare the tcmu-runner vs krbd by:
read 4k, write 4k, random read 4k, random write 4k, etc ?

hi lxbsz,

In theory the tcmu-runner should always have slower performance than krbd. Because the IO path is much longer than that in krbd.

yes i now that... but we have only neary 50mb/s read and 40mb/s write speed...
the rbd does an average of min 450mb/s
the recovery if one osd node was down and up is nearly 500 to 600 mb/s.
so i guess that iscsi schould be much higher then 50mb/s read and 40mb/s write speed
or not?

BTW, could you check the tcmu-runner logs and is there any frequent lock switching logs for the same image ?

i have this sometimes and spradically,... dont now why
2021-08-31 15:58:58.850 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_3: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 15:58:58.851 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_3: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 15:58:58.901 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 15:58:58.902 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 16:03:58.843 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_3: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 16:03:58.845 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_3: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 16:03:58.871 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-08-31 16:03:58.873 1105 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.

Such as in case you are using the Round Robin Path Selection Policy, someone also report that sometimes even they used the Most Recently Used policy they could see the EXSI was switching the paths frequently. When doing the active path switching it will affect the performance much too.

i already tested it and i know... but same problem if i set "most recently"

BTW, what's your test script ? Are u using the fio ? If so what's your parameters ? Have u ever compare the tcmu-runner vs krbd by:
read 4k, write 4k, random read 4k, random write 4k, etc ?

i move VMs or images from a fast Fibrechannel storage to the ceph lun and i look into the logs and the ceph dashboard.
i calculate it myself or i see it in the ceph dashboard

@lxbsz @lightmans2
My test results are as follows：（3 nvme osds）
test case 1:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=1 -runtime=300 -time_based  -group_reporting -name=test2
res：iops is 22.1k
test case 2:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=4 -runtime=300 -time_based  -group_reporting -name=test2
res：iops is 3208
so：
When using multi-threaded testing, tcmu has performance problems.  Now，i known is not caused by the rbd_lock，I guess it may be caused by the lock of tcmu's own process.
@lightmans2
you can test your ceph iscsi use test case1 and case2 ,  confirm whether the problem is caused by multiple processes.

I analyzed the code of tcmu，When tcmu gets messages from uio, it is no lock so it will not distinguish whether it is multi-threaded or not. I guess the performance difference between tcmu and krbd is 10%.
The problem I am currently experiencing is that the performance of ceph-iscsi under multi-threading is very poor. The reason lies in iscsi, not tcmu. I used krbd to test iscsi and this has been confirmed

Yeah, the TCMU and tcmu-runner don't know and also don't care about that, the TCMU will just queue the SCSI cmds in the TCMU's buffer and the tcmu-runner will handle them one by one. No locks in tcmu-runner when handing this.

Hello lxbsz,

test case 1:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=1 -runtime=300 -time_based -group_reporting -name=test2
test case 2:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=4 -runtime=300 -time_based -group_reporting -name=test2

yes i will test this later or tonight
yesterday night i foud now a solution or the right settings for performance, and it was a long night :-)

with that speed i can live
iscsi runs now with 150mb/s and up tp 250mb/s
with settings:
cmdsn_depth 512
hw_max_sectors 8192
max_data_area_mb 32
and i found out that the performance goes hard down if i have one iscsitarget for ex. iqn.2003-01.com.ceph.iscsi-gw  with two or more LUNs then the performance are going down to max 50mb/s
now i have a different problem... if i test the speed during some vms are running on this lun.... the iops goes up to >3k and speed with >150mb/s ... one of the gateways get stucket and the process freeze and crash
looks like the gw who are mapping the rbd image gets stucks... unfortunately I couldn't find a usable log last night
this makes the gateways instable :-(
in which log could i see it?
on the machine console i found that

Hello lxbsz,

test case 1:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=1 -runtime=300 -time_based -group_reporting -name=test2
test case 2:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=4 -runtime=300 -time_based -group_reporting -name=test2

yes i will test this later or tonight
yesterday night i foud now a solution or the right settings for performance, and it was a long night :-)

with that speed i can live
iscsi runs now with 150mb/s and up tp 250mb/s
with settings:
cmdsn_depth 512
hw_max_sectors 8192
max_data_area_mb 32
and i found out that the performance goes hard down if i have one iscsitarget for ex. iqn.2003-01.com.ceph.iscsi-gw with two or more LUNs then the performance are going down to max 50mb/s
now i have a different problem... if i test the speed during some vms are running on this lun.... the iops goes up to >3k and speed with >150mb/s ... one of the gateways get stucked and the process freeze and crash
looks like the gw who are mapping the rbd image gets stucked.. unfortunately I couldn't find a usable log last night
this makes the gateways instable :-(
in which log could i see it?
on the machine console i found that

What are your tcmu-runner/ceph-iscsi versions ?
Could you upload the tcmu-runner.log and rbd-target-api.log files ? And at the same time could you any crash errors in the journal log on that gateway node ?
There has one known crash issue, please see https://github.com/open-iscsi/tcmu-runner/pull/667. In that PR I have fixed several other bugs that also could cause crash.

Hi,
tcmu-runner v1.5.2
root@cd133-ceph-rgw-01:/var/log/rbd-target-api# apt info ceph-iscsi
Package: ceph-iscsi
Version: 3.5-1
Status: install ok installed
Priority: optional
Section: python
Maintainer: Freexian Packaging Team<EMAIL_ADDRESS>Installed-Size: 575 kB
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: python3:any, tcmu-runner (>= 1.4.0), python3-configshell-fb, python3-cryptography, python3-flask, python3-netifaces, python3-openssl, python3-rados, python3-rbd, python3-rtslib-fb, python3-distutils, python3-rpm, python3-requests
Homepage: https://github.com/ceph/ceph-iscsi
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: common logic and CLI tools for creating and managing LIO gateways for Ceph
 It includes the rbd-target-api daemon which is responsible for
 restoring the state of LIO following a gateway reboot/outage and
 exporting a REST API to configure the system using tools like
 gwcli. It replaces the existing 'target' service.
 .
 There is also a second daemon rbd-target-gw which exports a REST API
 to gather statistics.
 .
 It also includes the CLI tool gwcli which can be used to configure
 and manage the Ceph iSCSI gateway, which replaces the existing
 targetcli CLI tool. This CLI tool utilizes the rbd-target-api server
 daemon to configure multiple gateways concurrently.

here are the logs
the crashes was yesterday night between 01/09 and 02/09 and 1am to 3am
cd-88tcmu-runner.log
cd-133rbd-target-api.log
cd-133rbd-target-api.log.1.log
cd-133tcmu-runner.log
cd-88rbd-target-api.log.1.log
cd-88rbd-target-api.log.2.log

Hi,
tcmu-runner v1.5.2
root@cd133-ceph-rgw-01:/var/log/rbd-target-api# apt info ceph-iscsi
Package: ceph-iscsi
Version: 3.5-1
Status: install ok installed
Priority: optional
Section: python
Maintainer: Freexian Packaging Team<EMAIL_ADDRESS>Installed-Size: 575 kB
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: python3:any, tcmu-runner (>= 1.4.0), python3-configshell-fb, python3-cryptography, python3-flask, python3-netifaces, python3-openssl, python3-rados, python3-rbd, python3-rtslib-fb, python3-distutils, python3-rpm, python3-requests
Homepage: https://github.com/ceph/ceph-iscsi
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: common logic and CLI tools for creating and managing LIO gateways for Ceph
 It includes the rbd-target-api daemon which is responsible for
 restoring the state of LIO following a gateway reboot/outage and
 exporting a REST API to configure the system using tools like
 gwcli. It replaces the existing 'target' service.
 .
 There is also a second daemon rbd-target-gw which exports a REST API
 to gather statistics.
 .
 It also includes the CLI tool gwcli which can be used to configure
 and manage the Ceph iSCSI gateway, which replaces the existing
 targetcli CLI tool. This CLI tool utilizes the rbd-target-api server
 daemon to configure multiple gateways concurrently.

here are the logs
the crashes was yesterday night between 01/09 and 02/09 and 1am to 3am
cd-88tcmu-runner.log
cd-133rbd-target-api.log
cd-133rbd-target-api.log.1.log
cd-133tcmu-runner.log
cd-88rbd-target-api.log.1.log
cd-88rbd-target-api.log.2.log

Could you also upload the journal logs during the crash ?
$ journalctl -r > journal.log

From the above logs I couldn't know which service crashed.

From one of the tcmu-runner.log:
2021-09-02 01:20:29.923 1236 [WARN] tcmu_rbd_lock:762 rbd/rbd.disk_1: Acquired exclusive lock.
2021-09-02 01:20:32.683 1236 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-09-02 01:20:32.686 1236 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-09-02 01:22:08.320 1236 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-09-02 01:22:08.322 1236 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-09-02 01:43:56.224 1231 [INFO] load_our_module:547: Inserted module 'target_core_user'

This should be the same issue which has been fixed by https://github.com/open-iscsi/tcmu-runner/pull/667/commits/b48eeebaa7e36e6cfc78aafab7156bfa0a1eb955 in https://github.com/open-iscsi/tcmu-runner/pull/667.
Is that possible to test that PR in you setups ? Thanks.

@lxbsz @lightmans2
My test results are as follows：（3 nvme osds）
test case 1:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=1 -runtime=300 -time_based -group_reporting -name=test2
res：iops is 22.1k
test case 2:
fio -filename=/dev/sdam -direct=1 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=4 -runtime=300 -time_based -group_reporting -name=test2
res：iops is 3208
so：
When using multi-threaded testing, tcmu has performance problems. Now，i known is not caused by the rbd_lock，I guess it may be caused by the lock of tcmu's own process.
@lightmans2
you can test your ceph iscsi use test case1 and case2 , confirm whether the problem is caused by multiple processes.

root@kvm:~# fio -filename=/dev/rdb0 -direct=0 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=1 -runtime=300 -time_based -group_reporting -name=test2
test2: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.16
Starting 1 thread
fio: io_u error on file /dev/rdb0: No space left on device: write offset=7948804096, buflen=4096
fio: pid=2597, err=28/file:io_u.c:1787, func=io_u error, error=No space left on device

test2: (groupid=0, jobs=1): err=28 (file:io_u.c:1787, func=io_u error, error=No space left on device): pid=2597: Thu Sep  2 14:38:32 2021
  write: IOPS=33.0k, BW=4000KiB/s (4096kB/s)(4096B/1msec); 0 zone resets
    slat (nsec): min=1373, max=34785, avg=3668.42, stdev=5975.05
    clat (nsec): min=100228, max=100228, avg=100228.00, stdev= 0.00
     lat (nsec): min=136286, max=136286, avg=136286.00, stdev= 0.00
    clat percentiles (nsec):
     |  1.00th=[99840],  5.00th=[99840], 10.00th=[99840], 20.00th=[99840],
     | 30.00th=[99840], 40.00th=[99840], 50.00th=[99840], 60.00th=[99840],
     | 70.00th=[99840], 80.00th=[99840], 90.00th=[99840], 95.00th=[99840],
     | 99.00th=[99840], 99.50th=[99840], 99.90th=[99840], 99.95th=[99840],
     | 99.99th=[99840]
  lat (usec)   : 250=3.03%
  cpu          : usr=0.00%, sys=0.00%, ctx=0, majf=0, minf=1
  IO depths    : 1=3.0%, 2=6.1%, 4=12.1%, 8=24.2%, 16=48.5%, 32=6.1%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,33,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=4000KiB/s (4096kB/s), 4000KiB/s-4000KiB/s (4096kB/s-4096kB/s), io=4096B (4096B), run=1-1msec

root@kvm:~# fio -filename=/dev/rdb0 -direct=0 -iodepth=32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=10g -numjobs=4 -runtime=300 -time_based -group_reporting -name=test2
test2: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
...
fio-3.16
Starting 4 threads
fio: io_u error on file /dev/rdb0: No space left on device: write offset=7005753344, buflen=4096
fio: pid=2625, err=28/file:io_u.c:1787, func=io_u error, error=No space left on device
fio: io_u error on file /dev/rdb0: No space left on device: write offset=6449979392, buflen=4096
fio: pid=2623, err=28/file:io_u.c:1787, func=io_u error, error=No space left on device
fio: io_u error on file /dev/rdb0: No space left on device: write offset=7948804096, buflen=4096
fio: io_u error on file /dev/rdb0: No space left on device: write offset=8794103808, buflen=4096
fio: pid=2622, err=28/file:io_u.c:1787, func=io_u error, error=No space left on device
fio: pid=2624, err=28/file:io_u.c:1787, func=io_u error, error=No space left on device

test2: (groupid=0, jobs=4): err=28 (file:io_u.c:1787, func=io_u error, error=No space left on device): pid=2622: Thu Sep  2 14:38:51 2021
  write: IOPS=132k, BW=15.6MiB/s (16.4MB/s)(16.0KiB/1msec); 0 zone resets
    slat (nsec): min=1343, max=130153, avg=14340.23, stdev=14503.69
    clat (usec): min=442, max=450, avg=446.52, stdev= 4.08
     lat (usec): min=455, max=501, avg=479.62, stdev=19.70
    clat percentiles (usec):
     |  1.00th=[  445],  5.00th=[  445], 10.00th=[  445], 20.00th=[  445],
     | 30.00th=[  445], 40.00th=[  445], 50.00th=[  445], 60.00th=[  449],
     | 70.00th=[  449], 80.00th=[  449], 90.00th=[  449], 95.00th=[  449],
     | 99.00th=[  449], 99.50th=[  449], 99.90th=[  449], 99.95th=[  449],
     | 99.99th=[  449]
  lat (usec)   : 500=3.03%
  cpu          : usr=0.00%, sys=0.00%, ctx=12, majf=0, minf=4
  IO depths    : 1=3.0%, 2=6.1%, 4=12.1%, 8=24.2%, 16=48.5%, 32=6.1%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,132,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=15.6MiB/s (16.4MB/s), 15.6MiB/s-15.6MiB/s (16.4MB/s-16.4MB/s), io=16.0KiB (16.4kB), run=1-1msec

yes we can test it
the problem is only i can do it only at the afernoons because the storage medium productive :-) because our other datastores are full and we need urgent and fast new additional space.
if you can tell me or explain me how i upgrade or patch , then no problem
and of course i need a way back to the prior version as fallback

Are you using the cephadm/containers for the ceph-iscsi/tcmu-runner service ? If so I am afraid you need to update the package or install the tcmu-runner from source to override it on the node.

hi,
its a physical server with ubuntu 20.04 and ceph-iscsi installed from ceph debian repo as package. so no containers...
i read your documentation about building the gitsource ... but its for rpm systems...
i need help then to compile the packages as .deb or can you build it for me and put the .deb somewhere to download?

Currently I didn't have the .deb setups to build the package. I usually build them from source:
$ cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .
$ make && make install

You can try this.

i have this error
what i need ?
root@cd88-ceph-rgw-01:~/test/tcmu-runner# cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
TCMALLOC_LIB
    linked by target "handler_file_zbc" in directory /root/test/tcmu-runner
    linked by target "tcmu_static" in directory /root/test/tcmu-runner
    linked by target "tcmu-runner" in directory /root/test/tcmu-runner
    linked by target "tcmu-synthesizer" in directory /root/test/tcmu-runner
    linked by target "handler_file_optical" in directory /root/test/tcmu-runner
    linked by target "handler_rbd" in directory /root/test/tcmu-runner
    linked by target "tcmu" in directory /root/test/tcmu-runner
    linked by target "handler_qcow" in directory /root/test/tcmu-runner

-- Configuring incomplete, errors occurred!
See also "/root/test/tcmu-runner/CMakeFiles/CMakeOutput.log".

Okay i compiled it  and installit , i found the missing -dev package...
version 1.5.4 is installed
is he bugfix in this version?
root@cd88-ceph-rgw-01:~/test/tcmu-runner# cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .
-- Configuring done
-- Generating done
-- Build files have been written to: /root/test/tcmu-runner
root@cd88-ceph-rgw-01:~/test/tcmu-runner# make
Scanning dependencies of target handler_file_zbc
[  1%] Building C object CMakeFiles/handler_file_zbc.dir/scsi.c.o
[  3%] Building C object CMakeFiles/handler_file_zbc.dir/file_zbc.c.o
[  5%] Linking C shared library handler_file_zbc.so
[  5%] Built target handler_file_zbc
[  7%] Generating tcmuhandler-generated.c, tcmuhandler-generated.h
Scanning dependencies of target tcmu_static
[  9%] Building C object CMakeFiles/tcmu_static.dir/strlcpy.c.o
[ 11%] Building C object CMakeFiles/tcmu_static.dir/configfs.c.o
[ 13%] Building C object CMakeFiles/tcmu_static.dir/api.c.o
[ 15%] Building C object CMakeFiles/tcmu_static.dir/libtcmu.c.o
[ 17%] Building C object CMakeFiles/tcmu_static.dir/libtcmu-register.c.o
[ 19%] Building C object CMakeFiles/tcmu_static.dir/tcmuhandler-generated.c.o
[ 21%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_log.c.o
[ 23%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_config.c.o
[ 25%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_time.c.o
[ 27%] Linking C static library libtcmu_static.a
[ 27%] Built target tcmu_static
Scanning dependencies of target tcmu
[ 29%] Building C object CMakeFiles/tcmu.dir/strlcpy.c.o
[ 31%] Building C object CMakeFiles/tcmu.dir/configfs.c.o
[ 33%] Building C object CMakeFiles/tcmu.dir/api.c.o
[ 35%] Building C object CMakeFiles/tcmu.dir/libtcmu.c.o
[ 37%] Building C object CMakeFiles/tcmu.dir/libtcmu-register.c.o
[ 39%] Building C object CMakeFiles/tcmu.dir/tcmuhandler-generated.c.o
[ 41%] Building C object CMakeFiles/tcmu.dir/libtcmu_log.c.o
[ 43%] Building C object CMakeFiles/tcmu.dir/libtcmu_config.c.o
[ 45%] Building C object CMakeFiles/tcmu.dir/libtcmu_time.c.o
[ 47%] Linking C shared library libtcmu.so
[ 49%] Built target tcmu
Scanning dependencies of target tcmu-runner
[ 50%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_work.c.o
[ 52%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_cmd_handler.c.o
[ 54%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_aio.c.o
[ 56%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_device.c.o
[ 58%] Building C object CMakeFiles/tcmu-runner.dir/target.c.o
[ 60%] Building C object CMakeFiles/tcmu-runner.dir/alua.c.o
[ 62%] Building C object CMakeFiles/tcmu-runner.dir/scsi.c.o
[ 64%] Building C object CMakeFiles/tcmu-runner.dir/main.c.o
[ 66%] Building C object CMakeFiles/tcmu-runner.dir/tcmuhandler-generated.c.o
[ 68%] Linking C executable tcmu-runner
[ 70%] Built target tcmu-runner
Scanning dependencies of target tcmu-synthesizer
[ 72%] Building C object CMakeFiles/tcmu-synthesizer.dir/scsi.c.o
[ 74%] Building C object CMakeFiles/tcmu-synthesizer.dir/tcmu-synthesizer.c.o
[ 76%] Linking C executable tcmu-synthesizer
[ 76%] Built target tcmu-synthesizer
Scanning dependencies of target handler_file
[ 78%] Building C object CMakeFiles/handler_file.dir/file_example.c.o
[ 80%] Linking C shared library handler_file.so
[ 80%] Built target handler_file
Scanning dependencies of target consumer
[ 82%] Building C object CMakeFiles/consumer.dir/scsi.c.o
[ 84%] Building C object CMakeFiles/consumer.dir/consumer.c.o
[ 86%] Linking C executable consumer
[ 86%] Built target consumer
Scanning dependencies of target handler_file_optical
[ 88%] Building C object CMakeFiles/handler_file_optical.dir/scsi.c.o
[ 90%] Building C object CMakeFiles/handler_file_optical.dir/file_optical.c.o
[ 92%] Linking C shared library handler_file_optical.so
[ 92%] Built target handler_file_optical
Scanning dependencies of target handler_rbd
[ 94%] Building C object CMakeFiles/handler_rbd.dir/rbd.c.o
[ 96%] Linking C shared library handler_rbd.so
[ 96%] Built target handler_rbd
Scanning dependencies of target handler_qcow
[ 98%] Building C object CMakeFiles/handler_qcow.dir/qcow.c.o
[100%] Linking C shared library handler_qcow.so
[100%] Built target handler_qcow

root@cd88-ceph-rgw-01:~/test/tcmu-runner# ./tcmu-runner --version
tcmu-runner 1.5.4
root@cd88-ceph-rgw-01:~/test/tcmu-runner# make install
[  5%] Built target handler_file_zbc
[ 27%] Built target tcmu_static
[ 49%] Built target tcmu
[ 70%] Built target tcmu-runner
[ 76%] Built target tcmu-synthesizer
[ 80%] Built target handler_file
[ 86%] Built target consumer
[ 92%] Built target handler_file_optical
[ 96%] Built target handler_rbd
[100%] Built target handler_qcow
Install the project...
-- Install configuration: ""
-- Installing: /usr/lib/x86_64-linux-gnu/libtcmu.so.2.2
-- Up-to-date: /usr/lib/x86_64-linux-gnu/libtcmu.so.2
-- Installing: /usr/lib/x86_64-linux-gnu/libtcmu.so
-- Installing: /usr/bin/tcmu-runner
-- Set runtime path of "/usr/bin/tcmu-runner" to ""
-- Installing: /usr/lib/x86_64-linux-gnu/tcmu-runner/handler_file_optical.so
-- Installing: /usr/lib/x86_64-linux-gnu/tcmu-runner/handler_file_zbc.so
-- Installing: /usr/lib/x86_64-linux-gnu/tcmu-runner/handler_rbd.so
-- Installing: /usr/lib/x86_64-linux-gnu/tcmu-runner/handler_qcow.so
-- Installing: /etc/tcmu//tcmu.conf.old
-- Installing: /etc/tcmu//tcmu.conf
-- Installing: /etc/logrotate.d/tcmu-runner.bak/tcmu-runner
-- Installing: /etc/logrotate.d/tcmu-runner
-- Installing: /usr/share/dbus-1/system-services/org.kernel.TCMUService1.service
-- Installing: /etc/dbus-1/system.d/tcmu-runner.conf
-- Installing: /usr/lib/systemd/system/tcmu-runner.service
-- Installing: /usr/share/man/man8/tcmu-runner.8

root@cd88-ceph-rgw-01:~# systemctl daemon-reload
root@cd88-ceph-rgw-01:~# systemctl restart tcmu-runner.service
root@cd88-ceph-rgw-01:~# systemctl status tcmu-runner.service
● tcmu-runner.service - LIO Userspace-passthrough daemon
     Loaded: loaded (/lib/systemd/system/tcmu-runner.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-09-03 12:49:42 CEST; 6s ago
       Docs: man:tcmu-runner(8)
   Main PID: 12172 (tcmu-runner)
      Tasks: 22 (limit: 256201)
     Memory: 28.3M
     CGroup: /system.slice/tcmu-runner.service
             └─12172 /usr/bin/tcmu-runner

looks better now
iscsi gateway 1:
root@cd88-ceph-rgw-01:~# tail -f /var/log/tcmu-runner.log
2021-09-03 13:01:02.722 12172 [WARN] tcmu_rbd_lock:947 rbd/rbd.disk_1: Acquired exclusive lock.
2021-09-03 13:01:02.722 12172 [INFO] tcmu_acquire_dev_lock:489 rbd/rbd.disk_1: Write lock acquisition successful
2021-09-03 13:01:06.868 12172 [WARN] tcmu_notify_lock_lost:271 rbd/rbd.disk_1: Async lock drop. Old state 5
2021-09-03 13:01:06.882 12172 [INFO] alua_implicit_transition:581 rbd/rbd.disk_1: Starting read lock acquisition operation.
2021-09-03 13:01:06.965 12172 [INFO] tcmu_rbd_rm_stale_entries_from_blacklist:340 rbd/rbd.disk_1: removing addrs: {<IP_ADDRESS>:0/1398731605}
2021-09-03 13:01:07.919 12172 [INFO] tcmu_rbd_open:1162 rbd/rbd.disk_1: address: {<IP_ADDRESS>:0/583028032}
2021-09-03 13:01:07.919 12172 [INFO] tcmu_acquire_dev_lock:486 rbd/rbd.disk_1: Read lock acquisition successful
2021-09-03 13:01:07.923 12172 [INFO] alua_implicit_transition:592 rbd/rbd.disk_1: Starting write lock acquisition operation.
2021-09-03 13:01:09.073 12172 [WARN] tcmu_rbd_lock:947 rbd/rbd.disk_1: Acquired exclusive lock.
2021-09-03 13:01:09.073 12172 [INFO] tcmu_acquire_dev_lock:489 rbd/rbd.disk_1: Write lock acquisition successful

iscsi gateway 2
root@cd133-ceph-rgw-01:~/test/tcmu-runner# tail -f /var/log/tcmu-runner.log
2021-09-03 13:01:05.854 1230 [INFO] alua_implicit_transition:570 rbd/rbd.disk_1: Starting lock acquisition operation.
2021-09-03 13:01:06.941 1230 [WARN] tcmu_rbd_lock:762 rbd/rbd.disk_1: Acquired exclusive lock.
2021-09-03 13:01:24.890 1230 [ERROR] tcmu_rbd_has_lock:515 rbd/rbd.disk_1: Could not check lock ownership. Error: Cannot send after transport endpoint shutdown.
2021-09-03 13:01:51.297 1230 [CRIT] main:1390: Exiting...
2021-09-03 13:01:51.363 830507 [CRIT] main:1302: Starting...
2021-09-03 13:01:51.363 830507 [INFO] tcmur_register_handler:92: Handler fbo is registered
2021-09-03 13:01:51.363 830507 [INFO] tcmur_register_handler:92: Handler zbc is registered
2021-09-03 13:01:51.364 830507 [INFO] tcmur_register_handler:92: Handler qcow is registered
2021-09-03 13:01:51.403 830507 [INFO] tcmur_register_handler:92: Handler rbd is registered
2021-09-03 13:01:51.512 830507 [INFO] tcmu_rbd_open:1162 rbd/rbd.disk_1: address: {<IP_ADDRESS>:0/1876153824}
2021-09-03 13:03:00.842 830507 [INFO] alua_implicit_transition:581 rbd/rbd.disk_1: Starting read lock acquisition operation.
2021-09-03 13:03:00.842 830507 [INFO] tcmu_acquire_dev_lock:486 rbd/rbd.disk_1: Read lock acquisition successful

Hey @lightmans2
Looks cool. Thanks very much for your tests.
For the tcmalloc issue we may need to fix this in extra/install_dep.sh.
BTW, with this PR have hit any other issue ? Thanks.

I am afraid you were using the 1.5.2 instead not the 1.5.4, we can see tcmu_rbd_has_lock:515, in the version 1.5.4 it not  Line#515 any more.
This will only happen in version 1.5.2:
 508 static int tcmu_rbd_has_lock(struct tcmu_device *dev)
 509 {
 510         struct tcmu_rbd_state *state = tcmur_dev_get_private(dev);
 511         int ret, is_owner;
 512
 513         ret = rbd_is_exclusive_lock_owner(state->image, &is_owner);
 514         if (ret < 0) {
 515                 tcmu_dev_err(dev, "Could not check lock ownership. Error: %s.\n",
 516                              strerror(-ret));
 517                 if (ret == -ESHUTDOWN || ret == -ETIMEDOUT)
 518                         return ret;
 519
 520                 /* let initiator figure things out */
 521                 return -EIO;
 522         } else if (is_owner) {
 523                 tcmu_dev_dbg(dev, "Is owner\n");
 524                 return 1;
 525         }
 526         tcmu_dev_dbg(dev, "Not owner\n");
 527
 528         return 0;
 529 }

I am afraid your installing from source didn't work. Or the path you choose to install is not the same with the package did, so your didn't override the ones from the pacakge.

hi lxbsz,
hmm okay... can you help me to fix that? iam not a developer so dont know how to fix that or to correct that.

hi lxbsz,
hmm okay... can you help me to fix that? iam not a developer so dont know how to fix that or to correct that.

Do you mean the install_deps.sh, right ? Yeah I will fix this later.

the gateways are now stable and the performance are not between 100 - 200 mb/s

For building from source issue, you can check what's the install paths for all the binaries in the tcmu-runner 1.5.2 deb package, then you can specify the install prefix in -DCMAKE_INSTALL_PREFIX= :
# cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .

If the https://github.com/open-iscsi/tcmu-runner/pull/667 works well for you I will merge it and do the new release soon.

hi lxbsz,
hmm okay... can you help me to fix that? iam not a developer so dont know how to fix that or to correct that.

Do you mean the install_deps.sh, right ? Yeah I will fix this later.

the gateways are now stable and the performance are not between 100 - 200 mb/s

For building from source issue, you can check what's the install paths for all the binaries in the tcmu-runner 1.5.2 deb package, then you can specify the install prefix in -DCMAKE_INSTALL_PREFIX= :
# cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .

Hi lxbsz,
you sayed that the install prefix are maybe wrong...
i analyzed the dpkg files/package of the ceph-iscsi in debian/ubuntu.
how yould the path look like?
cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .
the original looks like that:
root@cd133-ceph-mon-01:~# apt-file list ceph-iscsi
ceph-iscsi: /etc/init.d/rbd-target-api
ceph-iscsi: /etc/init.d/rbd-target-gw
ceph-iscsi: /lib/systemd/system/rbd-target-api.service
ceph-iscsi: /lib/systemd/system/rbd-target-gw.service
ceph-iscsi: /usr/bin/gwcli
ceph-iscsi: /usr/bin/rbd-target-api
ceph-iscsi: /usr/bin/rbd-target-gw
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi-3.4.egg-info/PKG-INFO
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi-3.4.egg-info/dependency_links.txt
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi-3.4.egg-info/top_level.txt
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/__init__.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/alua.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/backstore.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/client.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/common.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/discovery.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/gateway.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/gateway_object.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/gateway_setting.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/group.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/lio.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/lun.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/metrics.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/settings.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/target.py
ceph-iscsi: /usr/lib/python3/dist-packages/ceph_iscsi_config/utils.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/__init__.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/ceph.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/client.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/gateway.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/hostgroup.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/node.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/storage.py
ceph-iscsi: /usr/lib/python3/dist-packages/gwcli/utils.py
ceph-iscsi: /usr/share/doc/ceph-iscsi/changelog.Debian.gz
ceph-iscsi: /usr/share/doc/ceph-iscsi/copyright
ceph-iscsi: /usr/share/man/man8/gwcli.8.gz

hi lxbsz,
hmm okay... can you help me to fix that? iam not a developer so dont know how to fix that or to correct that.

Do you mean the install_deps.sh, right ? Yeah I will fix this later.

the gateways are now stable and the performance are not between 100 - 200 mb/s

For building from source issue, you can check what's the install paths for all the binaries in the tcmu-runner 1.5.2 deb package, then you can specify the install prefix in -DCMAKE_INSTALL_PREFIX= :
# cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .

Hi lxbsz,
you sayed that the install prefix are maybe wrong...
i analyzed the dpkg files/package of the ceph-iscsi in debian/ubuntu.
how should the path look like?
cmake -Dwith-glfs=false -DSUPPORT_SYSTEMD=ON -DCMAKE_INSTALL_PREFIX=/usr .
the original looks like that:

I didn't try this in Debian yet, the above will always be true for Centos/Fedora/RHEL.

root@cd133-ceph-mon-01:~# apt-file list ceph-iscsi

It should be for tcmu-runner package here.
But it seems the abbove prefix is correct, then I have no idea why you were still running the old tcmu-runner version.
After you installed it did you reload and restart it ?

Hi lxbsz,
yes i rebooted booth gatway servers and checked the tcmu-runner version its 1.5.4

we have build 3x osd nodes with 60 bluestore osd with and 60x6TB  spinning disks, 12 ssd´s and 3nvme.
osd nodes have 32cores and 256gb Ram
the osd disk are connected to a scsi raid controller ... each disk is configured as raid0 and with write back enabled to use the raid controller cache etc.
we have 3x mons and 2x iscsi gateways
all servers are connected on a 10Gbit network (switches)
all servers have two 10gbit network adapter configured as bond-rr
we created one rbd pool with autoscaling and 128pg (at the moment)
in the pool are at the moment 5 rbd images... 2x 10tb and 3x500gb with feature exlusic lock and striping v2 (4mb obj / 1mb stipe / count 4)
All the images are attached to the two iscsi gateays running tcmu-runner 1.5.4 and exposed as iscsi target
we have 6 esxi 6.7u3 servers as computed node connected to the ceph iscsi target

esxi iscsi config:
esxcli system settings advanced set -o /ISCSI/MaxIoSizeKB -i 512
esxcli system module parameters set -m iscsi_vmk -p iscsivmk_LunQDepth=64
esxcli system module parameters set -m iscsi_vmk -p iscsivmk_HostQDepth=64
esxcli system settings advanced set --int-value 1 --option /DataMover/HardwareAcceleratedMove
the osd nodes, mons, rgw/iscsi gateways and esxi nodes are all connected to the 10gbit network with bond-rr
rbd benchmark test:
root@cd133-ceph-osdh-01:~# rados bench -p rbd 10 write
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_cd133-ceph-osdh-01_87894
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      16        69        53   211.987       212    0.250578    0.249261
    2      16       129       113   225.976       240    0.296519    0.266439
    3      16       183       167   222.641       216    0.219422    0.273838
    4      16       237       221   220.974       216    0.469045     0.28091
    5      16       292       276   220.773       220    0.249321     0.27565
    6      16       339       323   215.307       188    0.205553     0.28624
    7      16       390       374   213.688       204    0.188404    0.290426
    8      16       457       441   220.472       268    0.181254    0.286525
    9      16       509       493   219.083       208    0.250538    0.286832
   10      16       568       552   220.772       236    0.307829    0.286076
Total time run:         10.2833
Total writes made:      568
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     220.941
Stddev Bandwidth:       22.295
Max bandwidth (MB/sec): 268
Min bandwidth (MB/sec): 188
Average IOPS:           55
Stddev IOPS:            5.57375
Max IOPS:               67
Min IOPS:               47
Average Latency(s):     0.285903
Stddev Latency(s):      0.115162
Max latency(s):         0.88187
Min latency(s):         0.119276
Cleaning up (deleting benchmark objects)
Removed 568 objects
Clean up completed and total clean up time :3.18627

the rbd benchmark says that min 250 mb/s is possible... but i saw realy much more... up to 550mb/s
if i start iftop on one osd node i see the ceph iscsi gw names as rgw and the traffic is nearly 80mb/s

the ceph dashboard shows that the write iscsi performance are only 40mb/s
the max value i saw was between 40 and 60mb/s.. very poor

if i look into the vcenter and esxi datastore performance i see very high storage device latencys between 50 and 100ms... very bad

root@cd133-ceph-mon-01:/home/cephadm# ceph config dump
WHO                                               MASK       LEVEL     OPTION                                       VALUE                                                                                RO
global                                                       basic     container_image                              docker.io/ceph/ceph@sha256:829ebf54704f2d827de00913b171e5da741aad9b53c1f35ad59251524790eceb  *
global                                                       advanced  journal_max_write_bytes<PHONE_NUMBER>
global                                                       advanced  journal_max_write_entries                    10000
global                                                       advanced  mon_osd_cache_size                           1024
global                                                       dev       osd_client_watch_timeout                     15
global                                                       dev       osd_heartbeat_interval                       5
global                                                       advanced  osd_map_cache_size                           128
global                                                       advanced  osd_max_write_size                           512
global                                                       advanced  rados_osd_op_timeout                         5
global                                                       advanced  rbd_cache_max_dirty                          134217728
global                                                       advanced  rbd_cache_max_dirty_age                      5.000000
global                                                       advanced  rbd_cache_size                               268435456
global                                                       advanced  rbd_op_threads                               2
  mon                                                        advanced  auth_allow_insecure_global_id_reclaim        false
  mon                                                        advanced  cluster_network                              <IP_ADDRESS>/24                                                                                *
  mon                                                        advanced  public_network                               <IP_ADDRESS>/24                                                                                *
  mgr                                                        advanced  mgr/cephadm/container_init                   True                                                                                *
  mgr                                                        advanced  mgr/cephadm/device_enhanced_scan             true                                                                                *
  mgr                                                        advanced  mgr/cephadm/migration_current                2                                                                                *
  mgr                                                        advanced  mgr/cephadm/warn_on_stray_daemons            false                                                                                *
  mgr                                                        advanced  mgr/cephadm/warn_on_stray_hosts              false                                                                                *
  mgr                                                        advanced  mgr/dashboard/<IP_ADDRESS>/server_addr                                                                                *
  mgr                                                        advanced  mgr/dashboard/ALERTMANAGER_API_HOST          http://<IP_ADDRESS>:9093                                                                   *
  mgr                                                        advanced  mgr/dashboard/GRAFANA_API_SSL_VERIFY         false                                                                                *
  mgr                                                        advanced  mgr/dashboard/GRAFANA_API_URL                https://<IP_ADDRESS>:3000                                                                  *
  mgr                                                        advanced  mgr/dashboard/ISCSI_API_SSL_VERIFICATION     true                                                                                *
  mgr                                                        advanced  mgr/dashboard/NAME/server_port               80                                                                                *
  mgr                                                        advanced  mgr/dashboard/PROMETHEUS_API_HOST            http://<IP_ADDRESS>:9095                                                                   *
  mgr                                                        advanced  mgr/dashboard/PROMETHEUS_API_SSL_VERIFY      false                                                                                *
  mgr                                                        advanced  mgr/dashboard/RGW_API_ACCESS_KEY             W8VEKVFDK1RH5IH2Q3GN                                                                         *
  mgr                                                        advanced  mgr/dashboard/RGW_API_SECRET_KEY             IkIjmjfh3bMLrPOlAFbMfpigSIALAQoKGEHzZgxv                                                     *
  mgr                                                        advanced  mgr/dashboard/camdatadash/server_addr        <IP_ADDRESS>                                                                               *
  mgr                                                        advanced  mgr/dashboard/camdatadash/ssl_server_port    8443                                                                                *
  mgr                                                        advanced  mgr/dashboard/cd133-ceph-mon-01/server_addr                                                                                *
  mgr                                                        advanced  mgr/dashboard/dasboard/server_port           80                                                                                *
  mgr                                                        advanced  mgr/dashboard/dashboard/server_addr          <IP_ADDRESS>                                                                               *
  mgr                                                        advanced  mgr/dashboard/dashboard/ssl_server_port      8443                                                                                *
  mgr                                                        advanced  mgr/dashboard/server_addr                    <IP_ADDRESS>                                                                                *
  mgr                                                        advanced  mgr/dashboard/server_port                    8080                                                                                *
  mgr                                                        advanced  mgr/dashboard/ssl                            false                                                                                *
  mgr                                                        advanced  mgr/dashboard/ssl_server_port                8443                                                                                *
  mgr                                                        advanced  mgr/orchestrator/orchestrator                cephadm
  mgr                                                        advanced  mgr/prometheus/server_addr                   <IP_ADDRESS>                                                                                *
  mgr                                                        advanced  mgr/telemetry/channel_ident                  true                                                                                *
  mgr                                                        advanced  mgr/telemetry/contact<EMAIL_ADDRESS>                                                                              *
  mgr                                                        advanced  mgr/telemetry/description                    ceph cluster                                                                         *
  mgr                                                        advanced  mgr/telemetry/enabled                        true                                                                                *
  mgr                                                        advanced  mgr/telemetry/last_opt_revision              3                                                                                *
  osd                                                        dev       bluestore_cache_autotune                     false
  osd                                             class:ssd  dev       bluestore_cache_autotune                     false
  osd                                                        dev       bluestore_cache_size<PHONE_NUMBER>
  osd                                             class:ssd  dev       bluestore_cache_size<PHONE_NUMBER>
  osd                                                        dev       bluestore_cache_size_hdd<PHONE_NUMBER>
  osd                                                        dev       bluestore_cache_size_ssd<PHONE_NUMBER>
  osd                                             class:ssd  dev       bluestore_cache_size_ssd<PHONE_NUMBER>
  osd                                                        advanced  bluestore_default_buffered_write             true
  osd                                             class:ssd  advanced  bluestore_default_buffered_write             true
  osd                                                        advanced  osd_max_backfills                            1
  osd                                             class:ssd  dev       osd_memory_cache_min<PHONE_NUMBER>
  osd                                             class:hdd  basic     osd_memory_target<PHONE_NUMBER>
  osd                                             class:ssd  basic     osd_memory_target<PHONE_NUMBER>
  osd                                                        advanced  osd_recovery_max_active                      3
  osd                                                        advanced  osd_recovery_max_single_start                1
  osd                                                        advanced  osd_recovery_sleep                           0.000000
    client.rgw.ceph-rgw.cd133-ceph-rgw-01.klvrwk             basic     rgw_frontends                                beast port=8000                                                                              *
    client.rgw.ceph-rgw.cd133-ceph-rgw-01.ptmqcm             basic     rgw_frontends                                beast port=8001                                                                              *
    client.rgw.ceph-rgw.cd88-ceph-rgw-01.czajah              basic     rgw_frontends                                beast port=8000                                                                              *
    client.rgw.ceph-rgw.cd88-ceph-rgw-01.pdknfg              basic     rgw_frontends                                beast port=8000                                                                              *
    client.rgw.ceph-rgw.cd88-ceph-rgw-01.qkdlfl              basic     rgw_frontends                                beast port=8001                                                                              *
    client.rgw.ceph-rgw.cd88-ceph-rgw-01.tdsxpb              basic     rgw_frontends                                beast port=8001                                                                              *
    client.rgw.ceph-rgw.cd88-ceph-rgw-01.xnadfr              basic     rgw_frontends                                beast port=8001                                                                              *

can somebody explain me what i am doing wrong or what can i do to get a better performance with ceph-iscsi?
doesnt matter what i do or what i tweak the write performance will not get better.
i already experimented with gwcli and the iscsi queue and other settings.
actually i set:
hw_max_sectors 8192
max_data_area_mb 32
cmdsn_depth 64 / the esxi nodes are alredy set fixed to 64 max iscsi commands
everything is fine and multipathing is workind and the recovery is fast ... but the iscsi very slow and i dont know why.
can somebody help me maybe?


New relevant arXiv paper

Add-it: Training-Free Object Insertion in Images With Pretrained Diffusion Models
https://arxiv.org/abs/2411.07232

I have fixed this issue anh @tamlhp. Thank you!


chore: add missing init.py

Follow up https://github.com/ansible/eda-server/pull/696, add missing init.py

The init.py is not required for packages.


[BUG] Wrong metric expression for Deployment/ReplicaSet Metric's section

Rancher Server Setup
Rancher version: 2.7.9
Number of nodes: 3
Node OS version: Ubunutu 20.04 LTS
Monitoring version:
102.0.2+up40.1.2
Issue
This happens for any deployment/ReplicaSet in the whole cluster.
In the RancherUI, the CPU and memory metrics in the Metrics tab of any Deployment/Replicaset are wrong. They display double the amount of the actual usage.
Business impact:
Metrics are misleading.
Other
SURE-7237

Duplicate of https://github.com/rancher/rancher/issues/24343


Add WASM_BINDGEN_DRIVER_TIMEOUT

This PR introduces the WASM_BINDGEN_DRIVER_TIMEOUT environment variable for wasm-bindgen-test-runner, which sets the timeout for connecting to the test driver.
Before this PR the timeout was fixed to 5 seconds, which failed often when testing Safari in GitHub Actions CI. My experience is that the MacOS ARM runners, nowadays the default, tend to stall quite a lot, which I believe was the reason why this triggered the timeout so often and made CIs fail consistently.

Turns out this wasn't the issue after all. I'm gonna make a new PR shortly.
@RunDevelopment I appreciate you taking a look :heart:!


fix(idempotency): use ExpressionAttributeNames in DynamoDBPersistenceLayer _put_record

Issue #, if available: #693
Description of changes:

Use ExpressionAttributeNames in DynamoDBPersistenceLayer _put_record call to to table.put_item.
Checklist

[x] Meet tenets criteria
[x] Update tests
[ ] Update docs
[x] PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you so much @Tankanow - LGTM; merging!


Parallel requests and Exception handling

The program below logs the error when using 4.0.0, but when I upgrade to 5.0.0 it no longer logs the error
module Main where

import Prelude

import Control.Monad.Aff (Aff, launchAff)
import Control.Monad.Aff.Console (log, logShow)
import Control.Monad.Eff.Exception (EXCEPTION, error)
import Control.Monad.Error.Class (throwError, try)
import Control.Parallel (parallel, sequential)
import Data.Tuple (Tuple(..))
import Network.HTTP.Affjax (AJAX, get)

getPostbin :: forall eff.  Aff (exception :: EXCEPTION, ajax :: AJAX | eff) String
getPostbin = do
  resp <- get "http://postb.in/BgIt83CL"
  void $ throwError (error "Oops")
  pure resp.response

main = void $ launchAff do
    t <- try $ sequential $ Tuple <$> parallel getPostbin <*> parallel getPostbin
    logShow t

Is it the "Oops" error you're expecting to see? This is down to a change in Aff rather than affjax, and I think it may be intentional. /cc @natefaubion

Hmm maybe you're right then! I just took a look at the diff between v4 and v5, and although it's "just" the aff update it wasn't entirely straight forward.

can you see the error if you do main = runAff_ traceAnyA do ...?

Unfortunately it's still not showing with that change

This is probably https://github.com/slamdata/purescript-affjax/issues/112. When running things in parallel, if one throws an exception the runtime will cancel the other fibers. However cancellation is broken, and so the canceller never yields, hanging it.


TagSet object not in asn1Spec

At least 0.3.7 was working fine, now there is an error while trying to access a resource. Looks like that this is related to the encoder optimization.
pyasn1.error.PyAsn1Error: <TagSet object at 0x7f6b9803f160 tags 0:32:16> not in asn1Spec: <OctetString schema object at 0x7f6b78414ac8 tagSet <TagSet object at 0x7f6b981e8cf8 tags 0:0:4> encoding iso-8859-1>

$ pip3 freeze | grep pyasn1
pyasn1==0.4.2
pyasn1-modules==0.2.1

I guess this is what happens when you run a decoder over some serialization.
Is it that this serialization is being produced differently by 0.4.2 encoder? Or is it the same serialization which still works with 0.3.7 decoder but does not with 0.4.2?
Could you please give me a reproducer? If not, second best option would be a debug log:
from pyasn1 import debug
debug.setLogger(debug.Debug('all'))

I could try to guess what happens from the full traceback, but I it is way tricker.

The error occurs when using 0.4.2 with sleekxmpp 1.3.2 and a server that supports TLS. The same setup works with 0.3.7.

Traceback (most recent call last):
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/xmlstream.py", line 1490, in _process
    if not self.__read_xml():
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/xmlstream.py", line 1562, in __read_xml
    self.__spawn_event(xml)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/xmlstream.py", line 1630, in __spawn_event
    handler.prerun(stanza_copy)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/handler/callback.py", line 64, in prerun
    self.run(payload, True)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/handler/callback.py", line 76, in run
    self._pointer(payload)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/features/feature_starttls/starttls.py", line 64, in _handle_starttls_proceed
    if self.xmpp.start_tls():
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/xmlstream.py", line 887, in start_tls
    cert.verify(self._expected_server_name, self._der_cert)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/cert.py", line 142, in verify
    cert_names = extract_names(raw_cert)
  File "/runner/lib64/python3.6/site-packages/sleekxmpp/xmlstream/cert.py", line 73, in extract_names
    asn1Spec=OctetString())[0]
  File "/runner/lib64/python3.6/site-packages/pyasn1/codec/ber/decoder.py", line 1318, in __call__
    '%s not in asn1Spec: %r' % (tagSet, asn1Spec)
pyasn1.error.PyAsn1Error: <TagSet object at 0x7f53f5fb74e0 tags 0:32:16> not in asn1Spec: <OctetString schema object at 0x7f53f5f51d68 tagSet <TagSet object at 0x7f540c3cef28 tags 0:0:4> encoding iso-8859-1>

I'm getting a similar error parsing TLS certificates following a system upgrade to 0.4.2. Here's a code excerpt.
    for extension in core['extensions']:
        if extension['extnID'] == rfc2459.id_ce_subjectAltName:
            octet_string = decoder.decode(extension.getComponentByName('extnValue'), asn1Spec=OctetString())[0]
            (san_list, r) = decoder.decode(octet_string, rfc2459.SubjectAltName())
            for san_struct in san_list:
                if san_struct.getName() == 'dNSName':
                    fqdns.add(str(san_struct.getComponent()))

The traceback.
Traceback (most recent call last):
  File "/root/bin/renew_certificates.py", line 138, in <module>
    config['admin_email'], staging=args.staging, verbose=args.verbose)
  File "/root/bin/renew_certificates.py", line 113, in handle_certificates
    (fqdns, expiration_date) = parse_certificate(cert_path)
  File "/root/bin/renew_certificates.py", line 39, in parse_certificate
    octet_string = decoder.decode(extension.getComponentByName('extnValue'), asn1Spec=OctetString())[0]
  File "/usr/lib/python3.6/site-packages/pyasn1/codec/ber/decoder.py", line 1318, in __call__
    '%s not in asn1Spec: %r' % (tagSet, asn1Spec)
pyasn1.error.PyAsn1Error: <TagSet object at 0x7fe9b1da5668 tags 0:32:16> not in asn1Spec: <OctetString schema object at 0x7fe9b18f5128 tagSet <TagSet object at 0x7fe9b1f97da0 tags 0:0:4> encoding iso-8859-1>

Using the 0.4.2-1 package for Archlinux with Python 3.6.3

This must have something to do with the OpenType support feature in pyasn1 0.4.x release.
I'm trying to reproduce this locally, if anyone could paste a working reproducer (code + cert) - that would be helpful! ;-)

The code I pasted earlier is part of a short script for renewing Let's Encrypt certificates automatically. pyasn1 is used to read some data (commonName, subjectAltName and notAfter) from the cert. The crash occurs while reading subjectAltName value. Here is the full script for reference.
#!/usr/bin/env python3
# -*- coding: UTF-8 -*-

import os, sys, pwd, subprocess, re, argparse
from datetime import datetime

from pyasn1_modules import pem, rfc2459
from pyasn1.codec.der import decoder
from pyasn1.type.univ import OctetString

import yaml

CONF_FILE = '/etc/letsencrypt/renew.yaml'
RE_CERTIFICATE_FILENAME = re.compile(r'^(\d+)_cert.crt$')

def parse_certificate(certificate_path):
    fqdns = set()

    substrate = pem.readPemFromFile(open(certificate_path))
    cert = decoder.decode(substrate, asn1Spec=rfc2459.Certificate())[0]
    core = cert['tbsCertificate']

    # Extract CommonName
    for rdnss in core['subject']:
        for rdns in rdnss:
            for name in rdns:
                if name.getComponentByName('type') == rfc2459.id_at_commonName:
                    value = decoder.decode(name.getComponentByName('value'), asn1Spec=rfc2459.DirectoryString())[0]
                    fqdns.add(str(value.getComponent()))

    # extract notAfter datetime
    notAfter = str(core['validity'].getComponentByName('notAfter').getComponent()).strip('Z')
    (year, month, day, hour, minute, seconds) = [int(notAfter[i:i+2]) for i in range(0, len(notAfter), 2)]
    expiration_date = datetime(2000 + year, month, day, hour, minute, seconds)

    # Extract SubjectAltName
    for extension in core['extensions']:
        if extension['extnID'] == rfc2459.id_ce_subjectAltName:
            octet_string = decoder.decode(extension.getComponentByName('extnValue'), asn1Spec=OctetString())[0]
            (san_list, r) = decoder.decode(octet_string, rfc2459.SubjectAltName())
            for san_struct in san_list:
                if san_struct.getName() == 'dNSName':
                    fqdns.add(str(san_struct.getComponent()))
    return (fqdns, expiration_date)

def renew_certificate(cn, webroot, fqdns, working_dir, admin_email, staging = False, verbose = False):
    cert_symlink = 'latest_cert.crt'
    chain_symlink = 'latest_chain.pem'
    fullchain_symlink = 'latest_fullchain.pem'

    os.chdir(working_dir)
    latest = os.readlink(cert_symlink)
    serial = int(RE_CERTIFICATE_FILENAME.match(latest).group(1))

    new_cert = '{:04d}_cert.crt'.format(serial + 1)
    new_fullchain = '{:04d}_fullchain.pem'.format(serial + 1)
    new_chain = '{:04d}_chain.pem'.format(serial + 1)

    command = ['certbot', 'certonly', '-n', '-q',
            '--webroot', '-w', webroot,
            ]
    for fqdn in fqdns:
        command.extend(['-d', fqdn])
    command.extend(['--email', admin_email,
            '--csr', os.path.join(working_dir, cn + '.csr'),
            '--cert-path', os.path.join(working_dir, new_cert),
            '--fullchain-path', os.path.join(working_dir, new_fullchain),
            '--chain-path', os.path.join(working_dir, new_chain),
            ])
    if staging:
        command.extend(['--staging', '--break-my-certs'])
    if verbose:
        subprocess.call(['echo'] + command)
    ret_code = subprocess.call(command)
    if verbose:
        print(ret_code)

    if ret_code == 0:
        if os.path.exists(new_cert):
            if os.path.exists(cert_symlink):
                os.remove(cert_symlink)
            os.symlink(new_cert, cert_symlink)
        if os.path.exists(new_chain):
            if os.path.exists(chain_symlink):
                os.remove(chain_symlink)
            os.symlink(new_chain, chain_symlink)
        if os.path.exists(new_fullchain):
            if os.path.exists(fullchain_symlink):
                os.remove(fullchain_symlink)
            os.symlink(new_fullchain, fullchain_symlink)

def restart_daemons(daemons, verbose = False):
    for daemon in daemons:
        command = ['systemctl', daemon['action'], daemon['name']]
        if verbose:
            subprocess.call(['echo'] + command)
        ret_code = subprocess.call(command)
        if verbose:
            print(ret_code)

def handle_certificates(cert_root, www_root, threshold, daemons, admin_email, staging = False, verbose = False):
    will_restart_daemons = False
    for site in os.listdir(cert_root):
        if verbose:
            print('Evaluating', site)

        site_path = os.path.join(cert_root, site)
        owner = pwd.getpwuid(os.stat(site_path).st_uid).pw_name
        webroot = os.path.join(www_root, owner, site)
        cert_path = os.path.join(site_path, 'latest_cert.crt')

        if os.path.exists(cert_path):
            (fqdns, expiration_date) = parse_certificate(cert_path)
            if verbose:
                print(fqdns)

            now = datetime.now()
            delta = expiration_date - now
            if now >= expiration_date or delta.days <= threshold:
                if verbose:
                    print('Renewing, expired or expires in', delta.days, 'days, less than', threshold)
                renew_certificate(site, webroot, fqdns, site_path, admin_email, staging, verbose)
                will_restart_daemons = True
    if will_restart_daemons:
        restart_daemons(daemons, verbose)

if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('-v', '--verbose', action='store_true', help='talk more')
    parser.add_argument('-s', '--staging', action='store_true',
            help='issue staging certificates (useful for testing purposes)')
    parser.add_argument('-c', '--config', default=CONF_FILE,
            help='path to a config file (default: {})'.format(CONF_FILE))
    args = parser.parse_args()
    config = yaml.load(open(args.config))

    handle_certificates(config['certs_root'], config['www_root'], config['threshold'], config['daemons'],
            config['admin_email'], staging=args.staging, verbose=args.verbose)

Here is the small config filed used with this script.
certs_root:
    /etc/letsencrypt/live
www_root:
    /var/www
admin_email:
<EMAIL_ADDRESS>threshold:
    30
daemons:
    - name:
        nginx
      action:
        reload

And here is the certificate crashing the script with text data (though I suspect any certificate will crash it, as the SAN isn't particularly fancy)
-----BEGIN CERTIFICATE-----
MIIEVzCCAz+gAwIBAgISA3/ikQnQ0zcdEYpxMrbISAe1MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA5MzAyMTAwMTVaFw0x
NzEyMjkyMTAwMTVaMBwxGjAYBgNVBAMTEXFjaGF0LmxvcmRyYW4ubmV0MHYwEAYH
KoZIzj0CAQYFK4EEACIDYgAEGoTG6dTiWGMEzrGxZkCCEc5oTxTpndrwhdaXu5VQ
ZBqTFE+biqEtW45Ip5ghsrmI2kKKWjw4IIdpI0SNnIlcvOjWIsKnAC9/HJeS6o3c
O/5YBM0p8fTNoqtnNAxwjxXKo4ICETCCAg0wDgYDVR0PAQH/BAQDAgeAMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBTqzEN+pvfQifP+lleAPoxI1ltfaTAfBgNVHSMEGDAWgBSoSmpjBH3duubRObem
RWXv86jsoTBvBggrBgEFBQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3Nw
LmludC14My5sZXRzZW5jcnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0
LmludC14My5sZXRzZW5jcnlwdC5vcmcvMBwGA1UdEQQVMBOCEXFjaGF0LmxvcmRy
YW4ubmV0MIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB
1jAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsG
AQUFBwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQg
dXBvbiBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3
aXRoIHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRz
ZW5jcnlwdC5vcmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBABiP+dRn
Ivm/k/1PYCakaObZlK69I6gGtOdxPAYBZ13QK0DXTRnKXw3NIYfoojV4Q1ld2GzA
5fbUCB9wL0eDb1YguumgoJtJTC+4SrPKfSivGLn6xnfyuu6zd0NsEmXu6c8pvCd/
nbwVHUodY2d/WzD3Uloa1bRwbgnJsWRu7cKAB+tENw1Y5r+kMdMMgcqkHgKP0aoV
y4WKw3bCwG/OY1GRWrVvM0hiE0xl+GbIZEDPGKFbOKNetPdbLPnMXCeAjtD+Jfpb
cnGb05HRpa7yVtKiL4zLfO9odCOTyaL5/kbYSzSV4rspNVta4p1i/Is43BRBLOd3
n5HkV2S7N4xsuCA=
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:7f:e2:91:09:d0:d3:37:1d:11:8a:71:32:b6:c8:48:07:b5
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Sep 30 21:00:15 2017 GMT
            Not After : Dec 29 21:00:15 2017 GMT
        Subject: CN = qchat.lordran.net
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:1a:84:c6:e9:d4:e2:58:63:04:ce:b1:b1:66:40:
                    82:11:ce:68:4f:14:e9:9d:da:f0:85:d6:97:bb:95:
                    50:64:1a:93:14:4f:9b:8a:a1:2d:5b:8e:48:a7:98:
                    21:b2:b9:88:da:42:8a:5a:3c:38:20:87:69:23:44:
                    8d:9c:89:5c:bc:e8:d6:22:c2:a7:00:2f:7f:1c:97:
                    92:ea:8d:dc:3b:fe:58:04:cd:29:f1:f4:cd:a2:ab:
                    67:34:0c:70:8f:15:ca
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                EA:CC:43:7E:A6:F7:D0:89:F3:FE:96:57:80:3E:8C:48:D6:5B:5F:69
            X509v3 Authority Key Identifier:
                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

            X509v3 Subject Alternative Name:
                DNS:qchat.lordran.net
            X509v3 Certificate Policies:
                Policy: <IP_ADDRESS>.2.1
                Policy: <IP_ADDRESS>.4.1.449<IP_ADDRESS>
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

    Signature Algorithm: sha256WithRSAEncryption
         18:8f:f9:d4:67:22:f9:bf:93:fd:4f:60:26:a4:68:e6:d9:94:
         ae:bd:23:a8:06:b4:e7:71:3c:06:01:67:5d:d0:2b:40:d7:4d:
         19:ca:5f:0d:cd:21:87:e8:a2:35:78:43:59:5d:d8:6c:c0:e5:
         f6:d4:08:1f:70:2f:47:83:6f:56:20:ba:e9:a0:a0:9b:49:4c:
         2f:b8:4a:b3:ca:7d:28:af:18:b9:fa:c6:77:f2:ba:ee:b3:77:
         43:6c:12:65:ee:e9:cf:29:bc:27:7f:9d:bc:15:1d:4a:1d:63:
         67:7f:5b:30:f7:52:5a:1a:d5:b4:70:6e:09:c9:b1:64:6e:ed:
         c2:80:07:eb:44:37:0d:58:e6:bf:a4:31:d3:0c:81:ca:a4:1e:
         02:8f:d1:aa:15:cb:85:8a:c3:76:c2:c0:6f:ce:63:51:91:5a:
         b5:6f:33:48:62:13:4c:65:f8:66:c8:64:40:cf:18:a1:5b:38:
         a3:5e:b4:f7:5b:2c:f9:cc:5c:27:80:8e:d0:fe:25:fa:5b:72:
         71:9b:d3:91:d1:a5:ae:f2:56:d2:a2:2f:8c:cb:7c:ef:68:74:
         23:93:c9:a2:f9:fe:46:d8:4b:34:95:e2:bb:29:35:5b:5a:e2:
         9d:62:fc:8b:38:dc:14:41:2c:e7:77:9f:91:e4:57:64:bb:37:
         8c:6c:b8:20

Following your instructions, I did manage to make it work again by replacing the problematic line like this:
    for extension in core['extensions']:
        if extension['extnID'] == rfc2459.id_ce_subjectAltName:
            (san_list, r) = decoder.decode(extension.getComponentByName('extnValue'), rfc2459.SubjectAltName())
            for san_struct in san_list:
                if san_struct.getName() == 'dNSName':
                    fqdns.add(str(san_struct.getComponent()))

Thank you for the debugging aid! I've been able to reproduce this.
The root cause seems to be the fix to pyasn1_modules.rfc2459.Extension definition. In ASN.1 it looks like this:
Extension  ::=  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN OPTIONAL, -- DEFAULT FALSE XXX
     extnValue   OCTET STRING
}

However in pyasn1-modules < 0.2.1 it is:
class Extension(univ.Sequence):
    componentType = namedtype.NamedTypes(
        namedtype.NamedType('extnID', univ.ObjectIdentifier()),
        namedtype.DefaultedNamedType('critical', univ.Boolean('False')),
        namedtype.NamedType('extnValue', univ.Any())
    )

Which violates the original definition (e.g. Any instead of OctetString). Since pyasn1-modules 0.2.1 this definition is fixed what has this effect of automatic unwrapping the OctetString tags off the extnValue.
Therefore my original suggestion is still valid and there is nothing to fix about pyasn1/modules.
Does it make sense?

I'm also using SleekXMPP, version 1.3.3, and on an upgrade of pyasn1 to 0.4.2 it broke logging using an SSL certificate. Is this a new API or some such that SleekXMPP will have to fix then or is there something in pyasn1 that is not quite right?


fix: manual ZH translation update

What

fix: manual ZH translation update
But we should really fix: #1638

Codecov Report

Merging #1639 (78ef1a3) into develop (2ea0da3) will decrease coverage by 0.14%.
The diff coverage is 0.84%.

@@            Coverage Diff             @@
##           develop   #1639      +/-   ##
==========================================
- Coverage     8.86%   8.71%   -0.15%
==========================================
  Files          161     164       +3
  Lines         6623    6789     +166
==========================================
+ Hits           587     592       +5
- Misses        6036    6197     +161

Impacted Files
Coverage Δ

...t_cards/knowledge_panels/knowledge_panel_card.dart
0.00% <0.00%> (ø)

...rds/knowledge_panels/knowledge_panels_builder.dart
2.17% <0.00%> (ø)

...s/product_cards/smooth_product_card_not_found.dart
0.00% <0.00%> (ø)

.../smooth_app/lib/data_models/onboarding_loader.dart
0.00% <ø> (ø)

...mooth_app/lib/data_models/product_query_model.dart
1.38% <ø> (ø)

...s/smooth_app/lib/data_models/user_preferences.dart
34.42% <ø> (+2.11%)
:arrow_up:

...s/smooth_app/lib/database/dao_string_list_map.dart
0.00% <0.00%> (ø)

...ckages/smooth_app/lib/database/local_database.dart
0.00% <0.00%> (ø)

...s/smooth_app/lib/database/paged_product_query.dart
0.00% <0.00%> (ø)

...oth_app/lib/database/robotoff_questions_query.dart
0.00% <0.00%> (ø)

... and 29 more

Continue to review full report at Codecov.

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


Tagging across subscriptions

Can you share tagging best practice to apply around 5 tags across 5 subscriptions.  I created 5 policies and put them into one initiative definition.  Should I create 5 assignments (each subscription)?

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

ID: 048b3989-d4b9-2de8-af56-aab179ea8878
Version Independent ID: ecd6185f-5b5d-acff-84d5-3bcde13b36ca
Content: Azure Policy json sample - Apply tag and its default value
Content Source: articles/azure-policy/scripts/apply-tag-def-val.md
Service: azure-policy
GitHub Login: @DCtheGeek
Microsoft Alias: dacoulte

@prara06 Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

@prara06 - Thanks for the question! You are already on the right path by grouping the policies into an initiative. Since an assignment can only be to a single subscription, you have two options: Create an assignment to each subscription as you mention or create a single assignment to an appropriate management group. This is assuming that each subscription needs the same parameters on the initiative.  If they each need their own, then going with an assignment per subscription is the only way to achieve that.
If you aren't familiar with management groups, they allow you to group subscriptions into a hierarchy. Management groups are fairly new and Azure Policy already fully supports them. If these 5 subscriptions were in a management group and the assignment of the initiative used the same parameters, then in this way you could create a single assignment.  Thanks again for the question!
@MicrosoftDocs/azure-cxp-triage Please change the label on this to 'product-question' and #please-close.


Accelerate confirmation showing ridiculous transaction fees by default

Clicked on accelerate confirmation today. Here's a screen what the app was showing me

This can't be right

Fixed


Super Spine documentation enhancement

Issue Type

Documentation Report

Summary
For this enhancement there is some documentation available, we have to make sure it follows AVD standards.

Role or Module Name

arista.avd collection and Python libraries version

$ pip freeze

OS / Environment
EOS Version

Cloudvision version

OS running Ansible

Steps to reproduce

Expected results

$

Actual results

Solved.


Make sure the status message is cleared when updating users

fixes #408

Codecov Report

Merging #409 into dev will decrease coverage by <.01%.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             dev    #409      +/-   ##
========================================
- Coverage    5.3%    5.3%   -0.01%
========================================
  Files        322     322
  Lines      15456   15459       +3
  Branches    4655    4656       +1
========================================
  Hits         820     820
- Misses     12495   12498       +3
  Partials    2141    2141

Impacted Files
Coverage Δ

lib/manager/actions/user.js
0% <0%> (ø)
:arrow_up:

lib/manager/reducers/status.js
3.77% <0%> (-0.03%)
:arrow_down:

Continue to review full report at Codecov.

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

I refactored this so that an error message is shown when the update fails and that the user list is refreshed upon success.

The new code changes the behavior after a successful update so that the user list is refreshed each time. Therefore, the check to update is no longer needed, because the most recent data gets refetched.
That error message was copy-pasta-no-updata. Pushed a fix for that.

Just added back logic to update current user permissions after a self-update is performed.

I added more comments and refactored as suggest.

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Redesign checkboxes for skills

When we'll add new skill checkboxes, usability could become a problem in search and profile registration due to the high count of items. This should be redesigned.

We could have more Categories?
Or in the search a at least BLSnn experience?
Or first filter by BSL-Level, then by Education level, then by skills?

This also applies to the devices/materials checkboxes


[2] add player name and turf inked to battle results page's team table

add player name and turf inked to battle results for team members.

Turf inked: I will add a "point ↔ inked" switcher
Players' name:  I'm thinking how to handle it. I believe it shouldn't be public. Because stat.ink is just stats site and not for pillory. For example, the "blackout" option is a part of such efforts.

mmm... Is meaning "display turf inked in Ranked Battle"?

Is it possible to just make names available to the owner of a battle?
Yes, I did did mean turf inked for ranked.

I see there being 4 options for names:

Do not ever show the user:  No names means no possibility of identifying other players.

Only allow owner of battle to see names for league and private battles:  This would allow the uploader to see how their friends stats.

Make names public for for league and private battles:  This would allow your friends to see their stats too.

Make names public for everything:  Splatnet2 already allows you to share battle information with names included.  Including this information in stat.ink is only a little more harmful.

My opinion is that 3 is probably a good compromise.

Added turf inked on Ranked Battle in commit 4c194156cbfd1d35de1bb29421f095b5d31932e6

I implemented this feature and deployed it.

New configuration for blacking out for details list was added.

The default value of this configuration is like your option 3.

If logged in as a battle's owner, all players' name will be shown. (This behavior has been implemented in commit<PHONE_NUMBER>f2b96c8c4ce0cad9be52bd668b7d13 and deployed 2 days ago)
If not logged in, the new configuration will apply (new behavior). Options are:

Always opened all players' name
Opened if private battle
Opened if private battle or league(4)'s team member
Always masked

Thanks


chore(feat-multi-module-components): release 0.92.11

:robot: I have created a release beep boop
0.92.11 (2024-11-11)
Features

Add --affected flag for turbo synth (#346) (8bb7b5e)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/vincenthsh/fogg/releases/tag/v0.92.11 :sunflower:


latest on Docker Hub is not from experimental-branch, but from master

https://hub.docker.com/r/rfvgyhn/factorio/builds/bzwraulsk7ivzl9kmxfavuo/
This build is 0.15.40 instead of 0.16.11 which it should be.
(Maybe consider adding experimental tag in Docker Hub or some other way that could prevent latest from ever being anything else but experimental.)

Thanks for letting me know. I was mucking around with manual builds and apparently triggered one on the master branch. Should be fixed now.


video controls

How can I make the style of the video controls the same as shown in your picture?

How can I make the style of the video controls the same as shown in your picture?

@xelavoklov90 use Icons, and ProgressBar


Coveralls badge

Closes #70

Coverage decreased (-0.1%) to 88.615% when pulling 5d2e2712a0e598cd7b97ab6d0550b8aebee84c5b on femtotrader:patch-2 into 5ff734bee7eb734d2779a01a3495be7a6cc59289 on mhallsmoore:master.

Thanks for this!


Update travis badge for dev status

closes #246

@samhatchett This has already been resolved. So I'm going to go ahead and close it.