[WIP][Triton-MLIR] Prefetch pass fixup

A (potential) problem by directly adopting tensor.extract_slice.
Long story short, tensor.extract_slice is not aware of swizzling. Consider the following shared memory tensor and its first three slices, where each slice includes two tile (the loading unit of LDGSTS) of elements. Currently, the tiles haven't been swizzled yet, so slicing seems to work.

However, now consider the following figure, which is the layout after applying swizzling on the first figure.

Note that on phase 2, all tiles have been swizzled out of their originally slices. This implies that if we use the tile index after slicing, we can no longer locate the correct tiles. For example, T3 was in slice 1 but got swapped to slice 0 after swizzling.
Here's a more detailed explanation. In the current triton-mlir branch, we only compute the relative offset of each tile. So T3's index in Slice 1 is 1, and it will be swizzled using 1 and phase id. Whereas the correct index of T3 should be 3, which is the relative offset to the beginning of the shared memory tensor being swizzled, and T3 should be swizzled using 3 and phase id.
This PR proposes a hacky solution for this problem. We restore the "correct" offset of each tile by assuming that slicing on a specific dim only happens at most once on the output of insert_slice_async. I admit it's risky and fragile.
The other possible solution is adopting cutlass' swizzling logic that limits the indices being swizzled in a "bounding box" that matches the mma instruction executes. For example, in the following tensor layout, each 4x4 submatrix is a minimum swizzling unit, and the entire tensor represents the tensor layout of operand A in mma.16816.

@ptillet @daadaada Could you please provide some feedbacks? Thank you.

I think the hacky solution seems reasonable for now! I'll add this to the list of things to revisit later.


Fix issue where after.insert is handling collection with Mongo.ObjectID _id

Fixes #195

This is great, and looks good to me. Thank you so much @mbanting

You're welcome @matb33!

@matb33 can you push this to Atmosphere when you get the chance? Thanks in advance!

Done :)

Thank you!


radard: enable avg input service frequency checks

this will cost some CPU, but it's worth it. possible after #31391

I think the controlsd.init_timeout event started happening in my Focus from this commit e886087f430e7fe7/2024-02-13--20-13-34


2020 RDX fw [56a8b30d8b604750]

@VirtuallyChris You can use ./test_fw_query_on_routes.py --car "ACURA RDX 2020 TECH" "56a8b30d8b604750|2020-12-16--12-54-49" (in selfdrive/debug) to check if it fingerprints correctly. In this case it works fine!


Moved the MSI 'must' section first

Visual Studio users have the VS installer install Azure Powershell, but generally use Powershell 'raw', and so, as I did - discover too late that they should have tried using the Win 10 Apps uninstall procedure.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-conceptual/azurermps-6.13.0/uninstall-azurerm-ps.md
:white_check_mark:Succeeded
View (azurermps-6.13.0)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Thanks for your contribution. This is something that I'll need to take a closer look at, because the MSI instructions have been moved around based on our recommended install path via PSGallery, which is what most users install with. If using Uninstall-Module on an MSI install produces broken results and prevents proper reinstallation I'll accept this PR.

Since the Az instructions recommend checking for the app install first, before uninstalling via PSGet, accepting this PR. Thanks!


Torque defined as function of Angular Velocity

I am trying to define Torque given to the system, dependant of Angular Velocity in transient analysis, which means I need to grab the angular velocity from previous timestep in current timestep.
Is there any variable where all the dataset like this gets stored, which i can use in my equation.
Also in Time Dependant analysis why do I have to define the Force in function, as I am just trying to see the transient response to torque I provide to the system.

Hi there!
I have marked this issue as stale because it has not had activity for 45 days.
Consider the following options:

If the issue refers to a large task, break it in smaller issues that can be solved in
less than 45 days;
Label the issue as wontfix or wontfix for now and close it.


Add geoip action and action alias

Add new geoip action to the pack.

[x] Update README.
[x] Add action to return geoip information for an IP address.
[x] Add action alias for geoip action.
[x] Add action tests.
[x] Add action alias tests.
[x] Local testing.

@emedvedev The tests are crrently passing, however it's not running any of the tests. It was like that when the pack was moved over to StackStorm-Exchange last year.

https://circleci.com/gh/StackStorm-Exchange/stackstorm-networking_utils/5

I think this test error may need corrected in ST2:
======================================================================
ERROR: test_geoip (test_action_aliases.GeoIP)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/st2/st2tests/st2tests/action_aliases.py", line 44, in setUp
    self.action_alias_db = self._get_action_alias_db_by_name(name=self.action_alias_name)
  File "/tmp/st2/st2tests/st2tests/action_aliases.py", line 108, in _get_action_alias_db_by_name
    action_alias=alias_path)
  File "/tmp/st2/st2common/st2common/bootstrap/aliasesregistrar.py", line 118, in _get_action_alias_db
    (pack, pack_field))
Exception: Model is in pack "stackstorm-networking_utils" but field "pack" is different: networking_utils

Other than this it should be good, just need to carry out the local testing.

Good catch and thanks for the fixes.
We will have a look as soon as we get the chance :)

I'm trying to figure out why the tests are failing, but the Circle CI output is not loading for me so I will need to have a look later.

@Kami I had the same problem, collapsing and expanding the section did the trick for me.

The test error seems to be related to an issue with the new pack layout (repo name doesn't equal pack name).
I will dig in and work on a bug-fix in st2 on Monday :)

Merged https://github.com/StackStorm/st2/issues/3256 into master and re-ran the build - https://circleci.com/gh/StackStorm-Exchange/stackstorm-networking_utils/35.
The alias tests are running now, but it looks like there is a legit test failure.
Thanks again for catching and reporting this issue.

Thanks - let me know when all the comments are addressed and I will have a look again :)

@Kami That's the tests passing and the review changes completed.
I'll need to figure out running tests locally now that st2contrib has gone as doing them via CI greatly increases the commits and slows things down.

Thanks, I will have a look.
As far as running tests locally goes - here are some pointers to using st2-run-pack-tests to run them locally - https://docs.stackstorm.com/development/pack_testing.html#running-tests.
In addition to that, we are working on some improvements to st2-run-packs-tests tool in v2.2.1 so it will work out of the box on StackStorm deb / rpm package based installations. Right now you need to clone st2 repo and set ST2_REPO_PATH to make it work.

Thanks.
I added some comments, but no real blockers for me so I will go ahead and merge it :+1:

@Kami Thank you,

@Kami Thanks for the pointer to the docs. I'll give that a review again and get back up to speed on local tests in time for my next PR.


rbd: VolumeGroupSnapshot support

Add support for VolumeGroupSnapshots in RBD. The last two commits enable the feature in the Group Controller Server and expose the capability. All other commits provide the functionality through the rbd.Manager interface.
Currently there is no Ceph container-image release that provides the required librbd features. Building from this PR will not provide support for VolumeGroupSnapshot yet, the base container-image needs to be set to Ceph CI main branch (quay.ceph.io/ceph-ci/ceph:main) for that. A test-image based on Ceph main can be found at quay.io/nixpanic/cephcsi:pr_4739.
Notable changes:

internal/rbd_types package with interfaces so that objects can be passed around cleaner
internal/rbd/volume.go implementing the new Volume interface for rbdImage
internal/rbd_group package for all RBD-group functionalities
internal/rbd/group_controller.go for all CSI VolumeGroup service procedures

Depends-on: #4794
Depends-on: #4870
Depends-on: #4871
Depends-on: #4884
Depends-on: #4885
Depends-on: #4898
Depends-on: #4902
Depends-on: #4904
Depends-on: #4915

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)

/test ci/centos/mini-e2e-helm/k8s-1.30

@mergifyio refresh

/test ci/centos/mini-e2e-helm/k8s-1.30

@nixpanic we can rebase this and run the E2E to ensure that we are good. and i had couple of questions related to existing VolumeGroup and how both are going to work when the group is created by volumeGroup

There is no Ceph release yet that contains the required librbd changes, it can only be tested with Ceph-CSI builds that use the Ceph main-branch container-image as base. So testing in e2e is not trivial, we don't want Ceph-CSI to be based on a non-released Ceph version.
Because an RBD-image can only belong to one RBD-group at the time, a volume can either be replicated as a group (long living group), or snapshotted as a group (short living group), not both.
It is possible that a replication-group and snapshot-group contain the same source volumes. In that case, there would be no need to create (and delete) the group for snapshotting. This is something that can be added in the future.
@iPraveenParihar, @Madhu-1 and @Rakshith-R , I think I addressed all your comments and questions. Please have a look again.

@nixpanic the golangci-lint seems to fail, can you please take a look

@nixpanic we can rebase this and run the E2E to ensure that we are good. and i had couple of questions related to existing VolumeGroup and how both are going to work when the group is created by volumeGroup

There is no Ceph release yet that contains the required librbd changes, it can only be tested with Ceph-CSI builds that use the Ceph main-branch container-image as base. So testing in e2e is not trivial, we don't want Ceph-CSI to be based on a non-released Ceph version.

@nixpanic it would be good to add a commit to use the main ceph image and run the E2E to ensure the existing E2E testing passes, once it passes we can drop the commit. This is just to ensure we are good with current code.

Because an RBD-image can only belong to one RBD-group at the time, a volume can either be replicated as a group (long living group), or snapshotted as a group (short living group), not both.
It is possible that a replication-group and snapshot-group contain the same source volumes. In that case, there would be no need to create (and delete) the group for snapshotting. This is something that can be added in the future.

Its good to see that this is in plan as this is also one of the feature we have in plan, Thank you

@iPraveenParihar, @Madhu-1 and @Rakshith-R , I think I addressed all your comments and questions. Please have a look again.

@nixpanic it would be good to add a commit to use the main ceph image and run the E2E to ensure the existing E2E testing passes, once it passes we can drop the commit. This is just to ensure we are good with current code.

The CI container-image that is built from the Ceph main branch is not available in the CI mirror, so I'll make some modifications to the Dockerfiles directly and push those.

DCO is expected to fail, preventing unintended merging of the last 3 commits.
All other commits can be reviewed, please check again @iPraveenParihar, @Madhu-1 and @yati1998.

/test ci/centos/mini-helm-e2e/k8s-1.31

/test ci/centos/mini-e2e-helm/k8s-1.31

