Priority queue

Description
Added data structure priority queue using C++
Closes issue #319
Checklist

[x] I've checked the issue list BEFORE deciding what to submit
[x] I've read the contribution guidelines
[x] I've edited the README.md link to my code

Don't forget to visit our website!
Feel free to add this badge after your submission is accepted!

@all-contributors please add @ChiragTutlani  for code

@all-contributors please add @ChiragTutlani for code


[CLEANUP]  Removing static member import in test class.

Build Commands:
Build:

rm -r ~/.kettle; rm -r ~/.pentaho; echo removed hidden folders
ant -Dpentaho.coding.standards.version=1.0.4 -Djunit.jvmargs=-XX:PermSize=256m -f core/build.xml clean-all resolve jacoco jacoco-integration checkstyle publish-local

Cleanup:
rm -r ~/.ivy2/local || echo no publish local to remove
Changed files:
core/test-src/org/pentaho/di/core/jdbc/ThinUtilTest.java


only transform certain cloudinary nodes

current package versions
"gatsby": "^5.3.3",
"gatsby-transformer-cloudinary": "^4.3.0",
"gatsby-plugin-image": "^3.3.2",

In a previous version of this module there was a setting cloudinaryAssetData that needed to be true in order to transform an existing node into a cloudinaryAsset node. We have a legacy mongoDB site that is set up in this way and we have a media item node type to hold many different kinds of assets, some of which are images which are uploaded to cloudinary on the backend.
After upgrading to gatsby v5 and updating this module i have managed to get images to work in develop, but in build there are a lot of errors around trying to read gatsbyImageData in build, I'm pretty sure this is the build process trying to do something with nodes where we'd previously set cloudinaryAssetData to be false.
Each media item looks like this
 mediaItem {
          cloudinary {
            publicId
            originalWidth
            originalHeight
            cloudinaryAssetData
            cloudName
          }
        ...otherstuff
        }

if the media item is not an image node, the above cloudinary info will be null and cloudinaryAssetData will be false.
I will try to make a patch - but might need some guidance if possible. Below are some of the errors we're getting in case that helps
 ERROR  UNKNOWN

[gatsby-transformer-cloudinary] Missing required fields on mongodbRca2022liveArtistsCloudinary: cloudName=undefined, publicId=undefined

 ERROR  UNKNOWN

[gatsby-transformer-cloudinary] Could not get metadata for mongodbRca2022liveArtistsWorksMediaItemsCloudinary for rca2020 >
rca2022/62b073c09213fab3c571d14d-735997: Request failed with status code 404

running graphql and trying to get all the gatsbyimagedata nodes gives errors like this in graphiQL:
"errors": [
    {
      "message": "Cannot read properties of undefined (reading 'width')",
      "locations": [
        {
          "line": 15,
          "column": 15
        }
      ],
      "path": [
        "allMongodbRca2022LiveArtists",
        "edges",
        5,
        "node",
        "works",
        0,
        "mediaItems",
        6,
        "cloudinary",
        "gatsbyImageData"
      ],
      "extensions": {
        "stack": [
          "TypeError: Cannot read properties of undefined (reading 'width')",
          "    at setDefaultDimensions (/Users/alistairmcclymont/Sites/mtj/RCA/2023/rca-wip-2023-public/node_modules/gatsby-plugin-image/src/image-utils.ts:169:22)",
          "    at y (/Users/alistairmcclymont/Sites/mtj/RCA/2023/rca-wip-2023-public/node_modules/gatsby-plugin-image/src/image-utils.ts:221:10)",
          "    at /Users/alistairmcclymont/Sites/mtj/RCA/2023/rca-wip-2023-public/node_modules/gatsby-transformer-cloudinary/gatsby-plugin-image/resolve-asset.js:116:12",
          "    at processTicksAndRejections (node:internal/process/task_queues:95:5)",
          "    at async Promise.all (index 5)",
          "    at async Promise.all (index 2)",
          "    at async Promise.all (index 6)",
          "    at async Promise.all (index 0)",
          "    at async Promise.all (index 0)",
          "    at async Promise.all (index 0)",
          "    at async Promise.all (index 0)",
          "    at async Promise.all (index 5)",
          "    at async Promise.all (index 0)",
          "    at async Promise.all (index 0)",
          "    at handler (/Users/alistairmcclymont/Sites/mtj/RCA/2023/rca-wip-2023-public/node_modules/graphql-http/lib/handler.js:272:22)",
          "    at requestListener (/Users/alistairmcclymont/Sites/mtj/RCA/2023/rca-wip-2023-public/node_modules/graphql-http/lib/use/express.js:28:34)"
        ]
      }
    },
]

I was pretty sure a solution for this was fixed with #218, will have a look at what might be the problem.

The error that you are seeing is letting you know the data does not confirm (and it means they should be skipped and resolve to null - not a gatsby image). Thinking they should be warnings instead maybe?
Are the errors happening on the build server, or when you try to build locally?

thanks for the reply - the error is building locally - develop works ok, though the errors above are in develop using graphilql to try to check all 14,000 or so images. I did another test and found that around 13,000 nodes have an image with cloudinary, around 1000 have a medianode node without a cloudinary image - i believe this is the issue, but some of the 404s might mean we have some bad/out of date cloudinary data.

I renamed this one to target the error stopping your build @amcc. Open a new issue if you need a way to conditionally transform, after reading my latest comment in #225


Analyzer: alwaysThrow from meta package don't work with null-safety.

Dart SDK version: 2.10.0-45.0.dev (dev) (Wed Aug 19 06:32:03 2020 -0700) on "linux_x64"
import 'package:meta/meta.dart';

void main() {
  print(toBool(-1));
}

bool toBool(int value) {
  if (value == 0) return false;
  if (value == 1) return true;
  // works
  // throw Exception(value);
  error(value);
}

@alwaysThrows
void error(dynamic value) {
  throw Exception(value);
}

Should i use Never for this?
Never error(dynamic value) {
  throw Exception(value);
}

Yes, you should use Never.
The @alwaysThrows annotation is just an annotation. It doesn't change how the language works, all it can do is to make the analyzer not complain about something that it was choosing to complain about otherwise, as an extra check not required by the language.
With null safety, a function returning bool can no longer be allowed to not return a bool value. The language prohibits that, and all the language sees is a call to a function returning void, the annotation has no effect on that. So, to make the language happy,  you have to make the function return Never.


website_sale_autopay: add support for multi company

With a help of this module https://github.com/OCA/website/tree/9.0/website_sale_order_company
we can use multi company mode in commerce.
For this reason we need to update website_sale_autopay. We need to have journal per each company and each payment type. Currently we have only journal per payment type.
Instead of field journal_id in payment.acquirer model, we can add payment_acquirer_id field to account.journal

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Autopay module is not supported anymore (feature is built-in)


Update zio-config, zio-config-magnolia, ... to 1.0.6

Updates

dev.zio:zio-config
dev.zio:zio-config-magnolia
dev.zio:zio-config-typesafe

from 1.0.0-RC29-1 to 1.0.6.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

labels: library-update, semver-pre-release

Superseded by #411.


Stuck upgrading from 4.14.0-0.okd-2023-10-28-073550 to 4.14.0-0.okd-2023-11-12-042703

The upgrade from 4.14.0-0.okd-2023-10-28-073550 to 4.14.0-0.okd-2023-11-12-042703 is stuck!
Weird thing is that nodes being upgraded use newer FCOS with older (?) kernel and older (?) crio ??
2023-10-28-073550: k8s=v1.27.6+f67aeb3  FCOS=38.20231002.3.1   kernel=6.5.5-200.fc38.x86_64   crio=cri-o://1.29.0
2023-11-12-042703: k8s=v1.27.6+b49f9d1  FCOS=38.20231027.3.2   kernel=6.5.4-300.fc39.x86_64   crio=cri-o://1.28.2

The upgrade is stuck since hours...All Cluster Operator have been updated, exceptmachine-config (of course)
Help!
NAME          STATUS                        ROLES                  AGE    VERSION           INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
oc4-master1   NotReady,SchedulingDisabled   control-plane,master   262d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.4-300.fc39.x86_64   cri-o://1.28.2
oc4-master2   Ready                         control-plane,master   262d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
oc4-master3   Ready                         control-plane,master   262d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
oc4-worker1   Ready                         infra,worker           14h    v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
oc4-worker2   Ready                         infra,worker           12h    v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
oc4-worker3   Ready                         worker                 12h    v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0

I will attach must-gather in a few mins

on oc4-master1
journalctl -u kubelet
Nov 13 15:15:00 oc4-master1 kubenswrapper[1160806]: I1113 15:15:00.020489 1160806 kubelet_node_status.go:75] "Successfully registered node" node="oc4-master1"
Nov 13 15:15:00 oc4-master1 kubenswrapper[1160806]: E1113 15:15:00.022052 1160806 kubelet.go:1556] "Failed to start ContainerManager" err="failed to get rootfs info: unable to find data in memory cache"
Nov 13 15:15:00 oc4-master1 systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
Nov 13 15:15:00 oc4-master1 systemd[1]: kubelet.service: Failed with result 'exit-code'.

any advice on this or 'just wait'? :)

@vrutkovs I left a comment on the associated PR
The kernel version you set for FCOS in Dockerfile does not seems right to me nut I may be wrong...

Is there a solution for the issue?

@madpearl, I think the way forward here is to wait for a new release and then forcefully upgrade the cluster.
After the cluster then has been upgraded, the machine-config-daemon pods will have to be restarted in order to ensure the next upgrades will complete without failure

Releasing a fix in 4.14.0-0.okd-2023-11-14-101924. If you're affected you should be able to start a new upgrade midflight.
Please report here if this actually helped.

I think there is a solution in this case.
The last working version of OS Image is:
quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b (quay.io/openshift/okd-content:4.14.0-0.okd-2023-11-14-101924-fedora-coreos)
Just to replace the baseOSContainerImage in ConfigMap machine-config-osimageurl namespace: openshift-machine-config-operator

oc -n openshift-cluster-version scale --replicas=0 deploy/cluster-version-operator
oc patch cm -n openshift-machine-config-operator machine-config-osimageurl --type=merge -p '{"data": {"baseOSContainerImage":"quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b"}'

