Don't depend on pyside

🚀 Feature
Depending on Pyside2 makes things easy to install, but if you already depend on qtpy, then maybe let the users decide which backend is best for them?
Just my 2 cents.

I kinda agree here.  I see that this creates a problem: how do you make an easy "one line install" for those who know nothing about Qt, while also preventing duplicate Qt backends for those who already depend on pyqt for other things.
I do think that it's really important for a beginner to just pip install napari and be off and running – even something like pip install napari[pyside] is undesirable – but when I went about trying to include support for napari in some of my other qt packages, I ran up against either needing to have both pyqt5 & pyside2 in the environment, or changing all my stuff over to pyside2.  @jni, do you have thoughts on how to approach that sort of thing?

If you guys want to use pyqt5 or another backend, you should first import the backend you want to use, then import napari. Since napari uses qtpy if before importing napari you have another backend imported pyside2 will not be able to import successfully.
About the reason of pyside2 choice, mainly licensing AFAIK. Correct me if i'm wrong @sofroniewn . As soon as we are not depending non-LGPL parts of pyqt5 it would be okay to switch backend and i love to do that too, personally i like pyqt5 better than pyside2.

I might be wrong... but I think the issue was not so much about how to get qtpy (and therefore napari) to use the desired backend.  That much is straightforward.  and it's also not so much about using pyside2 as the "go-to" default backend... that's also fine, particularly if it makes licensing easier.
I think it is an interesting discussion though as to whether installing napari will force the user to have pyside2 installed in their environment (even if they then take steps to not use it).

I think it is an interesting discussion though as to whether installing napari will force the user to have pyside2

^this

Good point @tlambert03 . But either way we need a backend by default. What could be an alternative? Do you have any suggestions?

nope!  😄   that's why in my first comment I said it creates a problem and punted to @jni :)
the only alternative I can think of would be to declare pyside2 as an "extra", and then have the readme say pip install napari[pyside] ... but I'm not necessarily promoting that, since I definitely think that napari should also try to be stupid easy for people to "just use".

As noted above pyside2(LGPL)  is listed in our requirements.txt instead of pyqt5 (GPL) only for licensing reasons, so our code can be redistributed as LGPL by others if they want, (you'll note that the code we write is actually BSD), and when we release the bundled napari app that will have pyside2 inside it and be LGPL.
@AhmetCanSolak

As soon as we are not depending non-LGPL parts of pyqt5

Do you have something in my mind here? I thought we weren't going to need any of the non-LGPL stuff (I'm not even too familiar with what is there, I thought it was really quite specialized stuff).
As to if users want to use pyqt5 or pyside2 that's totally up to them and we should continue to support both via qtpy. If you have both installed then you can switch between them with the environmental variable QT_API.
I can see though if you are already a pyqt5 user you shouldn't be forced to install pyside2 - so how about the following approach:
pip install napari

still works as before installing our default pyside2, but
pip install napari[pyqt5]

now installs with pyqt5 and does not install pyside2
We can also provide
pip install napari[pyside2]

for symmetry, but I think it is still important our default remains pyside2 for licensing reasons
The burden would then be on slightly more advanced users to specify pyqt5 during the install process, and it would all still just work for beginner users with pip install napari.
@hmaarrfk @tlambert03 @AhmetCanSolak does this seem like a reasonable proposal?

I like that!

the thing i've learned, is that until you give people a one click installer, then they will always find your GUI hard to install.
Asking
python -m venv napari
source napari/bin/activate
pip install napari

then
source napari/bin/activate
napari

is already too hard. So as far as package management goes, telling them to type pip install napari pyside2 is just as hard as asking them to type pip install napari

I've been wanting to get a bit more experience with pip extras. I think from the above, I like @sofroniewn's suggestion of:
pip install napari -> get PySide2
pip install napari[pyqt] or napari[pyqt5] -> get PyQt5
pip install napari[pyside] or pip install napari[pyside2] -> get PySide2
One variant that I would consider, but slightly dislike, is pip install napari -> get an informative RuntimeError that says that one of pyside2 or pyqt5 should be installed. However, I would prefer to avoid this particular form, for the same reasons that @sofroniewn enumerated. People who don't even read our instructions will try pip install napari. I would very much rather that didn't result in a non-functional install.
All this reminds me: I should get back to work on that conda-forge package... 😅

yeah, I think there's definitely something to be said for pip install napari over pip install napari pyside2.   It's of course easy enough to just state in the readme that you need to pip install napari pyside2 ... but when someone is doing it from memory, and all they remember is napari, there will inevitably be times when they have errors, or say to themselves "pip install what-was-it-again??".  So I like putting the burden on the minority of developers who would like to be more in control of their environment, while also at least making it possible for them to get their desired environment without doing pip install napari pyqt5 && pip uninstall pyside2

@AhmetCanSolak

As soon as we are not depending non-LGPL parts of pyqt5

Do you have something in my mind here? I thought we weren't going to need any of the non-LGPL stuff (I'm not even too familiar with what is there, I thought it was really quite specialized stuff).

Yes @sofroniewn you remember right. That's the Qt related part of things. I, personally, think it would be okay to have GPL pyqt5 too since napari is free and open source. To me it wouldn't be too much to ask users to open their source code when they have napari as dependency. I know many people prefer a more permissive license but IMO either with GPL or LGPL dependency we could be fine.

@hmaarrfk @tlambert03 @AhmetCanSolak does this seem like a reasonable proposal?
I like the idea but this would complicate our license. As soon as we clarify the situation well it sounds okay to me.

and agree with @tlambert03 that pip install napari pyside2 is hard to remember for the majority.

Unfortunately, a default requirement that can be overridden by an extra requirement is not possible.  Here's a discussion about this subject.  The reason boils down to that packages distill their requirements into a static text file that is not very flexible.
A possibility is that on napari startup, it looks for pyside and pyqt, and if neither is found, it automagically installs pyside.  It would be a pretty hacky though, because it is assuming that pip is the right way to install a package when it may not be.

@AhmetCanSolak PySide is already LGPL, which means that napari distributed as a bundle would have to be licensed as LGPL. Within the Python community, it's already a big ask. I don't want to get into a debate on the merits of licenses here (MPL is my favourite so far), but rather that if we are part of a particular community, in this case the scientific Python community, we should make an effort to play well with them, and that means BSD licensing.
For some reason my brain worked on this in a background thread (thanks @AhmetCanSolak! =P) and I think I see a way forward.