/test ci/centos/mini-e2e-helm/k8s-1.31

/test ci/centos/mini-e2e-helm/k8s-1.31

ci run
container logs

There might be a problem with the e2e test itself, as it fails with:
[FAILED] failed to test volumeGroupSnapshot: failed to create clones: failed to get PVC: resource name may not be empty

The test worked for CephFS, so I am uncertain what could be missing here...
Volume Group Snapshot creation succeeds, and there do not seem to be errors within the logs of the VGS operations:
  I1024 14:32:44.483671       1 utils.go:266] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GRPC call: /csi.v1.GroupController/CreateVolumeGroupSnapshot
  I1024 14:32:44.483772       1 utils.go:267] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GRPC request: {"name":"groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407","parameters":{"clusterID":"2c26290d-404a-48cd-b4be-a0203715e6fc","csi.storage.k8s.io/volumegroupsnapshot/name":"rbd-4275-vgs","csi.storage.k8s.io/volumegroupsnapshot/namespace":"rbd-4275","csi.storage.k8s.io/volumegroupsnapshotcontent/name":"groupsnapcontent-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407","pool":"replicapool"},"secrets":"***stripped***","source_volume_ids":["0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-872b750b-3ff4-4e5f-aee9-e16218f3341b","0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-f03bed91-c16d-4419-973d-6f9bfdb9cfc5","0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-15b9c8c4-1666-4b8e-963a-bc36978f6482"]}
  I1024 14:32:44.485399       1 omap.go:89] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.872b750b-3ff4-4e5f-aee9-e16218f3341b"): map[csi.imageid:21252f2e6686 csi.imagename:csi-vol-872b750b-3ff4-4e5f-aee9-e16218f3341b csi.volname:pvc-560542c3-6b4d-4433-be61-30e94dd04b0d csi.volume.owner:rbd-4275]
  I1024 14:32:44.511821       1 omap.go:89] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.f03bed91-c16d-4419-973d-6f9bfdb9cfc5"): map[csi.imageid:2125269bf88d csi.imagename:csi-vol-f03bed91-c16d-4419-973d-6f9bfdb9cfc5 csi.volname:pvc-4346c19f-8e51-45e9-935a-136cca2bf83a csi.volume.owner:rbd-4275]
  I1024 14:32:44.530090       1 omap.go:89] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.15b9c8c4-1666-4b8e-963a-bc36978f6482"): map[csi.imageid:212543a812dc csi.imagename:csi-vol-15b9c8c4-1666-4b8e-963a-bc36978f6482 csi.volname:pvc-19955273-9aa2-4db2-a39f-1b250e9502d7 csi.volume.owner:rbd-4275]
  I1024 14:32:44.549923       1 group_controller.go:103] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 all 3 Volumes for VolumeGroup "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407" have been found
  E1024 14:32:44.550553       1 omap.go:80] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 omap not found (pool="replicapool", namespace="", name="csi.groups.default"): rados: ret=-2, No such file or directory
  I1024 14:32:44.550572       1 manager.go:145] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 the journal does not contain a reservation for group "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407" yet
  I1024 14:32:44.557735       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.groups.default"): map[csi.volume.group.groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407:6c4d4385-45e0-42a1-a35f-3ca24f78fedd])
  I1024 14:32:44.560609       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[csi.creationtime:2024-10-24T14:32:44.557751094Z csi.groupname:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407])
  I1024 14:32:44.560630       1 manager.go:153] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got UUID "6c4d4385-45e0-42a1-a35f-3ca24f78fedd" for group "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407"
  I1024 14:32:44.560783       1 util.go:102] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 object for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd" has been initialized
  I1024 14:32:44.561510       1 omap.go:221] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[csi.creationtime:2024-10-24T14:32:44.557751094Z csi.groupname:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407]
  I1024 14:32:44.561544       1 group_snapshot.go:108] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GetVolumeGroupSnapshot(0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd) returns {commonVolumeGroup:{id:0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd requestName:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 name:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd creationTime:0xc0009fb0b0 clusterID:2c26290d-404a-48cd-b4be-a0203715e6fc objectUUID:6c4d4385-45e0-42a1-a35f-3ca24f78fedd credentials:0xc000741980 conn:<nil> ioctx:<nil> monitors:rook-ceph-mon-a.rook-ceph.svc.cluster.local:6789 pool:replicapool namespace: csiDriver:default journal:0xc000ac4590} snapshots:[] snapshotsToFree:[]}
  I1024 14:32:44.561575       1 group_controller.go:117] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 need to create new volume group snapshot, failed to get existing one with name "volume group snapshot \"replicapool/csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd\" is incomplete, it has no snapshots": %!v(MISSING)
  I1024 14:32:44.562296       1 omap.go:89] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.groups.default"): map[]
  I1024 14:32:44.562314       1 manager.go:278] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 the journal does not contain a reservation for a volume group with name "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg" yet
  I1024 14:32:44.570555       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.groups.default"): map[csi.volume.group.groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg:9c6177ad-1fad-4002-911b-3ef61b3b8e5a])
  I1024 14:32:44.575335       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): map[csi.creationtime:2024-10-24T14:32:44.570571418Z csi.groupname:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg])
  I1024 14:32:44.575549       1 util.go:102] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 object for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a" has been initialized
  I1024 14:32:44.577213       1 omap.go:221] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): map[csi.creationtime:2024-10-24T14:32:44.570571418Z csi.groupname:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg]
  I1024 14:32:44.577240       1 volume_group.go:110] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GetVolumeGroup(0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a) returns {commonVolumeGroup:{id:0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a requestName:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg name:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a creationTime:0xc0009fb1a0 clusterID:2c26290d-404a-48cd-b4be-a0203715e6fc objectUUID:9c6177ad-1fad-4002-911b-3ef61b3b8e5a credentials:0xc000741980 conn:<nil> ioctx:<nil> monitors:rook-ceph-mon-a.rook-ceph.svc.cluster.local:6789 pool:replicapool namespace: csiDriver:default journal:0xc000ac4b50} volumes:[] volumesToFree:[]}
  I1024 14:32:44.577271       1 util.go:225] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 connection established for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a"
  I1024 14:32:44.577280       1 util.go:276] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 iocontext created for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a" in pool "replicapool"
  I1024 14:32:44.584572       1 volume_group.go:178] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 volume group "replicapool/csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a" has been created
  I1024 14:32:44.584595       1 group_controller.go:131] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 VolumeGroup "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407-vg" has been created: replicapool/csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a
  I1024 14:32:44.619090       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): map[0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-872b750b-3ff4-4e5f-aee9-e16218f3341b:])
  I1024 14:32:44.647108       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): map[0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-f03bed91-c16d-4419-973d-6f9bfdb9cfc5:])
  I1024 14:32:44.677539       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): map[0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-15b9c8c4-1666-4b8e-963a-bc36978f6482:])
  I1024 14:32:44.679509       1 omap.go:89] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.groups.default"): map[csi.volume.group.groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407:6c4d4385-45e0-42a1-a35f-3ca24f78fedd]
  I1024 14:32:44.680532       1 omap.go:221] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[csi.creationtime:2024-10-24T14:32:44.557751094Z csi.groupname:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407]
  I1024 14:32:44.680551       1 manager.go:153] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got UUID "6c4d4385-45e0-42a1-a35f-3ca24f78fedd" for group "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407"
  I1024 14:32:44.680759       1 util.go:102] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 object for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd" has been initialized
  I1024 14:32:44.681292       1 omap.go:221] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[csi.creationtime:2024-10-24T14:32:44.557751094Z csi.groupname:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407]
  I1024 14:32:44.681315       1 group_snapshot.go:108] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GetVolumeGroupSnapshot(0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd) returns {commonVolumeGroup:{id:0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd requestName:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 name:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd creationTime:0xc0009fb350 clusterID:2c26290d-404a-48cd-b4be-a0203715e6fc objectUUID:6c4d4385-45e0-42a1-a35f-3ca24f78fedd credentials:0xc000741980 conn:<nil> ioctx:<nil> monitors:rook-ceph-mon-a.rook-ceph.svc.cluster.local:6789 pool:replicapool namespace: csiDriver:default journal:0xc000ac5400} snapshots:[] snapshotsToFree:[]}
  I1024 14:32:44.681324       1 manager.go:455] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 found existing volume group snapshot "replicapool/csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd" for id "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd"
  I1024 14:32:44.932162       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snaps.default"): map[csi.snap.csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-0:ee75bde7-ff88-4d94-b201-e4bbaf1192cc])
  I1024 14:32:44.935780       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.ee75bde7-ff88-4d94-b201-e4bbaf1192cc"): map[csi.imagename:csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc csi.snapname:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-0 csi.source:csi-vol-f03bed91-c16d-4419-973d-6f9bfdb9cfc5 csi.volume.owner:rbd-4275])
  I1024 14:32:44.935808       1 rbd_journal.go:418] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 generated Volume ID (0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-ee75bde7-ff88-4d94-b201-e4bbaf1192cc) and image name (csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc) for request name (csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-0)
  I1024 14:32:44.935842       1 rbd_util.go:1629] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 setting image options on replicapool/csi-vol-f03bed91-c16d-4419-973d-6f9bfdb9cfc5
  I1024 14:32:44.935863       1 snapshot.go:248] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 going to clone snapshot image "replicapool/csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc@csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc" from image "replicapool/csi-vol-f03bed91-c16d-4419-973d-6f9bfdb9cfc5" with snapshot ID 105
  I1024 14:32:45.941294       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.ee75bde7-ff88-4d94-b201-e4bbaf1192cc"): map[csi.imageid:2125a0208df])
  I1024 14:32:45.955342       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snaps.default"): map[csi.snap.csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-1:c65f62c5-e9d7-4eac-b72f-4c40c1ea183f])
  I1024 14:32:45.959232       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.c65f62c5-e9d7-4eac-b72f-4c40c1ea183f"): map[csi.imagename:csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f csi.snapname:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-1 csi.source:csi-vol-872b750b-3ff4-4e5f-aee9-e16218f3341b csi.volume.owner:rbd-4275])
  I1024 14:32:45.959255       1 rbd_journal.go:418] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 generated Volume ID (0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f) and image name (csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f) for request name (csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-1)
  I1024 14:32:45.959272       1 rbd_util.go:1629] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 setting image options on replicapool/csi-vol-872b750b-3ff4-4e5f-aee9-e16218f3341b
  I1024 14:32:45.959285       1 snapshot.go:248] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 going to clone snapshot image "replicapool/csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f@csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f" from image "replicapool/csi-vol-872b750b-3ff4-4e5f-aee9-e16218f3341b" with snapshot ID 107
  I1024 14:32:46.950479       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.c65f62c5-e9d7-4eac-b72f-4c40c1ea183f"): map[csi.imageid:212510dbadf5])
  I1024 14:32:46.964586       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snaps.default"): map[csi.snap.csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-2:35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8])
  I1024 14:32:46.968854       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8"): map[csi.imagename:csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8 csi.snapname:csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-2 csi.source:csi-vol-15b9c8c4-1666-4b8e-963a-bc36978f6482 csi.volume.owner:rbd-4275])
  I1024 14:32:46.968913       1 rbd_journal.go:418] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 generated Volume ID (0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8) and image name (csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8) for request name (csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a-snap-2)
  I1024 14:32:46.968943       1 rbd_util.go:1629] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 setting image options on replicapool/csi-vol-15b9c8c4-1666-4b8e-963a-bc36978f6482
  I1024 14:32:46.968960       1 snapshot.go:248] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 going to clone snapshot image "replicapool/csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8@csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8" from image "replicapool/csi-vol-15b9c8c4-1666-4b8e-963a-bc36978f6482" with snapshot ID 106
  I1024 14:32:47.965978       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.snap.35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8"): map[csi.imageid:2125406ac939])
  I1024 14:32:48.017628       1 manager.go:500] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 volume group snapshot "groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407" contains 3 snapshots: [replicapool/csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc@csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc replicapool/csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f@csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f replicapool/csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8@csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8]
  I1024 14:32:48.017763       1 util.go:102] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 object for volume group "0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd" has been initialized
  I1024 14:32:48.019125       1 omap.go:221] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 got omap values: (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[csi.creationtime:2024-10-24T14:32:44.557751094Z csi.groupname:csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd csi.volname:groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407]
  I1024 14:32:48.021946       1 omap.go:159] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 set omap keys (pool="replicapool", namespace="", name="csi.volume.group.6c4d4385-45e0-42a1-a35f-3ca24f78fedd"): map[0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8:csi-snap-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8 0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f:csi-snap-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f 0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-ee75bde7-ff88-4d94-b201-e4bbaf1192cc:csi-snap-ee75bde7-ff88-4d94-b201-e4bbaf1192cc])
  I1024 14:32:48.021972       1 manager.go:507] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 volume group snapshot "replicapool/csi-vol-group-6c4d4385-45e0-42a1-a35f-3ca24f78fedd" has been created
  I1024 14:32:48.038070       1 omap.go:126] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 removed omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): [0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-872b750b-3ff4-4e5f-aee9-e16218f3341b]
  I1024 14:32:48.055631       1 omap.go:126] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 removed omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): [0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-f03bed91-c16d-4419-973d-6f9bfdb9cfc5]
  I1024 14:32:48.076714       1 omap.go:126] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 removed omap keys (pool="replicapool", namespace="", name="csi.volume.group.9c6177ad-1fad-4002-911b-3ef61b3b8e5a"): [0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-15b9c8c4-1666-4b8e-963a-bc36978f6482]
  I1024 14:32:48.077266       1 group_controller.go:79] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 removing temporary volume group "replicapool/csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a"
  I1024 14:32:48.086407       1 volume_group.go:199] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 volume group "replicapool/csi-vol-group-9c6177ad-1fad-4002-911b-3ef61b3b8e5a" has been removed
  I1024 14:32:48.092837       1 omap.go:126] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 removed omap keys (pool="replicapool", namespace="", name="csi.groups.default"): [csi.volume.group.0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-9c6177ad-1fad-4002-911b-3ef61b3b8e5a]
  I1024 14:32:48.093144       1 utils.go:273] ID: 29 Req-ID: groupsnapshot-ca51faa2-a3e0-4f2c-b2ea-e8930cfd7407 GRPC response: {"group_snapshot":{"creation_time":{"nanos":557751094,"seconds":1729780364},"group_snapshot_id":"0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-6c4d4385-45e0-42a1-a35f-3ca24f78fedd","ready_to_use":true,"snapshots":[{"creation_time":{"nanos":854143772,"seconds":1729780359},"ready_to_use":true,"size_bytes":1073741824,"snapshot_id":"0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-ee75bde7-ff88-4d94-b201-e4bbaf1192cc"},{"creation_time":{"nanos":838776242,"seconds":1729780357},"ready_to_use":true,"size_bytes":1073741824,"snapshot_id":"0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-c65f62c5-e9d7-4eac-b72f-4c40c1ea183f"},{"creation_time":{"nanos":878418762,"seconds":1729780361},"ready_to_use":true,"size_bytes":1073741824,"snapshot_id":"0001-0024-2c26290d-404a-48cd-b4be-a0203715e6fc-0000000000000004-35fed0aa-e7fd-4f03-9a51-4bb2b2dc6dd8"}]}}