You don't need to patch the CM (MCO will revert this change), use layering.
You can specify either previous: quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b or updated OS image quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b

My cluster is already upgraded , just I'm waiting the worker nodes
NAME                            STATUS                     ROLES    AGE    VERSION           INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
libvirt-cp-1.libvirt.alma.lan   Ready                      master   517d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
libvirt-cp-2.libvirt.alma.lan   Ready                      master   517d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
libvirt-cp-3.libvirt.alma.lan   Ready                      master   517d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
libvirt-w-1.libvirt.alma.lan    Ready                      worker   517d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
libvirt-w-2.libvirt.alma.lan    Ready,SchedulingDisabled   worker   517d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
libvirt-w-3.libvirt.alma.lan    Ready                      worker   517d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
libvirt-w-4.libvirt.alma.lan    Ready                      worker   329d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
libvirt-w-5.libvirt.alma.lan    Ready                      worker   329d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0

# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-d4688823c74e8141ea7a7a2e4bf6a2f0   True      False      False      3              3                   3                     0                      517d
worker   rendered-worker-408401a9f9c48f4080c05109139b62f7   False     True       False      5              1                   1                     0                      517d

I've forced the machine-config on each server to be upgraded at the first time, then the upgrade process start with upgrade the last version. I've tried to run from the machine /run/bin/machine-config-daemon pivot... thinking that will force upgrade, but during the upgrade it is not possible. In ERROR message is explained what I can do and I did it!
[root@libvirt-w-2 ~]# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b

	ERROR: pivot no longer forces a system upgrade. It will be fully removed in a later y release.
	If you are attempting a manual OS upgrade, please try the following steps:
	-delete the currentconfig(rm /etc/machine-config-daemon/currentconfig)
	-create a forcefile(touch /run/machine-config-daemon-force) to retry the OS upgrade.

	More instructions can be found here: https://access.redhat.com/solutions/5598401

[root@libvirt-w-2 ~]# mv /etc/machine-config-daemon/currentconfig .
[root@libvirt-w-2 ~]# touch /run/machine-config-daemon-force
[root@libvirt-w-2 ~]# exit
logout
[core@libvirt-w-2 ~]$ exit
logout

@vrutkovs, seemed to work. The master02 node is now ready.
[19:42:13 - root@helper01 ~]# oc get nodes -o wide
NAME                           STATUS                        ROLES                  AGE    VERSION           INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
master01.okd.domain.tld   Ready                         control-plane,master   256d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master02.okd.domain.tld   Ready,SchedulingDisabled      control-plane,master   256d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master03.okd.domain.tld   Ready                         control-plane,master   256d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
worker01.okd.domain.tld   Ready                         worker                 256d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
worker02.okd.domain.tld   NotReady,SchedulingDisabled   worker                 256d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0

Should I continue to uncordon the node?

Excellent. Yeah, you'd probably have to uncordon it manually, not sure if MCO will do that.
Same needs to be done with NotReady worker

Okay, done.
The upgrade to seems to have gone through with the exception of machine-config:
[20:00:43 - root@helper01 ~]# oc adm upgrade
Failing=True:

  Reason: ClusterOperatorNotAvailable
  Message: Cluster operator machine-config is not available

info: An upgrade is in progress. Unable to apply 4.14.0-0.okd-2023-11-14-101924: the cluster operator machine-config is not available

Upgradeable=False

  Reason: DegradedPool
  Message: Cluster operator machine-config should not be upgraded between minor versions: One or more machine config pools are degraded, please see `oc get mcp` for further details and resolve before upgrading

Upstream: https://amd64.origin.releases.ci.openshift.org/graph
Channel: stable-4
No updates available. You may still upgrade to a specific release image with --to-image or wait for new updates to be available.

Would forcing a system upgrade be an option here?

For me, it worked without a forced cluster upgrade. Had the same problems, applied the latest update, booted the failing machine with the previous version in the grub boot menu. Followed https://access.redhat.com/solutions/5414371 to get the failing machine to update. Cluster is now upgraded and everything is healthy.
Thanks for the quick fix by the way!

I think I found a solution but I'm currently hitting a '403' when pulling images from quay but It's highly unlikely it's a issue with okd since this is happening with another kubernetes cluster and podman

I think I found a solution but I'm currently hitting a '403' when pulling images from quay but It's highly unlikely it's a issue with okd since this is happening with another kubernetes cluster and podman

Yes quay.io is having some issues.
https://status.quay.io

just to follow up, the update has worked now and the cluster is healthy.

I also ran into this issue, but I wasn't able to get it fixed as described above with oc adm upgrade --allow-not-recommended --to 4.14.0-0.okd-2023-11-14-101924 --allow-upgrade-with-warnings. All my operators are still at 4.14.0-0.okd-2023-11-12-042703, and
Upgrade conditions report the following errors:
Preconditions failed for payload loaded version="4.14.0-0.okd-2023-11-14-101924" image="registry.ci.openshift.org/origin/release@sha256:72d40c51e7c4d1b9c31e9b0d276d045f1b2b93def5ecee49186df856d40bcb5c": Multiple precondition checks failed:
* Precondition "ClusterVersionUpgradeable" failed because of "ClusterOperatorsNotUpgradeable": Multiple cluster operators should not be upgraded between minor versions:
* Cluster operator machine-config should not be upgraded between minor versions: DegradedPool: One or more machine config pools are degraded, please see `oc get mcp` for further details and resolve before upgrading

I'm stuck with the following situation right now:
Node upgrade status is half v1.27.6+f67aeb3, half v1.26.9+636f2be
oc get node -o wide
NAME        STATUS                     ROLES    AGE    VERSION           INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
compute01   Ready                      worker   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
compute02   Ready                      worker   291d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
compute03   Ready,SchedulingDisabled   worker   291d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
compute04   Ready                      worker   291d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master01    Ready                      master   332d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
master02    Ready                      master   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master03    Ready                      master   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0

However, operators are still on 4.14.0-0.okd-2023-11-12-042703
oc get co
NAME                                       VERSION                          AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.14.0-0.okd-2023-11-12-042703   True        False         False      130m
baremetal                                  4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
cloud-controller-manager                   4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
cloud-credential                           4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
cluster-autoscaler                         4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
config-operator                            4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
console                                    4.14.0-0.okd-2023-11-12-042703   True        False         False      123m
control-plane-machine-set                  4.14.0-0.okd-2023-11-12-042703   True        False         False      284d
csi-snapshot-controller                    4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
dns                                        4.14.0-0.okd-2023-11-12-042703   True        False         False      291d
etcd                                       4.14.0-0.okd-2023-11-12-042703   True        False         False      332d
image-registry                             4.14.0-0.okd-2023-11-12-042703   True        False         False      114m
ingress                                    4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
insights                                   4.14.0-0.okd-2023-11-12-042703   True        False         False      284d
kube-apiserver                             4.14.0-0.okd-2023-11-12-042703   True        False         False      332d
kube-controller-manager                    4.14.0-0.okd-2023-11-12-042703   True        False         False      332d
kube-scheduler                             4.14.0-0.okd-2023-11-12-042703   True        False         False      332d
kube-storage-version-migrator              4.14.0-0.okd-2023-11-12-042703   True        False         False      114m
machine-api                                4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
machine-approver                           4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
machine-config                             4.13.0-0.okd-2023-10-28-065448   True        True          True       106m    Unable to apply 4.14.0-0.okd-2023-11-12-042703: error during syncRequiredMachineConfigPools: [context deadline exceeded, error MachineConfigPool worker is not ready, retrying. Status: (pool degraded: true total: 4, ready 0, updated: 0, unavailable: 2)]
marketplace                                4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
monitoring                                 4.14.0-0.okd-2023-11-12-042703   True        False         False      146m
network                                    4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
node-tuning                                4.14.0-0.okd-2023-11-12-042703   True        False         False      14h
openshift-apiserver                        4.14.0-0.okd-2023-11-12-042703   True        False         False      87d
openshift-controller-manager               4.14.0-0.okd-2023-11-12-042703   True        False         False      284d
openshift-samples                          4.14.0-0.okd-2023-11-12-042703   True        False         False      14h
operator-lifecycle-manager                 4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
operator-lifecycle-manager-catalog         4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
operator-lifecycle-manager-packageserver   4.14.0-0.okd-2023-11-12-042703   True        False         False      291d
service-ca                                 4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
storage                                    4.14.0-0.okd-2023-11-12-042703   True        False         False      333d

Any ideas how to get this sorted? plz halp! :pray:  :sweat:

@b2cc You are still is 4.13.0-0.okd-2023-10-28-065448.
Can you show the output of oc get mcp?

@llomgui :
oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75   False     True       True       3              0                   0                     2                      333d
worker   rendered-worker-907db1844bf150e23b391af092688ce1   False     True       True       4              0                   0                     2                      333d

Also oc adm upgrade says:
oc adm upgrade
info: An upgrade is in progress. Working towards 4.14.0-0.okd-2023-11-14-101924

Upgradeable=False

  Reason: ClusterOperatorsNotUpgradeable
  Message: Multiple cluster operators should not be upgraded between minor versions:
  * Cluster operator machine-config should not be upgraded between minor versions: DegradedPool: One or more machine config pools are degraded, please see `oc get mcp` for further details and resolve before upgrading
  * Cluster operator kube-apiserver should not be upgraded between minor versions: KubeletMinorVersion_KubeletMinorVersionUnsupportedNextUpgrade: KubeletMinorVersionUpgradeable: Kubelet minor versions on nodes compute02, compute03, and master01 will not be supported in the next OpenShift minor version upgrade.

ReleaseAccepted=False

  Reason: PreconditionChecks
  Message: Preconditions failed for payload loaded version="4.14.0-0.okd-2023-11-14-101924" image="registry.ci.openshift.org/origin/release@sha256:72d40c51e7c4d1b9c31e9b0d276d045f1b2b93def5ecee49186df856d40bcb5c": Multiple precondition checks failed:
  * Precondition "ClusterVersionUpgradeable" failed because of "ClusterOperatorsNotUpgradeable": Multiple cluster operators should not be upgraded between minor versions:
  * Cluster operator machine-config should not be upgraded between minor versions: DegradedPool: One or more machine config pools are degraded, please see `oc get mcp` for further details and resolve before upgrading
  * Cluster operator kube-apiserver should not be upgraded between minor versions: KubeletMinorVersion_KubeletMinorVersionUnsupportedNextUpgrade: KubeletMinorVersionUpgradeable: Kubelet minor versions on nodes compute02, compute03, and master01 will not be supported in the next OpenShift minor version upgrade.
  * Precondition "ClusterVersionRecommendedUpdate" failed because of "UnknownUpdate": RetrievedUpdates=False (NoArchitecture), so the recommended status of updating from 4.14.0-0.okd-2023-11-14-101924 to 4.14.0-0.okd-2023-11-14-101924 is unknown.