rename napari napari-base in PyPI, and stop depending on PySide2. Issue a helpful RuntimeError if napari is run with no Qt backend.
create extras so that napari[PyQt5], napari[PySide2], napari[pyside] etc all work as expected (getting only the desired backend)
create a metapackage napari that either is an alias for napari[PySide2] (not sure if that's possible), or depends on both napari-base and PySide2.

Unless I'm missing something, the above should not be a huge amount of work on the packaging side and it should work!

rename napari napari-base in PyPI, and stop depending on PySide2. Issue a helpful RuntimeError if napari is run with no Qt backend.

This is doable.

create extras so that napari[PyQt5], napari[PySide2], napari[pyside] etc all work as expected (getting only the desired backend)

This is also doable.

create a metapackage napari that either is an alias for napari[PySide2] (not sure if that's possible), or depends on both napari-base and PySide2.

If there is a napari package, it cannot depend on napari[PySide2].  If napari depends on napari-base and PySide2, then napari[PyQt5] will install napari-base, PySide2, and PyQt5.  Extras are always additive to the base package.

Extras are always additive to the base package.

Ah, of course! 🤦♂ D'oh! Do we then forget about extras and just make multiple packages and metapackages? napari-pyside2, napari-pyqt etc? Or do we spend our efforts lobbying the PyPA to implement alternative dependencies?

we could also make napari install napari-base and pyside2 and those who don’t want pyside2 would have to do napari-base[pyqt]. This leaves the “burden” on those who want want we predict to be the slightly less common scenario.

#1059 now makes it possible to install napari without pyside2. We'll be updating our docs accordingly, and so I am closing this issue


Add a pinout diagram in the program

Add button "Show pinout" that show this image:

It's not fancy, but this may help!


Delete README.txt

Delete this file. I'm not so sure if it is needed.

I think it's all done. Let's merge it.


Fix broken docs links

🔗 Linked issue
#206
❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Fix broken docs links
📝 Checklist

[x] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

Wow, thanks! I appreciate the help, I recently migrated Schema.org to the Unhead docs and didn't have a chance to validate the links


Broken API versioning

Describe the bug
I built an API Client and have a set of schemas I use as part of the test suite like the schema you can see here for example. These have been breaking in CI recently and upon inspection I see that the API docs for the v1 API are not what the API returns and the changes since v1 should be namespaced under v2 now.
Case in hand, this is how the v1 docs define a challenge response via https://www.codewars.com/api/v1/code-challenges/:id_or_slug to have the following keys:

id
name
slug
category
publishedAt
approvedAt
languages
url
rank
createdBy
approvedBy
description
totalAttempts
totalCompleted
totalStars
tags

In actuality though, the API returns the following extra keys in the response:

createdAt
voteScore
contributorsWanted
unresolved

To Reproduce
Check the v1 API definitions and then the actual API response.
Expected behavior
That the versioning system is not broken and that a new v2 version is created for changes since the v1 release and v1 is reverted.
Screenshots
N/A
Browser
N/A
Additional context
N/A

I apologize for the inconvenience, but the documentation is simply outdated. We haven't touched the API in a while, definitely not since your project had started. For that specific endpoint, it was last changed more than 6 years ago (2014-07-18). Also, adding a new field to a response is generally not considered a breaking change either. (I do agree that it should be documented for the users to know.)
The API v1 hasn't been in a good shape for many years (or ever), and I'm not planning to touch it. v2 is necessary to resolve the issues and expand, but it's not a priority at the moment.

@kazk Can you give a very rough overview of the internal plan or thoughts for v2?
Related: I also raised #2305 before and we briefly discussed the current state of the API over email, would be interested in an update since then as you had mentioned you were working on the API at that time if memory serves.

you were working on the API at that time if memory serves.

No, I wasn't working on it. I basically said the same thing.

Can you give a very rough overview of the internal plan or thoughts for v2?

No, I haven't even started to think about it.
You're probably frustrated with the pace of development, but I'd like you to know that I spend a lot of unpaid time to maintain it. I do work for Qualified, the company behind Codewars, but I usually have other priorities for different projects during work hours.
I took over the project around the end of 2018, and have been the only dev and admin.

As you can see in the above commit activity, Codewars wasn't actively developed for years when I took over. The codebase was in a terrible condition. I focused on major technical issues and most of them are resolved now, but the codebase is still not in a good shape. Making a change takes much longer than it should :(
I'd love to provide a better API for users like you, but there are many other things to be worked on with much higher impact.

No, I wasn't working on it. I basically said the same thing.

Ah, I misremembered then, my bad!

You're probably frustrated with the pace of development

Not at all actually. Just looking to be in the loop.

I took over the project around the end of 2018, and have been the only dev and admin.

Crazy, is the team at Qualified not able to support or is the workload elsewhere just so high? Thanks for the work to date in that case! 🙇🏻

I'd love to provide a better API for users like you, but there are many other things to be worked on with much higher impact.

Understandable and the platform itself is great, I have used it for quite some time now personally and would like to see it grow and mature further.
I guess my only real questions left would be:

Has there been an internal discussion or idea to just restart with a clean slate since it's so hard to refactor?
Are Qualified supporting you in your efforts with the platform since their name is on it? You seem to be doing the lions share the work and yet you even do unpaid time, seems a bit unfair.
What are the chances of more focus being put onto the platform or is it something that they would rather retire eventually?

Crazy, is the team at Qualified not able to support or is the workload elsewhere just so high?

We're a team of 2.5 devs (3 senior devs, but one is our CTO). I think we're extremely productive, considering our competitors having tens to hundreds of devs.

1. Has there been an internal discussion or idea to just restart with a clean slate since it's so hard to refactor?

When I started to work on Codewars back in 2018, I almost gave up and wanted to rewrite it in Phoenix because I fell in love with it, and I was so sick of mutations. But I decided to at least clean some up first because it was too messy to even think about what it takes to migrate. Then it became somewhat manageable after months of struggle, so I decided to keep refactoring. If I could literally start from scratch (forgetting all the existing data in MongoDB), then restarting made more sense. It's taking long to refactor mainly because I don't have much time, even less consecutive time.

2. Are Qualified supporting you in your efforts with the platform since their name is on it? You seem to be doing the lions share the work and yet you even do unpaid time, seems a bit unfair.

I don't consider the situation unfair at all. Just to be clear, they're not making me do unpaid work in any way. I just care about Codewars a lot, and decided to work on it when I can.
You can think of it like a side project with millions of global users that you sometimes get sponsored to work on. I don't know about you, but that's pretty cool to me. I admit it's sometimes stressful, especially the community aspect (e.g., dealing with problematic users and support), but it's satisfying.

3. What are the chances of more focus being put onto the platform or is it something that they would rather retire eventually?

Our main focus will always be Qualified, and we're doing great. Note that Qualified's success is required for Codewars to exist. After all, Codewars doesn't make money, so it's not sustainable by itself.  If we had to monetize Codewars, I believe we'll lose a lot of its value.
There's no plan to retire Codewars. I wouldn't be spending time on it if there was :)

@kazk thanks for the detailed response!
Well, hopefully we can see things move forward in the future and once again, thanks for all you do in maintaining the platform 🙇♂
If I can somehow contribute to the API, do let me know, I’d be happy to help develop the features I’m asking for myself and contribute to the platform if you’d be able to show me the ropes but otherwise, all the best dude ✌


Development: Building MadLib blurb

As a user
I would like to see my results in an easy to read sentence.
A / C

Content is correct
Content should update as I enter values into the form
Content should match design

needs #80

@Br3nda @dlouise64 to catch-up on children

With Children

No Children


digging 10 dirt does nothing

EDIT: ima test this and see if i can get digging dirt to work
EDIT: THIS issue appears to be placing 10 dirt does nothing not digging dirt does nothing

thanks,
i must have put a bug in it last night.  should be fixed now

nope, now nothing works... leave it with me and i'll sort it out

also, this is craft_guide project, I assume you ment to post it as an issue here:
https://github.com/cornernote/minetest-skyblock/issues

oh oops yes i did mean to upload that to minetest-skyblock XD i will transfer the first post


TopoLVM Snapshot Issue: Multiple Logical Volumes Created

First of all, thank you for this fantastic project; it's exactly what I've been looking for. I've tested it on my test system with 1 Master and 1 Worker in Kubernetes.
Environments
Helm Version: v3.12.1
Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.6
I'd like to incorporate TopoLVM as a cache for the Actions-Runner-Controller for Docker image caching. Therefore, snapshot functionality is essential to me. My goal is to create a PVC, start a pod, bind it to the PVC, pull the necessary images, remove the pod, and create a snapshot of the PVC. Then, I want the Actions-Runner-Controller to dynamically create the TopoLVM from the snapshot.
I've created a volume group on the node, deployed TopoLVM with Helm, created a PVC, created a pod, mounted the PVC to the pod, pulled images, and received the following message when creating the snapshot: "Failed to check and update snapshot content: failed to take a snapshot of the volume 25e63f2f-7fce-4fe9-bad1-f8d074ab574c: "rpc error: code = Unimplemented desc = device class is not thin. Thick snapshots are not implemented yet."
So far, my first config for topolvm looked like this:
# useLegacy -- If true, the legacy plugin name and legacy custom resource group is used(topolvm.cybozu.com).
useLegacy: false

image:
  # image.repository -- TopoLVM image repository to use.
  repository: ghcr.io/topolvm/topolvm-with-sidecar

  # image.tag -- TopoLVM image tag to use.
  # @default -- `{{ .Chart.AppVersion }}`
  tag: #13.0.1

  # image.pullPolicy -- TopoLVM image pullPolicy.
  pullPolicy:  # Always

  # image.pullSecrets -- List of imagePullSecrets.
  pullSecrets: []

  csi:
    # image.csi.nodeDriverRegistrar -- Specify csi-node-driver-registrar: image.
    # If not specified, `ghcr.io/topolvm/topolvm-with-sidecar:{{ .Values.image.tag }}` will be used.
    nodeDriverRegistrar:  # registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.2.0

    # image.csi.csiProvisioner -- Specify csi-provisioner image.
    # If not specified, `ghcr.io/topolvm/topolvm-with-sidecar:{{ .Values.image.tag }}` will be used.
    csiProvisioner:  # registry.k8s.io/sig-storage/csi-provisioner:v2.2.1

    # image.csi.csiResizer -- Specify csi-resizer image.
    # If not specified, `ghcr.io/topolvm/topolvm-with-sidecar:{{ .Values.image.tag }}` will be used.
    csiResizer:  # registry.k8s.io/sig-storage/csi-resizer:v1.2.0

    # image.csi.csiSnapshotter -- Specify csi-snapshot image.
    # If not specified, `ghcr.io/topolvm/topolvm-with-sidecar:{{ .Values.image.tag }}` will be used.
    csiSnapshotter:  # registry.k8s.io/sig-storage/csi-snapshotter:v5.0.1

    # image.csi.livenessProbe -- Specify livenessprobe image.
    # If not specified, `ghcr.io/topolvm/topolvm-with-sidecar:{{ .Values.image.tag }}` will be used.
    livenessProbe:  # registry.k8s.io/sig-storage/livenessprobe:v2.3.0

# A scheduler extender for TopoLVM
scheduler:
  # scheduler.enabled --  If true, enable scheduler extender for TopoLVM
  enabled: false

  # scheduler.args -- Arguments to be passed to the command.
  args: []

  # scheduler.type -- If you run with a managed control plane (such as GKE, AKS, etc), topolvm-scheduler should be deployed as Deployment and Service.
  # topolvm-scheduler should otherwise be deployed as DaemonSet in unmanaged (i.e. bare metal) deployments.
  # possible values:  daemonset/deployment
  type: daemonset

  # Use only if you choose `scheduler.type` deployment
  deployment:
    # scheduler.deployment.replicaCount -- Number of replicas for Deployment.
    replicaCount: 1

  # Use only if you choose `scheduler.type` deployment
  service:
    # scheduler.service.type -- Specify Service type.
    type: LoadBalancer
    # scheduler.service.clusterIP -- Specify Service clusterIP.
    clusterIP:  # None
    # scheduler.service.nodePort -- (int) Specify nodePort.
    nodePort:  # 30251

  # scheduler.updateStrategy -- Specify updateStrategy on the Deployment or DaemonSet.
  updateStrategy: {}
  #  rollingUpdate:
  #    maxUnavailable: 1
  #  type: RollingUpdate

  # scheduler.terminationGracePeriodSeconds -- (int) Specify terminationGracePeriodSeconds on the Deployment or DaemonSet.
  terminationGracePeriodSeconds:  # 30

  # scheduler.minReadySeconds -- (int) Specify minReadySeconds on the Deployment or DaemonSet.
  minReadySeconds:  # 0

  # scheduler.affinity -- Specify affinity on the Deployment or DaemonSet.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: Exists

  podDisruptionBudget:
    # scheduler.podDisruptionBudget.enabled -- Specify podDisruptionBudget enabled.
    enabled: true

  # scheduler.tolerations -- Specify tolerations on the Deployment or DaemonSet.
  ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
    - key: node-role.kubernetes.io/control-plane
      effect: NoSchedule
    # node-role.kubernetes.io/master taint will not be used in k8s 1.25+.
    # cf. https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md
    # TODO: remove this when minimum supported version becomes 1.25.
    - key: node-role.kubernetes.io/master
      effect: NoSchedule

  # scheduler.nodeSelector -- Specify nodeSelector on the Deployment or DaemonSet.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
  nodeSelector: {}

  # scheduler.priorityClassName -- Specify priorityClassName on the Deployment or DaemonSet.
  priorityClassName:

  # scheduler.schedulerOptions -- Tune the Node scoring.
  # ref: https://github.com/topolvm/topolvm/blob/master/deploy/README.md
  schedulerOptions: {}
  #  default-divisor: 1
  #  divisors:
  #    ssd: 1
  #    hdd: 10

  options:
    listen:
      # scheduler.options.listen.host -- Host used by Probe.
      host: localhost
      # scheduler.options.listen.port -- Listen port.
      port: 9251

  # scheduler.podLabels -- Additional labels to be set on the scheduler pods.
  podLabels: {}
  # scheduler.labels -- Additional labels to be added to the Deployment or Daemonset.
  labels: {}

# lvmd service
lvmd:
  # lvmd.managed -- If true, set up lvmd service with DaemonSet.
  managed: true

  # lvmd.socketName -- Specify socketName.
  socketName: /run/topolvm/lvmd.sock

  # lvmd.deviceClasses -- Specify the device-class settings.
  deviceClasses:
    - name: localcache-hdd
      volume-group: vg_localcache
      default: true
      spare-gb: 10

  # lvmd.lvcreateOptionClasses -- Specify the lvcreate-option-class settings.
  lvcreateOptionClasses: []
   #- name: localcache-hdd
   #  options:
   #    - --thin

  # lvmd.args -- Arguments to be passed to the command.
  args: []

  # lvmd.priorityClassName -- Specify priorityClassName.
  priorityClassName:

  # lvmd.tolerations -- Specify tolerations.
  ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
    - key: node-role.kubernetes.io/control-plane
      effect: NoSchedule

  # lvmd.nodeSelector -- Specify nodeSelector.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
  nodeSelector: {}

  # lvmd.affinity -- Specify affinity.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: {}

  # lvmd.volumes -- Specify volumes.
  volumes: []
  #  - name: lvmd-socket-dir
  #    hostPath:
  #      path: /run/topolvm
  #      type: DirectoryOrCreate

  # lvmd.volumeMounts -- Specify volumeMounts.
  volumeMounts: []
  #  - name: lvmd-socket-dir
  #    mountPath: /run/topolvm

  # lvmd.env -- extra environment variables
  env: []
  #  - name: LVM_SYSTEM_DIR
  #    value: /tmp

  # lvmd.additionalConfigs -- Define additional LVM Daemon configs if you have additional types of nodes.
  # Please ensure nodeSelectors are non overlapping.
  additionalConfigs: []
  #  - tolerations: []
  #      nodeSelector: {}
  #      device-classes:
  #        - name: ssd
  #          volume-group: myvg2
  #          default: true
  #          spare-gb: 10

  # lvmd.updateStrategy -- Specify updateStrategy.
  updateStrategy: {}
  #  type: RollingUpdate
  #  rollingUpdate:
  #    maxSurge: 50%
  #    maxUnavailable: 50%

  # lvmd.podLabels -- Additional labels to be set on the lvmd service pods.
  podLabels: {}
  # lvmd.labels -- Additional labels to be added to the Daemonset.
  labels: {}

  # lvmd.initContainers -- Additional initContainers for the lvmd service.
  initContainers: []

# CSI node service
node:
  # node.lvmdEmbedded -- Specify whether to embed lvmd in the node container.
  # Should not be used in conjunction with lvmd.managed otherwise lvmd will be started twice.
  lvmdEmbedded: false
  # node.lvmdSocket -- Specify the socket to be used for communication with lvmd.
  lvmdSocket: /run/topolvm/lvmd.sock
  # node.kubeletWorkDirectory -- Specify the work directory of Kubelet on the host.
  # For example, on microk8s it needs to be set to `/var/snap/microk8s/common/var/lib/kubelet`
  kubeletWorkDirectory: /var/lib/kubelet

  # node.args -- Arguments to be passed to the command.
  args: []

  # node.securityContext. -- Container securityContext.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  securityContext:
    privileged: true

  metrics:
    # node.metrics.enabled -- If true, enable scraping of metrics by Prometheus.
    enabled: true
    # node.metrics.annotations -- Annotations for Scrape used by Prometheus.
    annotations:
      prometheus.io/port: metrics

  prometheus:
    podMonitor:
      # node.prometheus.podMonitor.enabled -- Set this to `true` to create PodMonitor for Prometheus operator.
      enabled: false

      # node.prometheus.podMonitor.additionalLabels -- Additional labels that can be used so PodMonitor will be discovered by Prometheus.
      additionalLabels: {}

      # node.prometheus.podMonitor.namespace -- Optional namespace in which to create PodMonitor.
      namespace: ""

      # node.prometheus.podMonitor.interval -- Scrape interval. If not set, the Prometheus default scrape interval is used.
      interval: ""

      # node.prometheus.podMonitor.scrapeTimeout -- Scrape timeout. If not set, the Prometheus default scrape timeout is used.
      scrapeTimeout: ""

      # node.prometheus.podMonitor.relabelings -- RelabelConfigs to apply to samples before scraping.
      relabelings: []
      # - sourceLabels: [__meta_kubernetes_service_label_cluster]
      #   targetLabel: cluster
      #   regex: (.*)
      #   replacement: ${1}
      #   action: replace

      # node.prometheus.podMonitor.metricRelabelings -- MetricRelabelConfigs to apply to samples before ingestion.
      metricRelabelings: []
      # - sourceLabels: [__meta_kubernetes_service_label_cluster]
      #   targetLabel: cluster
      #   regex: (.*)
      #   replacement: ${1}
      #   action: replace

  # node.priorityClassName -- Specify priorityClassName.
  priorityClassName:

  # node.tolerations -- Specify tolerations.
  ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
    - key: node-role.kubernetes.io/control-plane
      effect: NoSchedule

  # node.nodeSelector -- Specify nodeSelector.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
  nodeSelector: {}

  # node.affinity -- Specify affinity.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: {}

  # node.volumes -- Specify volumes.
  volumes: []
  #  - name: registration-dir
  #    hostPath:
  #      path: /var/lib/kubelet/plugins_registry/
  #      type: Directory
  #  - name: node-plugin-dir
  #    hostPath:
  #      path: /var/lib/kubelet/plugins/topolvm.io/node
  #      type: DirectoryOrCreate
  #  - name: csi-plugin-dir
  #    hostPath:
  #      path: /var/lib/kubelet/plugins/kubernetes.io/csi
  #      type: DirectoryOrCreate
  #  - name: pod-volumes-dir
  #    hostPath:
  #      path: /var/lib/kubelet/pods/
  #      type: DirectoryOrCreate
  #  - name: lvmd-socket-dir
  #    hostPath:
  #      path: /run/topolvm
  #      type: Directory

  volumeMounts:
    # node.volumeMounts.topolvmNode -- Specify volumes.
    topolvmNode: []
    # - name: node-plugin-dir
    #   mountPath: /var/lib/kubelet/plugins/topolvm.io/node
    # - name: csi-plugin-dir
    #   mountPath: /var/lib/kubelet/plugins/kubernetes.io/csi
    #   mountPropagation: "Bidirectional"
    # - name: pod-volumes-dir
    #   mountPath: /var/lib/kubelet/pods
    #   mountPropagation: "Bidirectional"
    # - name: lvmd-socket-dir
    #   mountPath: /run/topolvm

  # node.updateStrategy -- Specify updateStrategy.
  updateStrategy: {}
  #  type: RollingUpdate
  #  rollingUpdate:
  #    maxSurge: 50%
  #    maxUnavailable: 50%

  # node.podLabels -- Additional labels to be set on the node pods.
  podLabels: {}
  # node.labels -- Additional labels to be added to the Daemonset.
  labels: {}

  # node.initContainers -- Additional initContainers for the node service.
  initContainers: []

# CSI controller service
controller:
  # controller.replicaCount -- Number of replicas for CSI controller service.
  replicaCount: 1

  # controller.args -- Arguments to be passed to the command.
  args: []

  storageCapacityTracking:
    # controller.storageCapacityTracking.enabled -- Enable Storage Capacity Tracking for csi-provisioner.
    enabled: true

  securityContext:
    # controller.securityContext.enabled -- Enable securityContext.
    enabled: true

  nodeFinalize:
    # controller.nodeFinalize.skipped -- Skip automatic cleanup of PhysicalVolumeClaims when a Node is deleted.
    skipped: false

  prometheus:
    podMonitor:
      # controller.prometheus.podMonitor.enabled -- Set this to `true` to create PodMonitor for Prometheus operator.
      enabled: false

      # controller.prometheus.podMonitor.additionalLabels -- Additional labels that can be used so PodMonitor will be discovered by Prometheus.
      additionalLabels: {}

      # controller.prometheus.podMonitor.namespace -- Optional namespace in which to create PodMonitor.
      namespace: ""

      # controller.prometheus.podMonitor.interval -- Scrape interval. If not set, the Prometheus default scrape interval is used.
      interval: ""

      # controller.prometheus.podMonitor.scrapeTimeout -- Scrape timeout. If not set, the Prometheus default scrape timeout is used.
      scrapeTimeout: ""

      # controller.prometheus.podMonitor.relabelings -- RelabelConfigs to apply to samples before scraping.
      relabelings: []
      # - sourceLabels: [__meta_kubernetes_service_label_cluster]
      #   targetLabel: cluster
      #   regex: (.*)
      #   replacement: ${1}
      #   action: replace

      # controller.prometheus.podMonitor.metricRelabelings -- MetricRelabelConfigs to apply to samples before ingestion.
      metricRelabelings: []
      # - sourceLabels: [__meta_kubernetes_service_label_cluster]
      #   targetLabel: cluster
      #   regex: (.*)
      #   replacement: ${1}
      #   action: replace

  # controller.terminationGracePeriodSeconds -- (int) Specify terminationGracePeriodSeconds.
  terminationGracePeriodSeconds:  # 10

  # controller.priorityClassName -- Specify priorityClassName.
  priorityClassName:

  # controller.updateStrategy -- Specify updateStrategy.
  updateStrategy: {}
  #  type: RollingUpdate
  #  rollingUpdate:
  #    maxSurge: 50%
  #    maxUnavailable: 50%

  # controller.minReadySeconds -- (int) Specify minReadySeconds.
  minReadySeconds:  # 0

  # controller.affinity -- Specify affinity.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: |
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app.kubernetes.io/component
                operator: In
                values:
                  - controller
              - key: app.kubernetes.io/name
                operator: In
                values:
                  - {{ include "topolvm.name" . }}
          topologyKey: kubernetes.io/hostname

  # controller.tolerations -- Specify tolerations.
  ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
    - key: node-role.kubernetes.io/control-plane
      effect: NoSchedule

  # controller.nodeSelector -- Specify nodeSelector.
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
  nodeSelector: {}

  # controller.volumes -- Specify volumes.
  volumes:
    - name: socket-dir
      emptyDir: {}

  podDisruptionBudget:
    # controller.podDisruptionBudget.enabled -- Specify podDisruptionBudget enabled.
    enabled: true

  # controller.podLabels -- Additional labels to be set on the controller pod.
  podLabels: {}
  # controller.labels -- Additional labels to be added to the Deployment.
  labels: {}

  # controller.initContainers -- Additional initContainers for the controller service.
  initContainers: []

resources:
  # resources.topolvm_node -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  topolvm_node: {}
  #  requests:
  #    memory: 100Mi
  #    cpu: 100m
  #  limits:
  #    memory: 500Mi
  #    cpu: 500m
  # resources.csi_registrar -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  csi_registrar: {}
  # requests:
  #   cpu: "25m"
  #   memory: "10Mi"
  # limits:
  #   cpu: "200m"
  #   memory: "200Mi"
  # resources.liveness_probe -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  liveness_probe: {}
  # requests:
  #   cpu: "25m"
  #   memory: "10Mi"
  # limits:
  #   cpu: "200m"
  #   memory: "200Mi"
  # resources.topolvm_controller -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  topolvm_controller: {}
  #  requests:
  #    memory: "50Mi"
  #    cpu: "50m"
  #  limits:
  #    memory: "200Mi"
  #    cpu: "200m"
  # resources.csi_provisioner -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  csi_provisioner: {}
  #  requests:
  #    memory: "50Mi"
  #    cpu: "50m"
  #  limits:
  #    memory: "200Mi"
  #    cpu: "200m"
  # resources.csi_resizer -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  csi_resizer: {}
  #  requests:
  #    memory: "50Mi"
  #    cpu: "50m"
  #  limits:
  #    memory: "200Mi"
  #    cpu: "200m"
  # resources.csi_snapshotter -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  csi_snapshotter: {}
  #  requests:
  #    memory: "50Mi"
  #    cpu: "50m"
  #  limits:
  #    memory: "200Mi"
  #    cpu: "200m"
  # resources.lvmd -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  lvmd: {}
  #  requests:
  #    memory: 100Mi
  #    cpu: 100m
  #  limits:
  #    memory: 500Mi
  #    cpu: 500m
  # resources.topolvm_scheduler -- Specify resources.
  ## ref: https://kubernetes.io/docs/user-guide/compute-resources/
  topolvm_scheduler: {}
  #  requests:
  #    memory: "50Mi"
  #    cpu: "50m"
  #  limits:
  #    memory: "200Mi"
  #    cpu: "200m"

env:
  # env.topolvm_node -- Specify environment variables for topolvm_node container.
  topolvm_node: []
  # env.csi_registrar -- Specify environment variables for csi_registrar container.
  csi_registrar: []
  # env.liveness_probe -- Specify environment variables for liveness_probe container.
  liveness_probe: []
  # env.topolvm_controller -- Specify environment variables for topolvm_controller container.
  topolvm_controller: []
  # env.csi_provisioner -- Specify environment variables for csi_provisioner container.
  csi_provisioner: []
  # env.csi_resizer -- Specify environment variables for csi_resizer container.
  csi_resizer: []
  # env.csi_snapshotter -- Specify environment variables for csi_snapshotter container.
  csi_snapshotter: []
  # To specify environment variables for lvmd, use lvmd.env instead.
  # lvmd: []
  # env.topolvm_scheduler -- Specify environment variables for topolvm_scheduler container.
  topolvm_scheduler: []

livenessProbe:
  # livenessProbe.topolvm_node -- Specify resources.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  topolvm_node:
    failureThreshold:
    initialDelaySeconds: 10
    timeoutSeconds: 3
    periodSeconds: 60
  # livenessProbe.csi_registrar -- Specify livenessProbe.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  csi_registrar:
    failureThreshold:
    initialDelaySeconds: 10
    timeoutSeconds: 3
    periodSeconds: 60
  # livenessProbe.topolvm_controller -- Specify livenessProbe.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  topolvm_controller:
    failureThreshold:
    initialDelaySeconds: 10
    timeoutSeconds: 3
    periodSeconds: 60
  # livenessProbe.lvmd -- Specify livenessProbe.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  lvmd:
    failureThreshold:
    initialDelaySeconds: 10
    timeoutSeconds: 3
    periodSeconds: 60
  # livenessProbe.topolvm_scheduler -- Specify livenessProbe.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
  topolvm_scheduler:
    failureThreshold:
    initialDelaySeconds: 10
    timeoutSeconds: 3
    periodSeconds: 60

# storageClasses -- Whether to create storageclass(es)
# ref: https://kubernetes.io/docs/concepts/storage/storage-classes/
storageClasses:
  - name: topolvm-provisioner  # Defines name of storage class.
    storageClass:
      # Supported filesystems are: ext4, xfs, and btrfs.
      fsType: ext4
      # reclaimPolicy
      reclaimPolicy:  # Delete
      # Additional annotations
      annotations: {}
      # Default storage class for dynamic volume provisioning
      # ref: https://kubernetes.io/docs/concepts/storage/dynamic-provisioning
      isDefaultClass: false
      # volumeBindingMode can be either WaitForFirstConsumer or Immediate. WaitForFirstConsumer is recommended because TopoLVM cannot schedule pods wisely if volumeBindingMode is Immediate.
      volumeBindingMode: WaitForFirstConsumer #Immediate
      # enables CSI drivers to expand volumes. This feature is available for Kubernetes 1.16 and later releases.
      allowVolumeExpansion: true
      additionalParameters: {}
      topolvm.io/device-class: "localcache-hdd"

webhook:
  existingCertManagerIssuer: {}
  #  group: cert-manager.io/v1
  #  kind: ClusterIssuer
  #  name: letsencrypt-prod
  podMutatingWebhook:
    # webhook.podMutatingWebhook.enabled -- Enable Pod MutatingWebhook.
    enabled: false
  pvcMutatingWebhook:
    # webhook.pvcMutatingWebhook.enabled -- Enable PVC MutatingWebhook.
    enabled: true

# Container Security Context
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
securityContext:
  # securityContext.runAsUser -- Specify runAsUser.
  runAsUser: 10000
  # securityContext.runAsGroup -- Specify runAsGroup.
  runAsGroup: 10000

cert-manager:
  # cert-manager.enabled -- Install cert-manager together.
  ## ref: https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm
  enabled: true

priorityClass:
  # priorityClass.enabled -- Install priorityClass.
  enabled: true
  # priorityClass.name -- Specify priorityClass resource name.
  name: topolvm
  # priorityClass.value  -- Specify priorityClass value.
  value: 1000000

snapshot:
  # snapshot.enabled -- Turn on the snapshot feature.
  enabled: true

I unfortunately don't have control over disk provisioning, but I can create logical volumes with thin provisioning using the lvcreate --thin ... command. Therefore, I included it in the config like this:
  deviceClasses:
    - name: localcache-hdd
      volume-group: vg_localcache
      default: true
      spare-gb: 10
      lvcreate-options:
        - --thin

I re-deployed TopoLVM and started from scratch.

Created PVC
Created a container (PVC couldn't be attached to the pod) :(

Description of PVC:
Events:
  Type     Reason               Age                      From                                                                                Message
  ----     ------               ----                     ----                                                                                -------
  Warning  ProvisioningFailed   3m27s (x8 over 3h12m)    topolvm.io_topolvm-controller-5b446dc55d-ks9sd_820a7725-8a58-4089-a564-575cf399b91e  failed to provision volume with StorageClass "topolvm-provisioner": rpc error: code = Internal desc = not found
  Normal   WaitForPodScheduled  2m33s (x811 over 3h12m)  persistentvolume-controller                                                          waiting for pod dind to be scheduled
  Warning  ProvisioningFailed   117s (x57 over 3h12m)    topolvm.io_topolvm-controller-5b446dc55d-ks9sd_820a7725-8a58-4089-a564-575cf399b91e  failed to provision volume with StorageClass "topolvm-provisioner": rpc error: code = ResourceExhausted desc = no enough space left on VG: free=10670309376, requested=10737418240
  Normal   Provisioning         106s (x66 over 3h12m)    topolvm.io_topolvm-controller-5b446dc55d-ks9sd_820a7725-8a58-4089-a564-575cf399b91e  External provisioner is provisioning volume for claim "docker/localcache-pvc"

Log from topolvm-lvmd:
{"level":"info","ts":"2024-01-18T12:58:09Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"info","ts":"2024-01-18T12:58:09Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"info","ts":"2024-01-18T12:58:10Z","msg":"invoking LVM command","args":["lvcreate","-n","381debf8-d1e0-4cf9-acf5-c414d7af82d7","-L","10737418240b","-W","y","-y","--thin","vg_localcache"]}
{"level":"info","ts":"2024-01-18T12:58:10Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"error","ts":"2024-01-18T12:58:10Z","msg":"failed to create volume","name":"381debf8-d1e0-4cf9-acf5-c414d7af82d7","requested":10737418240,"tags":[],"error":"not found","stacktrace":"github.com/topolvm/topolvm/lvmd.(*lvService).CreateLV\n\t/workdir/lvmd/lvservice.go:122\ngithub.com/topolvm/topolvm/lvmd/proto._LVService_CreateLV_Handler\n\t/workdir/lvmd/proto/lvmd_grpc.pb.go:127\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:1374\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:1751\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:986"}
{"level":"info","ts":"2024-01-18T12:58:10Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"info","ts":"2024-01-18T12:58:18Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"info","ts":"2024-01-18T12:58:18Z","msg":"invoking LVM command","args":["fullreport","--reportformat","json","--units","b","--nosuffix","--configreport","vg","-o","vg_name,vg_uuid,vg_size,vg_free","--configreport","lv","-o","lv_uuid,lv_name,lv_full_name,lv_path,lv_size,lv_kernel_major,lv_kernel_minor,origin,origin_size,pool_lv,lv_tags,lv_attr,vg_name,data_percent,metadata_percent,pool_lv","--configreport","pv","-o,","--configreport","pvseg","-o,","--configreport","seg","-o,"]}
{"level":"error","ts":"2024-01-18T12:58:18Z","msg":"not enough space left on VG","name":"e6c6985f-b781-493e-b818-780cb9afec57","free":10670309376,"requested":10737418240,"stacktrace":"github.com/topolvm/topolvm/lvmd.(*lvService).CreateLV\n\t/workdir/lvmd/lvservice.go:90\ngithub.com/topolvm/topolvm/lvmd/proto._LVService_CreateLV_Handler\n\t/workdir/lvmd/proto/lvmd_grpc.pb.go:127\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:1374\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:1751\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.3/server.go:986"}

And when I check lvs on the node, I see:
root@runner-test-wrk-1:~# lvs
  LV                                   VG            Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  03421acb-f56f-4dc2-9ae5-f39debd478ee vg_localcache twi-a-tz-- 10.00g             0.00   10.61
  6b846237-1867-411d-8450-c6123c36ac10 vg_localcache twi-a-tz-- 10.00g             0.00   10.61
  7d46aed5-4df0-4eb1-92a0-55e03d6f6e01 vg_localcache twi-a-tz-- 10.00g             0.00   10.61
  d9070b16-3d09-4073-a2b5-eeb95e038bee vg_localcache twi-a-tz-- 10.00g             0.00   10.61

I can't figure out why TopoLVM is creating multiple logical volumes. What exactly is going wrong here?

Hi Koray! the reason you are seeing this is because of your LVMD config:
  deviceClasses:
    - name: localcache-hdd
      volume-group: vg_localcache
      default: true
      spare-gb: 10
      lvcreate-options:
        - --thin

is not the right way to initiate a thin pool.
  deviceClasses:
    - name: localcache-hdd
      volume-group: vg_localcache
      default: true
      spare-gb: 10
      type: thin
      thin-pool:
         name: thin-pool-1
         overprovision-ratio: 2 //arbitrary

@daichimukai maybe it makes sense to validate that --thin is not part of lvcreate-options and throw an error instead?

@koraypinarci Hi. I'm not sure why the multiple LVs were created in your settings, but could you try the following steps to create a snapshot?

Before deploying TopoLVM, run lvcreate --thin ... command on your own. TopoLVM doesn't create a thin pool (ref.), so you need to create one. See also the corresponding code in our e2e test.
Modify your values.yaml to define a device class for the thin pool. You need to specify type: thin and thin-pool field. See our e2e test.
Define a new StorageClass using the device class you defined in the previous step. Use additionalParameters here. See also here.
Apply a PVC using the the StorageClass you defined, bind a Pod to the PVC, and take a snapshot of it.

@jakobmoellerdev I think lvcreate-options is a kind of escape hatch for users and is expected not to be validated at all, as the document says. Instead, we may need more docs for snapshots like the one above.

@ushitora-anqou the code in topolvm does not work properly for thin pools referenced with lvcreate because all of the Thin pool checks are based on the property in lvmd, not on the lvcreate option. I think this is the reason for the misbehaving codeline. The test that you linked only shows the vg/lv creation but the lvmd associated with it shows that we need this different format: https://github.com/topolvm/topolvm/blob/f9c44dbed50698883a1c9743ae5e7eef926999b0/e2e/lvmd1.yaml#L20-L23
I do agree that this can be used as "escape hatch" for RAID etc. but not for thin provisioning since its already part of TopoLVMs API

I agree that lvcreate-options is not intended for thin provisioning, and the properties of lvmd should be edited to use it.
However, the idea of validating lvcreate-options doesn't seem to be an appropriate option here. My concerns are as follows:

The TopoLVM documentation already says that lvcreate-options should be used at users' own risk. I'd like to keep it that way.
Validating lvcreate-options in a sound and complete way seems very difficult to me. That is, I want to avoid annoying situations where TopoLVM lvcreate-options doesn't support some strings that lvcreate does, or vice versa. For example, naive string matching for --thin and -T won't work if a complex command-line argument is used such as -vT. To avoid such situations, we need to parse the command-line options passed through lvcreate-options in exactly the same way as lvcreate. But this will be difficult because lvcreate uses getopt(3) to parse the arguments, but we can't use it because we're writing Go (without cgo).

It seems to me that this issue (#827) was raised because TopoLVM currently lacks documentation for thin provisioning and snapshots. So, I'd like to suggest adding a short step-by-step tutorial that will be sufficient for users to start using snapshots.

Hello everyone,
Thank you for your prompt response.
It took me some time to implement and test the configuration you recommended. I'm happy to report that TopoLVM is performing exactly as I envisioned. Thank you once again for your support. I'd like to share my configuration here in case someone else encounters the same issue, to help them find a solution more quickly. Therefore, some aspects might be repetitive.
Here's what I've changed in my setup:

As @jakobmoellerdev suggested, I adjusted my deviceClasses:

  deviceClasses:
    - name: localcache-hdd-thin
      volume-group: vg_localcache
      default: true
      spare-gb: 5
      type: thin
      thin-pool:
        name: thin-pool-1
        overprovision-ratio: 2

Then, I created a new thin pool on the node. @ushitora-anqou, thank you for the tip.

List diks
lsblk

First step create Phisical Volume
pvcreate /dev/sdb

Second step create Volume Groups
vgcreate vg_localcache /dev/sdb

Create thin-pool
lvcreate -T -n thin-pool-1 -L 45G vg_localcache

I adjusted my StorageClass

storageClasses:
  - name: topolvm-provisioner  # Defines name of storage class.
    storageClass:
      fsType: ext4
      reclaimPolicy:  # Delete
      annotations: {}
      isDefaultClass: false
      volumeBindingMode: WaitForFirstConsumer
      allowVolumeExpansion: true
      additionalParameters: {}
      topolvm.io/device-class: "localcache-hdd-thin"
  - name: topolvm-provisioner-thin
    storageClass:
      fsType: xfs
      isDefaultClass: true
      volumeBindingMode: WaitForFirstConsumer
      allowVolumeExpansion: true
      additionalParameters:
        '{{ include "topolvm.pluginName" . }}/device-class': "localcache-hdd-thin"

Redeployed TopoLVM with Helm

#!/bin/bash

set -euo pipefail

TOPVLM_CONTEXT=ghrunner-test
TOPOLVM_NAMESPACE=topolvm-system
TOPPLVM_INSTALLATION_NAME=topolvm
TOPOLVM_VALUES_FILE=/topolvm/kube-system/values.yaml
KUBECONFIG_PATH=~/.kube/config.yaml
TOPOLVM_CHART_VERION=13.0.1

# Change context
kubectl config use-context "${TOPVLM_CONTEXT}"

# Add helm repo for topolvm
helm repo add topolvm https://topolvm.github.io/topolvm \
  && helm repo update

# Crate namespace
kubectl --kubeconfig "${KUBECONFIG_PATH}" create namespace "${TOPOLVM_NAMESPACE}" || true
kubectl --kubeconfig "${KUBECONFIG_PATH}" label namespace "${TOPOLVM_NAMESPACE}" topolvm.io/webhook=ignore \
  && kubectl --kubeconfig "${KUBECONFIG_PATH}" create namespace kube-system || true
     kubectl --kubeconfig "${KUBECONFIG_PATH}" label namespace kube-system topolvm.io/webhook=ignore

# Install topoLVM with the release name
helm --kubeconfig "${KUBECONFIG_PATH}" upgrade --install "${TOPPLVM_INSTALLATION_NAME}" \
     --namespace "${TOPOLVM_NAMESPACE}" \
     --create-namespace \
     --values "${TOPOLVM_VALUES_FILE}" \
     --version "${TOPOLVM_CHART_VERION}" \
     --debug \
     topolvm/topolvm

# Check if topoLVM is running. All topoLVM pods should be running.
kubectl --kubeconfig "${KUBECONFIG_PATH}" get pod --namespace "${TOPOLVM_NAMESPACE}"

This is a simple script that saves me the effort of deploying resources individually.

#!/bin/bash

set -euo pipefail

# Configuration variables
TOPVLM_CONTEXT=ghrunner-test
KUBECONFIG_PATH=~/.kube/config.yaml
CONFI_DIR=/topolvm/custom
TOPOLVM_NAMESPACE=default

# Function to apply Kubernetes configurations
apply_config() {
    echo "🚀 Applying $1..."
    kubectl --kubeconfig "${KUBECONFIG_PATH}" apply -f "${CONFI_DIR}/$1"
    sleep 10
}

# Function to delete Kubernetes configurations
delete_config() {
    echo "💀 Deleting $1..."
    kubectl --kubeconfig "${KUBECONFIG_PATH}" delete -f "${CONFI_DIR}/$1"
    sleep 10
}

# Create PVC
apply_config "pvc.yaml"

# Create initial Pod
apply_config "dind-init-pod.yaml"

# Pull Docker images
echo "🐋 Pulling images"
kubectl --kubeconfig "${KUBECONFIG_PATH}" exec -n "${TOPOLVM_NAMESPACE}" dind -- docker pull ubuntu
sleep 10

# Create SnapshotClass
apply_config "snapshotclass.yaml"

# Remove initial Pod
delete_config "dind-init-pod.yaml"

# Create Snapshot
apply_config "snapshot.yaml"

# Remove original PVC
delete_config "pvc.yaml"

# Start second Pod and bind PVC
apply_config "dind-2-pod.yaml"

# Start third Pod
apply_config "dind-3-pod.yaml"

With this, I was able to create a snapshot from a PVC and use the snapshot to create new PVCs and bind them to my two pods.
This was exactly what I wanted to do. Thank you very much.

I'm glad to hear that! I've opened another PR #833 to track an additional document for Snapshot&Restore, so I'll close this issue.


Cache open_ctrl field in controlled gates

Summary
Currently, every time the name of a controlled quantum gate is accessed, the field open_ctrl field  ist recomputed. It is not a terrible overhead but it adds up and it was observable while working on the runtime of the commutation analysis. I added a new field for open_ctrl and a setter for its corresponding property that is called whenever ctrl_state is set.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
18 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.003%) to 87.531%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
6
91.41%

crates/qasm2/src/parse.rs
12
96.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
59147

Relevant Lines:
67573

💛  - Coveralls


Use ~/.ssh as default for ssh_keygen, etc

In recent versions, the ~ folder is writable.  Thus ~/.ssh is now accessible.  This lets us store ssh keys in the proper location, i.e where paramiko searches for system hosts and keys, so allows third party libraries to work.
I believe ssh-keygen should be updated to use ~/.ssh rather than stash/.ssh.

Fixed in commit 79e4725a92af2e4ec3dd76d136e43773ab116f9b
ssh-keygen now saves the keys in ~/.ssh as well as $STASH_ROOT/.ssh for backwards compatibility.
You can update with selfupdate dev


User search through console

From chicchiricco on September 27, 2010 08:27:58
Add this missing feature.
Original issue: http://code.google.com/p/syncope/issues/detail?id=48

From<EMAIL_ADDRESS>on September 27, 2010 06:06:45
Status: Accepted

From<EMAIL_ADDRESS>on September 27, 2010 06:07:02
Status: Started

From<EMAIL_ADDRESS>on October 07, 2010 06:31:37
This issue was closed by revision r625 .
Status: Fixed


rsync failure results in a "successful" deploy

ember-cli-deploy-with-rsync isn't checking the result of executing rsync.
Here's a snippet from a failed deploy -- the directory was created and no files were synced.
[cem-ui-deploy] Running shell script
+ yarn deploy --mutex file:/tmp/.yarn-mutex -- production --activate
yarn deploy v0.24.6
$ ember deploy production --activate
cleaning up...
- Uploading `applicationFiles` to /data_storage/apps/cem/revisions/d191117
- Activating revision d191117
- Fetching Revisions
Done in 82.44s.
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

Thanks for reporting this and sorry for not acknowledging or taking care of this sooner! This should be better in the just-released version 0.2.0.


Suggestion: use history.action for ScrollToTop component

I was reading the Scroll Restoration documentation but found the current implementation a little lacking, mainly because the effect would invoke a scroll-to-top on every route change, regardless of a PUSH or POP.
I would like to suggest that you change the documentation to have this component implementation instead which keeps track of the history.action property as well:
const ScrollToTop = ({
  children,
  history: { action },
  location: { pathname }
}) => {
  useEffect(() => {
    if (action == "PUSH") {
      window.scrollTo(0, 0);
    }
  }, [pathname]);

  return children || null;
};

export default withRouter(ScrollToTop);

That way, the component will send the user to the top of the page whenever they proceed to click a Link element, but will get out of the way when the user clicks back or forward in their history, allowing the browser's Scroll Restoration to take care of the rest.
Happy to submit a PR with this updated component, an alternative component, and some explanation if you have some guidance on what you would like it to say.

A PR would be the better format for this, but I don't think we need to change the example. It's simplified intentionally. I would use something like react-router-scroll-memory instead if you need more specific behavior.

@timdorr Maybe you missed my point - I wouldn't want to use react-router-scroll-memory at all, in fact my modification leverages the Browser Scroll History spec just like your documentation mentions. This component as it stands currently in the documentation clobbers the Browser Scroll History entirely.
Does that make more sense?


EventLoop aware APIs

Currently you have APIs that return EventLoopFutures. It is very hard for users to anticipate on which EL those EventLoopFutures will be running. Because of this users who are deep into NIO will need to .hop(to:) after each call. This is a burden that we shouldn't put on users...
Code example:
https://github.com/funcmike/rabbitmq-nio/blob/poc/Sources/AMQPClient/AMQPChannel.swift#L83-L94
Instead the function should take an optional EventLoop parameter. If an EventLoop is passed, the returned EventLoopFuture must execute on the provided EL. If none is passed the ELF should always run on the connections EL.

I am wondering how relevant this still is in light of the "new" NIO guidance around AsyncChannel.
I feel we should rather slowly get rid of the promise/future stuff in the public APIs and make the async versions "first-class" implementations.

Not at all. Go all in on async/await. Don't expose any ELF/ELP API.


Some tests in the test run did not pass, failing the task

Hi.
I have tests which execute tests on remote test agents (Windows 7). Build definition use test plan. When I execute it shows me:

DistributedTests: Test run 'XXX' is in 'InProgress' state.
DistributedTests: Total Tests : 336, Passed Tests : 0
DistributedTests: Test run 'XXX' is in 'InProgress' state.
DistributedTests: Total Tests : 336, Passed Tests : 0
DistributedTests: Test run 'XXX' is in 'InProgress' state.
DistributedTests: Total Tests : 336, Passed Tests : 0
DistributedTests: Test run 'XXX' is in 'InProgress' state.
DistributedTests: Total Tests : 336, Passed Tests : 0
DistributedTests: Test run 'XXX' is in 'Completed' state.
DistributedTests: Total Tests : 336, Passed Tests : 0
Some tests in the test run did not pass, failing the task.

So this task execute during few minutes. If I switch to another test agent, tests execute 100% successful. It means that problem with test agent.
My test agent was update for last version of test agent 2015 Update 3.
On test agent in log file I see next log (part of them):

V, 2128, 3, 2016/06/30, 13:06:00.247,<PHONE_NUMBER>7, DTAExecutionHost.exe, TestPluginCache: Updating loadOnlyWellKnownExtensions from False to False.
V, 2128, 3, 2016/06/30, 13:06:00.247,<PHONE_NUMBER>5, DTAExecutionHost.exe, TestPluginCache: Ignoring the new extensions update as there is no change. Current extensions are 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\EXTENSIONS\MICROSOFT\WEB TOOLS\DNX\Microsoft.VisualStudio.Web.UnitTest.TestAdapter.dll'.
I, 2128, 3, 2016/06/30, 13:06:00.247,<PHONE_NUMBER>4, DTAExecutionHost.exe, Initializing the platform loadOnlyWellKnownExtensions=False, forceX86Discoverer=False.
V, 2128, 3, 2016/06/30, 13:06:00.247,<PHONE_NUMBER>9, DTAExecutionHost.exe, TestRunRequest.ExecuteAsync: Creating test run request.
W, 2128, 3, 2016/06/30, 13:06:00.247,<PHONE_NUMBER>9, DTAExecutionHost.exe, TelemetrySession: Error in starting Telemetry for unit test session : Cannot access a disposed object.
Object name: 'it is not allowed to use disposed Microsoft.VisualStudio.Telemetry.TelemetrySession object.'.
V, 2128, 3, 2016/06/30, 13:06:00.263,<PHONE_NUMBER>1, DTAExecutionHost.exe, TestRunRequest.ExecuteAsync: Created test run request.

So how it's fix?

Can you please post the fresh DTAExecution Host log? Please clear up the file before running the tests.

Hi.
Here link to this log.
https://1drv.ms/u/s!AvT3p5dgeHiNgQ-DTycg_zrrAm5N
Thanks in advance.

Also, can you please clarify. If it is required install Visual Studio on test agent for execute coded UI tests?

No, Visual Studio is not required on the Test Agent machine. Thanks!

Can you send me your skype details to debug this issue devops_tools at microsoft.com

Had offline discussion with customer and closing the issue.


Remove total field in event list, browser logs, alarm list commands.

Follow https://github.com/apache/skywalking-query-protocol/pull/91

Codecov Report

Merging #153 (b7b4b63) into master (48238c6) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head b7b4b63 differs from pull request most recent head bf9f4fd. Consider uploading reports for the commit bf9f4fd to get more accurate results

@@           Coverage Diff           @@
##           master     #153   +/-   ##
=======================================
  Coverage   27.47%   27.47%
=======================================
  Files          20       20
  Lines         404      404
=======================================
  Hits          111      111
  Misses        286      286
  Partials        7        7

Continue to review full report at Codecov.

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


Improve SVG encoding in data URIs

First of all, thank you for PostCSS Assets!
I think the encoding of SVGs in data URIs can be improved as described in the blog post Optimizing SVGs in data URIs. The method "Optimized URL-encoded" yields a smaller result than "Fully URL-encoded".
postcss-svgo uses the optimized URL-encoding. (But in my specific use case the SVG files have already been processed by SVGO when I pass them to PostCSS Assets. So ideally I do not want to run them through SVGO a second time.)

@steffenweber thanks, this is a really nice one. I've started to implement the advanced optimization based on that article and the postcss-svgo plugin code: https://github.com/assetsjs/assets/tree/feature/svg-data-optimization
However, for now I would like to omit the quotes optimization, because they require some tricky logic: the quotes in attributes should be forced to be single, while the rest should be kept as they were (so we don’t break possible textual content inside SVG). postcss-svgo acts pretty naive in this case — it just converts every quote, so those textual contents could be spoiled.
I think I'd release a new version without quote optimization and do it later. I would also appreciate any help in implementing it.

Thank you for starting the implementation! There is a small change required to make it work because currently the generated data URIs have a syntax error (Chrome reports net::ERR_INVALID_URL in the Developer Tools console).
Bad: data:image/svg+xml;…
Good: data:image/svg+xml,…
Alternative: data:image/svg+xml;charset=utf-8,…
The alternative is easier to implement: just prepend 'charset=utf-8,' to the result of optimizedEncodeUri in encodeBuffer.js. The more complete fix would be to change this module's code such that not all data URIs require a charset/encoding (I have not tried to implement this change).
Quote optimization: I thought that quotes appearing unencoded as " instead of as " in textual contents were a syntax error in SVG. But the W3 validator has no problem with them. :confused:
General approach: For safety reasons, I think it would be better to apply encodeURIComponent and then undo those substitutions that are known to be safe (whitelist instead of blacklist approach). Like this:
module.exports = function (string) {
  return encodeURIComponent(string.trim())
    .replace(/%20/g, ' ')
    .replace(/%2F/g, '/')
    .replace(/%3A/g, ':')
    .replace(/%3D/g, '=');
};

Hmm, maybe the proposed optimization is not such a good idea after all.

Permitted characters within a data URI are the ASCII characters for the lowercase and uppercase letters of the modern English alphabet, and the Arabic numerals. Octets represented by any other character must be percent-encoded, as in %26 for an ampersand (&).
https://en.wikipedia.org/wiki/Data_URI_scheme

See also: https://perishablepress.com/stop-using-unsafe-characters-in-urls/

How about an option for custom function to encode svg  like here?
For example:


[RFE] make better choices for API export

When dealing with clusters with multiple APIs for the same resource we're not always choosing the best.
Going from OpenShift 3.x to 4.x for example:

We export deployments from 3.11 clusters as deployments.extensions/v1beta1, rather than deployments.apps/v1. These can't be imported on newer 4.x releases without making changes.  The same is probably true from daemonsets and others.

RBAC

in at least some cases (maybe all?) such as kubernetes or newer openshift destinations it's preferable to export rolebindings using rolebinding.rbac.authorization.k8s.io rather than rolebinding.authorization.openshift.io. We currently seem to be preferring rolebinding.authorization.openshift.io though.

Related to #102

Is there a reliable manner to determine the preferred API? I assume we should always prefer a non beta API over a beta API if it's present?
I had a thought about being concerned about up converting the resource, but thinking more about that, it doesn't apply here.
This is talking about exporting a resource as a MOST PREFERRED gvk that's actually present tin the source cluster.
Converting an exported resource to a gvk that is not present on the source, but is present on the target, is an entirely separate problem

This deserved an enhancement I think first.

There is a feature flag in velero discovery that we can use to dump all versions:
diff --git a/cmd/export/export.go b/cmd/export/export.go
index 4cd9c06..a91ec27 100644
--- a/cmd/export/export.go
+++ b/cmd/export/export.go
@@ -9,6 +9,7 @@ import (
        "github.com/konveyor/crane/internal/flags"
        "github.com/spf13/cobra"
        "github.com/spf13/viper"
+       velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
        "github.com/vmware-tanzu/velero/pkg/discovery"
        "github.com/vmware-tanzu/velero/pkg/features"
        errorsutil "k8s.io/apimachinery/pkg/util/errors"
@@ -115,6 +116,7 @@ func (o *ExportOptions) Run() error {

        features.NewFeatureFlagSet()

+       features.Enable(velerov1api.APIGroupVersionsFeatureFlag)
        discoveryHelper, err := discovery.NewHelper(discoveryClient, log)
        if err != nil {
                log.Errorf("cannot create discovery helper: %#v", err)

I then changed the filenames so they wouldn't overwrite each other
--- a/cmd/export/discover.go
+++ b/cmd/export/discover.go
@@ -121,7 +121,7 @@ func getFilePath(obj unstructured.Unstructured) string {
        if namespace == "" {
                namespace = "clusterscoped"
        }
-       return strings.Join([]string{obj.GetKind(), namespace, obj.GetName()}, "_") + ".yaml"
+       return strings.Join([]string{obj.GetKind(), obj.GetObjectKind().GroupVersionKind().GroupKind().Group, namespace, obj.GetName()}, "_") + ".yaml"
 }

From there I get all representations:
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_crane-operator.v99.0.0-crane-operator-controller-man-6cf64744f5.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_crane-operator.v99.0.0-proxy-7444f7dc97.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_crane-operator.v99.0.0.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_openshift-operators-prometheus-k8s-read-binding.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_system:deployers.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_system:image-builders.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_system:image-pullers.yaml
export/resources/openshift-migration-toolkit/RoleBinding_authorization.openshift.io_openshift-migration-toolkit_tekton-operator-info.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_crane-operator.v99.0.0-crane-operator-controller-man-6cf64744f5.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_crane-operator.v99.0.0-proxy-7444f7dc97.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_crane-operator.v99.0.0.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_openshift-operators-prometheus-k8s-read-binding.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_system:deployers.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_system:image-builders.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_system:image-pullers.yaml
export/resources/openshift-migration-toolkit/RoleBinding_rbac.authorization.k8s.io_openshift-migration-toolkit_tekton-operator-info.yaml

Although we could then white things out we don't want that might not be a great approach.
I get the impression there's also preferred versions by cluster. We might want to look at what's preferred on the destination and export for that. There's some mention of that on velero issues like: https://github.com/vmware-tanzu/velero/issues/2551

I was hoping we could also get a preferred API. It seems like only a preferred version:
    {
      "name": "rbac.authorization.k8s.io",
      "versions": [
        {
          "groupVersion": "rbac.authorization.k8s.io/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "rbac.authorization.k8s.io/v1",
        "version": "v1"
      }
    },
...
    {
      "name": "authorization.openshift.io",
      "versions": [
        {
          "groupVersion": "authorization.openshift.io/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "authorization.openshift.io/v1",
        "version": "v1"
      }
    },

These PRs will pull down everything discard the known duplcates from the extensions and authorization.openshift.io groups, and anything not exported using the preferred (newest) version for the resource type.
https://github.com/konveyor/crane/pull/134
https://github.com/konveyor/crane-lib/pull/111
https://github.com/konveyor/crane-plugin-openshift/pull/18


[Improvement] Bump Spark 3.3.3 to 3.3.4

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

What would you like to be improved?
https://spark.apache.org/releases/spark-release-3-3-4.html
How should we improve?
No response
Are you willing to submit PR?

[ ] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
[x] No. I cannot submit a PR at this time.

Please assgin to me, thanks.


need example for init data

could you please give me an example, how can i init view with some data, thanks

@DachengChen Sorry for the late replay, you can find an example here


Migrate stress cluster to use workload identity

Notes TBD, a couple more edits need to be made (docs, test updates, and some more config deletion). Then I will publish out of draft.

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow


[Op] Add an operator for comparing shape values

This PR adds an operator called shape_equals that, as the name suggests, compares two shapes and returns a bool indicating whether they are equal. This will allow for comparing shapes within Relax without using a PackedFunc.
CC @mbaret

@mbaret recommended it for dynamically inspecting shapes. Perhaps he can give more specifics?

Note, this PR should likely be part of PRs to send to unity branch


Automaticly authorize?

hi,
Is can we authorize automaticly spesificed username and password?

VKontakte allows to authenticate only using oAuth or via the official VK app. At the login and password can not access.


Ruuter GET request bugfix

This is a bugfix for #7

Acceptance Criteria

[ ] #7 works according to https://github.com/buerokratt/Ruuter/blob/main/samples/steps/http-get.md
[ ] Outgoing request is constructed based on Ruuter DSL parameters

For example, in the following example, queryVal and varFromDSL are considered as DSL parameters to pass as GET query params:
get_message:
  call: http.get
  args:
    url: "[#DOMAIN_URL]:[#PORT]/scripting/passing-get-parameters"
    query:
      queryVal: queryVariableFromHell
      varFromDSL: "variableFromDSL"

Used this DSL for testing:
get_message:
  call: http.get
  args:
    url: "http://localhost:9000/scripting/passing-get-parameters?url_param=value1"
    query:
      some_val: "Hello World"
      another_val: 123
  result: the_message

With netcat "simply-log-all-incoming-requests" ( nc -k -l  -p 9000 ) running in localhost:9000.
This resulted with correctly formed GET request with all query parameters included and urlencoded:
GET /scripting/passing-get-parameters?url_param=value1&some_val=Hello%20World&another_val=123 HTTP/1.1

Problem is with reading the request, not making it. Additional ETA of 3h to 3h already spent.


Moving grpc_pick_unused_port_of_die before creating a deadline.

Should help with invalid_call_argument_test flakes on Windows a bit.

LGTM, waiting for tests.


in multithreading，appear Core dump error

I created a thread pool，Write each frame of video in a thread，appear "core dumped" error， please help

@abhiTronix

@mujinbao This is a incomplete issue and missing basic information to understand it properly. Kindly reformat your issue and provide proper Source-Code and other relevant information related to your issue, Otherwise, This issue will be marked invalid and will be closed

@abhiTronix  I'm so sorry，this is my code：
`
create thread pool
pool = ThreadPoolExecutor(max_workers=1500)
create video out
output_params = {"-vcodec": "libx264", "-input_framerate": "25", "-crf":28, "-preset":"ultrafast", "-tune":"zerolatency"}
out = WriteGear(output_filename=os.path.join(current_path, 'video', 'video.mp4'),
compression_mode=True,
**output_params)
camera = cv2.VideoCapture(0)
while camera.isOpened():
ret, frame = camera.read()
pool.submit(out_frame, frame, out) # the function code is  "out.write(frame) " and other  )

# do something....

`
In this way, the video is written in multi-threaded, and “Segmentation fault (core dumped) ” appears.
This is not always the case, and I suddenly found two times, I would like to ask if it is related to ffmpeg or other thread security settings.

@mujinbao Can you explain what it is the necessity of using Thread pool here? What are the performance advantages you're getting from this? Since, VidGear itself self-optimize the OpenCV & FFmpeg's I/O processes, and there is no need of creating an additional layer of a thread pool, that may result in undesired behaviour as in your case.
Reason for the Error: The VidGear's FFmpeg pipeline relies on subprocess python module to communicates with FFmpeg binaries. As speed of writing is dependent on speed of processing time of this Pipeline, therefore You cannot increase speed up the process more than the execution speed of Pipeline itself, thereby as the result see this segmentation fault at the output, as threadpool workers are working too much faster than capacity of FFmpeg Pipeline that can't handle it.
Instead of using the threaded pool with OpenCV, I'll advice you must try powerful & threaded VidGear API's such as CamGear with WriteGear API. Both work out of the box on any high to lower-end systems. Here's an example to use them:
# import libraries
from vidgear.gears import CamGear
from vidgear.gears import WriteGear
import cv2

output_params = {"-vcodec":"libx264", "-crf": 0, "-preset": "fast"} #define (Codec,CRF,preset) FFmpeg tweak parameters for writer

stream = CamGear(source=0).start() #Open live webcam video stream on first index(i.e. 0) device

writer = WriteGear(output_filename = 'Output.mp4', compression_mode = True, logging = True, **output_params) #Define writer with output filename 'Output.mp4'

# infinite loop
while True:

	frame = stream.read()
	# read frames

	# check if frame is None
	if frame is None:
		#if True break the infinite loop
		break

	# do something with frame here

	# write a modified frame to writer
        writer.write(frame)

        # Show output window
	cv2.imshow("Output Frame", frame)

	key = cv2.waitKey(1) & 0xFF
	# check for 'q' key-press
	if key == ord("q"):
		#if 'q' key-pressed break out
		break

cv2.destroyAllWindows()
# close output window

# safely close video stream
stream.stop()
# safely close writer
writer.close()

Closed. Feel free to reopen if you encounter further problems or Kindly provide complete GDB debug backtrace of your crashed program and full error log from your terminal for further investigation.

@abhiTronix
I got GDB information.

Allow me to explain this function code:
According to the needs of Party A, I need to create four video output objects to save the original image and the image after deep learning recognition, and video formats require both AVI and mp4.
As the latency requirement was minimized, I had to use thread pool to optimize processing speed.
Therefore, in the "write_video" function, the same image is written twice, and then the image is detected by in-depth learning. The new image after detection is also written twice. This code also happens "core dump".
I don't understand why there was no problem saving only AVI format before，from the GDB information, it seems that the address of this object has changed, and then there is a pointer error.
But segment errors (core dumps) do not occur very often, and they occur only twice or three times a day.
Please help me. Thank you very much.

#49

@mujinbao Try putting breakpoints after each line, you can also clone this library and put breakpoints and print commands to see at which line or at which input value this error is happening. It is very hard to debug this error just by seeing as this is happening within threads, so we can't tell what is the actual cause or you can share the entire code for debugging. So my advise is to Try your code without using any threading at all, to see the actual error is. There may be a wrong input value or corrupt data which is resulting in this error/crash.


[taglib] Update to 1.13

Upgrade TagLib to the latest stable version, 1.13. The removed patch was merged upstream.

What does your PR fix?
See above.

Which triplets are supported/not supported? Have you updated the CI baseline?
All. No.

Does your PR follow the maintainer guide?

Yes

@microsoft-github-policy-service agree default

Please bump the port version. See documentation.
Also please run command vcpkg x-add-version --taglib then commit the changes.

@FrankXie05 The bumped port version should be 4, or 0?. The documentation says to reset to 0 when the package version increases, but when I set port-version to 0 I get the below error when running vcpkg x-add-version:
error: taglib is not properly formatted
Run `vcpkg format-manifest ports/taglib/vcpkg.json` to format the file
Don't forget to commit the result!

If I run that formatting command, it removes the "port-version": 0 from the manifest file. So I am a bit confused here.

@complexlogic
The following steps are recommended:

Delete the "port-version": 3,line in the vcpkg.json file (for updates).
.

@FrankXie05 Done.


Windows installer for CLI

Adds a windows installer to automate pip install for gorilla-cli, addressing Ideas discussion #103 and QnA discussion #40. Requires Python and pip to be installed on the user's machine, but completely automates installation process of gorilla-cli.

Hey @RoastSea8 thanks for the PR! This is very timely. A few quick comments:

Can you also commit the script that you used to come up with the exe so we can keep it updated as and when needed?
If python/pip are not installed what is the fallback mechanism? Is there a way we side step this.. Thoughts?
Thanks!!

Hi @ShishirPatil

I've committed the script.
The most we can do if the user does not have python/pip installed is download the package on their device (i.e., there is a way to automate the installation of the package on the local device without pip). However, as per my research, locally downloading the package does not allow the user to use gorilla's commands in the CLI. I believe even adding the package's directory path to PATH as an environment variable doesn't "activate" the usage in the command line of gorilla=go_cli:main, specified in setup.py. Using gorilla's commands in the CLI requires either that gorilla-cli be downloaded via pip or that the project's setup.py file be run using python. We can set up a call and discuss further if you'd like.


Creating a group results in a weird animations

Regression?
No
System Info and Version
 System/Version info
Hyprland, built from branch  at commit 918d8340afd652b011b937d29d5eea0be08467f5  (flake.lock: update).
Date: Tue Jun 25 12:06:02 2024
Tag: v0.41.2, commits: 4886

flags: (if any)

System Information:
System name: Linux
Node name: KOMP
Release: 6.9.7-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 04:32:50 +0000

GPU information:
28:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6950 XT] [1002:73a5] (rev c0) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:
  hypreasymotion by Zakk ver 1.0

group {
    groupbar {
        # text_color = rgb(ff0000)
        col.inactive = rgb(444444)
        col.active = rgb(999999)
        height = 14
    }
}

default animations config (I commented out animations {} section so it uses the defaults)

Description
It seems that when creating groups and when switching between group items for the first time, animations are not behaving correctly, they are jumping around.
How to reproduce

Create some windows
Create a group
Move windows into that group - note that the entire group will weirdly jump towards the new window
Move between windows in a group - note that the entire group will jump on each move (this only happens when you first cycle through the windows. Subsequent cycles work fine).

Crash reports, logs, images, videos
recording.webm

what dispatcher are you using I can't repro this anymore with moveintogroup

Ah, I'm using movewindoworgroup

oh it's only on master layout

No, I just tested and it also happens on dwindle for me.

No, I just tested and it also happens on dwindle for me.

i couldn't reproduce on dwindle then

After some investigation, trigger line appears to be this:
dwindle {
    no_gaps_when_only = true
}

then it at least partially happens on dwindle too:
out.webm
Here is full config that I can reproduce it with (default config + some changes in the end):
repro_conf.conf.txt


Use changelogs/release.yaml for the version number source everywhere

Currently both the top banner of the site and the top paragraph on the Changelogs page pull the current version number of the spec from config.toml, i.e:
https://github.com/matrix-org/matrix-doc/blob/6c6aa0b3d6eb6edc65c68ad78072a6733998969b/layouts/shortcodes/changelog/changelog-description.html#L8-L15
Note the {{ .Site.Params.version.number }} bit.
However, we already have a method of specifying the version number of a release build of the spec: changelogs/release.yaml:
https://github.com/matrix-org/matrix-doc/blob/6c6aa0b3d6eb6edc65c68ad78072a6733998969b/layouts/shortcodes/changelog/changelog-changes.html#L1-L16
This commit changes the site banner and Changelogs page to use tag in changelogs/release.yaml for the version number of the spec, instead of having two different ways to do things. Note that if we're building an unstable version of the spec, then changelogs/release.yaml is never read from.

The thought occurs to me: if the unstable flag comes from config.toml, shouldn't the version number? In other words, should we go the other way and make changelog-changes use the value from config.toml rather than release.yaml?

I'm not really familiar with this templating system, whatever it is - but it looks plausible, as long as you've tested it :)

Oh right - I should've mentioned. It's hugo's own templating system. Looks quite similar to jinja2. https://gohugo.io/templates/introduction/

The thought occurs to me: if the unstable flag comes from config.toml, shouldn't the version number? In other words, should we go the other way and make changelog-changes use the value from config.toml rather than release.yaml?

The historical context is in https://github.com/matrix-org/matrix-doc/pull/2992 (note that we switched from individual release.yaml files to a single one in https://github.com/matrix-org/matrix-doc/pull/2992 after the global version number proposal). I believe the original reason for keeping it in a file versus config.toml was that we originally had to deal with multiple versions of the spec. Nowadays that's not the case.
It would certainly be easier in templates to pull a parameter from the config than parsing yaml files everywhere, so perhaps we should move the date and time into config.yaml. Note that the Changelog page only shows the current release version and the changes since the last release. We just export a different release per git tag, so there'll never be a need for multiple release.yaml files.

@richvdh I've updated things to use the information in config.toml everywhere instead of having a separate changelogs/release.yaml file. Looks good on a test! :slightly_smiling_face:

Presumably this necessitates a change to #3295?

Yep! Hope you don't mind if I do so via a rebase...


As a dev, I want to set up a base project with Next.js, Zustand, and Material-UI

Description
Context
We are starting our frontend project from scratch, transitioning from vanilla React to using Next.js, Zustand, and Material-UI. We want to ensure the project has a solid foundation so that the team can work in parallel efficiently. This base will include key configurations, folder structures, and tooling to standardize our development process.
Problem Statement
The base project needs to be set up with the core technologies and configurations to ensure consistency across the team, allowing us to develop features in parallel without conflicts.
Acceptance Criteria

Set up Next.js project with proper initialization.
Define and implement a consistent folder structure.
Integrate Zustand for global state management.
Configure Material-UI with custom theming.
Implement basic routing and navigation setup.
Set up ESLint and Prettier for linting and formatting.
Integrate Jest and React Testing Library for unit testing.
Configure environment variable management using Next.js built-in features.
Provide initial documentation with setup and contribution guidelines.
Include sample components and pages for state management, routing, and Material-UI usage.
Consider opting out of Next.js telemetry: How do I opt-out?

@k-allagbe @Youllou  @ChromaticPanic
Do we want to install middleware for log state change?

@k-allagbe @Youllou @ChromaticPanic Do we want to install middleware for log state change?

This article recommends middleware for some scenarios like user authentication redirects https://blog.logrocket.com/guide-state-management-next-js/ [1]
Here is some discussion on the topic of handling state server side https://github.com/pmndrs/zustand/discussions/2200 [2]
For state within a page, state will still be handled client side. Not sure if currently we need to share state between pages? For data sharing between pages when using Next, my interpretation of the discussion in [2] is that there shouldn't be global state server side so any shared data will come from the database. It looks like they recommend useContext https://github.com/pmndrs/zustand/discussions/2200#discussioncomment-8395699

I think that for simplicity we should avoid trying to handle states on server side. I'm not too familiar with that to be honest. I suggest as a first step that we handle components rendering client-side (like usual) along with the state management. Once we nail down the details, we render static components on server. What do you think?

I think that for simplicity we should avoid trying to handle states on server side. I'm not too familiar with that to be honest. I suggest as a first step that we handle components rendering client-side (like usual) along with the state management. Once we nail down the details, we render static components on server. What do you think?

I agree, that is a good strategy. As we add components and functionality to the nextjs branch we can review the components for design issues.


[Task] Universal Back Button navigation within Appsmith

Summary
Users should be able to navigate between pages and states seamlessly without dabbling into the entity explorer. For large apps, entity explorer can get crowded, and if entities are not named well navigation can be a mess.
We need a simple and intuitive way for users to navigate within appsmith.
Example task flow-
Property Pane Lightning Menu -> Create New API -> API Pane -> Property Pane
Idea #1
All pages have a close button, closing the page takes you back to the canvas. Users can use the browser back button to navigate one step back.

Idea #2
All pages have a back and a forward button that replicates the behavior of browser navigation buttons.

We'll pick up this task a little later


Why are there duplicates?

In the first table there are 3 meters for 1-4 vCPU VM and 12 for the 5+ vCPU, why is this? What is the difference between them?
Looking in eg the PAYG rate cards, the duplicates are priced identically, have identical identifying strings (category, sub category, name) and all apply to every region.

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

ID: a0ed5d03-9f9e-1c7f-c450-a2f0f5bebd87
Version Independent ID: bde6e4cf-9245-25b5-82df-db7b30ecda99
Content: Understand Red Hat reservation plan discount and usage - Azure
Content Source: articles/billing/billing-understand-rhel-reservation-charges.md
Service: billing
GitHub Login: @yashesvi
Microsoft Alias: cwatson

Thanks for your comment. We are actively investigating and will get back to you shortly. Thanks for your patience.

@yashesvi  - any input please?

@tsarna Updated for clarity with https://github.com/MicrosoftDocs/azure-docs-pr/pull/118635. Thanks very much for your input.
#please-close


Please tag a release

Hi,
I would like to add hey to the FreeBSD ports tree, but I need a release number to add it.  Could you please tag a release, even if it something like 0.0.1?
Thank you.

+1

Yes please!

Tagged https://github.com/rakyll/hey/tree/v0.1.0.


checkJs not working in new playground

Here's an example.
Hover over the cool in super.cool() and it shows up as any, despite both checkJs being turned on and // @ts-check comment placed at the top of the file.
I am expecting it to be a type error.

Could be related to #49

Fixed in https://github.com/microsoft/TypeScript-Website/commit/8782d0dbfd72f19d46deb5123533dd7f6b623329


Add issue template

Can I make issue templates to enhance the workflow of the repository?

Can I make issue templates to enhance the workflow of the repository?

Sure @Kerveyfelix , Go ahead.


Fixed bug with logs

Coverage decreased (-0.2%) to 46.531% when pulling dd6919032e109f5eefb31b712efac1ff01c240fc on egopher:master into 670cd30561528cbe203c0e42e70c3edb28687c4e on supergiant:master.