[FAILED] failed to test volumeGroupSnapshot: failed to create clones: failed to get PVC: resource name may not be empty

Found the cause for this! The new rbdVolume.NewSnapshotByID() function did not set the SourceVolumeID if the newly generated rbdSnapshot.

/test ci/centos/mini-e2e-helm/k8s-1.31

/test ci/centos/mini-e2e-helm/k8s-1.31

ci job
plain text logs

[FAILED] failed to test volumeGroupSnapshot: failed to delete PVCs: failed to delete PVC: get on deleted PVC pvc-0 failed with error other than "not found": client rate limiter Wait returned an error: context deadline exceeded

It seems deleting the PVC is stuck in this state:
  I1025 16:59:36.054943 86583 pvc.go:287] Deleting PersistentVolumeClaim pvc-0 on namespace rbd-4237
  I1025 16:59:36.063179 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteOnce],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (0 seconds elapsed)
  I1025 16:59:36.064857 86583 pvc.go:313] PVC pvc-0 (status: {Bound [ReadWriteOnce] map[storage:{{1073741824 0} {<nil>} 1Gi BinarySI}] [] map[] map[] <nil> nil}) has not been deleted yet, rechecking...
  I1025 16:59:38.063223 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteOnce],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (2 seconds elapsed)
  I1025 16:59:38.067017 86583 pvc.go:329] PV pvc-99b7ed84-d2f0-4e5f-afc6-564578564aee (status: {Released   2024-10-25 16:59:36 +0000 UTC}) has not been deleted yet, rechecking...
  I1025 16:59:40.063482 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:,AccessModes:[],Capacity:ResourceList{},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (4 seconds elapsed)
  I1025 16:59:40.067461 86583 pvc.go:329] PV pvc-99b7ed84-d2f0-4e5f-afc6-564578564aee (status: {Released   2024-10-25 16:59:36 +0000 UTC}) has not been deleted yet, rechecking...

I wonder if Released is really not the right status for indicating its deletion?

/test ci/centos/mini-e2e-helm/k8s-1.31

ci job
plain text logs

[FAILED] failed to test volumeGroupSnapshot: failed to delete PVCs: failed to delete PVC: get on deleted PVC pvc-0 failed with error other than "not found": client rate limiter Wait returned an error: context deadline exceeded

It seems deleting the PVC is stuck in this state:
  I1025 16:59:36.054943 86583 pvc.go:287] Deleting PersistentVolumeClaim pvc-0 on namespace rbd-4237
  I1025 16:59:36.063179 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteOnce],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (0 seconds elapsed)
  I1025 16:59:36.064857 86583 pvc.go:313] PVC pvc-0 (status: {Bound [ReadWriteOnce] map[storage:{{1073741824 0} {<nil>} 1Gi BinarySI}] [] map[] map[] <nil> nil}) has not been deleted yet, rechecking...
  I1025 16:59:38.063223 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:Bound,AccessModes:[ReadWriteOnce],Capacity:ResourceList{storage: {{1073741824 0} {<nil>} 1Gi BinarySI},},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (2 seconds elapsed)
  I1025 16:59:38.067017 86583 pvc.go:329] PV pvc-99b7ed84-d2f0-4e5f-afc6-564578564aee (status: {Released   2024-10-25 16:59:36 +0000 UTC}) has not been deleted yet, rechecking...
  I1025 16:59:40.063482 86583 pvc.go:306] waiting for PVC pvc-0 in state &PersistentVolumeClaimStatus{Phase:,AccessModes:[],Capacity:ResourceList{},Conditions:[]PersistentVolumeClaimCondition{},AllocatedResources:ResourceList{},AllocatedResourceStatuses:map[ResourceName]ClaimResourceStatus{},CurrentVolumeAttributesClassName:nil,ModifyVolumeStatus:nil,} to be deleted (4 seconds elapsed)
  I1025 16:59:40.067461 86583 pvc.go:329] PV pvc-99b7ed84-d2f0-4e5f-afc6-564578564aee (status: {Released   2024-10-25 16:59:36 +0000 UTC}) has not been deleted yet, rechecking...

I wonder if Released is really not the right status for indicating its deletion?

  I1025 16:59:51.874357       1 utils.go:266] ID: 48 Req-ID: 0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c GRPC call: /csi.v1.Controller/DeleteVolume
  I1025 16:59:51.874430       1 utils.go:267] ID: 48 Req-ID: 0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c GRPC request: {"secrets":"***stripped***","volume_id":"0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c"}
  I1025 16:59:51.875918       1 omap.go:89] ID: 48 Req-ID: 0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c got omap values: (pool="replicapool", namespace="", name="csi.volume.72ec6463-1dcb-4da8-8817-840a8dfec17c"): map[csi.imageid:1e0e244954fd csi.imagename:csi-vol-72ec6463-1dcb-4da8-8817-840a8dfec17c csi.volname:pvc-99b7ed84-d2f0-4e5f-afc6-564578564aee csi.volume.owner:rbd-4237]
  E1025 16:59:51.923631       1 controllerserver.go:1044] ID: 48 Req-ID: 0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c rbd replicapool/csi-vol-72ec6463-1dcb-4da8-8817-840a8dfec17c is still being used
  E1025 16:59:51.923694       1 utils.go:271] ID: 48 Req-ID: 0001-0024-2f4c5f07-59be-4d2e-9458-817748419eec-0000000000000004-72ec6463-1dcb-4da8-8817-840a8dfec17c GRPC error: rpc error: code = Internal desc = rbd csi-vol-72ec6463-1dcb-4da8-8817-840a8dfec17c is still being used