@b2cc
On degraded machines, run the following (one by one):
sudo touch /run/machine-config-daemon-force
sudo rm -f /run/machine-config-daemon-force
It will trigger a new Os Upgrade.

@llomgui :  Ok thanks for your answer, did this on master01 now and could see how it , but it seems it rebooted into an older version (?)
I'm kind of confused what went wrong during the upgrade. I think it never pulled all the operator pods for 4.14.0-0.okd-2023-11-14-101924 or did anything to actually upgrade the nodes. Is there a way to force a full re-run of the upgrade process, including upgrading all the operators?
Regardind the the commands you sent, this happened:
In the machine-config-daemon logs I could see:
I1115 10:32:52.537867    3467 daemon.go:1835] Validating against current config rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 10:32:52.538474    3467 daemon.go:1748] SSH key location ("/home/core/.ssh/authorized_keys.d/ignition") up-to-date!
I1115 10:32:55.142646    3467 rpm-ostree.go:307] Running captured: rpm-ostree kargs
I1115 10:32:55.237488    3467 update.go:1946] Validated on-disk state
I1115 10:32:55.244579    3467 daemon.go:1914] Completing update to target MachineConfig: rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 10:33:05.948735    3467 update.go:1946] Update completed for config rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75 and node has been successfully uncordoned
I1115 10:33:06.046079    3467 daemon.go:1939] In desired state MachineConfig: rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 10:33:06.085785    3467 config_drift_monitor.go:246] Config Drift Monitor started
I1115 10:33:06.085945    3467 daemon.go:670] Transitioned from state: Degraded -> Done
I1115 10:33:06.085958    3467 daemon.go:673] Transitioned from degraded/unreconcilable reason unexpected on-disk state validating against rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75: expected target osImageURL "quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff", have "quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0" ("03633df374d8481181dfc80f969083d173d535e22f75393a4245ec9bfba8dc0f") ->
[ ... ]
I1115 11:31:22.724749   34709 update.go:1946] Starting to manage node: master01
I1115 11:31:22.732841   34709 rpm-ostree.go:307] Running captured: rpm-ostree status
I1115 11:31:22.909105   34709 daemon.go:1473] State: idle
Deployments:
* ostree-unverified-registry:quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff
                   Digest: sha256:66f89c40fa959073d6dcedcd746682e2e4a336d90ce3604715ff64d55c0bfe4c
                  Version: 38.20231002.3.1 (2023-10-27T20:30:47Z)
I1115 11:31:22.909696   34709 coreos.go:54] CoreOS aleph version: mtime=2022-07-25 19:04:41.434 +0000 UTC build=36.20220716.3.1 imgid=fedora-coreos-36.20220716.3.1-metal.x86_64.raw
I1115 11:31:22.910121   34709 coreos.go:71] Ignition provisioning: time=2022-12-16T10:15:12Z
I1115 11:31:22.910139   34709 rpm-ostree.go:307] Running captured: journalctl --list-boots
I1115 11:31:22.980944   34709 daemon.go:1482] journalctl --list-boots:
IDX BOOT ID                          FIRST ENTRY                  LAST ENTRY
 -3 afb875db060d4fe7b7384c4b95d862ff Mon 2023-09-18 20:50:55 CEST Tue 2023-11-14 18:54:24 CET
 -2 e3e1a0e8df064706b9df75ee98615ec4 Tue 2023-11-14 18:54:36 CET  Wed 2023-11-15 08:37:14 CET
 -1 401ec63ba9944929b6cacb4a29d1fbf2 Wed 2023-11-15 08:37:27 CET  Wed 2023-11-15 10:30:47 CET
  0 ec9643fe067a40838f2c694c5fb1c4a0 Wed 2023-11-15 10:30:58 CET  Wed 2023-11-15 11:31:22 CET
I1115 11:31:22.980986   34709 rpm-ostree.go:307] Running captured: systemctl list-units --state=failed --no-legend
I1115 11:31:23.001209   34709 daemon.go:1497] systemd service state: OK
I1115 11:31:23.001326   34709 daemon.go:1142] Starting MachineConfigDaemon
I1115 11:31:23.001496   34709 daemon.go:1149] Enabling Kubelet Healthz Monitor
I1115 11:31:23.778392   34709 daemon.go:606] Node master01 is part of the control plane
I1115 11:31:23.908448   34709 daemon.go:1308] Previous boot ostree-finalize-staged.service appears successful
I1115 11:31:23.908495   34709 daemon.go:1425] Current+desired config: rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 11:31:23.908519   34709 daemon.go:1441] state: Done
I1115 11:31:23.908594   34709 update.go:1931] Running: rpm-ostree cleanup -r
Deployments unchanged.
I1115 11:31:24.020604   34709 daemon.go:1835] Validating against current config rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 11:31:24.020861   34709 update.go:1946] Skipping on-disk validation; /run/machine-config-daemon-force present
I1115 11:31:24.058210   34709 update.go:1968] Adding SIGTERM protection
I1115 11:31:24.127226   34709 update.go:435] Checking Reconcilable for config rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75 to rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75
I1115 11:31:24.255269   34709 update.go:1946] Starting update from rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75 to rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75: &{osUpdate:true kargs:false fips:false passwd:false files:false units:false kernelType:false extensions:false}
I1115 11:31:24.258458   34709 update.go:346] Setting post config change action to postConfigChangeActionReboot; /run/machine-config-daemon-force present
I1115 11:31:24.258537   34709 update.go:1946] Update prepared; requesting cordon and drain via annotation to controller
I1115 11:32:44.305753   34709 update.go:1946] drain complete
I1115 11:32:44.310622   34709 drain.go:95] Successful drain took 80.050247861 seconds
I1115 11:32:44.310770   34709 update.go:1168] Updating files
I1115 11:32:44.310889   34709 file_writers.go:163] Writing file "/usr/local/bin/nm-clean-initrd-state.sh"
I1115 11:32:44.314765   34709 file_writers.go:163] Writing file "/etc/NetworkManager/conf.d/01-ipv6.conf"
I1115 11:32:44.318531   34709 file_writers.go:163] Writing file "/etc/NetworkManager/conf.d/20-keyfiles.conf"
I1115 11:32:44.321995   34709 file_writers.go:163] Writing file "/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt"
I1115 11:32:44.324107   34709 file_writers.go:163] Writing file "/etc/kubernetes/apiserver-url.env"
I1115 11:32:44.327590   34709 file_writers.go:163] Writing file "/etc/audit/rules.d/mco-audit-quiet-containers.rules"
I1115 11:32:44.331051   34709 file_writers.go:163] Writing file "/etc/tmpfiles.d/cleanup-cni.conf"
I1115 11:32:44.334254   34709 file_writers.go:163] Writing file "/etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem"
I1115 11:32:44.336179   34709 file_writers.go:163] Writing file "/usr/local/bin/configure-ovs.sh"
I1115 11:32:44.342916   34709 file_writers.go:163] Writing file "/etc/containers/storage.conf"
I1115 11:32:44.346485   34709 file_writers.go:163] Writing file "/etc/mco/proxy.env"
I1115 11:32:44.349473   34709 file_writers.go:163] Writing file "/etc/systemd/system.conf.d/10-default-env-godebug.conf"
I1115 11:32:44.352422   34709 file_writers.go:163] Writing file "/etc/modules-load.d/iptables.conf"
I1115 11:32:44.355559   34709 file_writers.go:163] Writing file "/etc/node-sizing-enabled.env"
I1115 11:32:44.358602   34709 file_writers.go:163] Writing file "/usr/local/sbin/dynamic-system-reserved-calc.sh"
I1115 11:32:44.362155   34709 file_writers.go:163] Writing file "/etc/systemd/system.conf.d/kubelet-cgroups.conf"
I1115 11:32:44.365118   34709 file_writers.go:163] Writing file "/etc/systemd/system/kubelet.service.d/20-logging.conf"
I1115 11:32:44.368438   34709 file_writers.go:163] Writing file "/etc/NetworkManager/conf.d/sdn.conf"
I1115 11:32:44.371431   34709 file_writers.go:163] Writing file "/etc/NetworkManager/dispatcher.d/pre-up.d/10-ofport-request.sh"
I1115 11:32:44.375487   34709 file_writers.go:163] Writing file "/var/lib/kubelet/config.json"
I1115 11:32:44.378564   34709 file_writers.go:163] Writing file "/etc/kubernetes/ca.crt"
I1115 11:32:44.381849   34709 file_writers.go:163] Writing file "/etc/sysctl.d/arp.conf"
I1115 11:32:44.384674   34709 file_writers.go:163] Writing file "/etc/sysctl.d/forward.conf"
I1115 11:32:44.389967   34709 file_writers.go:163] Writing file "/etc/sysctl.d/inotify.conf"
I1115 11:32:44.392989   34709 file_writers.go:163] Writing file "/etc/sysctl.d/enable-userfaultfd.conf"
I1115 11:32:44.395982   34709 file_writers.go:163] Writing file "/etc/sysctl.d/vm-max-map.conf"
I1115 11:32:44.399115   34709 file_writers.go:163] Writing file "/usr/local/bin/mco-hostname"
I1115 11:32:44.403676   34709 file_writers.go:163] Writing file "/usr/local/bin/recover-kubeconfig.sh"
I1115 11:32:44.408128   34709 file_writers.go:163] Writing file "/etc/kubernetes/kubelet-plugins/volume/exec/.dummy"
I1115 11:32:44.410132   34709 file_writers.go:163] Writing file "/etc/NetworkManager/dispatcher.d/99-vsphere-disable-tx-udp-tnl"
I1115 11:32:44.413003   34709 file_writers.go:163] Writing file "/etc/containers/registries.conf"
I1115 11:32:44.416016   34709 file_writers.go:163] Writing file "/etc/crio/crio.conf.d/00-default"
I1115 11:32:44.419689   34709 file_writers.go:163] Writing file "/etc/containers/policy.json"
I1115 11:32:44.422905   34709 file_writers.go:163] Writing file "/etc/kubernetes/cloud.conf"
I1115 11:32:44.425980   34709 file_writers.go:163] Writing file "/etc/kubernetes/kubelet.conf"
I1115 11:32:44.429254   34709 file_writers.go:163] Writing file "/usr/local/bin/kubenswrapper"
I1115 11:32:44.432395   34709 file_writers.go:163] Writing file "/etc/crio/crio.conf.d/01-mc-addInheritableCapabilities"
I1115 11:32:44.436167   34709 file_writers.go:223] Writing systemd unit "NetworkManager-clean-initrd-state.service"
I1115 11:32:44.443156   34709 file_writers.go:137] Writing systemd unit dropin "01-kubens.conf"
I1115 11:32:44.447831   34709 file_writers.go:123] Dropin for 10-mco-default-env.conf has no content, skipping write
I1115 11:32:44.447875   34709 file_writers.go:137] Writing systemd unit dropin "10-mco-profile-unix-socket.conf"
I1115 11:32:44.451321   34709 file_writers.go:137] Writing systemd unit dropin "10-mco-default-madv.conf"
I1115 11:32:45.779476   34709 update.go:1454] Preset systemd unit crio.service
I1115 11:32:45.779547   34709 file_writers.go:137] Writing systemd unit dropin "mco-disabled.conf"
I1115 11:32:47.017293   34709 update.go:1454] Preset systemd unit docker.socket
I1115 11:32:47.017360   34709 file_writers.go:223] Writing systemd unit "kubelet-auto-node-size.service"
I1115 11:32:47.020351   34709 file_writers.go:137] Writing systemd unit dropin "01-kubens.conf"
I1115 11:32:47.022961   34709 file_writers.go:123] Dropin for 10-mco-default-env.conf has no content, skipping write
I1115 11:32:47.023017   34709 file_writers.go:137] Writing systemd unit dropin "10-mco-default-madv.conf"
I1115 11:32:47.025499   34709 file_writers.go:223] Writing systemd unit "kubelet.service"
I1115 11:32:47.028130   34709 file_writers.go:223] Writing systemd unit "kubens.service"
I1115 11:32:47.030483   34709 file_writers.go:223] Writing systemd unit "machine-config-daemon-firstboot.service"
I1115 11:32:47.032786   34709 file_writers.go:223] Writing systemd unit "machine-config-daemon-pull.service"
I1115 11:32:47.035141   34709 file_writers.go:223] Writing systemd unit "node-valid-hostname.service"
I1115 11:32:47.037500   34709 file_writers.go:223] Writing systemd unit "nodeip-configuration.service"
I1115 11:32:47.040160   34709 file_writers.go:223] Writing systemd unit "ovs-configuration.service"
I1115 11:32:47.042576   34709 file_writers.go:137] Writing systemd unit dropin "10-ovs-vswitchd-restart.conf"
I1115 11:32:48.293623   34709 update.go:1454] Preset systemd unit ovs-vswitchd.service
I1115 11:32:48.293657   34709 file_writers.go:137] Writing systemd unit dropin "10-ovsdb-restart.conf"
I1115 11:32:48.296070   34709 file_writers.go:123] Dropin for 10-mco-default-env.conf has no content, skipping write
I1115 11:32:48.311765   34709 update.go:1491] Could not reset unit preset for pivot.service, skipping. (Error msg: error running preset on unit: Failed to preset unit: Unit file pivot.service does not exist.
)
I1115 11:32:48.311789   34709 file_writers.go:123] Dropin for 10-mco-default-env.conf has no content, skipping write
I1115 11:32:48.311824   34709 file_writers.go:137] Writing systemd unit dropin "mco-controlplane-nice.conf"
I1115 11:32:49.642895   34709 update.go:1454] Preset systemd unit rpm-ostreed.service
I1115 11:32:49.642950   34709 file_writers.go:137] Writing systemd unit dropin "mco-disabled.conf"
I1115 11:32:51.129906   34709 update.go:1454] Preset systemd unit zincati.service
I1115 11:32:51.129948   34709 file_writers.go:223] Writing systemd unit "custom-timezone.service"
I1115 11:32:52.394600   34709 update.go:1432] Enabled systemd units: [NetworkManager-clean-initrd-state.service kubelet-auto-node-size.service kubelet.service machine-config-daemon-firstboot.service machine-config-daemon-pull.service node-valid-hostname.service nodeip-configuration.service openvswitch.service ovs-configuration.service ovsdb-server.service custom-timezone.service]
I1115 11:32:53.689685   34709 update.go:1443] Disabled systemd units [kubens.service]
I1115 11:32:53.689762   34709 update.go:1231] Deleting stale data
I1115 11:32:53.690041   34709 update.go:1629] updating the permission of the kubeconfig to: 0o600
I1115 11:32:53.690190   34709 update.go:1595] Checking if absent users need to be disconfigured
I1115 11:32:53.841077   34709 update.go:1620] Password has been configured
I1115 11:32:53.841258   34709 update.go:2021] Already in desired image quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff
I1115 11:32:53.841280   34709 update.go:1931] Running: rpm-ostree cleanup -p
Deployments unchanged.
I1115 11:32:54.167877   34709 update.go:1946] Rebooting node

After the reboot it seems nothing changed on the node:
oc get node -o wide
NAME        STATUS   ROLES    AGE    VERSION           INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
compute01   Ready    worker   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
compute02   Ready    worker   291d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
compute03   Ready    worker   291d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
compute04   Ready    worker   291d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master01    Ready    master   332d   v1.26.9+636f2be   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.26.4
master02    Ready    master   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0
master03    Ready    master   332d   v1.27.6+f67aeb3   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231002.3.1   6.5.5-200.fc38.x86_64   cri-o://1.29.0

On the node, rpm-ostree
[root@master01 ~]# rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff
                   Digest: sha256:66f89c40fa959073d6dcedcd746682e2e4a336d90ce3604715ff64d55c0bfe4c
                  Version: 38.20231002.3.1 (2023-10-27T20:30:47Z)

Current mco status:
oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75   False     True       True       3              0                   0                     2                      333d
worker   rendered-worker-907db1844bf150e23b391af092688ce1   False     True       True       4              0                   0                     2                      334d

@b2cc just an idea but have you checked the machineconfiguration state of the node? This might give some clues on what is failing and why

Folks, please stop posting random command outputs. They barely have sufficient info about the cluster to determine it state. If you want to help, please post links to must-gathers

@vrutkovs ; understood, please find the must-gather here:

https://next.dest-unreachable.net/index.php/s/QM2iGoGgSwkPffZ/download/must-gather.local.3485124115697728764.tar.gz

@b2cc seems you've started the upgrade to broken version:
  - completionTime: null
    image: registry.ci.openshift.org/origin/release@sha256:72d40c51e7c4d1b9c31e9b0d276d045f1b2b93def5ecee49186df856d40bcb5c
    startedTime: "2023-11-15T07:51:56Z"
    state: Partial
    verified: false
    version: 4.14.0-0.okd-2023-11-14-101924
  - completionTime: "2023-11-15T07:51:56Z"
    image: registry.ci.openshift.org/origin/release@sha256:2242d1df4e4cbcc0cd27191ab9ad5f55ac4f0c60c3cda2a186181a2435e3bd00
    startedTime: "2023-11-14T18:40:47Z"
    state: Partial
    verified: true
    version: 4.14.0-0.okd-2023-11-12-042703

Check if https://github.com/okd-project/okd/issues/1798#issuecomment-1811150533 works for you?

@vrutkovs : sadly, I think this command is waht got me into this mess. True, I started from the broken version, and then tried to fix it with the command from the comment you mentioned (see also https://github.com/okd-project/okd/issues/1798#issuecomment-1812144668)
Anyways, when I currently run this command I only get this message:
~# oc adm upgrade --allow-not-recommended --to 4.14.0-0.okd-2023-11-14-101924 --allow-upgrade-with-warnings

info: Cluster is already at version 4.14.0-0.okd-2023-11-14-101924

This is why I was asking if there is a way to restart the upgrade, because to it looks like the cluster thinks it already upgraded, but all the operators and some of the ostree images of some nodes are still on the old version.

@vrutkovs : something must be off - on all the nodes where the c9625...7e94 image is active the MCO reports that it is actually not expected to be there:
I1115 13:00:50.586217       1 status.go:126] Degraded Machine: master01 and Degraded Reason: unexpected on-disk state validating against rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75: expected target osImageURL "quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff", have "quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b" ("c2eed2c2f03c345a650a4f67d3658d3a28bc943f7af9a2fbe4afe334e960a250")
I1115 13:00:50.586240       1 status.go:126] Degraded Machine: master02 and Degraded Reason: unexpected on-disk state validating against rendered-master-f6aeade89f39cb96bf1ef145be51a4df: expected target osImageURL "quay.io/openshift/okd-content@sha256:34f3d15a2a5f1a9b6e5e158e2198d077b149288ccc13cb31b31563d3cd493c48", have "quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0" ("eac647fc9377adb5774f646e4b7875e5d70d752e3a0e77919e3311c65202067b")
I1115 13:00:50.586253       1 status.go:126] Degraded Machine: master03 and Degraded Reason: unexpected on-disk state validating against rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75: expected target osImageURL "quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff", have "quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0" ("46c79a7d89ce53074f2e0c6c62eb1574b41d046fb6d4a6820225dc9e65079a95")
I1115 13:00:50.586583       1 node_controller.go:1096] No nodes available for updates
I1115 13:00:50.586743       1 status.go:126] Degraded Machine: compute01 and Degraded Reason: unexpected on-disk state validating against rendered-worker-2105c6a330a1754be6bff36191c3f659: expected target osImageURL "quay.io/openshift/okd-content@sha256:34f3d15a2a5f1a9b6e5e158e2198d077b149288ccc13cb31b31563d3cd493c48", have "quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0" ("76bc925e61e81958ff434f2e67349f75e72bad8eeaf561c8b6b080f8a28ad2d1")
I1115 13:00:50.586765       1 status.go:126] Degraded Machine: compute04 and Degraded Reason: unexpected on-disk state validating against rendered-worker-907db1844bf150e23b391af092688ce1: expected target osImageURL "quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff", have "quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0" ("6022f4615f322114ccbfa0f4c21793d003fbea7376d8c881e13d19a15c2778d7")