it looks like the image is still being used, csi is blocking the delete operation

Running the steps manually in a test cluster works just fine... It is not clear to me why the RBD-image was reported as still being used.

/test ci/centos/mini-e2e-helm/k8s-1.30

/test ci/centos/mini-e2e-helm/k8s-1.30

ci job
plain text logs

This one failed with the same is still being used error. I'll try to reproduce it again, and see what the issue could be.
One thing I noticed, is that the rbdSnapshot can point to the wrong rbdImageName, so I've moved the hacky correction for that to genSnapFromSnapID() from Manager.GetSnapshotByID().

/test ci/centos/mini-e2e-helm/k8s-1.30

/test ci/centos/mini-e2e-helm/k8s-1.30

ci job
plain text logs

Again the same thing with the still in use error...
But I was able to reproduce it now on a new build, maybe something changed in the Ceph main branch? There is indeed a watcher:
sh-5.1$ rbd status ocs-storagecluster-cephblockpool/csi-vol-c9972a94-7a34-4483-b651-62bd0924dc6f
Watchers:
	watcher=<IP_ADDRESS>:0/4174434214 client.36038 cookie=140136260223008

/test ci/centos/mini-e2e-helm/k8s-1.30

ci job
plain text logs

Again the same thing with the still in use error...
But I was able to reproduce it now on a new build, maybe something changed in the Ceph main branch? There is indeed a watcher:
sh-5.1$ rbd status ocs-storagecluster-cephblockpool/csi-vol-c9972a94-7a34-4483-b651-62bd0924dc6f
Watchers:
	watcher=<IP_ADDRESS>:0/4174434214 client.36038 cookie=140136260223008

there could be a case where we opened the image in cephcsi but not closed it.

/test ci/centos/mini-e2e-helm/k8s-1.30

/test ci/centos/mini-e2e-helm/k8s-1.30

/test ci/centos/mini-e2e-helm/k8s-1.30

  E1029 17:18:02.612576       1 rbd_util.go:582] too many watchers (2 > 1): [{<IP_ADDRESS>:0/4124955348 8327<PHONE_NUMBER>79488} {<IP_ADDRESS>:0/4124955348 8327<PHONE_NUMBER>55104}]
  E1029 17:18:02.617948       1 controllerserver.go:1044] ID: 44 Req-ID: 0001-0024-7be0790e-478e-48ff-bb76-d94dd344c535-0000000000000004-fd2b6c4f-6f38-4851-a79d-d99e2b78d15f rbd replicapool/csi-vol-fd2b6c4f-6f38-4851-a79d-d99e2b78d15f is still being used
  E1029 17:18:02.618008       1 utils.go:271] ID: 44 Req-ID: 0001-0024-7be0790e-478e-48ff-bb76-d94dd344c535-0000000000000004-fd2b6c4f-6f38-4851-a79d-d99e2b78d15f GRPC error: rpc error: code = Internal desc = rbd csi-vol-fd2b6c4f-6f38-4851-a79d-d99e2b78d15f is still being used

1 watcher is expected, but there (still) seem to be 2. This could indicate that there is still an open RBD-image after the creation of the VolumeGroupSnapshot. From manual testing, I can see that there is continuously one watcher from the provisioner pod, it does not seem to get disconnected, even after a long time. Still trying to find what causes it...

1 watcher is expected, but there (still) seem to be 2. This could indicate that there is still an open RBD-image after the creation of the VolumeGroupSnapshot. From manual testing, I can see that there is continuously one watcher from the provisioner pod, it does not seem to get disconnected, even after a long time. Still trying to find what causes it...

The rbdVolume.AddToGroup() function opens the image, but is missing a defer image.Close() . This has been introduced in f9ab14e826, and is not something new with this PR. I expect that deleting Volumes that were added (and removed) from a VolumeGroup are giving similar still in use failures. The 1st commit in this PR should fix it.

/test ci/centos/mini-e2e-helm/k8s-1.30

DeleteVolume for pvc-0 now worked:
  I1030 10:59:22.717399       1 utils.go:266] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 GRPC call: /csi.v1.Controller/DeleteVolume
  I1030 10:59:22.717492       1 utils.go:267] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 GRPC request: {"secrets":"***stripped***","volume_id":"0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250"}
  I1030 10:59:22.718581       1 omap.go:89] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 got omap values: (pool="replicapool", namespace="", name="csi.volume.613c72df-b383-4055-a67f-46436d6ac250"): map[csi.imageid:2127dbfc2e18 csi.imagename:csi-vol-613c72df-b383-4055-a67f-46436d6ac250 csi.volname:pvc-a3bc89dc-5179-490a-bb4a-380577b172d8 csi.volume.owner:rbd-7659]
  I1030 10:59:22.779288       1 rbd_util.go:657] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 rbd: delete csi-vol-613c72df-b383-4055-a67f-46436d6ac250-temp using mon rook-ceph-mon-a.rook-ceph.svc.cluster.local:6789, pool replicapool
  I1030 10:59:22.783756       1 controllerserver.go:1059] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 deleting image csi-vol-613c72df-b383-4055-a67f-46436d6ac250
  I1030 10:59:22.783801       1 rbd_util.go:657] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 rbd: delete csi-vol-613c72df-b383-4055-a67f-46436d6ac250 using mon rook-ceph-mon-a.rook-ceph.svc.cluster.local:6789, pool replicapool
  I1030 10:59:22.808049       1 rbd_util.go:699] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 rbd: adding task to remove image "replicapool/csi-vol-613c72df-b383-4055-a67f-46436d6ac250" with id "2127dbfc2e18" from trash
  I1030 10:59:22.814588       1 rbd_util.go:723] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 rbd: successfully added task to move image "replicapool/csi-vol-613c72df-b383-4055-a67f-46436d6ac250" with id "2127dbfc2e18" to trash
  I1030 10:59:22.819165       1 omap.go:126] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 removed omap keys (pool="replicapool", namespace="", name="csi.volumes.default"): [csi.volume.pvc-a3bc89dc-5179-490a-bb4a-380577b172d8]
  I1030 10:59:22.819262       1 utils.go:273] ID: 45 Req-ID: 0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-613c72df-b383-4055-a67f-46436d6ac250 GRPC response: {}

However, there was a failure while removing the volume from the VolumeGroup after the VolumeGroupSnapshot was created:
  I1030 10:58:58.458117       1 manager.go:502] ID: 29 Req-ID: groupsnapshot-95eb3e6a-9a9c-4517-ad0b-29edc0fd8f2a volume group snapshot "replicapool/csi-vol-group-ad9898bb-af10-4657-ad46-d990898166a1" has been created
  I1030 10:58:58.468703       1 omap.go:126] ID: 29 Req-ID: groupsnapshot-95eb3e6a-9a9c-4517-ad0b-29edc0fd8f2a removed omap keys (pool="replicapool", namespace="", name="csi.volume.group.2d8f2e57-c49f-4efc-b43c-f5eaa8d3adfc"): [0001-0024-3760ed6a-d2e8-4054-b4f1-bf3dd6b80c0a-0000000000000003-267c69be-217d-4540-8ab5-3c6c2ff18262]
  I1030 10:58:58.468852       1 util.go:213] ID: 29 Req-ID: groupsnapshot-95eb3e6a-9a9c-4517-ad0b-29edc0fd8f2a missing credentials for common volume group "replicapool/csi-vol-group-2d8f2e57-c49f-4efc-b43c-f5eaa8d3adfc": goroutine 29 [running]:
  github.com/ceph/ceph-csi/internal/util.CallStack(...)
  	/go/src/github.com/ceph/ceph-csi/internal/util/util.go:378
  github.com/ceph/ceph-csi/internal/rbd/group.(*commonVolumeGroup).getConnection(0xc0009463c0, {0x2ce6118, 0xc000a11da0})
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group/util.go:213 +0x1e5
  github.com/ceph/ceph-csi/internal/rbd/group.(*commonVolumeGroup).GetIOContext(0xc0009463c0, {0x2ce6118, 0xc000a11da0})
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group/util.go:261 +0x45
  github.com/ceph/ceph-csi/internal/rbd.(*rbdVolume).RemoveFromGroup(0xc0007dc488, {0x2ce6118, 0xc000a11da0}, {0x2cf8940, 0xc0009463c0})
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group.go:69 +0x3a
  github.com/ceph/ceph-csi/internal/rbd/group.(*volumeGroup).RemoveVolume(0xc0009463c0, {0x2ce6118, 0xc000a11da0}, {0x2cffe70, 0xc0007dc488})
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group/volume_group.go:257 +0x89
  github.com/ceph/ceph-csi/internal/rbd.(*ControllerServer).CreateVolumeGroupSnapshot.func1()
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group_controller.go:62 +0x91
  github.com/ceph/ceph-csi/internal/rbd.(*ControllerServer).CreateVolumeGroupSnapshot(0xc00019cdc0, {0x2ce6118, 0xc000a11da0}, 0xc000a14420)
  	/go/src/github.com/ceph/ceph-csi/internal/rbd/group_controller.go:155 +0xf37
  github.com/container-storage-interface/spec/lib/go/csi._GroupController_CreateVolumeGroupSnapshot_Handler.func1({0x2ce6118?, 0xc000a11da0?}, {0x23c8900?, 0xc000a14420?})
  	/go/src/github.com/ceph/ceph-csi/vendor/github.com/container-storage-interface/spec/lib/go/csi/csi_grpc.pb.go:890 +0xcb
  github.com/ceph/ceph-csi/internal/csi-common.panicHandler({0x2ce6118?, 0xc000a11da0?}, {0x23c8900?, 0xc000a14420?}, 0xc000a2c540?, 0x1db5a4b?)
  	/go/src/github.com/ceph/ceph-csi/internal/csi-common/utils.go:341 +0x77
  github.com/ceph/ceph-csi/internal/csi-common.NewMiddlewareServerOption.ChainUnaryServer.func3.1({0x2ce6118?, 0xc000a11da0?}, {0x23c8900?, 0xc000a14420?})
  	/go/src/github.com/ceph/ceph-csi/vendor/github.com/grpc-ecosys
  E1030 10:58:58.468899       1 group_controller.go:64] ID: 29 Req-ID: groupsnapshot-95eb3e6a-9a9c-4517-ad0b-29edc0fd8f2a failed to remove volume "replicapool/csi-vol-613c72df-b383-4055-a67f-46436d6ac250" from volume group "replicapool/csi-vol-group-2d8f2e57-c49f-4efc-b43c-f5eaa8d3adfc": failed to remove volume "replicapool/csi-vol-613c72df-b383-4055-a67f-46436d6ac250" from volume group "replicapool/csi-vol-group-2d8f2e57-c49f-4efc-b43c-f5eaa8d3adfc": could not get iocontext for volume group "replicapool/csi-vol-group-2d8f2e57-c49f-4efc-b43c-f5eaa8d3adfc": RBD group is not connected: failed to connect: can not connect to cluster without credentials