E.g. on master01 the update was definitely applied, I can see it on the node:
[root@master01 ~]# rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b
                   Digest: sha256:f4427952552049d1fb8088660db6b1dc9d5d90968deb00265cc9f8f1238d37f5
                  Version: 38.20231027.3.2 (2023-11-14T09:43:10Z)

but the MCO pod complains about it being the wrong image:
E1115 14:04:25.797385    3444 writer.go:226] Marking Degraded due to: unexpected on-disk state validating against rendered-master-1ab7ec20bb3a1ae7bf1d65cad995df75: expected target osImageURL "quay.io/openshift/okd-content@sha256:49dfcf845391bae2140b73ba93461acd93d75b4fd14d774e8c91c0e2acd8f0ff", have "quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b" ("c2eed2c2f03c345a650a4f67d3658d3a28bc943f7af9a2fbe4afe334e960a250")

New must-gather is here:

https://next.dest-unreachable.net/index.php/s/QxDJJFXbxnzM7Xd/download/must-gather.local.4739750401485647279.tar.gz

Nov 13 15:31:49 oc4-master1 kubenswrapper[1175832]: E1113 15:31:49.501347 1175832 kubelet.go:1556] "Failed to start ContainerManager" err="failed to get rootfs info: unable to find data in memory cache"

This indicates that it's a problem with cgroupsv1.  Updating the nodes to use cgroupsv2 will also allow them to boot.  Edit nodes.config/cluster if you follow that direction.  Afterwards this needs some messaging of the machine-config-daemon to allow the other nodes to come u again though.

@ibotty : this is just the error from one of the broken master nodes on version 4.14.0-0.okd-2023-11-12-042703, where the kubelet is not starting. There is no need to switch to cgroupsv2 as far as I can tell, 4.14.0-0.okd-2023-11-14-101924 works fine.
What I'm trying to figure out is how I can get my cluster to actually upgrade to 4.14.0-0.okd-2023-11-14-101924, because currently I'm stuck in some kind of limbo.

I had some adventures with this upgrade as well. Took me 2 days to untangle my cluster but I finally did it (and this issue helped me) so posting my observations here in hopes it helps someone else. On the upside, my application downtime was 0, so cheers to all the things about this platform that worked well. I should say thank you to the developers more often :)
It seems the 4.14.0-0.okd-2023-11-12-042703 combined with kernel 6.5.4-300.fc39.x86_64 caused great unhappiness for the kubelet. More specifically, the unhappy nodes got stuck in NotReady state and investigation into the kubelet status (journalctl -xeu kubelet) on those nodes revealed the familiar Failed to start ContainerManager .. failed to get rootfs info: unable to find data in memory cache. Googling said error message led me to
https://github.com/kubernetes/kubernetes/issues/120813  which hinted at the cgroups issues. I knew I was guilty of mucking with cgroups last year in an attempt to work around the CPU hang in https://github.com/okd-project/okd/issues/1310 so I figured I'd try to fail forward and force my kernel onto cgroupsv2 ( systemd.unified_cgroup_hierarchy=1). This combination allowed the kubelet to start, but got me into major trouble with the MCO - which kept trying to revert back into cgroupsv1 and complained about degraded pools. By the end of the first night, I had multiple overriding configurations in my kernel args, the cpu leaks back, and a headache. So for anyone else trying to get clever with cgroupsv2 - don't 🙂.
What finally worked was a combination of kernel 6.5.5-200.fc38.x86_64 with cgroupsv1. It took some time to get the half-updated nodes / operators happy onto 4.14.0-0.okd-2023-11-14-101924  but the process involved the layered mc from https://github.com/okd-project/okd/issues/1798#issuecomment-1810652942 (which worked partially on the nodes healthy enough to apply it) + manually forcing the MCO out of degraded state  + manually uncordoning nodes so the MCO can learn it should happy + manual rebasing the kernel on nodes that landed on the wrong one. Looked something like this:

upgrade stuck because pool degraded?

sudo touch /run/machine-config-daemon-force

and uncordon the node so the machine config daemon can mark the pool as no longer degraded.

upgrade stuck because some node not ready?  is uname -a showing the 300 kernel and cat /proc/cmdline showing systemd.unified_cgroup_hierarchy=0 ?

sudo rpm-ostree rebase ostree-unverified-registry:quay.io/openshift/okd-content@sha256:9d7531141cc297d75785cd3adc353ae98cd3738af46205de14c14ef2cd6039d0

and reboot
There may have been a more graceful way to do this, but iterating through the problematic nodes like this seemed to do the trick. Good luck out there🙂

Ok, I can report progress here as well. With much fiddling around in some ways similar as described by @kapetre above, I managed to get the MCO operator errors out of the way and the cluster back into a working state. However, the overall cluster state is a mess right now :see_no_evil:
First of all, as advised in a comment above, I now have all nodes running on image sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b. Also, the the MCO seems to be satisfied as well, no pools show as updating anymore:
oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-4bad9a599f9f3b8b46171a6ef0d1e828   True      False      False      3              3                   3                     0                      334d
worker   rendered-worker-9d8446a4343fd3f23c23a0223b3bcf10   True      False      False      4              4                   4                     0                      334d

oc get node -o wide
NAME        STATUS   ROLES    AGE    VERSION           INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION          CONTAINER-RUNTIME
compute01   Ready    worker   333d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
compute02   Ready    worker   292d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
compute03   Ready    worker   292d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
compute04   Ready    worker   292d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
master01    Ready    master   333d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
master02    Ready    master   333d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0
master03    Ready    master   333d   v1.27.6+b49f9d1   <IP_ADDRESS>   <none>        Fedora CoreOS 38.20231027.3.2   6.5.5-200.fc38.x86_64   cri-o://1.27.0

However, clusterversions never updated and still show the cluster being on 4.13:
oc get clusterversions
NAME      VERSION                          AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.0-0.okd-2023-10-28-065448   True        True          36h     Working towards quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b

More confusingly, all the operators are listed at being at 4.14.0-0.okd-2023-11-12-042703, which was  the broken version. So it seems te operators never updated to 4.14.0-0.okd-2023-11-14-101924 (?):
oc get co
NAME                                       VERSION                          AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.14.0-0.okd-2023-11-12-042703   True        False         False      12h
baremetal                                  4.14.0-0.okd-2023-11-12-042703   True        False         False      334d
[ ... ]
kube-apiserver                             4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
kube-controller-manager                    4.14.0-0.okd-2023-11-12-042703   True        False         False      333d
machine-config                             4.14.0-0.okd-2023-11-12-042703   True        False         False      11h
[ ... ]
service-ca                                 4.14.0-0.okd-2023-11-12-042703   True        False         False      334d
storage                                    4.14.0-0.okd-2023-11-12-042703   True        False         False      334d

And, for good measure, oc adm upgrade still shows the cluster as updating, with a keyring error and a Message: Architecture has not been configured error:
oc adm upgrade
info: An upgrade is in progress. Working towards quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b

ReleaseAccepted=False

  Reason: RetrievePayload
  Message: Retrieving payload failed version="" image="quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b" failure=The update cannot be verified: unable to verify sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b against keyrings: verifier-public-key-ci

Upstream: https://amd64.origin.releases.ci.openshift.org/graph
Channel: stable-4
warning: Cannot display available updates:
  Reason: NoArchitecture
  Message: Architecture has not been configured.

Any pointers on how I get this riddle untangled?
New must-gather here:

Working towards quay.io/openshift/okd-content@sha256:c9625a8236f0cbe4a32e4788502d1a3d9f1a24f017db6fa09f3f224b2987e94b

That doesn't look correct. This is a machine-os image, not a release payload. This is why CVO is not happy (NoArchitecture and no signature).
Running oc adm upgrade --allow-not-recommended --to-image=quay.io/openshift/okd@sha256:72d40c51e7c4d1b9c31e9b0d276d045f1b2b93def5ecee49186df856d40bcb5c --allow-upgrade-with-warnings should resolve that

@vrutkovs : thanks for the quick response, I'll look into it!

@vrutkovs : Thank you so much for your support - that was the missing piece. Must have have confused the os-image and the release at some point. Now the operators finally upgraded, and the update finished! :+1:
oc get clusterversions
NAME      VERSION                          AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.0-0.okd-2023-11-14-101924   True        False         115s    Cluster version is 4.14.0-0.okd-2023-11-14-101924

:tada:
Thanks again and all the best!

Total mess on my side. I didn't manage to recover from the first upgrade failure as I described it initially in this ticket
I tried almost all of the trick described here, ie go back to previous kernel, force mco to upgrade the nodes, uncordon the failing nodes etc and I probably did some bad moves/actions ("replace" worker nodes..) that lead to a total mess of the cluster
I finally reinstalled the cluster with the latest OKD version, half a day of outage
This had the advantage to refresh our install procedures.
I also tried to reduced the capabilities on install as it is possible now with v4.14, but I hit other walls and learned the hard way (eg if you disable the "image" capability, custom certificates to pull image are not propagated to the nodes Updating the global cluster pull secret, probably a bug, but that another story..)
So the freshly re-installed cluster is now up and runnning again
I will close this ticket in a few days, to give the time to everyone to describe their experience on how they recover from this bad OKD release

f you disable the "ImageRegistry" capability, custom certificates to pull image are not propagated to the nodes

that indeed sounds like a bug, but not OKD specific, please file a new one in RH Jira

@vrutkovs I am also trying to get a cluster through this trouble.
With your advice from above I got it so far that all nodes are ready again. One master and one worker have sort of new release but MCO still complains about these being degraded.
Could you please take a look at this? Thanks!
https://domino.ars.de/file/must-gather.local.4374526442884007980.tar.gz