Possibly something did a vg.Destroy() that wiped the credentials from the struct. After .Destroy() the VolumeGroup should not be used anymore, so now I'm hunting for this erroneous call.

@nixpanic i have added pod to the workflow https://github.com/ceph/ceph-csi/pull/4934, it would be good to run this as well to ensure the complete flow works. if there is any watcher the pod will not start as well

@nixpanic i have added pod to the workflow #4934, it would be good to run this as well to ensure the complete flow works. if there is any watcher the pod will not start as well

Included that one in this PR now too. Thanks!

/test ci/centos/mini-e2e-helm/k8s-1.30

/test ci/centos/mini-e2e-helm/k8s-1.30

Found a bug in storing the GroupID for Snapshots in the journal. This has been corrected with 6f8cd5b and things seem to work much smoother now.

Yay, this ci run passed now, including e2e changes from #4899 and #4934.
Will drop the last commits from this PR now, so that it is really ready for review+merging.

a small change in file name internal/rbd/group_controller.go -> internal/rbd/group_controllerserver.go
It confused me for a bit when i saw controller at the end.

You live too much in the Kubernetes Operator world! :rofl:

internal/rbd/group_controller.go -> internal/rbd/group_controllerserver.go

Only change since last reviews. Please check again @Madhu-1 and @Rakshith-R

@mergifyio queue


Adopt Kubernetes recommended label for app

/kind bug
What happened?
The Helm chart is deployed with the resources labelled with app instead of the Kubernetes recommended label app.kubernetes.io/name.
What you expected to happen?
The Helm chart makes use of the recommended label.
How to reproduce it (as minimally and precisely as possible)?
Deploy it.
Anything else we need to know?:
This may possibly be a breaking change as it might require a re-installation of the Helm chart because the selector matchLabels will change.
Same issue in the AWS EBS CSI driver: https://github.com/kubernetes-csi/external-snapshotter/issues/843
Environment

Kubernetes version (use kubectl version): 1.27
Driver version: 0.1.0

Please also attach debug logs to help us better diagnose
n/a

Thank you for bringing this to our attention. We will make this fix promptly.

these changes have been released, closing. Thank you for opening this issue!
/close


Unify configuration options

As @kootoopas correctly pointed out, config options are a bit of a mess.
It would be nice to have a common config for all the global configuration values.
There are three different ways to configure different parts of the daemon or cli.

config file (.nimona/config

[ ] peer key (.key)

env vars

[ ] log level (LOG_LEVEL)
[ ] show debug info for blocks (DEBUG_BLOCKS)
[ ] upnp support (UPNP)
[ ] telemetry client support (TELEMETRY)
[ ] announce local addresses (BIND_LOCAL which might just be the worst env name ever)
[ ] announce ipv6 addresses (BIND_IPV6 same as above)
[ ] telemetry server config (TELEMETRY_*)

command line args

[ ] announce hostname (--announce-hostname)
[ ] api address (--api)
[ ] config path (--config)
[ ] env (--env I'm not even sure what this does)

Assuming we'll go with viper (since we are already using cobra) we would just stick to their precedence as they don't seem to support changing the order.

Viper uses the following precedence order. Each item takes precedence over the item below it:

explicit call to Set
flag
env
config
key/value store
default

It's a bit weird that env precedes config but other than that got no issue.

daemon has been refactored, flags are no longer a thing


Add config directory support

This takes @rtrox's work in GH-93 and cleans it up a bit; pretty much just taking out unrelated changes that were inadvertently included.
@rtrox deserves credit for the feature.
This lets one have a directory full of supernova config files -- e.g.:
$ ls -l ~/.config/supernova.d/
total 32
-rw-r--r--+ 1 marca  staff  406 Jul  8 11:00 az1.ini
-rw-r--r--+ 1 marca  staff  409 Jul  8 10:59 az2.ini
-rw-r--r--+ 1 marca  staff  348 Jul  8 11:00 az3.ini
-rw-r--r--+ 1 marca  staff  348 Jul  8 11:00 az4.ini

This closes #93.

[Current coverage][cc-pull] is 100%

Merging [#121][cc-pull] into [master][cc-base-branch] will not change coverage

@@           master   #121   diff @@
====================================
  Files           6      6
  Lines         367    389    +22
  Methods         0      0
  Messages        0      0
  Branches       74     81     +7
====================================
+ Hits          367    389    +22
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last updated by [05b1bad...a2ce685][cc-compare]
[cc-base-branch]: https://codecov.io/gh/major/supernova/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/major/supernova/compare/05b1bad872c26419dc6b20086ec66316040742ba...a2ce685abe37297ead908427d6d2ec05e72b6b02?src=pr
[cc-pull]: https://codecov.io/gh/major/supernova/pull/121?src=pr

This should have the enhancement label.


Camembert dependency parsing

❓ Questions and Help
Hi, I'm trying to train a model for Dependency Parsing Task. I  found a way to encode the labels of dependency parsing task (using connlu format) and use such that representation to perform a sequence labeling on them (https://github.com/mstrise/dep2label). The problem is that the number of labels is too high.
Which approach did you follow?
Thank you

@louismartin (and benjamin, can't find his github)

@benjamin-mlr any ideas ?

Hi,
The way we did it is to append a graph predictor following Dozat et al. work (https://arxiv.org/abs/1611.01734) on top of CamemBERT.
Then using greedy decoding, we predict the parse tree.
We will release the code soon but meanwhile.
Benjamin

Hello @benjamin-mlr
Do you still plan to release the code?

Hi @GuillaumeEmvista,
We do plan to release the code.
This might take longer than we originally planned but I will keep you updated when we have a clear schedule for the release of the fine-tuned models and the code.

Hi @nlp-ensae,
Any update on this matter ?
Thanks

HI @nlp-ensae,
is there any news?
Thank you!

The code for fine-tuning has not been integrated with fairseq, It is
based on a fork from the transformer library: Here is it
https://github.com/benjamin-mlr/camembert_finetune
On Tue, Nov 10, 2020 at 1:01 PM Elidor00<EMAIL_ADDRESS>wrote:

Hi @nlp-ensae https://github.com/nlp-ensae,
is there any news?
Thank you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pytorch/fairseq/issues/1601#issuecomment-724686718,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEHOJY2LIFQG3UMIHTWUQMDSPE2RXANCNFSM4KEGX3FQ
.

--
Benjamin Muller
Ms in Data Science, specialised in Deep Learning applied to NLP
www.linkedin.com/in/ http://www.linkedin.com/in/benjamin-muller-19796191
Benjamin Muller
Ms in Data Science, specialised in Deep Learning applied to NLP
www.linkedin.com/in/ http://www.linkedin.com/in/benjamin-muller-19796191


Rejected promise during reconnection

Hi,
I noticed that library rejects promise when connection fails and creates new one after dealy (this.settings.timeOut). If I set 30 seconds to reconnect, during this time functions send and unsubscribe won't work properly, because they rely on promise, which is rejected.

You want to send data when the system isn't connected ? Even if the modification are made to support that, the Stomp.js underlying system wont allow this operation.
From the official doc of Stomp.js :

When a client is disconnected, it can no longer send or receive messages

So, I think the problem is somewhere else. You have to choose a smaller timeOut or check the state of the connection. I could add a method on the service to say if the system is connected or not (which will rely on the state of the promise).

Good point. Right now it is imposibble to determine state of the connection. It would be great if you could add such a method.

I'll close this issue and open another to add this element :D


this allows to add mavenLocal by CLI

More https://docs.gradle.org/current/userguide/init_scripts.html
Essentially, run it with -I ./gradle/mavenLocal.init.gradle.kts and mavenLocal will be add for the current command
@ctrueden
Ps: I put this in ./gradle to avoid polluting more the root

Thank you @elect86 for looking at this, and for the pointer to gradle's -I flag for including additional configuration in this way. That is slick.
That said, I don't think it's necessary to include this specific tweak in this repository. So I would close it without merge. Unless @skalarproduktraum or @kephale feel differently? Is it something you would use? If so, keep! But I'm comfortable now just adding mavenLocal() myself to the repositories section as needed locally, in the cases where it's needed.

I'm closing this, but if anyone else feels strongly that having it added would be helpful, please reopen. I have no strong objection against merging it either. Just trying to keep things "simple by default".


conflict with typesafe zinc

Hi,
I am using scala, with it I am using typesafe's zinc (link). After installing the cli globally I am getting the following error after  running zinc -nailed -start:
The specified command --nailgun-port is invalid. For available options, see 'ng help'.
Seems that both libs share the same namespace.
By removing the cli - all gets back to normal.
Here the zinc script which is already uses the ng command:
#!/usr/bin/env bash
#
# Copyright (C) 2012 Typesafe, Inc. <http://www.typesafe.com>
#
# Nailgun client wrapper

# get the source location for this script; handles symlinks
function get_script_path {
  local source="${BASH_SOURCE[0]}"
  while [ -h "$source" ] ; do
    local linked="$(readlink "$source")"
    local dir="$(cd -P $(dirname "$source") && cd -P $(dirname "$linked") && pwd)"
    source="$dir/$(basename "$linked")"
  done
  echo ${source}
}

# script details
declare -r script_path=$(get_script_path)
declare -r script_name=$(basename "$script_path")
declare -r script_dir="$(cd -P "$(dirname "$script_path")" && pwd)"

# default ng command
declare ng_cmd="ng"

# check whether we have an ng command
function ng_exists {
  type -P $ng_cmd > /dev/null 2>&1
}

if ! ng_exists ; then
  # choose bundled binary based on platform
  declare -r una=$( uname -a | tr "[:upper:]" "[:lower:]" )
  declare platform=""
  case "$una" in
    *cygwin*)        platform="win32" ;;
    *mingw32*)       platform="win32" ;;
    *darwin*x86_64*) platform="darwin64" ;;
    *darwin*)        platform="darwin32" ;;
    *linux*x86_64*)  platform="linux64" ;;
    *linux*)         platform="linux32" ;;
    *)               platform="unknown" ;;
  esac
  cmd="$script_dir/ng/$platform/ng"
  [[ -x "$cmd" ]] && ng_cmd="$cmd"