I could not wait longer so I reverted the cluster now back to OKD 4.13 2023-10-28.
Together with this cluster I have a total of six clusters currently on one of the last OKD 4.13 releases.
For these I will have to find a solution to get them to 4.14.
So the question is: how can this issue be avoided? I assume the 4.14 2023-11-12 release should be avoided at any cost.
But the update graph does currently not allow a direct upgrade from the last 4.13 release to the 2023-11-14 release.
Neither does it allow an upgrade from 4.14 2023-10-28 to the 2023-11-14 release...

Added new upgrade edges:

4.13.0-0.okd-2023-10-28-065448 -> 4.14.0-0.okd-2023-11-14-101924
4.14.0-0.okd-2023-10-28-073550 -> 4.14.0-0.okd-2023-11-14-101924
Ping me if more edges should be added

problem solved by upgrading to 4.14.0-0.okd-2023-11-14-101924+

@vrutkovs Is it possible to remove the edges pointing to the 4.14.0-0.okd-2023-11-12-042703 release? I think nobody wants to land on it accidentally.

I don't think so, but I don't see a reason why would it be picked if its not the latest release.
I'll check with release-controller devs on this

For the record: an upgrade fom 4.13 2023-10-28 to 4.14 2023-11-14 just went through fine.


adjust web phone start time to match active call time

Coverage decreased (-0.02%) to 40.419% when pulling b457f519672ed865280413e63cb42c430328e85e on embbnux:bugfix/active-call-match-time into 0c20f333f00c4adf9ebc312516d64ae444933854 on ringcentral:master.


VRAM overflow

After three generations, the third case became a VRAM overflow, even though I have 24GB VRAM (RTX 3090) and using ref images. I see that after the generation, for some reason, it uses more and more memory and in the end it doesn't empty the memory.
Is it possible that the previous model will not be removed from memory when the model is changed?
It would be nice to improve this a bit more to generate more. Now I only generate one image at a time, so I stay under 24 GB (17 GB on average).
Is this the reason why not all pictures are captioned with Classic Comic style?

Same issue!!! Please try to fix this devs


⚠ 366.ru has degraded performance

In 2c0289f, 366.ru (https://366.ru) experienced degraded performance:

HTTP code: 200
Response time: 1680 ms

Resolved: 366.ru performance has improved in 30e5765.


How can i filter data into separate spreadsheets within the same workbook using the ImportExcel

Hello all,
I would like to use the ImportExcel module to separate spreadsheets within the same workbook. I would like create multiple new worksheets based on different filter criteria from the main.

Please could you provide a sample of the xlsx file before and after.


engine-api: create unique description for each API version

Signed-off-by: Sebastiaan van Stijn<EMAIL_ADDRESS>
Proposed changes

Unreleased project version (optional)

Related issues (optional)

@usha-mandya ptal


Refactor create and generate core functions to class

Description
Rather than having separate functions hanging there in a file create a class  and access modifier to it, so that the code looks clean.
Suggested solution
Create a singleton class and add the function to it and also add the appropriate access modifiers.
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[ Triaged ] Good to start developing.


Css of feedback page in mobile view

css of feedback page is not good

@codervivek5 please assign as gssoc is going to end final contributions


Docker-Compose Infrastructure As Code

This Micro byte has activities to create Docker Compose file

Any leads? @kethavathsivanaik . We were expecting u to be working these days

If I want to explain each and every keyword from code It will become some pages so I taught it won't be a micro byte

@Kevinpaulose05 If I want to explain each and every keyword from code It will become some pages. That's the reason I add a reference in the end.so I taught it won't be a micro byte

We are also not expecting u to spoon feed each and every term. But to a newbie do u think it will make sense when he/she reads ur title? Even after going thru ur material, no one can get what lamp. For a docker person, it may make some sense. Refer this
U need to mention pre-requisites in which u shud cover installation of docker with suitable links. Then all activities should be aimed towards building something and learning along the way. Pls restructure ur microbyte into a more reformed manner. Do refer other microbytes to get an idea.  We are pleased to have u onboard. But if u fail to contribute on time we may fail to acknowledge u. Kindly stick with us and make the changes.

As we are done with #IBelieveinDoing - Hacktoberfest edition we have officially stopped accepting any more PRs. We are sorry to do this but we have to close this PR to avoid any further confusion on our side. We apologise for not being to guide you in the right time. Hope you participate actively in our next month's edition of #IBelieveinDoing and other events at Crio too. Till then keep contributing and all the best!


Makefile: cleanup build system

Allow overriding the "general purpose" (performance, debugging, hardening) flags in $(CFLAGS), $(CXXFLAGS) and $(LDFLAGS) while at the same time ensuring they always contain the "functionally required" flags (C/C++ standard conformance, diagnostics and preprocessor definitions).

This e.g. makes it possible to build inotify-info with
$ make CFLAGS=-O2 CXXFLAGS=-O2

Where -O2 overrides the instruction set, optimization level and debugging information generation flags (as might be the distro policy), while keeping the necessary flags such as -std=... and -D... intact.

Thanks! I just realized I have packaged this to NixOS with -march=native.

I think we should get rid of -march=native and leave it to the callers. Can you review https://github.com/mikesart/inotify-info/pull/44 ?


Add documentation website

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@959e2bb). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #72   +/-   ##
=======================================
  Coverage        ?   70.55%
=======================================
  Files           ?       16
  Lines           ?     1002
  Branches        ?        0
=======================================
  Hits            ?      707
  Misses          ?      295
  Partials        ?        0


ASP.NET Identity Core 2.0 - Expiration phone token

One of the methods exposed by UserManager is GenerateChangePhoneNumberTokenAsync.
Looking to the code, I noticed that the method mentioned is calling Rfc6238AuthenticationService.GenerateCode. It seems to me that the lifetime of the token is hardcoded to 3 minutes as showed bellow.
private static readonly TimeSpan _timestep = TimeSpan.FromMinutes(3);

        // More info: https://tools.ietf.org/html/rfc6238#section-4
        private static ulong GetCurrentTimeStepNumber()
        {
            var delta = DateTime.UtcNow - _unixEpoch;
            return (ulong)(delta.Ticks / _timestep.Ticks);
        }

        // More info: https://tools.ietf.org/html/rfc6238#section-4
        private static ulong GetCurrentTimeStepNumber()
        {
            var delta = DateTime.UtcNow - _unixEpoch;
            return (ulong)(delta.Ticks / _timestep.Ticks);
        }

        public static int GenerateCode(byte[] securityToken, string modifier = null)
        {
            if (securityToken == null)
            {
                throw new ArgumentNullException(nameof(securityToken));
            }

            // Allow a variance of no greater than 9 minutes in either direction
            var currentTimeStep = GetCurrentTimeStepNumber();
            using (var hashAlgorithm = new HMACSHA1(securityToken))
            {
                return ComputeTotp(hashAlgorithm, currentTimeStep, modifier);
            }
        }

Source: https://github.com/aspnet/Identity/blob/85f8a49aef68bf9763cd9854ce1dd4a26a7c5d3c/src/Core/Rfc6238AuthenticationService.cs
Am I correct? Is this the lifetime of the phone token?
If yes, since the value is hardcoded, any ideas how to change it?

+1

Having to replace EmailTokenProvider and PhoneTokenProvider because they rely on the inconfigurable internal Rfc6238AuthenticationService.  This is starting to become a pattern where classes are "designed" for override, but hide/pin all the bits you need.
for example.

UserManager  ( UpdateSecurityStampInternal, UpdatePasswordHash, NewSecurityStamp, etc )
UserStore ( DbSets )
IdentityUserContext ( GetStoreOptions )
OpenIdConnectHandlers ( Hardcoded generic parameter type for base - closes event handler extensibility )

When these issues are brought up they are generally put on the backlog, never to be addressed, meanwhile we copy all your code and hope it doesn't change.

Closing as by design


Box spec is now matches Ellipse

This is a simple fix to Box so it uses the (width, height) spec, matching Ellipse. I think what happened is I fixed the flip in Ellipse but forgot to make the same fix in Box.

@philippjfr Tests are passing. Ready to merge.

Any idea what's up with the coverage drop?

I'll merge and assume coveralls just got confused.


Email sending failure in lite user registration

Describe the issue:
If a lite user registration request is made as given below, the server will respond with an internal server error.
Request
curl -X POST -H "Authorization: Basic [Base64encode(Username>:<Password>)]=" -H "Content-Type: application/json" -d '{"email
": "<regsiter_email>","realm": "PRIMARY","preferredChannel":"Email","claims":[], "properties": []}' "https://localhost:9443/api/identity/user/v1.0/lite"

Response
{
    "code": "20019",
    "message": "Internal server error",
    "description": "The server encountered an internal error. Please contact administrator.",
    "traceId": "dcc8721d-d654-467c-a6b0-f4c58d5821eb"
}

Error trace
2023-04-27 04:49:48,366] [dcc8721d-d654-467c-a6b0-f4c58d5821eb] ERROR {org.wso2.carbon.identity.user.endpoint.impl.LiteApiServiceImpl} - Error occurred in the server while performing the task. org.wso2.carbon.identity.recovery.IdentityRecoveryServerException: Error while adding self signup user
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
.
.
.
	... 74 more
Caused by: org.wso2.carbon.identity.event.IdentityEventException: Email notification sending failed. Sending email address is not configured for the user.
	at org.wso2.carbon.identity.event.handler.notification.util.NotificationUtil.buildNotification(NotificationUtil.java:526)
	at org.wso2.carbon.identity.event.handler.notification.NotificationHandler.handleEvent(NotificationHandler.java:66)
	at org.wso2.carbon.identity.event.services.IdentityEventServiceImpl.handleEvent(IdentityEventServiceImpl.java:56)
	at org.wso2.carbon.identity.recovery.handler.LiteUserRegistrationHandler.triggerNotification(LiteUserRegistrationHandler.java:392)
	... 75 more

The request is successful if the email address is given as a claim value.
curl -X POST -H "Authorization: Basic [Base64encode(Username>:<Password>)]=" -H "Content-Type: application/json" -d '{"email
": "<regsiter_email>","realm": "PRIMARY","preferredChannel":"Email","claims":[{"uri": "http://wso2.org/claims/emailaddress","value": "<regsiter_email>" }], "properties": []}' "https://localhost:9443/api/identity/user/v1.0/lite"

How to reproduce:
Follow the steps given in https://is.docs.wso2.com/en/6.0.0/guides/identity-lifecycles/self-registration-workflow/
Expected behavior:
The confirmation email should be sent using the registration email without defining it again in the claims.
Environment information

Product Version: IS 6.1.0

similar issue reported in https://github.com/wso2/product-is/issues/11373

Track the doc improvement for resending confirmation mail as well https://github.com/wso2/product-is/issues/13468

After analysing the lite user registration flow, following details have been identified.
Example Payload
{
    "email": "<regsiter_email>",
    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[],
    "properties": []
}

Based on the existing implementation, the email field within the mentioned payload functions as the designated username for the user. However, during the process of sending email confirmations to users, the system attempts to retrieve the email address from email claims. Consequently, email notifications are dispatched to the email address found within the claims, even if we have explicitly provided an email address in the email field.
The existing behaviour of the API in handling various payload types is as follows:
Provide only email field

Payload

{
    "email"<EMAIL_ADDRESS>    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[],
    "properties": []
}

Response (Status - 500)

{
    "code": "20019",
    "message": "Internal server error",
    "description": "The server encountered an internal error. Please contact administrator.",
    "traceId": "b740a817-17ba-4c38-88f7-1a87332824d1"
}

As we haven't included the email within the claims, the send-to field becomes null when sending notifications. Consequently, the error message Email notification sending failed. Sending email address is not configured for the user. is triggered.

Populate the designated email field and the email claims with the same email address

Payload