fi

# run ng client command
"$ng_cmd" "$@"

Can I bypass this issue?

You could use the absolute path to ng instead of relying on the environment $PATH resolution.
Basically the problem seems to be that your npm's ng is in front of the one zinc is trying to use. Depending on which one you actually want to use on the command line you'll have to prioritize and fix the other one by using absolute path for the other one.
Hope this helps.

@hansl, This is trivial solution. There will be probably more developers that will encounter, maybe you should consider to rename 'ng'  to something more specific.
Thanks for the help though.


How to Dial HTTPS website

I don't know how to Dial with HTTPS/SSL/TLS website using HTTP proxies, could you help me ? :>

Proxy streaming via HTTP's CONNECT method, The current default Dial is to use that.
https://github.com/wzshiming/httpproxy/blob/3a656c24e6fb3d305588384c131b449a5dfcc188/dialer.go#L105
https://github.com/wzshiming/httpproxy/blob/3a656c24e6fb3d305588384c131b449a5dfcc188/proxy.go#L79


[BUG] Drift detection of user and role collection assignment

Check the drift detection of users and role collections:

[ ] Is the setup consistent with the APIs of the BTP CLI
[ ] Document gaps and/or limitations of the setup for detecting drift for the user management

Scenario A (which is the central one for this request), should be fixed with #518. Needs to be validated after merge

A handling of drifts according to best practices was introduced with #513  and #518 . However the role collection assignment and the connected user management namely the platform APIs do not support a proper handling in accordance to the options of the Terraform framework implemented in aforementioned PRs.
Consequently a sustainable solution would be a proper modelling of a user resource as described in #126 which would provide:

a proper user on- and offboarding
an option to provide proper drift detection

I there fore close this issue in favor of #126,


You need buy mobile proxies

You need buy for attack ru mobile proxies with ip rotation (by timer, with socks5 support)
Example:
https://mobileproxy.space
https://rsocks.net/en/mobile-proxy
https://onlinesim.ru/en/proxy/
PS. Mobile operators have large ip list

How often they can change ip's?

How often they can change ip's?

By timer, 1 min - 5 min
Depends where you bought