{
    "email"<EMAIL_ADDRESS>    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response

201 Created

Populate the designated email field and the email claims with the different email address

Payload

{
    "email"<EMAIL_ADDRESS>    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response

201 Created

During user creation, the username is set as<EMAIL_ADDRESS>and the email address is set as<EMAIL_ADDRESS>As a result, the email confirmation will be sent to the<EMAIL_ADDRESS>address.

Populate the designated email field with a username and the email claim with an email address

Payload

{
    "email": "diltest",
    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response

201 Created

Since the email field uses as the username, it undergoes username validation. This enables users to input a username through the email field while sending the actual email address via claims.

Add the username claim with a different value

Payload

{
    "email"<EMAIL_ADDRESS>    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/username","value": "diltest"},
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response (500)

{
    "code": "20019",
    "message": "Internal server error",
    "description": "The server encountered an internal error. Please contact administrator.",
    "traceId": "f8e58a4f-49f8-49de-b7b7-9d909715401b"
}

There is a validation step to check whether the email field and username claim are same. If not the error Username and the username claim value should be same. is thrown.

Add the username claim with the same value

Payload

{
    "email": "diltest",
    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/username","value": "diltest"},
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response

201 Created

Exclude the email field

Payload

{
    "realm": "PRIMARY",
    "preferredChannel":"Email",
    "claims":[
        {"uri": "http://wso2.org/claims/username","value": "diltest"},
        {"uri": "http://wso2.org/claims/emailaddress","value"<EMAIL_ADDRESS>    ],
    "properties": []
}

Response (400)

{
    "code": "USR-10004",
    "message": "Bad Request",
    "description": "Either email or mobile should be submitted.",
    "traceId": "5483b079-0b6b-4363-beff-1091a727309a"
}

Another related issue: https://github.com/wso2/product-is/issues/16206

Another related issue: #16206

This should have been sorted, @DilshanSenarath could u verify this issue?


A way to spawn monsters in activated state

Would it be possible to integrate a feature that allows to spawn monsters in an already activated state, as it is done in some RtL Quests?

I have never seen this in RtL. If the monster spawns at the end round trigger it won't activate that round, but will not show as activated. This is consistent with RtL.

This happens in multiple quests in RtL. The easiest example to point to is the first Quest of the "Kindred Fire" campaign.
See screenshots for a reproduceable example:

I hadn't realised that.  I will think about a good way to do this.

BUMP ¬_¬


how to build the image for packaged war using jib

Description of the issue:

Expected behavior:
Steps to reproduce:

Environment:
jib-maven-plugin Configuration:
PASTE YOUR pom.xml CONFIGURATION HERE

jib-gradle-plugin Configuration:
PASTE YOUR build.gradle CONFIGURATION HERE

Log output:
Additional Information:

For containerizing WAR projects, see https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#war-projects
If you are asking if it is possible to put a packaged WAR instead of putting exploded WAR contents into the image, implementing the support is on our radar. (For example, we recently implemented a feature to put a packaged JAR (#905), to be released in 1.4.0.) But I think in many cases, images using exploded WAR contents will work fine. Do you have any issue using exploded WAR?

Hi,
When I used spring bot application   with jib the exploded war got created
and copied to web inf folder in tomcat server. But, the application is not
visible and accessible. Even i tried with manually copying  war to webapps
folder it's not working still.
On Fri, Jun 21, 2019, 8:17 PM Chanseok Oh<EMAIL_ADDRESS>wrote:

For containerizing WAR projects, see
https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#war-projects
If you are asking if it is possible to put a packaged WAR instead of
putting exploded WAR contents into the image, implementing the support is
on our radar. (For example, we recently implemented a feature to put a
packaged JAR (#905
https://github.com/GoogleContainerTools/jib/issues/905), to be released
in 1.4.0.) But I think in many cases, images using exploded WAR contents
will work fine. Do you have any issue using exploded WAR?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleContainerTools/jib/issues/1802?email_source=notifications&email_token=ALDFQWI3VL7DL3QFEUUGT6TP3TSZTA5CNFSM4H2SEHS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYIVQJY#issuecomment-504453159,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALDFQWKDUXKGCW67LDGHQO3P3TSZTANCNFSM4H2SEHSQ
.

@murali474 Our war support uses defaults for the gcr.io/distroless/java/jetty image.  It sounds like you need to set a different appRoot for Tomcat, which is discussed in the docs (Gradle, Maven)

Hi,
i have used the tomcat as base image and added corresponding approot value
under plugin configuration.
Regards,
Murali
On Tue, Jun 25, 2019 at 10:12 PM Brian de Alwis<EMAIL_ADDRESS>wrote:

@murali474 https://github.com/murali474 Our war support uses defaults
for the gcr.io/distroless/java/jetty image. It sounds like you need to
set a different appRoot for Tomcat, which is discussed in the docs (Gradle
https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#war-projects,
Maven
https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#war-projects
)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleContainerTools/jib/issues/1802?email_source=notifications&email_token=ALDFQWM4LNPH7SVJCJG2XSTP4JDG3A5CNFSM4H2SEHS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQ3M2Q#issuecomment-505525866,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALDFQWP3TY2BIF3GWLUJHEDP4JDG3ANCNFSM4H2SEHSQ
.

@murali474 it should work. I suspect your project's main artifact is not a WAR. From the other issue of yours, I know you are using Maven. Does your pom.xml has <packaging>war</packaging>? (<packaging> is not a Jib configuration but a Maven one.)
And I've not used Spring Boot WAR for a long time, but I remember the Spring Boot application should have a SpringBootServletInitializer class defined, so double-check you have it.

Closing due to inactivity. Feel free to re-open if you have an update or feedback.

Is there a good example of how to create a docker container using jib plugin with tomcat and spring-boot as a WAR? The documentation is very weak in this matter.

@ffroliva Spring Boot WAR projects should work with Jib. If applying Jib doesn't work, most likely you are not putting the exploded WAR contents into the right directory where your base image expects. Here's an example configuration.
However, whenever we get this type of questions, especially if you are developing a new application or using Spring Boot, we strongly recommend not using the legacy WAR format. WARs are for the days where resources and CPU were expensive and you needed an app server to run multiple apps to share resources. When building a container image, running an app server for a WAR doesn't make a lot of sense, especially for a Spring Boot app.
For some reason if you still must create a WAR, we still recommend a profile approach (e.g., #2229) to avoid WAR for a container image.


Can`t make breakpoints using debugger in unit test

In chrome browser on port 9876 on break point to analyze code.
Issue Overview
http://prntscr.com/bga96j
Issue Description
add debugger in tests
Reproducables
just try to add debugger in tests and run chrome browser on localhost:9876
Information

Operating System
Windows/OSX/Ubuntu/orYourOSHere

Node version
4.x/5.x/orYourNodeVersionHere

NPM Version
2.x/3.x/orYourNPMVersionHere

Environment
Browser/Mobile/WebWorker

not sure how to fix this, this may help

Tomorrow I will try to run separately. I hope this helps.

This information was not very helpful. I guess this problems is related to type script remapping .

Remapping is a separate process after karma's done, not sure why it's the problem.

Anyway I need more details on how you do the debugging.
For now, I just tried gulp test -w and use Karma Chrome launcher, then do click DEBUG, and then I started to put debugger; statement in spec file, and refresh the debug page, here is what I got

It worked well (although I got tslint warning on debugger; usage)

This works as expected. Working on "real time" debugging and compiling.
Created
gulpfile.js
gulp.task('serv', function() {
runSequence('serve-local', 'unit-test');
});
and
serve.js
gulp.task('serve-local', function ()
{
startBrowsersync(config.browserSync.dev);
});
Then added debugger after launched
gulp serv --exclude-source -w
I guess  ['tsc-app', 'watch-ts'] need to be added.

closing this issue then

{ included: false, watched: false, pattern: 'src/app/**/*.ts' },
In Karma why included: false is false?

because ts files are not loaded directly via script tag
https://karma-runner.github.io/0.13/config/files.html

After changing spec file need to kill gulp test -w and run over again.

Sorry please explain the detail more, why you need to kill the test watch?
Working well on my side.

Can You Explain local development cycle writing code, test and checking changes on web server? Because every time I need to close gulp commands and start others tasks to preprocess type script and code coverage and start static server.

And using  --exclude-source on every gulp command to avoid writing directly to c drive is not best solution. Currently local workflow is main issue.

If the problem is workflow, then it'll get nowhere, since everyone have different opinions on this. You can fork the starter and start implementing your desired flows, I'll help where I can.


feat(testrunner): test discovery using f#

Uses vstest and F# instead of dotnet test -t. Needs to specify exe path manually via configuration for now. Uncertain about linux compatibility. Matches testresults with id instead of name
Features:

[x] Fixes MSTest discovery issues
[x] Better lookup on testresults using Id instead of fully qualified name

Issues:

[x] Requires an absolute vstest.console path to work (ships with dotnet sdk confirmed)
[x] Test on linux
[ ] Add check if name doesnt contain . and use namespace instead (or merge name and namespace)
[ ] Value too large (partition json with F#)

Before merging:

[x] Replace old test parser with new programatically

Hi, I could test this if you are ready for feedback

Yeah knock yourself out, you need to add path to config like this
{
  test_runner = {
    vstest_path = "C:/etc..."
  }
}

On windows i had to open visual studio command prompt and write where vstest.console.exe to get the path.

Was looking into vstest on linux. I came to this docu: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-vstest
Have you tried this?

Yeah i made a question on my issue on the microsoft github asking whether the path is necessary or if i can reference something preinstalled in dotnet cli

Ok, cool. I will wait for the answer of the vstest project. I got some troubles trying to install vstest on linux. In the worst case I could use wine, but this is for me the last resort.
To be honest, actually I am using WSL, so theoretically I could use the vstest executable of windows, but this is always to avoid due to the performance issues.
In any case, I could give a try to both options

If this comes down to either WSL or wine for linux compability, I will probably discard this PR and improve stdout parsing

Seems like it ships with the dotnet sdk. I just tested with vstest_path = "C:/Program Files/dotnet/sdk/8.0.400/vstest.console.dll"
Can you test if you find it and if it works on linux @franroa

I can confirm that there is a file there:
/usr/lib/dotnet/sdk/8.0.108/vstest.console.dll
Will test with that path later today. Let me know when this is ready

Just tried only out of curiosity. It works pretty well, but there is an issue with (apparently) json objects when the project is too big:
Vim:E1510: Value too large:
stack traceback:
	[C]: in function 'json_decode'
	.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:191: in function <.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:185>
Vim:E1510: Value too large:
stack traceback:
	[C]: in function 'json_decode'
	.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:191: in function <.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:185> function: builtin#18 Vim:E1510: Value too large:
stack traceback:
	[C]: in function 'json_decode'
	.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:191: in function <.../easy-dotnet.nvim/lua/easy-dotnet/test-runner/runner.lua:185>

Yeah Im aware of this, I was unsure when this would be a problem, ill just have to update the F# script to partition the json output

Either dump as partitioned json in stdout or write to os.tmpname and cleanup afterwards

per line reading seems to be a good solution. I will test this branch afterwards

@franroa Should work now, I added the json partitioning using line by line as mentioned above. Let me know if there are any more issues

It works pretty well in general. By every new run I get an error by two or three cases. The cases don't seem to be always the same.
This is an output:
`
Malformed json: Vim:E474: Expected string end: {"Id":"13800776-ddd7-f32f-b72b-27c134ed2059","Namespace":"xxxxTest.Controllers.Calendars.CalendarQueryControllerTest.GetCalendarById","Name":"xxxxx.Test.Controllers.Calendars.CalendarQueryControllerTest.GetCalendarById(commandHandlerError: True)","
`
The json object is not parsed to the end, or the error is not showing the whole output

Yeah ill try writing the results from F# execution to a file and read line by line. I suspect there is some autowrap magic somewhere when printing long lines using dotnet fsi

maybe adding a bit more info here helps: https://github.com/prosegur/support-innovation-gims-api/pull/271
It would be good to know what is actually passed to the json_decode function

I fixed it by emitting to a tmpfile an reading line by line from that to avoid accidental linebreaks. cant reproduce your issue no more. btw the repo is internal/private so i cant see it

Sorry send the wrong link

Finally! The specflow example works with full namespace support 🤘

Using https://www.nuget.org/packages/Microsoft.TestPlatform.TranslationLayer it outputs the full namespaces even on MSTests. You can also press g on any test to go to file and line!

Just tested. Very well done!
Just one issue. This stuck on Running:

Okay so you open the InsertCalendarTest.xml file which  indicates that this should be one singular unit test. But in your xml it specifies multiple <UnitTestResult .../> nodes with the same id(!?). Does all the nodes have the same status?
I clearly see why its failing, I just have no idea what is so special about the InsertCalendarTest.
Below is what the xml should have looked like, with a single <UnitTestResult /> node

Can you try and make a super basic repro where you get the same behaviour as the InsertCalendarTest. aka when you run it the xml contains multiple duplicate entries

Yes I will do it. I need to analyze myself why this is showing up as a normal test and not as classdata. I have many tests like that, and there is no difference between those and the "normal" classdata tests

Just to confirm, using dotnet test -t it outputs a single entry for InsertCalendarTest?

@franroa Is the bug you're experiencing a blocker for merging this do you think?

I think you can merge, and I add a bug for this. Not sure if I will manage to put together a repro today, so I would'nt want to block

Hi, just got to know that I have to move to other project, so I will not be using neovim for now. If you still need a repro I can try to do it, otherwise if you don't need it we can merge this PR

Oh wow! Good luck on your new project! Dont worry about the repro, someone will likely run into the issue down the road anyways.

ok! thanks!
You are doing a great job here!


Autorest Regen Preview to 3.0.0-alpha.20230821.4 by Anne Loomis Thompson from refs/pull/3674/head

Triggered from https://github.com/Azure/autorest.csharp/pull/3674

/azp run net - core - ci

/azp run net - core - ci

API change check
API changes are not detected in this pull request.


RFC3986 validator too strict?

I propose we don't use the validator by default, and just let the developers decide if they want to use it.
Currently we are forcing this validation, here: https://github.com/lnbits/lnurl/blob/master/lnurl/types.py#L16
We can just change the line so it reads:

STRICT_RFC3986 = os.environ.get("LNURL_STRICT_RFC3986", "0") == "1"

@jogc, what do you think?

Yep, that's the way it worked in my original module as well


Include support for AnalyticsMetadata in initiateAuthRequest and InitiateSRPAuthrequest

Describe the feature
In Cognito provider with initiateAuthRequest and other API.. AnalyticsMetadata is supported but is not added in this extension.
Use Case
For Pinpoint Analytics this field is required
Proposed Solution
Change InitiateAuthRequest and InitiateRequest to add Analyticsmetatdata attribute as well (similare to clientmetadata)
Other Information
No response
Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

AWS .NET SDK and/or Package version used
AWS SDK
Targeted .NET Platform
.Net framework 4.7
Operating System and version
Windows

Hello @rajneeshmadan,
Thank you for submitting this feature request. This looks a reasonable ask especially when the Cognito API (e.g. InitiateAuthRequest) supports the Analyticsmetatdata property.
I will further review this with the .NET SDK team. Thank you.
Regards,
Chaitanya

Thanks for working on this.. I see PR is still not merged. Please help by prioritizing it.

Changes released in Amazon.Extensions.CognitoAuthentication 2.5.5.


fix createComponent import

Latest Solid release removed solid-js/dom, this PR fix the import of createComponent and bump the Solid peerDependency to the first Solid version that exports createComponent from solid-js

Hi, thank you for the PR. It looks like breaking changes, so that I will publish that with a major version.


activerecord: Add ActiveRecord::Base.offset

refs:

https://github.com/rails/rails/blob/v<IP_ADDRESS>/activerecord/lib/active_record/querying.rb#L15
https://github.com/rails/rails/blob/v<IP_ADDRESS>/activerecord/lib/active_record/relation/query_methods.rb#L746

/merge


added breeze from github

Breeze is now added as an SBT managed dependency pointing to your Breeze GitHub repository. I have made it so it's the nounou branch that's being used.
The addition can be found in project/Build.scala on line 24
I have restructured the entire SBT build process and tomorrow once Jennifer comes home so she can keep an eye on the puppy I will begin on the next milestones.
From here on, using the sbt-assembly plugin to do some decent packaging of JAR files should be easier than adding the GitHub dependency today.
I will also set up PGP signing so we can start publishing nounou to SonaType. For this I will make sure that SBT knows how to sign the packages with my PGP key, or yours if it's on your computer.
Additionally there are several other features I will implement in the next few days.
Only problem now are some issues with logging through scala-logging/slf4j complaining about the lazylogging in your logging trait.

@ktakagaki
SBT can now compile using the new build system structure based on your latest commit to master. All files should be up to date


questpatcher brokey brokey

i went to go laucnh gorilla tag and it kept on saying "gorilla tag has stopped"
so i uninstalled it and re installed it and realized all my mods were gone
so i went to go launch quest patcher and it keeps on having an error at startup
and it keeps on closing
QuestPatcher.Core.AdbException: mkdir: '/sdcard/QuestPatcher': No such file or directory
at QuestPatcher.Core.AndroidDebugBridge.RunCommand(String command, Int32[] allowedExitCodes) in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\AndroidDebugBridge.cs:line 148
at QuestPatcher.Core.AndroidDebugBridge.RunShellCommands(List1 commands) in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\AndroidDebugBridge.cs:line 275    at QuestPatcher.Core.AndroidDebugBridge.CreateDirectories(List1 paths) in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\AndroidDebugBridge.cs:line 310
at QuestPatcher.Core.Modding.ModManager.CreateModsDirectories() in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\Modding\ModManager.cs:line 103
at QuestPatcher.Core.Modding.ModManager.DetectAndRemoveOldMods() in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\Modding\ModManager.cs:line 119
at QuestPatcher.Core.QuestPatcherService.MigrateOldFiles() in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\QuestPatcherService.cs:line 170
at QuestPatcher.Core.QuestPatcherService.RunStartup() in D:\a\QuestPatcher\QuestPatcher\QuestPatcher.Core\QuestPatcherService.cs:line 127
at QuestPatcher.Services.QuestPatcherUIService.LoadAndHandleErrors() in D:\a\QuestPatcher\QuestPatcher\QuestPatcher\Services\QuestPatcherUIService.cs:line 89

This is unlikely to be an issue with QuestPatcher, and is more likely to be a bug with one of your mods crashing the game. To fix the opening issue however, delete /sdcard/QuestPatcher using the SideQuest file manager.
Closing due to inability to reproduce second issue, and the first not being QuestPatcher related.

ive been trying to download mods for gorilla tag for a while now and today after getting lib files that contain codegen and monkecomputer but each time i try to open the file for questpatcher it just says that my quest is offline

This thread is not for support.

then where do i go

Nowhere, gorilla tag quest mods are not available at the moment.