we are buying :) Check message in our Discord community https://discord.com/channels/947780848898437170/953993364951416852/953997642210353222
They cost a lot :( So we need donations https://github.com/opengs/uashield/blob/master/README-en.md#donations


VRF cannot open the vmap_c and vwrld_c of my HLA map

Describe the bug
Self explanatory.

Files: vmap_c&vwrld_c.zip
Expected behavior
It should open it
Relevant log output or exception with stacktrace
System.InvalidCastException: Specified cast is not valid.
   at GUI.Types.Renderer.WorldLoader.LoadEntitiesFromLump(EntityLump entityLump, String layerName, Matrix4x4 parentTransform) in /_/GUI/Types/Renderer/WorldLoader.cs:line 779
   at GUI.Types.Renderer.WorldLoader.Load() in /_/GUI/Types/Renderer/WorldLoader.cs:line 76
   at GUI.Types.Renderer.WorldLoader..ctor(World world, Scene scene) in /_/GUI/Types/Renderer/WorldLoader.cs:line 52
   at GUI.Types.Renderer.GLWorldViewer.LoadScene() in /_/GUI/Types/Renderer/GLWorldViewer.cs:line 173
   at GUI.Types.Renderer.GLSceneViewer.OnLoad(Object sender, EventArgs e) in /_/GUI/Types/Renderer/GLSceneViewer.cs:line 272
   at GUI.Controls.GLViewerControl.OnLoad(Object sender, EventArgs e) in /_/GUI/Controls/GLViewerControl.cs:line 438

What game does this happen in
Half life Alyx
Reference file in a Source 2 game
vmap_c&vwrld_c.zip
What version of VRF are you using? Test latest dev build.
10.0.3621

There's nothing to be fixed since you are not sharing the full map.


Bugfix/manager change confirm

@adamgering the fix is in proposals.py, the order of the parameters were messed up before. the change of log message is just a way to figure it out and may be useful down the road as it contains more information


apply_kernel: Allow to use apply_kernel on more dimension types?

Process ID: apply_kernel
Describe the issue:
In the dev telco the proposal came up to use apply_kernel also for other types of dimensions, e.g. to run on the temporal dimension.
Proposed solution:
Allow to choose the dimensions to pass in and make the kernel more flexible.
Additional context:
Might be a breaking change, what's the exact difference to apply_neighborhood?

Closing as duplicate of #324


Profiler instructions from the doc produce an error when installing pmutools

I am trying to use VHive's profiler.
I followed each step of the quick start guide (cloning version 1.4.1) on a CloudLab cluster with the "vHive-cluster-env" profile with 2 nodes.
Then I followed the steps described in docs/profiling.md, but when running scripts/install_pmutools.sh, I get the following error:
Traceback (most recent call last):
  File "/usr/local/pmu-tools/toplev", line 3781, in <module>
    version = runner_emaps()
  File "/usr/local/pmu-tools/toplev", line 3771, in runner_emaps
    runner.ectx.emap = ocperf.find_emap(pmu=runner.pmu if runner.pmu else "cpu")
  File "/usr/local/pmu-tools/ocperf.py", line 979, in find_emap
    return json_with_extra(el, eventmap_is_file, pmu)
  File "/usr/local/pmu-tools/ocperf.py", line 877, in json_with_extra
    name = event_download.eventlist_name(el, pmu_to_type[pmu])
  File "/usr/local/pmu-tools/event_download.py", line 232, in eventlist_name
    files = parse_map_file(name, key, acceptfile=True)
  File "/usr/local/pmu-tools/event_download.py", line 146, in parse_map_file
    cpu, version, name, typ = n
ValueError: too many values to unpack

Do you know why this happens and how to fix it ?
Thanks in advance !

thanks for reporting this issue. @amohoste also noticed the same error few days ago
@dhschall as you are an active user of PMU tools, could you please take a look at why it fails in our script?

Hey, @michaelpaper
yes I also encountered this problem and it seems to come from a bug in the upstream repo.
I fixed it by adding a , *_ in the tuple unpacking of line 146

@dhschall could you please submit a bug fix to upstream?

Created issue and pull request in upstream repo.

I pushed now my changes also to our own fork

@dhschall please open a PR in this repo as well, changing the branch and the repo to the ones in our fork.

fixed by #445


ci(changelog): add automation for changelog

Codecov Report

Merging #305 (f114ea7) into master (97a14ee) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #305   +/-   ##
=======================================
  Coverage   44.80%   44.80%
=======================================
  Files          50       50
  Lines        3049     3049
  Branches      532      532
=======================================
  Hits         1366     1366
  Misses       1506     1506
  Partials      177      177

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 97a14ee...f114ea7. Read the comment docs.


Add ts-toolbelt

ts-toolbelt - Large collection of type utilities for TypeScript
The other type libraries in the list are smaller. It may be helpful to point to this one, too, since it contains some utilities I haven't found in the other ones, such as Narrow (force implicit "as const" in function arguments).

Thank you @ariofrio! Merged


Documentation: Little bug in "What's New" order

It's only appear on main documentation site https://gatling.io/docs/gatling/
I have checked some of other pages and it's look correct but you should check all of them.

That's a know issue (also happens with the "Upgrading" section). We're still investigating. Looks like a cache refresh issue.

Aditionally in exclamation mark table in "What's New in 3.9" should be information about 3.9 breaking changes (it's about 3.8) and there should be link to correct Upgrade guide - now its to 3.7 to 3.8.

Yes, I still see that.
I have cleared browser cache and try in incognito mode:

I tried on mobile phone too using mobile internet and I have the same result.

I think the issue is with synchronizing parent pages. But that's for @notdryft to investigate.

It was indeed in the synchronization. Should be fixed, will close the issue on confirmation.

That's all good now! Thanks a lot!


Added iteration number to stdout

Added an iteration column to the slow cooker stdout in order to know how many iterations to easily see the current progress of the benchmark.
#                         iteration good/b/f t   goal%  min [p50 p95 p99  p999]  max bhash change
2018-10-08T08:28:24+02:00 0    382/0/166 12500   3% 5s   4 [  6  12 2305 2307 ] 2306      0 +
2018-10-08T08:28:29+02:00 1   6493/0/0 12500  51% 5s   2 [  3   5   7   18 ]   18      0 -
2018-10-08T08:28:34+02:00 2   7834/0/0 12500  62% 5s   1 [  3   3   4   20 ]   20      0 --
2018-10-08T08:28:39+02:00 3   1689/15/0 12500  13% 5s   1 [  2   3  15 1058 ] 1058      0 -
2018-10-08T08:28:44+02:00 4     33/10/0 12500   0% 5s   1 [  2 1007 2008 2008 ] 2008      0
2018-10-08T08:28:49+02:00 5     28/25/0 12500   0% 5s   1 [  3 1010 2007 4011 ] 4011      0
2018-10-08T08:28:54+02:00 6     27/2/0 12500   0% 5s   1 [  2 3007 3007 3007 ] 3007      0
2018-10-08T08:28:59+02:00 7   4705/10/0 12500  37% 5s   0 [  2   3   4 2007 ] 2007      0 --
2018-10-08T08:29:04+02:00 8   6753/0/0 12500  54% 5s   0 [  1   2   3  662 ]  662      0 --
2018-10-08T08:29:09+02:00 9   4771/0/0 12500  38% 5s   0 [  1   2   2 2008 ] 2008      0 --
...

Formatting changes done

@farquet Merged, thanks!

Thanks @farquet! Nice to see you again!


Indicator not working when first building the app

This happens only when the app is first built.
When swiping, the indicator does not move. Some pages is empty as well.
When tapping the menu items, the content pages work appropriately. But the indicator still doesn't work

After a while inspecting the code, I found out the reason:
currentOrientationIsPortrait is false for the first time building the app since UIDevice.currentDevice().orientation return Unknown
A quick solution, enable orientation notifications before getting the device orientation:
UIDevice.currentDevice().beginGeneratingDeviceOrientationNotifications()

Thanks for sharing the solution, @trinhngocthuyen !
You're right. This error occurred only sometimes and It was driving me crazy.
Cheers.

This also fixes my problem. I think you should create a pull request.

Also i have fixed my issue with this solution. Thanks

Can anyone point me out where to mofify the code I am so new to iOS. thank you

@trinhngocthuyen  Where and how to replace.

@nonesc @RajIET for swift 3  find  UIDevice.current.orientation in page menu and replace it with UIApplication.shared.statusBarOrientation thanks @trinhngocthuyen

oh you give me a BIG help，thanks ！

You just saved me a ton of time. Thanks @trinhngocthuyen @amitpant

Replaced UIDevice.current.orientation in page menu with UIApplication.shared.statusBarOrientation. It worked. Thank you all for the solution.


HDFS-17162. RBF: Add missing comments in StateStoreService

Description of PR
Small doc fix. StateStoreService lacks an introduction to StateStoreFileSystemImpl and StateStoreMySQLImpl .
How was this patch tested?
No need test, it is doc fix.
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[x] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[x] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

@simbadzina Could you please help to review.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
48m 33s

trunk passed

+1 :green_heart:
compile
0m 42s

trunk passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
0m 36s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
checkstyle
0m 29s

trunk passed

+1 :green_heart:
mvnsite
0m 41s

trunk passed

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 30s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
1m 25s

trunk passed

+1 :green_heart:
shadedclient
39m 51s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 33s

the patch passed

+1 :green_heart:
compile
0m 34s

the patch passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
0m 34s

the patch passed

+1 :green_heart:
compile
0m 30s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
javac
0m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 18s

the patch passed

+1 :green_heart:
mvnsite
0m 33s

the patch passed

+1 :green_heart:
javadoc
0m 29s

the patch passed with JDK Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 23s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
1m 20s

the patch passed

+1 :green_heart:
shadedclient
38m 56s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
22m 12s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

165m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5959/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5959

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux b97c0314cf40 4.15.0-212-generic #223-Ubuntu SMP Tue May 23 13:09:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / cb8d8792e636c4a30d5cd07e9a5ff39d44e2b00f

Default Java
Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.20+8-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5959/1/testReport/

Max. process+thread count
2746 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project/hadoop-hdfs-rbf

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5959/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

When will this code be merged, so it will become my first PR. Hhh,😄.

I don't think the failure of the above test has anything to do with my pr. Can anybody merge my code now. Thx.

hey, remember to include the JIRA ID in the commit title; when i first saw this in the commit message i thought it was a CVE fix going in.
how about we revert and then recommit with the same title as this PR, and credit the author? if it's @flaming-archer's first commit, they deserve to have their name in the commit log...

hey, remember to include the JIRA ID in the commit title; when i first saw this in the commit message i thought it was a CVE fix going in.
how about we revert and then recommit with the same title as this PR, and credit the author? if it's @flaming-archer's first commit, they deserve to have their name in the commit log...

HDFS-17162. RBF: Add missing comments in StateStoreService #5959

Contributed by tian bao

final bit of credit; is TIsNotT your jira account id? as we need to credit you on jira too

hey, remember to include the JIRA ID in the commit title; when i first saw this in the commit message i thought it was a CVE fix going in.
how about we revert and then recommit with the same title as this PR, and credit the author? if it's @flaming-archer's first commit, they deserve to have their name in the commit log...

My bad, I should've tuned the PR description before merging.

no worries. when i saw it in the change log I was wondering if there was a CVE fix coming in

final bit of credit; is TIsNotT your jira account id? as we need to credit you on jira too

yes, it is my jira account id.


Aladdin generated examples

Add Aladdin crafted examples.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: aladdindoc sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

add to S167


log.c: fix double free

Bug found by Svace static analyzer:
Pointer 'pem' is passed to a function free at log.c:1468 by calling function 'free'
after the referenced memory was deallocated at logbuf.c:54 by passing as 1st parameter
to function 'logbuf_new' at log.c:1464

Thanks again. Svace seems like a useful tool, but it apparently misses a few similar double-free bugs in our code.
logbuf_new() is called from two other functions:

logger_write_freebuf()
logger_print_freebuf()

If you search for the places where logger_print_freebuf() is used, you'll find the log_connect_print_free() macro. And then if you search for the places where log_connect_print_free() is called, you'll find two places in pxyconn.c:

pxy_log_connect_nonhttp()
pxy_log_connect_http()

And in both cases msg buf is freed upon error, which is the same bug as svace has found.
It seems like svace cannot handle macros well. What about function pointers (we use function pointers a lot in certain parts of the code)? Does svace handle them well? Or is it a config option?
I was able to manually find only those additional cases yet, I'll keep searching. And I think those are some of the most difficult bugs to catch. Do you think you can use svace to search for all such cases?
Svace does not seem FOSS, or is it? Where do you download it, if possible at all?

I plan to fix all the errors found using the Svace utility. As far as I know, Svace is not FOSS yet.

@sonertari I couldn't find more than you did.

Looking good to me, including your refactoring in logger.c. Thanks.


Fix/bulkactions

Follwoing https://github.com/basxsoftwareassociation/bread/pull/53

nice work, thanks!


add DOI badge

Hi Laura @lazigu ,
this PR just adds a DOI badge to the readme. It links to this page:
https://doi.org/10.5281/zenodo.5884658
Which can be used to scientifically cite the software. I configured Zenodo so that it automatically updates that page everytime we create a new release. I'm happy to show you (or anybody else) how this works. It is surprisingly easy:
https://genr.eu/wp/cite/
Best,
Robert

Hi Robert, this looks great, thanks! And I would definitely like to see how this works.


Mobile candlestick range dropdown and volume dropdown placement/style

We stacked the ochl above the dropdowns b/c there wasn't any room to have them in a line.
Design have any thoughts?

placing below the buttons makes it more connected to the chart. Saves jumping over an obstacle.
Please see the figma mobile designs for guidance

taking this tix for development.

box location looks fixed - closing ticket


Fix qpid proton require under zeitwerk

Add qpid_proton stubs for macs so we can run zeitwek:check

    Before this, macs had to prevent zeitwerk from testing eager loading
    the caller file expecting the Qpid constant to be known.

    Now, we can run it:
    DEBUG_MANAGEIQ_ZEITWERK=true bin/rails zeitwerk:check --trace

Nuage provider assumes Qpid constant is loaded or autoloadable

    manageiq-providers-nuage can be eager loaded on all platforms.  It's dependency,
    qpid_proton, is hidden because it can't be required on macos. Because this is an
    optional dependency, any platforms that can install it will need to eager require it
    since EventCatcher::MessagingHandler needs it at require/load time.

    The alternative is to make qpid_proton require work on mac and define these constants.

    For example:
    class ManageIQ::Providers::Nuage::NetworkManager::EventCatcher::MessagingHandler < Qpid::Proton::MessagingHandler
    ...
    end
    https://github.com/ManageIQ/manageiq-providers-nuage/blob/541494cded64b1ef281c71767d7d5f88cf4bb08d/app/models/manageiq/providers/nuage/network_manager/event_catcher/messaging_handler.rb#L1

I stumbled upon this when I noticed we haven't been building the updated translations.
https://github.com/ManageIQ/manageiq/actions/runs/5861960194/job/15892980355 (last good)
https://github.com/ManageIQ/manageiq/actions/runs/6043713331/job/16401194211 (first bad)
This is because zeitwerk was enabled on August 23rd.  By eager requiring qpid_proton on linux, we should be able to satisfy zeitwerk.

FWIW, I think we are "close" to getting this building on a Mac just fine.  brew install qpid-proton currently installs 0.39.0, but the latest gem is 0.37.0, which is where the mismatch occurs.
Separately, @agrare has been trying to get us to at least 0.37.0 such as in #22271 .  It's strange that rubygems doesn't have a 0.39.0, but maybe we can help make that happen once we get futher on supporting the newer qpid-protons

I actually got qpid-proton 0.37.0 installed locally on mac just fine with some brew tweaking to pull in the old version.  cc @agrare
brew tap homebrew/core
cd /opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/q/
git show ab90ea1d3356382d55bd6aba6e87fc29d5afdb33:Formula/qpid-proton.rb > qpid-proton.rb
HOMEBREW_NO_INSTALL_FROM_API=0 brew install qpid-proton

cd ~/dev/manageiq
gem install qpid_proton -- --with-qpid-proton-dir=$(brew --prefix qpid-proton)

That's awesome, yeah I think we're ready to upgrade to that once we get the appliance rpm side updated (@bdunne )

I do find it interesting that qpid-proton is "optional" from our Gemfile, but not actually optional because Nuage needs it?  Does Zeitwerk not respect optional gem groups?

@agrare Is it possible to go to 0.39.0, since that's the latest (at least the latest in brew)...that would help avoid the annoying homebrew games to install an old version

I believe you can use version 0.39 for the library and 0.37 for the gem (especially for development).
As for going to 0.39 for the gem we are at the mercy of the qpid_proton developers and whenever they push to rubygems.  We could probably ask the mailing list for a release but there is no GH repo as far as I know to open an issue on.

I do find it interesting that qpid-proton is "optional" from our Gemfile, but not actually optional because Nuage needs it? Does Zeitwerk not respect optional gem groups?

It's only "needed" so far for:

zeiterk:check since that tries to eager load the app and engines
locale:update_all because it eager loads models to be able to capture the messages for i18n for each model.

It blows up on https://github.com/ManageIQ/manageiq-providers-nuage/blob/541494cded64b1ef281c71767d7d5f88cf4bb08d/app/models/manageiq/providers/nuage/network_manager/event_catcher/messaging_handler.rb#L1
Yeah, it's messy because of mac.  We moved the requires down into methods to avoid hitting require 'qpid_proton' at require time.  Unfortunately, the toplevel constant above subclasses from a qpid constant so at require/load time, qpid is needed.

I believe you can use version 0.39 for the library and 0.37 for the gem (especially for development).

That failed to compile the gem for me with lots of errors :(

That failed to compile the gem for me with lots of errors :(

Okay that's unfortunate, I've used mixed versions in the past but maybe something breaking about 0.39

This is what I get trying to build 0.37.0 gem against the 0.39.0_1 qpid-protin library:
gem install qpid_proton -- --with-qpid-proton-dir=$(brew --prefix qpid-proton)
Fetching qpid_proton-0.37.0.gem
Building native extensions with: '--with-qpid-proton-dir=/opt/homebrew/opt/qpid-proton'
This could take a while...
ERROR:  Error installing qpid_proton:
	ERROR: Failed to build gem native extension.

    current directory: /Users/jfrey/.gem/ruby/3.0.6/gems/qpid_proton-0.37.0/ext/cproton
/Users/jfrey/.rubies/ruby-3.0.6/bin/ruby -I /Users/jfrey/.rubies/ruby-3.0.6/lib/ruby/3.0.0 -r ./siteconf20231023-29924-hp6l41.rb extconf.rb --with-qpid-proton-dir\=/opt/homebrew/opt/qpid-proton
checking for -lqpid-proton... yes
checking for proton/engine.h... yes
checking for proton/message.h... yes
checking for proton/sasl.h... yes
checking for proton/messenger.h... yes
creating Makefile

current directory: /Users/jfrey/.gem/ruby/3.0.6/gems/qpid_proton-0.37.0/ext/cproton
make DESTDIR\= clean

current directory: /Users/jfrey/.gem/ruby/3.0.6/gems/qpid_proton-0.37.0/ext/cproton
make DESTDIR\=
compiling cproton.c
cproton.c:1172:1: warning: function 'Ruby_Format_OverloadedError' could be declared with attribute 'noreturn' [-Wmissing-noreturn]
{
^
cproton.c:2126:12: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
    return sz;
    ~~~~~~ ^~
cproton.c:2137:12: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
    return sz;
    ~~~~~~ ^~
cproton.c:2148:12: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
    return sz;
    ~~~~~~ ^~
cproton.c:2399:31: error: call to undeclared function 'PN_CLASS'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    static pn_class_t clazz = PN_CLASS(Pn_rbkey);
                              ^
cproton.c:2399:23: error: variable has incomplete type 'pn_class_t' (aka 'struct pn_class_t')
    static pn_class_t clazz = PN_CLASS(Pn_rbkey);
                      ^
/opt/homebrew/opt/qpid-proton/include/proton/types.h:472:16: note: forward declaration of 'struct pn_class_t'
typedef struct pn_class_t pn_class_t;
               ^
cproton.c:2467:11: warning: unused variable 'result' [-Wunused-variable]
    VALUE result = rb_funcall(pni_ruby_get_proton_module(), rb_intern("add_to_registry"), 2, key, value);
          ^
cproton.c:4175:45: error: use of undeclared identifier 'PN_WEAKREF'
  _val = SWIG_NewPointerObj(SWIG_as_voidptr(PN_WEAKREF), SWIGTYPE_p_pn_class_t,  0 );
                                            ^
cproton.c:4282:20: error: call to undeclared function 'pn_class_incref'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (void *)pn_class_incref((struct pn_class_t const *)arg1,arg2);
                   ^
cproton.c:4282:12: warning: cast to 'void *' from smaller integer type 'int' [-Wint-to-void-pointer-cast]
  result = (void *)pn_class_incref((struct pn_class_t const *)arg1,arg2);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cproton.c:4312:17: error: call to undeclared function 'pn_class_refcount'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (int)pn_class_refcount((struct pn_class_t const *)arg1,arg2);
                ^
cproton.c:4312:17: note: did you mean 'pn_class_reactor'?
/opt/homebrew/opt/qpid-proton/include/proton/reactor.h:171:26: note: 'pn_class_reactor' declared here
PNX_EXTERN pn_reactor_t *pn_class_reactor(const pn_class_t *clazz, void *object);
                         ^
cproton.c:4342:17: error: call to undeclared function 'pn_class_decref'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (int)pn_class_decref((struct pn_class_t const *)arg1,arg2);
                ^
cproton.c:4370:3: error: call to undeclared function 'pn_class_free'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  pn_class_free((struct pn_class_t const *)arg1,arg2);
  ^
cproton.c:4399:26: error: call to undeclared function 'pn_class_reify'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (pn_class_t *)pn_class_reify((struct pn_class_t const *)arg1,arg2);
                         ^
cproton.c:4399:12: warning: cast to 'pn_class_t *' (aka 'struct pn_class_t *') from smaller integer type 'int' [-Wint-to-pointer-cast]
  result = (pn_class_t *)pn_class_reify((struct pn_class_t const *)arg1,arg2);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cproton.c:4429:23: error: call to undeclared function 'pn_class_hashcode'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (uintptr_t)pn_class_hashcode((struct pn_class_t const *)arg1,arg2);
                      ^
cproton.c:4465:12: error: call to undeclared function 'pn_class_compare'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = pn_class_compare((struct pn_class_t const *)arg1,arg2,arg3);
           ^
cproton.c:4465:12: note: did you mean 'pn_class_create'?
/opt/homebrew/opt/qpid-proton/include/proton/object.h:36:23: note: 'pn_class_create' declared here
PN_EXTERN pn_class_t *pn_class_create(const char *name,
                      ^
cproton.c:4501:18: error: call to undeclared function 'pn_class_equals'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (bool)pn_class_equals((struct pn_class_t const *)arg1,arg2,arg3);
                 ^
cproton.c:4513:3: error: use of undeclared identifier 'pn_string_t'
  pn_string_t *arg3 = (pn_string_t *) 0 ;
  ^
cproton.c:4513:16: error: use of undeclared identifier 'arg3'
  pn_string_t *arg3 = (pn_string_t *) 0 ;
               ^
cproton.c:4513:37: error: expected expression
  pn_string_t *arg3 = (pn_string_t *) 0 ;
                                    ^
cproton.c:4513:24: error: use of undeclared identifier 'pn_string_t'
  pn_string_t *arg3 = (pn_string_t *) 0 ;
                       ^
cproton.c:4538:24: error: expected expression
  arg3 = (pn_string_t *)(argp3);
                       ^
cproton.c:4538:11: error: use of undeclared identifier 'pn_string_t'
  arg3 = (pn_string_t *)(argp3);
          ^
cproton.c:4538:3: error: use of undeclared identifier 'arg3'
  arg3 = (pn_string_t *)(argp3);
  ^
cproton.c:4539:17: error: call to undeclared function 'pn_class_inspect'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  result = (int)pn_class_inspect((struct pn_class_t const *)arg1,arg2,arg3);
                ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
7 warnings and 20 errors generated.
make: *** [cproton.o] Error 1

make failed, exit code 2

Gem files will remain installed in /Users/jfrey/.gem/ruby/3.0.6/gems/qpid_proton-0.37.0 for inspection.
Results logged to /Users/jfrey/.gem/ruby/3.0.6/extensions/arm64-darwin-22/3.0.0/qpid_proton-0.37.0/gem_make.out

I'll manually generate the message catalogs while we try to get this merged so the bot can generate them from the update_all github workflow.

ok, manually opened a PR to do the updated english messages: https://github.com/ManageIQ/manageiq/pull/22754

Do we have any problems with merging this for now until we can build qpid_proton on mac?  I'd like to see if this allows me to run the github workflow for translations so we can get the bot posting updates to translations: https://github.com/ManageIQ/manageiq/actions/workflows/locale_update_all.yaml

Yea, https://github.com/apache/qpid-proton is only for pull requests and not for issues.

I'm starting to think we should do this another way.  I think the fundamental problem is that the ovirt code is requiring qpid-proton too early, because it is subclassing a Qpid::Proton class directly and that subclassing is suspicious to begin with.  Ideally no provider plugin should require its client libraries until we actually need them (I do understand this case is slightly different because it's about i18n which effectively loads everything.
If we changed the ovirt plugin to not subclass the Qpid::Proton library but instead used composition, would that "avoid" the problem at i18n time?

Ideally no provider plugin should require its client libraries until we actually need them (I do understand this case is slightly different because it's about i18n which effectively loads everything).
If we changed the nuage plugin to not subclass the Qpid::Proton library but instead used composition, would that "avoid" the problem at i18n time?

👍  i18n time really means load time, so yes, if the instances were composed of proton classes, that would move the dependence on the library until instantiation time.

Ok, dropped qpid installation and kept the part where we tell zeitwerk to explicitly ignore eager loading the file that cannot be loaded without requiring the qpid_proton gem.
The github action for update_all was tested and worked: https://github.com/jrafanie/manageiq/actions/runs/6669465925/job/18127299126

restarting after merge of https://github.com/ManageIQ/manageiq/pull/22758

I'm good with this approach for now.  Slight alternative, is it possible to define that "exception" in the nuage plugin itself?  That way these exceptions can be made pluggable (and thus a future fix could remove the exception in the same PR).

Slight alternative, is it possible to define that "exception" in the nuage plugin itself? That way these exceptions can be made pluggable (and thus a future fix could remove the exception in the same PR).

I think I tried this in the past
initializer 'manageiq-decorators.configure_autoloader' do
  Rails.autoloaders.main.ignore("#{root}/lib/manageiq-decorators.rb")
end

I assume you'd define that initializer in the engine and update it to point to the correct path.  I think I chose to fix what I could to avoid that or define them here because engines/gems don't necessarily know if they're using zeitwerk.  Engines could do above.  Gems, no.  They'd need to check if the Rails.autoloaders exists or that it's being used with zeitwerk.

Yeah in this case it's explicitly an engine (and it's an miq engine at that)

I've moved the nuage loader ignore to https://github.com/ManageIQ/manageiq-providers-nuage/pull/299.  I'll move the last commit out to a new PR.