various fixes

the following things where  fixed or changed:

added packages rust and cargo to build image, fixing error "no rust compiler found"
changed version tag for alpine image from 3.10 to 3.12 because the rust compiler in 3.10 is to old to build the ansible cryptography package

After these changes I got a successful build run with minor warnings.

@DustinBragg can you review this and accept if OK?
We could also update Grafana for #11 and potentially recheck if documentation needs clarifications or updates.

Hi @BaneusCatrix, I appreciate the patch! We have a new contribution workflow, please read CONTRIBUTING.md and fill out the CLA mentioned in step 6, then we'll get this reviewed / merged in. Thanks

@BaneusCatrix do you have time to fill the CLA so that this patch can be accepted?

@scaleoutsean Now jet, I'm going to tomorrow. Sorry for the delay, I have to consult my legal department.

The recent updates for version 3.0 of the performance analyzer should address the issues addressed by this PR. I'm going to close the PR. Please let us know if the build image is not fixed for you with the 3.0 version.


Add description for Reference build field to get correct build number

I need to discuss with Yuqian about the message.


WIP: Added IQKeyboard Manager

I have added IQKeyboard Manager, But Done button is not showing.

In this MR , i have installed the IQKeyboardManager for Dismiss the Keyboard.
And initialised it in AppDelegate file, But it not showing the Done Button on the top-right side of keyboard.

I tracked the reason of not showing the Done Button in keyboard😊


[netpol] akash-deployment-restrictions prevents PODs from accessing kube-dns over 53/udp, 53/tcp in pod subnet

Issue type
Bug
Versions
Akash v0.12.1
What happened
akash-deployment-restrictions Kubernetes network policy prevents PODs from accessing kube-dns over 53/udp, 53/tcp in pod subnet
What did you expect to happen
How to reproduce it
Deploy any deployment on Akash and see if it can access internal Kubernetes DNS (i.e. kube-dns) - it won't.
Environment
Kubernetes v1.21.3
Calico v3.19.1
The Akash provider has been deployed 1:1 as in this article https://nixaid.com/deploy-akash-provider-with-kubeadm/
Anything else we need to know?
Despite that we seem to allow DNS to internal server (kube-dns), it gets restricted by this policy, specifically by the Except CIDR <IP_ADDRESS>/8 as my kube-dns is getting IP from that range (see pod subnet right below).
My Kubernetes is set to run with these networks:
# cat kubeadm-config.yaml
...
networking:
  podSubnet: "<IP_ADDRESS>/18" # --pod-network-cidr, taken from kubespray
  serviceSubnet: "<IP_ADDRESS>/18" # --service-cidr, taken from kubespray
...

kube-dns is taking <IP_ADDRESS> IP from the service subnet:
# kubectl get svc --all-namespaces -o wide --show-labels |grep dns
kube-system                                     kube-dns                             ClusterIP   <IP_ADDRESS>     <none>        53/UDP,53/TCP,9153/TCP       159m   k8s-app=kube-dns                                                                                k8s-app=kube-dns,kubernetes.io/cluster-service=true,kubernetes.io/name=CoreDNS

kube-dns is taking <IP_ADDRESS> & <IP_ADDRESS> IPs from the pod subnet:
# kubectl get pods --all-namespaces -o wide --show-labels |grep dns
kube-system                                     coredns-558bd4d5db-2shqz                    1/1     Running     0          120m   <IP_ADDRESS>    lamborghini   <none>           <none>            k8s-app=kube-dns,pod-template-hash=558bd4d5db
kube-system                                     coredns-558bd4d5db-t9r75                    1/1     Running     0          120m   <IP_ADDRESS>    lamborghini   <none>           <none>            k8s-app=kube-dns,pod-template-hash=558bd4d5db

Test:
root@lamborghini:~# kubectl exec -ti -n 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u app1-75858fc945-p8kd2  -- nslookup google.com

"iptables -L -nv" point of view:
Chain cali-po-_PEQS7MbYv_VZ0kzwj_Z (2 references)
 pkts bytes target     prot opt in     out     source               destination
   10   600 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:QnsDJqx8isXrAMDQ */ match-set cali40s:Ftht5x3x5WMy15Y2Nc9qjfE dst MARK or 0x10000
   10   600 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:UIC00y5hg-1FeDQ0 */ mark match 0x10000/0x10000
    0     0 MARK       udp  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/16       /* cali:K0CxdmTZN1u-OTzN */ multiport dports 53 MARK or 0x10000
    0     0 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:sunps0Pnf8ySgrTd */ mark match 0x10000/0x10000
    1    60 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:uid_UZezSIcQX8d0 */ MARK xset 0x40000/0xc0000
    1    60 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/8           /* cali:c5fDubma52T_LQVO */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/16       /* cali:G1DsvlXMZld2Mc-_ */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/12        /* cali:TrR3ptaMp8Gdehqc */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:ZdH496bdyuOAiIqT */ mark match 0x40000/0x40000 MARK or 0x10000
    0     0 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:42ojTJ8smdS-EjeA */ mark match 0x10000/0x10000

Suggested changes
I suggest to allow PODs talk to the kube-dns by finding it directly using namespaceSelector & podSelector as follows:
Current state
PODs can't talk to kube-dns.

Calico's ipBlock <IP_ADDRESS>/16 doesn't play any role, unless the kube-dns pod network lies within the <IP_ADDRESS>/16 range for some reason, which it should not. Here is more on <IP_ADDRESS> used by Calico https://docs.projectcalico.org/reference/faq#why-does-my-container-have-a-route-to-16925411
Only 53/udp is allowed, 53/tcp is missing - not a big deal probably;
the next network policy rule restricts all the egress POD traffic to the local CIDRs, which is good. Well, one of those (<IP_ADDRESS>/8) overlaps with the pod subnet I am using, <IP_ADDRESS>/18, which prevents the PODs from talking to the kube-dns POD since it’s running in a different namespace (kube-system). And the containers running within same POD are allowed to talk with each other as expected since they fall under same namespace, which gets permitted by this rule

root@lamborghini:~# kubectl -n 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u get netpol akash-deployment-restrictions -o yaml
...
  - ports:
    - port: 53
      protocol: UDP
    to:
    - ipBlock:
        cidr: <IP_ADDRESS>/16
...
...
  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
        except:
        - <IP_ADDRESS>/8
        - <IP_ADDRESS>/16
        - <IP_ADDRESS>/12

Suggested change

Allow PODs access the kube-dns service over 53/udp & 53/tcp within the POD subnet;

root@lamborghini:~# kubectl -n 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u get netpol akash-deployment-restrictions -o yaml
...
  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
    to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
...

iptables look after the suggested change

I have tested this and it is working well. :-)

root@lamborghini:~# iptables -L cali-po-_PEQS7MbYv_VZ0kzwj_Z -nv
Chain cali-po-_PEQS7MbYv_VZ0kzwj_Z (2 references)
 pkts bytes target     prot opt in     out     source               destination
   10   600 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:QnsDJqx8isXrAMDQ */ match-set cali40s:Ftht5x3x5WMy15Y2Nc9qjfE dst MARK or 0x10000
   10   600 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:UIC00y5hg-1FeDQ0 */ mark match 0x10000/0x10000
    1    60 MARK       tcp  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:21TSisd5filhqOOo */ match-set cali40s:TwSPtm330ezw8L_TsjzvdD8 dst multiport dports 53 MARK or 0x10000
    1    60 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:6JHuANZXMnhLhx8o */ mark match 0x10000/0x10000
    5   376 MARK       udp  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:gS0FLa01bgq4OSpV */ match-set cali40s:TwSPtm330ezw8L_TsjzvdD8 dst multiport dports 53 MARK or 0x10000
    5   376 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:R_V0PJl1iaKYsP4H */ mark match 0x10000/0x10000
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:zMNfc9nf8SABNVa_ */ MARK xset 0x40000/0xc0000
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/8           /* cali:9cvPZKksOczMqDSk */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/16       /* cali:721FDsCZXO_HylR4 */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/12        /* cali:rbUhdD78uha4jhLR */ MARK and 0xfffbffff
    0     0 MARK       all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:KJB0w6NtDH2MjpRU */ mark match 0x40000/0x40000 MARK or 0x10000
    0     0 RETURN     all  --  *      *       <IP_ADDRESS>/0            <IP_ADDRESS>/0            /* cali:15k0ELs_Nma5sl9a */ mark match 0x10000/0x10000

root@lamborghini:~# kubectl -n 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u get netpol akash-deployment-restrictions -o yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  creationTimestamp: "2021-07-28T10:18:10Z"
  generation: 45
  labels:
    akash.network: "true"
    akash.network/namespace: 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u
  name: akash-deployment-restrictions
  namespace: 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u
  resourceVersion: "12890"
  uid: 92435312-2f7b-4691-ba3a-2c5b434f3f1a
spec:
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          akash.network/namespace: 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u
  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
    to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
        except:
        - <IP_ADDRESS>/8
        - <IP_ADDRESS>/16
        - <IP_ADDRESS>/12
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          akash.network/namespace: 38cmacar26cvskaenuv33nv1p2iad9iq7jit3ephgj16u
  - from:
    - namespaceSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

This issue has been mentioned on Akash Community. There might be relevant details there:
https://forum.akash.network/t/containers-cant-talk-to-the-internet-as-akash-deployment-restrictions-network-policy-prevents-pods-from-accessing-kube-dns-over-53-udp-53-tcp-in-pod-subnet/654/1

Will be addressed in https://github.com/ovrclk/akash/issues/1276

Seems like a very different issues to me. For this case, a process (i.e. curl) running in a container can not resolve IP's with DNS.

Seems like a very different issues to me. For this case, a process (i.e. curl) running in a container can not resolve IP's with DNS.

We've got networking as whole to investigate and work out. This issue isn't going to be ignored it's being collapsed.

Seems like a very different issues to me. For this case, a process (i.e. curl) running in a container can not resolve IP's with DNS.

That's exactly what is causing your issue.
Search for "nslookup" in my original post. ;)

This is incredibly helpful.   Thanks, @arno01 !

This issue has been mentioned on Akash Community. There might be relevant details there:
https://forum.akash.network/t/containers-cant-resolve-the-ip-as-akash-deployment-restrictions-network-policy-prevents-pods-from-accessing-kube-dns-over-53-udp-53-tcp-in-pod-subnet/654/6

This issue has been mentioned on Akash Community. There might be relevant details there:
https://forum.akash.network/t/containers-cant-resolve-the-ip-as-akash-deployment-restrictions-network-policy-prevents-pods-from-accessing-kube-dns-over-53-udp-53-tcp-in-pod-subnet/654/8

copied from the Akash Community forum here for better visibility:

After testing kubespray deployment over 3 nodes for some time today I learned that the cross-service resolution wasn't working for me because I do not use NodeLocal DNS Cache which kubespray employs by default (since kubespray 2.10 release on Oct 16, 2019) which listens over <IP_ADDRESS> IP by default and 53/UDP requests to all addresses within <IP_ADDRESS>/16 range are getting permitted by the akash-deployment-restrictions Network Policy.
And that is not an issue with the kubespray deployments suggested by the current Akash documentation.
So, I guess the github https://github.com/ovrclk/akash/issues/1339 issue can probably be closed, maybe with some follow-up on:

Do we really want to allow 53/UDP requests to ALL addresses within <IP_ADDRESS>/16?
I think we can still leverage namespaceSelector & podSelector as I've been suggesting in the PR in order to support NodeLocal DNS Cache-less deployments, such as kube-dns (coredns).

copied from the Akash Community forum here for better visibility:

After testing kubespray deployment over 3 nodes for some time today I learned that the cross-service resolution is not working for me because I do not use NodeLocal DNS Cache (doc) which kubespray employs by default (since kubespray 2.10 release on Oct 16, 2019) which listens over <IP_ADDRESS> IP by default and cross-service resolution is working as 53/UDP requests are permitted to all addresses within <IP_ADDRESS>/16 range by the akash-deployment-restrictions Network Policy.
And that is not an issue with the kubespray deployments suggested by the current Akash documentation but rather with the custom Kubernetes deployments such as mine.
So, I guess the github #1339 issue can probably be closed, maybe with some follow-up on:

Do we really want to allow 53/UDP requests to ALL addresses within <IP_ADDRESS>/16?
I think we can still leverage namespaceSelector & podSelector for letting NodeLocal DNS Cache service explicitly instead of allowing 53/UDP across <IP_ADDRESS>/16. As well as maybe to support NodeLocal DNS Cache-less deployments, such as kube-dns (coredns).

Update:
I've updated my kubespray-less write-up with the NodeLocal DNSCache installation steps so that the cross-service DNS communication is working.
As well as I've added few notes on how to enable the IPVS kube-proxy mode O(1) (instead of the iptables one O(n)), but, it seem to be being blocked by the "akash-deployment-restrictions" network policy currently.
One might try the IPVS mode with his kubespray (or I will do it one day later.).

Can you show me an example of what network security policies we should consider rather than just opening up <IP_ADDRESS>/16? It shouldn't take long for me to try it out.

copied from the Akash Community forum here for better visibility:

After testing kubespray deployment over 3 nodes for some time today I learned that the cross-service resolution is not working for me because I do not use NodeLocal DNS Cache (doc) which kubespray employs by default (since kubespray 2.10 release on Oct 16, 2019) which listens over <IP_ADDRESS> IP by default and cross-service resolution is working as 53/UDP requests are permitted to all addresses within <IP_ADDRESS>/16 range by the akash-deployment-restrictions Network Policy.
And that is not an issue with the kubespray deployments suggested by the current Akash documentation but rather with the custom Kubernetes deployments such as mine.
So, I guess the github #1339 issue can probably be closed, maybe with some follow-up on:

Do we really want to allow 53/UDP requests to ALL addresses within <IP_ADDRESS>/16?
I think we can still leverage namespaceSelector & podSelector for letting NodeLocal DNS Cache service explicitly instead of allowing 53/UDP across <IP_ADDRESS>/16. As well as maybe to support NodeLocal DNS Cache-less deployments, such as kube-dns (coredns).

Update:
I've updated my kubespray-less write-up with the NodeLocal DNSCache installation steps so that the cross-service DNS communication is working.
As well as I've added few notes on how to enable the IPVS kube-proxy mode O(1) (instead of the iptables one O(n)), but, it seem to be being blocked by the "akash-deployment-restrictions" network policy currently.
One might try the IPVS mode with his kubespray (or I will do it one day later.).

Can you show me an example of what network security policies we should consider rather than just opening up <IP_ADDRESS>/16? It shouldn't take long for me to try it out.

It's already there, check the "Suggested change" and in the first post. 😉

@hydrogen18 the PR is for the

OK got it. Merge request #1422 implements this exactly. I did a quick local test & everything is functioning as I expect. I don't really know of a way to test DNS over TCP, but if you have a suggestion I'll try it out.

that fix is in master branch, when I did make in the master branch, I've got 0.12.2-39-g98fd6bd9 returned by akash version command.
Just want to check if that's expected and whether master is > v0.14.1-rc6 & v0.15.x ?

@hydrogen18 https://github.com/ovrclk/akash/pull/1440

Thanks @arno01

@hydrogen18

OK got it. Merge request #1422 implements this exactly. I did a quick local test & everything is functioning as I expect. I don't really know of a way to test DNS over TCP, but if you have a suggestion I'll try it out.

that fix is in master branch, when I did make in the master branch, I've got 0.12.2-39-g98fd6bd9 returned by akash version command. Just want to check if that's expected and whether master is > v0.14.1-rc6 & v0.15.x ?

refs #1437
There's no need to @ us, @arno01.  We see and pay attention to the activity feed and issues, PRs.

As far as I know this is complete.


Fix libwfkafka's description.

某次提交时给改错了。

Checksums were still not right:
error: ...modules/private/action/require/impl/actions/download.lua:187: unmatched checksum, current hash(5701ef31) != original hash(3d32cb42)
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:912]:
    [...modules/private/action/require/impl/actions/download.lua:187]: in function '_download'
    [...modules/private/action/require/impl/actions/download.lua:322]:

  => download https://github.com/sogou/workflow/archive/refs/tags/v0.10.6.tar.gz .. failed

right hash is 5701ef31518a7927e61b26cd6cc1d699cb43393bf1ffc77fa61e73e64d2dd28e


Add data from Treibhausgasbilanz Ebersberg

The Landkreis Ebersberg biyearly publishes a greenhouse gas balance:

2016: https://www.energieagentur-ebe-m.de/data/dokumente/konzepte ebe m/2020_05_12_Treibhausgasbericht_Landkreis_Ebersberg_2016_komprimiert.pdf
2018: https://www.energieagentur-ebe-m.de/data/dokumente/konzepte ebe m/2020-12-18_Treibhausgasbericht_Landkreis_Ebersberg_2018_web.pdf
2020: https://www.energieagentur-ebe-m.de/data/dokumente/sonstige/2022_11_22_THG_Bilanzierung_final_Web.pdf

The report also includes data aggregated by municipality, so we do also have numbers specifically for Vaterstetten.
As of March 2021, it was not intended to publish the data in a machine-readable format, but it could be worth asking if this would be possible for the 2020 report (published in 2022).

The data also includes the number of electric vehicles by municipality, which is not possible using the public data by the Kraftfahrtbundesamt (see #37). Maybe they get the data directly from the Kfz-Zulassungsbehörde in Ebersberg.


Adds a Quadrilateral primitive

Summary

This PR is a feature
It does the following:

Adds Quadrilateral primitive
Adds BoundingBox constructor that takes an initializer list
Extends BoundingBox::intersectsWith to work with a bounding box of a different dimension
Adds compute_bounding_box operator for Quadrilateral

Is there a command I can use to do automatic formatting since the style check is failing?

Is there a command I can use to do automatic formatting since the style check is failing?

Thanks @adayton1 --  make style from the build directory should do the trick.

Can someone tell me why the ci/gitlab/lc.llnl.gov pipeline failed? I don't have access to view that page.

Can someone tell me why the ci/gitlab/lc.llnl.gov pipeline failed? I don't have access to view that page.

This was the error for jobs with CUDA enabled:
/usr/WS1/atk/gitlab-runner/builds/zkQzXxmM/002/gitlab/axom/axom/src/axom/spin/tests/spin_bvh.cpp(1868): error: copy-list-initialization cannot use a constructor marked "explicit"
Error message in HIP enabled jobs:
/usr/WS1/atk/gitlab-runner/builds/9YsVm9VV/001/gitlab/axom/axom/src/axom/spin/tests/spin_bvh.cpp:1868:20: error: chosen constructor is explicit in copy-initialization
      boxes[idx] = {PointType(0.), PointType(1.)};
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/WS1/atk/gitlab-runner/builds/9YsVm9VV/001/gitlab/axom/axom/src/axom/core/../../axom/primal/geometry/BoundingBox.hpp:101:12: note: explicit constructor declared here
  explicit BoundingBox(std::initializer_list<PointType> pts);
           ^
/usr/WS1/atk/gitlab-runner/builds/9YsVm9VV/001/gitlab/axom/axom/src/axom/core/../../axom/primal/geometry/BoundingBox.hpp:67:7: note: passing argument to parameter here
class BoundingBox
      ^

Can someone tell me why the ci/gitlab/lc.llnl.gov pipeline failed? I don't have access to view that page.

Looks like with your new initializer list constructor, it needs:
  // single bounding box in [0,1] x [0,1] x [0,1]
  BoxType* boxes = axom::allocate<BoxType>(1, allocID);
  axom::for_all<exec>(
    0,
    1,
    AXOM_LAMBDA(axom::IndexType idx) {
-      boxes[idx] = {PointType(0.), PointType(1.)};
+      boxes[idx] = BoxType{PointType(0.), PointType(1.)};
    });

@kennyweiss  can we get @adayton1 access to CZ Gitlab?

@kennyweiss can we get @adayton1 access to CZ Gitlab?

Good call! Done.

Can someone tell me why the ci/gitlab/lc.llnl.gov pipeline failed? I don't have access to view that page.

Looks like with your new initializer list constructor, it needs:
  // single bounding box in [0,1] x [0,1] x [0,1]
  BoxType* boxes = axom::allocate<BoxType>(1, allocID);
  axom::for_all<exec>(
    0,
    1,
    AXOM_LAMBDA(axom::IndexType idx) {
-      boxes[idx] = {PointType(0.), PointType(1.)};
+      boxes[idx] = BoxType{PointType(0.), PointType(1.)};
    });

Or should I make the initializer list constructor implicit?

Thanks for this contribution @adayton1
Overall, it looks great, but it would be nice to have a few more unit tests for your expected use case of intersecting 2D and 3D bounding boxes.
It would also be nice to have a unit test for a 3D quadrilateral, and its associated area, but that could wait until we have a direct need.

I will add a unit test for intersecting 2D and 3D bounding boxes. I have not implemented the area calculation for a 3D quadrilateral since I haven't been able to find a universal algorithm that works with skewed (non-planar) quadrilaterals.

I will add a unit test for intersecting 2D and 3D bounding boxes. I have not implemented the area calculation for a 3D quadrilateral since I haven't been able to find a universal algorithm that works with skewed (non-planar) quadrilaterals.

Thanks. I agree let's hold off on the 3D area until we need it.
2D/3D BBox intersections would be useful though since that's needed in your application.

@kennyweiss, @rhornung67 do you have any more comments?

@kennyweiss, @rhornung67 do you have any more comments?

Could you please add a line to the RELEASE_NOTES about the new primitive?
Looks good to me once it passes all the CI. I'm not sure why the Azure jobs are failing.

@kennyweiss, @rhornung67 do you have any more comments?

Could you please add a line to the RELEASE_NOTES about the new primitive?
Looks good to me once it passes all the CI. I'm not sure why the Azure jobs are failing.

I updated the release notes. Yeah, something weird was going on in the CI. Hopefully restarting it will do the trick.


Allow 5 minutes for the taker to initiate collaborative settlement

In production, we saw scenarios where the timeout was triggered after 60s, but the taker never triggered a rollover again.
This could mean that the taker did send Initiate with the signature, but it did not arrive at the maker's collab settlement actor in time before the timeout was triggered, resulting in the taker to believe the settlement was "finished" (i.e. handled bt the maker), but the maker actually timed out.
As a quick fix this allows for 5 minutes to receive Initiate on the maker side instead of 1 minute.

Quickfix until we action https://github.com/itchysats/itchysats/issues/320

It would be really good to validate such kind of theories. I am happy to make this change but I also have a feeling that there is something else that is not working. 60 seconds should have been plenty.

I totally agree with this statement overall, we can think about more feedback loops between taker and maker.
In the current situation we cannot easily verify without the taker coming back to us with information. I think the best way forward is to implement #320 - that should make the problem of the taker trusting the maker to publish go away altogether.
The current problem is, that the taker transitions to a state that is treated as "final" trusting the maker. This will go away if both try to publish the transaction. The taker will then never transition to Pending Close unless the taker has the fully signed transaction.

bors r+


[Question] How to find out if an image anchor has been removed?

Environment
Please provide the following information about your environment:

Development OS: Mac
Device OS & Version: iOS 11.4, 12.0 beta
Version: ViroReact 2.10.0 and React Native 0.55.4
Device(s): iPhone X, iPhone 7

Description

Is there a chance to get notified when an image anchor has been removed or is not in the view anymore? I tried the onAnchorRemoved function but had no luck. The function is never called.
onAnchorUpdated is called for image anchors even if the anchor hasn't moved what leads to a jittering effect. Is that a problem with viro-react or ARKit 1.5 itself?
When using image anchors only the corresponding methods like onAnchorFound/Updated/Removed pass the anchor. Is this cases the anchorType (anchor.type) is "anchor" instead of "image".
When using multiple image markers: Is it possible to find out which one was detected when onAnchorFound has been called?

Thanks
Moe

Hi,

onAnchorRemoved() should be called when the anchor is removed by the underlying system, but it won't get called when a image is simply "out of view". We don't currently have a good way to detect that.
onAnchorUpdated() is invoked/called by the underlying AR system (ARKit). Over time, it does make minute changes to the position/rotation either because the image itself moves or ARKit has a better estimation of the user's own position/rotation and so the position/rotation of the anchor needs to be updated.
That's an interesting find. Are you using the onAnchorFound|Updated|Removed on the ViroARScene or on the ViroARImageMarker components themselves? We'll have to investigate this one more.
In this case, I'd attach an onAnchorFound to the ViroARImageMarker component and from that, you know which one has been found.

Thanks for trying out Viro!

Hi,
do you have any ideas on how to detect whether an image marker is out of view? I'm trying to improve the ar precision by using a mixed marker vs. plane model where objects will bind to a plane in case the marker is currently out of view.
Thanks
Moe

Hi @oOMoeOo,
There's not a great way to do this as the AR subsystem doesn't let us know when the marker is no longer "visible". However, what you could do is compute the angle between the camera forward and the last known position of the image marker relative to the camera. If that's greater than say 45 degrees, then most likely the image marker is no longer in the viewport of the camera (as the camera FOV is likely less than that). The FOV of the camera would be per-device dependent if you'd like to be more accurate in your computation (vertical FOV can be different than the horizontal FOV too).

@achuvm Well, i'm wondering why neither arkit nor arcore provide this function. I think it shouldn't be so complicated to determine it in the underlying arkit/scenekit implementation :-)
We're developing an app that requires the user to draw shapes precisely using ar. We need the shape to be in place with a precision of 0-2mm even if the user moves around. This is not possible with plane detection only. That's why we provide the user with multiple image anchors that have to be placed on a surface with fixed distances. We then try to bind the shape to the anchor that is currently in the view (using the difference vector between two related anchors). This is where we need to determine the anchor to view relation. Isn't it just the same as testing if a geometry is in the view?
The idea of tracking the camera angle sounds good but it doesn't take the distance and position of the camera into account. Is there any chance to determine the FOV?

Hi @oOMoeOo,
Yeah, that's a good point. You can try asking for a feature request :).
Yep, that's similar to testing if a geometry is in view. You can get the distance/position of the camera through the getCameraOrientationAsync() function on the ViroARScene component. We don't expose this information to the end-user right now. We might expose it in a future update or have a better way to determine if a geometry is in the viewport.
Thanks,

It seems it is now possible to determine in ARCore whether an image marker is currently detected in view or just tracked based on the last known location in the environment by using getTrackingMethod(). Is this already available in ViroReact? I can't find anything in the documentation. Is this planned for upcoming releases? This would be very helpful in our project.
Here are two links where this is mentioned:
https://developers.google.com/ar/develop/java/augmented-images#capabilities

Beginning with ARCore 1.9, you can use getTrackingMethod() to determine whether ARCore is currently tracking the image based on where the image is currently being detected in the camera view (FULL_TRACKING), or based on its most recently detected position in the world (LAST_KNOWN_POSE).

https://developers.google.com/ar/develop/java/augmented-images/guide#supporting_different_use_cases

When ARCore detects an Augmented Image, it creates a Trackable for that Augmented Image and sets TrackingState to TRACKING and TrackingMethod to FULL_TRACKING. When the tracked image moves out of camera view, ARCore changes the TrackingMethod to LAST_KNOWN_POSE while continuing to provide the orientation and position of the image.

Hey @pgims, as @achuvm mentioned in #682, we'll be exposing tracking methods in the next release.


SSL: CERTIFICATE_VERIFY_FAILED

Hey,
I'm getting:
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1007)>
In the lines:
imp = Volatility(ticker='^SPX', start_date='2024-7-4', wait=1, monthlies=True, q=0.013)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/volvisualizer/volatility.py", line 93, in __init__
    params = Utils.init_params(inputs)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/volvisualizer/utils.py", line 41, in init_params
    cls.set_interest_rate(params=params)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/volvisualizer/utils.py", line 96, in set_interest_rate
    params['yield_curve'] = DataPrep.generate_yield_curve(r=r)
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/volvisualizer/market_data_prep.py", line 731, in generate_yield_curve
    data = pd.read_html(url)[0]

Hi,
I couldn't replicate your error message but there were a few requirement issues that needed fixing (matplotlib 3.5.3 not compatible with numpy 2 and dependency on yFinance was not included). I've just pushed a new version 1.1.13 and installed that as per the instructions on the README and that ran without issue.


Can't embed video

Trying to embed a youtube video but I can't seem to get it to work when using ParsedownExtra. When using the HTML (embed html from YouTube), I'm getting:
DOMDocument::loadHTML(): Empty string supplied as input
I've also tried embedding using markdown but that doesn't produce the video at all. I'm fine using HTML to do it if there's a way to get around the error above.

Sometimes you need to strictly add two line break before and after the HTML block elements.


Fix specification of clusters/{clusterId}/rules/{ruleId}/report parameters

Description
Change on openapi specification, adding description and example for parameters for the clusters/{clusterId}/rules/{ruleId}/report endpoint.
Fixes #112 and fixes #117
Type of change

Documentation update

Testing steps
Regular CI

Codecov Report

Merging #177 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #177   +/-   ##
=======================================
  Coverage   49.28%   49.28%
=======================================
  Files          12       12
  Lines        1051     1051
=======================================
  Hits          518      518
  Misses        474      474
  Partials       59       59

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 5a11474...cffb3f0. Read the comment docs.


autogenerated LinkLocalIPv6Address can create two containers with the same ipv6 address

When I create containers without specifying any ip or mac address, ipv4, mac address and ipv6 are autogenerated (at least since version 1.5 for ipv6).
It looks like ip v4 and mac address can't conflicts, but you can generate two containers with the same ip v6:
Context

start docker daemon (because it will restart the auto assignation of ips to <IP_ADDRESS>)
create 17 containers
create a container "test1"
create 238 other useless containers
create a container "test2"

Expected results based on how ipv6 affectation seems to work in spirit

name
IPv4
mac
IPv6

test1
<IP_ADDRESS>
02:42:ac:11:00:12
fe80::42:acff:fe11:12

test2
<IP_ADDRESS>
02:42:ac:11:01:02
fe80::42:acff:fe11:102

Actual results

name
IPv4
mac
IPv6

test1
<IP_ADDRESS>
02:42:ac:11:00:12
fe80::42:acff:fe11:12

test2
<IP_ADDRESS>
02:42:ac:11:01:02
fe80::42:acff:fe11:12

Problem
It seems to me that the problem lies in #8947 in the file daemon/networkdriver/bridge/driver.go with the line:
return fmt.Sprintf("fe80::%x%x:%xff:fe%x:%x%x/64", hw[0], hw[1], hw[2], hw[3], hw[4], hw[5]), nil

which should look like (in spirit, I don't do go):
return fmt.Sprintf("fe80::%x:%x:%x:%x/64", hw[0]*0x100+hw[1], hw[2]*0x100+0xff, 0xfe*0x100+hw[3], hw[4]*0x100+hw[5]), nil

As I never wrote a line of go, I won't create a PR: I prefer to have someone who know what he's doing to do it.

Hi!
If you are reporting a new issue, PLEASE make sure that does not have any duplicates already open.
We would like to take this time to remind you of the information we need to debug the problem you are seeing. This is an automated response so if this ticket is not about a bug, do not fret.
If you fail to provide this information within 7 days, we will close this because we cannot debug your issue. We can reopen whenever the information is provided.
Thank you.
Please see:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues
Description of problem:

`docker version`:

`docker info`:

`uname -a`:

Environment details (AWS, VirtualBox, physical, etc.):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual Results:

Expected Results:

Additional info:

#ENEEDMOREINFO

Thanks for reporting this, and researching! As you might know, networking will get a major overhaul in Docker 1.7 with the integration of libnetwork. However, we're not there yet, so I'll include people from both "old" and "new" (libnetwork) here.
ping @MalteJ @mrjana @LK4D4

@gissehel thank you very much for your great work!
With your analysis I could write a fix really fast. I have opened a Pull Request.
BTW: Your code was quite good - it just has raised a type mismatch error. The hw array holds bytes (8 Bit) that cannot be multiplied with 0x100 (> 8 Bits), so I have had to cast the hw entities to int. Apart from that your code proposal is working. You really should write some Go code and contribute to Docker :wink:
Thanks!

As explained by @mrjana in https://github.com/docker/docker/pull/13226#issuecomment-106859731, link local IPv6 generation is now left to linux (libnetwork will just construct the MAC from the IPv4) and this issue no longer exists in current docker (at least since 1.7).
See o/p from latest docker:
$ ./docker run --rm --net nw2 --ip <IP_ADDRESS> busybox ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:12:01:02
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::42:acff:fe12:102/64 Scope:Link    <===
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:180 (180.0 B)  TX bytes:168 (168.0 B)

Therefore I am suggesting to close this issue.
ping @thaJeztah

Thanks @aboch, I'll close this issue, but @gissehel feel free to comment after I've closed :+1:


Add /-/healthy endpoint to Querier

Changes
Add /-/healthy endpoint to Querier.
For a related discussion on this change, you can find a similar discussion on the Prometheus Push Gateway repository.
This endpoint implementation is naive and in the future, we could maybe add verification of gRPC peers or anything else.
Verification

*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 10902 (#0)
> GET /-/healthy HTTP/1.1
> Host: <IP_ADDRESS>:10902
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 12 Oct 2018 11:26:48 GMT
< Content-Length: 19
< Content-Type: text/plain; charset=utf-8
<
Thanos is Healthy.
* Connection #0 to host <IP_ADDRESS> left intact

Perhaps with this the example Kubernetes deployment in kube/manifests/* should also be updated to include this new liveness probe: https://github.com/improbable-eng/thanos/blob/master/kube/manifests/thanos-query.yaml ?

You're absolutely right ! I'll add it tomorrow 😄 !


Changed required minimum intervals in cold start message

Description
Required minimum intervals to finish cold start is related to shingle size. This PR adds the shingle size in the computation and puts the result in the cold start message.
Testing done:

verified changing shingle size will change the message.

Signed-off-by: Kaituo Li<EMAIL_ADDRESS>Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.
[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Are we ignoring any interpolation for now with this message?

Are we ignoring any interpolation for now with this message?

yeah. So far we didn't do interpolation in HCAD. We only did it in single stream AD.


Update ci f32

Maintainers will complete the following section

[ ] Commit messages are descriptive enough
[ ] Code coverage from testing does not decrease and new code is covered
[ ] JSON/YAML configuration changes are updated in the relevant schema
[ ] Changes to metadata also update the documentation for the metadata
[ ] Pull request has a link to an osbs-docs PR for user documentation updates
[ ] New feature can be disabled from a configuration file

Coverage remained the same at 97.186% when pulling f72857e5b5ad6b7881ce78b57be30dd39a8eda2d on update-ci-f32 into 385988ccba637181ae3fc2b4edf0182b5044e700 on master.


replace ifndef guards with pragma once

Closes #243.

Oh, whoops. Looks like #271  does the same thing and was submitted yesterday. I checked the issues, but not the outstanding PRs when I started working on this.

No worries. Feel free to create the pull request. I'm still getting myself used to the code.

@ianklatzco and @jacwil both PRs are closed. Should I re-open one of them?

Looks like we both missed some ifndef guards. I've incorporated jacwil's changes into this PR.


Distributing typing information (#127)

Summary by CodeRabbit

New Features

Introduced new data aggregation functions for enhanced data processing.
Added configuration classes for managing predicates and temporal windows.
New utility functions for logging and time parsing.

Bug Fixes

Updated function signatures for clarity and simplicity.

Documentation

Enhanced documentation for new functions and classes to improve usability.

Should typing information be included inline and also with these stubs @mmcdermott?

Should typing information be included inline and also with these stubs @mmcdermott?

Yes, I think so, but google around or check the google style guide to see if there are other recommendations in the community.

@justin13601 can we merge or close this? Not sure which would be more appropriate, but I'd like to get it closed out rather than remaining indefinitely open. Thanks!

@justin13601 can we merge or close this? Not sure which would be more appropriate, but I'd like to get it closed out rather than remaining indefinitely open. Thanks!

Yep will try to merge this weekend!


occupations property should be array of occupation-ids

Similar to event-kind or role, the occupations property of an person entity should just return occupation ids (vocabulary entry id) instead of serializing the vocabulary entry for each occupation.

similarly, person.gender should only return ids, not full objects.


New architecture

Describe the Feature
With the upcoming new architecture of react native, it would be nice to start moving the packages over to the new arch. I couldn't find any references to new arch for this package, which is why i'm opening the issue
Possible Implementations
Implementing the steps under https://reactnative.dev/docs/next/new-architecture-library-intro

@Naturalclar I have attempted to implement the turbo modules but I have had great difficulty upgrading the package to react native versions >0.69.

looks like there's a PR on this

I have resolved this already without the need for third party lib, check this https://www.youtube.com/watch?v=MUMctNguavc and https://github.com/BraveEvidence/ReactNativeNewArchCopyToClipboard2023


Resolve Slow First Load

Appreciate your work on this project, using it in numerous Laravel projects myself.
However, I've found myself running a local fork of the project which contains the changes in this PR as I had noticed, at least on the machines I develop with (Windows) there appears to be an issue with the load times when building the Blade template / HTML. On average the load time is around 6~ seconds but in some cases has taken well over 10 seconds for the initial page load.
With regards to the changes -
I noticed an unused variable existed that looked like the intention was to cache the result of the 'isDevelopmentServerRunning' result, so I've gone and implemented this which reduces the 6-10 second load times I was experiencing down to 2~ seconds, as each load calls the 'isDevelopmentServerRunning' function at least 3 times.
However, I looked further into why the request was still taking 2-3~ seconds to initially load and had narrowed it down to the fsockopen call. Doing a bit of research seems to suggest that this call does not use any cached DNS responses from the OS but instead makes a DNS request to the nameserver each time it is called. Swapping to using 'gethostbyname' to resolve the hostname prior to the fsockopen function bought the initial function call time down from >2s to <100ms.
Both changes bring the page load time on the current project I'm working on down from 7s to 800-900ms on average.

Looks good, looks like the mock server in tests doesn't work anymore though. You're right about the cache variable (how did I miss that), but I was thinking about using the Http client from Laravel in the next version. That would clean up tests as well. Have you tried it?

Let's do like this for now and I'll update tests properly in https://github.com/innocenzi/laravel-vite/pull/176, thanks!


Update Core Language guide to Elm 0.16.0

Hi,
The REPL in its latest version now displays Type Annotations. Following POLA applied to documentation, it seems reasonable updating the main guide accordingly.
It sure does "clutter" the output a little in the guide, but having an inconsistent output in the REPL when compared with the guide is most likely going to confuse a lot of newcomers. To prevent that from happening, one could think of adding a sentence or a paragraph about Type Annotations, for example after the first round of examples (String values)--I did not, SoC :package: :package: applies.

If you split this into two PRs we can do one now. It makes sense to change the REPL header now, no problem there.
But I specifically decided not to show types, and put a message explaining this. I am not convinced that the real solution is not "make that notice more obvious".

Oh, I completely overlooked this message and went straight for "We will cover…". My face's beet-red!
Well, I'll push another PR for the header, so I'm going to close that one.

No worries, you found a problem in the docs! :)
My interpretation is: as is, it is pretty easy to miss the note about leaving the type annotations off.
So I feel like my preference would be one of the following:
** The REPL will print out the type of the result, but for the sake of introducing concepts gradually, we will leave them out in the REPL examples in this section.**
Note: The REPL will print out the type of the result, but for the sake of introducing concepts gradually, we will leave them out in the REPL examples in this section.

Note: The REPL will print out the type of the result, but for the sake of introducing concepts gradually, we will leave them out in the REPL examples in this section.

Not sure which would make it more noticeable. Seems likely that folks would do some skimming there, so it'd be good if it grabbed the attention of skimmers.

How about this one?
The REPL prints out the type of every result, but we will leave the type annotations off in this tutorial for the sake of introducing concepts gradually.

What happened, is my eyes got caught by the header inconsistency (0.15 vs 0.16), I alt-tabbed to note I should make a PR about that, then resumed scanning through the tutorial and unwillingly skipped the sentence about types. Meaning it may just have been me not paying attention, rather than the note being easy to miss.
Anyway. I too feel like adding some kind of emphasis to this part of the header could prove valuable.
It stands out, but does not gets in the way.

Do you mind doing a PR? I'll push these things to the site once we get both of these :)

Sure.


Add travis support, and basic testing.

This should actually fail because on an error in the parser.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Does GCP charges for cold start time?

I was wondering if GCP charges for the time the container is cold starting.

That's a good question.
You're not charged during the duration while the infrastructure is getting warmed up.
But you are charged while your container is started (and not yet listening on the port number). So if your app is slow to start the HTTP server, you're actually charged for that period.
This is actually clear in the docs (https://cloud.google.com/run/pricing):

Thanks for the fast answer, Ahmet!


update monaco.d.ts

update monaco.d.ts to add IActionDescriptor.precondition desc
when developer use action and find document, they don't  understand the IActionDescriptor.precondition  what  how to defind and use。the  desc 'Precondition rule' , it's confusing 。

could you tell me how to fix Code OSS error ？ @hediet

The monaco.d.ts file is auto-generated. Please fix this at the source.

I get .


sf::Music::openFromStream and sf::SoundBuffer::loadFromStream fails for non-flac files

Loading Music or SoundBuffer through an InputStream fails, but loading straight from the file with openFromFile/loadFromFile succeeds.
Code which recreates (orchestral.ogg from examples)
#include <SFML/Audio.hpp>
#include <SFML/System/FileInputStream.hpp>
#include <iostream>

int main() {
    std::cout << "Starting..." << std::endl;
    sf::Music fileMusic;
    if (!fileMusic.openFromFile("orchestral.ogg")) {
        std::cerr << "Too early boom?"  << std::endl;
        return 3;
    }

    sf::FileInputStream stream;
    sf::Music music;
    if (!stream.open("orchestral.ogg")) {
        std::cerr << "Too early boom?"  << std::endl;
        return 2;
    }
    if (!music.openFromStream(stream)) {
        std::cerr << "BOOM!"  << std::endl;
        return 1;
    }
    std::cout << "Done" << std::endl;
    return 0;
}

Is there any reason you "reimplemented" sf::FileStream? Did you ensure the problem isn't caused by the copied code?

The discussion is still pending on the forum, this issue will be reopened when things are confirmed.
By the way, SoundEffect doesn't exist, did you mean SoundBuffer?

It's indeed an issue with SFML. The SoundFileFactory.cpp is missing stream.seek(0);. Also the comment should get updated, since when working with a stream there are not "filenames". :wink:
The above example should read as follows, since sf::Music uses the stream.
#include <SFML/Audio.hpp>
#include <SFML/System/FileInputStream.hpp>
#include <iostream>
#include <cstdio>

int main() {
    std::cout << "Starting..." << std::endl;
    sf::Music fileMusic;
    if (!fileMusic.openFromFile("orchestral.ogg")) {
        std::cerr << "Too early boom?"  << std::endl;
        return 3;
    }

    sf::FileInputStream stream;
    sf::Music music;
    if (!stream.open("orchestral.ogg")) {
        std::cerr << "Too early boom?"  << std::endl;
        return 2;
    }
    if (!music.openFromStream(stream)) {
        std::cerr << "BOOM!"  << std::endl;
        return 1;
    }
    std::cout << "Done" << std::endl;
}

Superseded by #823


ncp_spi: Updates and fixes

This change contains changes to both ncp_spi.* and
spi-hdlc-adapter.c, based on experience with using both on actual
hardware. These changes fix a handful of critical bugs and also adds a
work-around (--spi-align-allowance) for naughty SPI-slave hardware.

LGTM :+1:

LGTM :+1:

LGTM 👍


Validating Webhook accountquotas.config.kiosk.sh

AccountQuota needs a validating webhook to check for the following things:

Create/Update:

Ensure valid resource list (currently you can specify invalid resources), basically do the same checks as ResourceQuota is doing

Create:

Account exists?

Is this issue still available? @FabianKramm ?

@rahulchheda yes this is still available, currently the check if the specified resources are valid is still missing, would be great if you would open a pr for this!

@FabianKramm , can you add context to this issue also, so I can take this up aswell?

@rahulchheda sure, in essence this issue is similar to #2, however this time we want to validate the AccountQuota resources (spec.quota). We want to do the exact same checks as kubernetes does for ResourceQuota spec, hence I think the best way is to reuse most of the validation kubernetes does for this type (corev1.ResourceQuotaSpec) if possible, you can take a look how kubernetes does it here: https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/validation/validation.go#L5339 .
I think the best idea would be to copy over the relevant code from them (because we do not want github.com/kubernetes/kubernetes as a dependency, see https://github.com/kubernetes/kubernetes/issues/80339#issuecomment-513293370 for more details) and change their internal *core.ResourceQuotaSpec type to the one we use *corev1.ResourceQuotaSpec.


[Q] Change URL at runtime?

The console sink (and others?) can be reconfigured at runtime by changing appsettings.json (assuming one is using json-based config).
A Seq sink is configured (in code) like so:
.WriteTo.Seq(SEQ_URL)

Can one change the URL at runtime, when configuration is performed in code?
(I assume the change logic exists, but am unsure whether it applies to this sink and whether it applies to the URL.)

Hi! I think reload support in Serilog.Settings.Configuration is limited to a handful of settings such as MinimumLevel. Changing the Seq URL won't result in a reload by default.
Check out ReloadableLogger from Serilog.Extensions.Hosting for a workable approach (you'll need to reload it on config changes):
https://github.com/serilog/serilog-extensions-hosting/blob/dev/src/Serilog.Extensions.Hosting/Extensions/Hosting/ReloadableLogger.cs
HTH,
Nick


Not using installed extensions

We have written the needed data into your clipboard because it was too large to send. Please paste.

 My family needs money for surgery, so I want to learn in Iran, because I do not like Iran. Please help me.

 My family needs money for surgery, so I want to learn in Iran, because I do not like Iran. Please help me.


KAFKA-17322: Document required header versions in Protocol Guide

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

I ran the tests locally and they ran successfully.


Support for Integer and Float Literals Added to Majestik Grammar and Compiler

Summary by CodeRabbit

New Features

Added support for integer, float, and number literal types.
Expanded runtime and compiler capabilities to handle new literal types.

Bug Fixes

Improved number parsing and conversions for Long and Double types.

Tests

Added tests for parsing long and double numbers.

Refactor

Enhanced code readability and maintainability through minor control flow adjustments and code commenting updates.

@coderabbitai full review


Book Changes

-updated the descriptions of the portal spells to reflect the new costs, and made them more clear-cut
-corrected the argument lists of a couple spells

The only problem I can see in this is that corrects portalhexaddon:setportalsides's "input": "entity (Portal), num, num", which is meant to have 2 nums, but I can fix this. And after this merge, Hex Ways 0.7 will be able to be released


cache permission keys

I guess there's a reason why ExpensiveCache isn't used that much in the core, but when profiling the loadAll method was consuming 7.06% of the time to render a page. When measuring I was able to improve performance by slightly less than 3%
part of #3287

Pretty sure it's because if you add a new permission key or remove a permission key, the cache isn't cleared. The CacheLocal is a RequestCache so it's looking those up every request (and thus is probably why we bother clearing the cache on adds/deletes). Ideally we could put this on the expensive cache but I think we need to be cautious that we're not overzealous about caching those permission keys and not clearing the cache when appropriate.

@joe-meyer you're of course right! We should be careful about clearing the cache, but I currently don't see how 5.7 could be improved to get to a reasonable performance without this approach. I'd be happy to hear counter-arguments.

@Remo I'm not opposed to moving things to the cache where it makes sense (and for a net gain of 4% performance improvement I'd be pretty difficult for me to argue against this one). With your latest commit this looks much better to me. :+1:

I'm all for experimenting with this – I think it's finding a balance between 5.5/5.6.0 where EVERYTHING was in the object cache and the filesystem file size was out of control and purging the cache took ages – and the current idea of pushing everything into the request cache. There are definite tradeoffs. Plus when we reimplemented the expensive cache in stash we were scared of it and I think that's why it's not used very much.
I could definitely see it being used more for things like this – things that change little, and that you can store in a large lump (the permission keys, for example.)
 We have to be careful about clearing, but that's pretty much it, isn't it?

Something else to consider about the expensive cache is it ends up on disk in the application. I know of at least a couple instances where hosts use SSD's for their databases but leave their user/web directories on Hard Drives. This means in potential cases where you might actually have better performance by not caching some things to the application disk.
Originally when we rolled out the Stash cache, we created 3 levels of caching, this is my recollection of what was made and their purposes:

cache - An object cache, which by was meant to store lower level data makes sense to cache if it can go to memory (or maybe even to disk if you're using SSDs), but when going to slower disks can actually harm performance, Ideally the thought was that this was meant to be persistent across requests via something like redis (Although I think we may have some persistent caching issues when we do this and probably need to really get those moved to cache/request, but it's been awhile since I've toyed with it)
cache/request - An ephemeral cache, meant to store objects in memory across the request, usually involving something request specific (otherwise it probably belongs in the object cache instead)
cache/expensive - This was intended for things that have a large performance benefit by going to a slow cache, generally speaking disk (but it could even be something like an NFS share or other that uses a local network share to link up several web server's application caches). I think this was originally intended for things like images, blocks, compiled css, etc that take a decent amount of compute power to rebuild. The other thing as @aembler is that we can certainly use up a LOT of space by dumping a lot of things here. Generally speaking disk is cheap, but when we're talking a 1% performance gain, it might be better to put something into an object cache so that people can configure it to save to disk if they can spare it, or leave it as ephemeral if not.

I don't think I/O is the main issue here. When I profiled this most of the time was consumed by the CPU, lots of small things, class methods, string functions etc. cache/request was already in place by using CacheLocal. The improvement showed up after running further calls.
I disagree that we should ignore this if it was only about 1%. For one it was almost 3% in my case and if we find a few more cases like that we might get an improvement of 3,5,10 percent or more. I don't know about you guys, but to me 5.7 is definitely too slow.


Luis schema version incompatibility

Proposed changes:

Fixes #1790
Allow Rasa to be trained by Luis schema with version higher than 4.
Showing a warning instead of throwing an exeption.

Status (please check what you already did):

[X] made PR ready for code review
[ ] added some tests for the functionality
[ ] updated the documentation
[X] updated the changelog
[X] reformat files using black (please check Readme for instructions)

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

Thanks for the PR, we'll give it a review as soon as possible.

Thanks for the PR @LucasPenido
Since you only changed the warning it seems as though the LUIS reader was actually able to read LUIS schema up to version 4 all along. Could you please share how you verified this?

Hi @imLew
I compared all jsons up to version 4 and confirmed that they have the same structure, so I can carantee that until version 4 RASA will train with no errors, after this version a warning will aware the user.

@imLew After your merge Travis failed, could you rebuild?

@imLew You have to merge, I think @LucasPenido does not have the permissions to do so

@imLew @LucasPenido How about adding luis v4 file into data/examples/luis and writing a test for it?

Since all that was left to do was the changelog entry and I could not push to the fork: I created a new PR that does this #4890.


Run minio-py tests from minio-py repo

After https://github.com/minio/minio-py/pull/547 is merged,

Remove local copy of minio-py functional tests.
Change the mint build process to pull tests from minio-py SDK (https://github.com/minio/minio-py) and execute those tests.

PR: #80

Fixed by #80


Run phpcs fixer for all files

master branch doesn't seem to be up to date with the codestyle.
That's why #359 is failing

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.

Project coverage is 95.91%. Comparing base (7de9ce4) to head (26dd1d8).
Report is 5 commits behind head on master.

Files with missing lines
Patch %
Lines

...ExternalRedirect/AllowListBasedTargetValidator.php
0.00%
1 Missing :warning:

src/Twig/Node/CSPNode.php
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master     #360   +/-   ##
=========================================
  Coverage     95.90%   95.91%
- Complexity      443      444    +1
=========================================
  Files            53       53
  Lines          1979     1982    +3
=========================================
+ Hits           1898     1901    +3
  Misses           81       81

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

okay, since main is running now with the current twig version I have a hen and egg problem:
need the codestyle to be fixed to merge #359
need the fix in #359 to merge this. Combining the PRs now


Fixes for -enable-experimental-associated-type-inference

We want to enable this by default since it unblocks some other work that's happening. The stdlib still doesn't build with this flag enabled, but it gets further with the fixes in this PR.

@swift-ci Please test

Superseded by https://github.com/apple/swift/pull/70311


New package: MOR v1.0.0-DEV

Registering package: MOR
Repository: https://github.com/fbelik/MOR.jl
Created by: @fbelik
Version: v1.0.0-DEV
Commit: c79ad393138b572d556c2c772de917c6078edfb9
Git reference: HEAD

ModelOrderReductionTools would be a perfectly fine name. Also, please make sure to add some documentation before registering (at least in the README).

I see, I will look into a different name and make sure to look through the general registry README and auto-merge guidelines.


Metrics generator

Description
This pr adds an microservice, collecting non-personal information.
It executes on cluster start and once every 24 hours (at midnight)

Codecov Report

Merging #1523 (0b1662f) into main (a334a53) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main    #1523   +/-   ##
=======================================
  Coverage   11.11%   11.11%
=======================================
  Files          31       31
  Lines        9839     9839
=======================================
  Hits         1094     1094
  Misses       8687     8687
  Partials       58       58

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

consider merging onto 0.9.12-prerelease1 instead of main?


Seaching where has this function called does run slowly

Seaching where has this function called does run slowly

Thanks for the report. Are you referring to find all references? or call hierarchy?
The first time you ask for "find all references" it would be slow, is it always slow?
thanks

"find all references" always takes five seconds at least.And the status bar is being loading "finding reference" when i refind all references without terminate previous unfinished load.

and the process Electron has not terminated after i close the vscode for a long time when i use macbook.

how big is your workspace?

by the way, can you use this template https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue to add more info on your issue so that we can have at least some logs ("python.analysis.logLevel": "Trace") to see what is going on while "find all references" are running?

Thanks a lot. I have figured out that there is too many files in the workspace, include history plugin files and pycache that may be analysed,i have no idea. Fortunately, i can find references quickly in a empty folder.


Add support for API key configuration in LiteLLM

🚀 The feature
Allow the LiteLLM integration to use an API key specified in the configuration object instead of requiring it to be set as an environment variable.
Motivation, pitch
Right now, the LiteLLM integration only allows setting the API key through environment variables, which isn't always the most convenient option. By allowing the API key to be specified directly in the configuration object (self.config.api_key), we make it easier for developers to manage their API keys within their application’s settings.

Yes @Dev-Khant, working on closing out this issue with #1747

Yes @Dev-Khant, working on closing out this issue with #1747

Sounds good, I have left a comment there. Please have a look.

Hi @Dev-Khant, are you still working on this?

Tried to generate required changes using potpie for this change for the next contributor to pick this up easily: https://app.potpie.ai/chat/019344ed-8b64-708d-8c8b-afa3877a92e7


🩳🧙 fix nml_mat_col_swap_r validation check

I changed the validation check inside the columns swap function. It was comparing col2 against the number of rows of the matrix, when i believe it should be comparing against the number of columns.
P.S. Loved the tutorial you made about this library :)

@arthursfares thank you for your contribution. Cheers!


Multisig. Empty filter for Delegate operation type

Description

Expected Behavior
Shows "Delegate" operation
Actual Behavior
Empty list
Environment
https://github.com/novasamatech/nova-spektr/commit/f7a2692393f448f894937ac31d2eb51284844ed6

Status verification: ✅


Usage with final-form

Can this library be used with final-form?

why not? We are using formik, all is fine.

Cool, could you please provide an example on how you are using it with formik? Thanks

Like any other component :-) something like this https://codesandbox.io/embed/mo9nwz599x?codemirror=1
(not my code publushed by @ctrlplusb)


[cdc] remove AST_EXT_CLK

The ast_ext_clk is stopped by PR #17012, so the ast_ext_clk won't appear as a clock domain outside of ast.

Thanks @cindychip. Is my understanding correct that

we constrained the CDC tool to not propagate AST_CLK_EXT out of AST (#17012) because outside AST the clock tree is the same independent of whether the on-chip or the external clock is used (#16897), and
this PR removes AST_EXT_CLK from CDC waivers because the CDC tool no longer considers that clock for the rules that are waived?

If so, this change LGTM.
I noticed that AST_EXT_CLK is also used in cdc_waivers.data.tcl and cdc_waivers.misc.tcl, should we remove it there as well?

Yes that is what i understand as well.
I have not clean up the other two blocks because we have some tool compile issue on my end. I could not test the other tcl files yet. So I wanted to create this PR first ;)
Sorry for the trouble.

Yes that is what i understand as well.
I have not clean up the other two blocks because we have some tool compile issue on my end. I could not test the other tcl files yet. So I wanted to create this PR first ;)
Sorry for the trouble.

Nice, thanks for the confirmation. I think you can merge this PR and change the other two files in a separate PR


Slave list shows nonexistent slave

For some reason, Singularity is currently showing me a slave which does not in fact exist in the cluster [1]. It has the same hostname as another slave, but a different ID, and possibly existed in the past, but no longer. Mesos itself does not show this slave [2].
It's not a UI bug, since /api/slaves is also showing 5 active slaves, when there are in fact 4.
I have not yet determined if this is impacting task placement.
[1] Singularity web UI slave list. The two with same hostname are circled, and the bogus slave ID is highlighted

[2] Mesos Web UI Slave List from the same cluster at the same time as the above singularity UI

I wonder if Mesos never delivered the framework message about this slave.
This the only case I can think of where it would continue to show it as active. If you restart Singularity, it should reconcile slave state with Mesos and move this slave to dead.
Alternatively, you can simply click to remove it in the UI.
Assuming there isn't a bug, which is possible, the only other action I can think of taking is to write a poller to reconcile state in the situation that Mesos does not deliver any updates about this slave.
Do you have logs from Singularity? Might be interesting to grep them for that ID.

We should probably have Singularity automatically reconcile every once in a while, or if it hasn't gotten an offer in some amount of time from a slave. That said, it will not impact new task placement. The task placement is done based on incoming offers. Since the slave was not active according to the master, there wouldn't be any offers coming in for it, so no new tasks would be scheduled there.

Can confirm, the issue looks to be largely cosmetic and doesn't affect task placement or other critical functionality.  It mostly just looks weird and sows distrust in administrators and users.


BUG issue on script bot.py

@AnandaRauf this is not necessarily a bug this is being cause by you likely providing an invalid boolean value in the config.cfg file if you're trying to set debug to true please user the following acceptable values [True/False]


Feature: Search with space

Hello!
When I searching "CTS1211" - everything is ok, but when I've searching "CTS1211 " (with space in the end), I'm getting no result. Can you fix it, please?

Yes, I should fix this soon. Thanks for your help.


[plugins] Injecting a dependency and source code into a top-level module

Hi! I'm trying to accomplish something a little weird with a webpack plugin and I think it should be possible, I'm just not sure how with webpack's internals.
I have multiple entry points that become named chunks. For each chunk, I want to take the top-level module and inject a dependency into it, and also add source code to the front of the module to execute the dependency's code. There's nothing special about the dependency; it's just a file on the filesystem, and it's also used in some other modules.
So my question is - what hooks do I need to plug into? At the moment i'm trying to use "optimize-chunks", and then check if the chunk has a name and an origin. If it does, I feed the Compilation object a dependency I made up with addModuleDependencies:
MyPlugin.prototype.apply = function(compiler) {
    compiler.plugin('compilation', function( compilation, params ) {

        compilation.plugin('optimize-chunks', function( chunks ) {
            chunks.forEach( function ( chunk ) {
                if ( chunk.origins.length === 0 ) {
                    return;
                }

                var chunkOrigin = chunk.origins[ 0 ];

                if ( chunkOrigin.name ) {
                    compilation.addModuleDependencies(
                        chunkOrigin,
                        [ [ {
                            module: null,
                            request: 'owen/user-timing',
                            userRequest: 'owen/user-timing',
                            optional: false
                        } ] ]
                    );
                }
            } );
        });
    });
};

This is pretty clearly wrong since it doesn't work but I haven't been able to find the right point at which I can get into where Webpack figures out what files are being resolved. A pointer to the right line would be awesome.
Thanks!

What's the use case for this?
Run some code before each chunk?

@sokra Yes, pretty much, but we also want to run some code after the contents of the top chunk. I have a lot of chunks and would like to emit analytics data to our servers about the performance of each chunk.

@TheLarkInn This is related to analytics so you might want to have a good look.


Not able to detect k8s metadata with containerd

Describe the bug
We switched our kubernetes clusters from docker to containerd. After we are not able to see kubernetes metadatas at all in falco events.
After (with docker):

Before (with containerd):

How to reproduce it
Install kubernetes cluster with manifests https://gist.github.com/zetaab/e134a6dbb80de296909a6d7ed34c3232
Expected behaviour
We expect that we could see kubernetes metadatas in events like it did work with docker.
Screenshots

Environment
Kubernetes cluster installed with kOps running in OpenStack / AWS

Falco version: 0.27.0

System info:

# falco --support | jq .system_info
{
  "machine": "x86_64",
  "nodename": "nodes-esptnl-rzkxpp",
  "release": "4.19.0-13-cloud-amd64",
  "sysname": "Linux",
  "version": "#1 SMP Debian 4.19.160-2 (2020-11-28)"
}

Cloud provider or hardware configuration: openstack / aws
OS: debian buster
Kernel: 4.19.0-13-cloud-amd64
Installation method: kubernetes

Additional context
falco kubernetes installation manifests https://gist.github.com/zetaab/e134a6dbb80de296909a6d7ed34c3232

@zetaab How do you generate those events?  It looks like the event from containerd 's container ID is host, while the event from docker 's container id is 8e5d05fd15d0.  That may explain why you don't see k8s metadata in the containerd one.

We ran the Falco event-generator the check if this issue is related to some type of rules, but unfortunately metadata is missing all the time.
If you can't reproduce the issue on GKE, then an important detail might be that as we are running Debian Buster nodes in the cluster.

Falco fetches container metadata by connecting to the container runtime (e.g., containerd).
If the container metadata is missing all the time, it's likely to be a configuration issue. Basically, that happens when Falco is not able to talk with the container runtime.
Otherwise, if it's an intermittent problem (sometimes the metadata are present, sometimes are missing), there may be several different causes. And ofc, this scenario is harder to debug.
In which scenario are you?

We are missing the metadata all the time.
As you can see from the gist provided in the issue, we have already check & tried the common problems. HOST_ROOT env variable is not an issue and neither is the async fetching, as toggling it on & off does not make a difference.
Are there any other details that you might need? We are running containerd v1.4.3.

Not sure if run grpcurl in falco container can help to find out more on what happened in the environment.  This is what I got in my GKE cluster.  They both look ok.
# ./grpcurl -plaintext -proto cri.proto -unix /host/run/containerd/containerd.sock runtime.v1alpha2.RuntimeService/Version
{
  "version": "0.1.0",
  "runtimeName": "containerd",
  "runtimeVersion": "1.4.1",
  "runtimeApiVersion": "v1alpha2"
}

# ./grpcurl -plaintext -proto cri.proto -unix /host/run/containerd/containerd.sock runtime.v1alpha2.RuntimeService/ListContainers
{
  "containers": [
    {
......
    },
  ]
}

You can find grpcurl here and cri.proto here .  Let me know what you find.

# ./grpcurl -plaintext -proto cri.proto -unix /host/run/containerd/containerd.sock runtime.v1alpha2.RuntimeService/Version
{
  "version": "0.1.0",
  "runtimeName": "containerd",
  "runtimeVersion": "v1.4.3",
  "runtimeApiVersion": "v1alpha2"
}

ListContainers will return array of containers
one example:
    {
      "id": "49d849e6c07199f37fa13e28c61e3fe4dcc1a34c7e40cc208f1082b7c30c0e21",
      "podSandboxId": "d22d2e93f8fc61f06493e06543bcd776798211ad85ba4a9ba6465d3365d66c21",
      "metadata": {
        "name": "flexvol-driver"
      },
      "image": {
        "image": "sha256:819d15844f0c92a60060a544e0032ff5e5623db333e5f180164a7966578b387d"
      },
      "imageRef": "sha256:819d15844f0c92a60060a544e0032ff5e5623db333e5f180164a7966578b387d",
      "state": "CONTAINER_EXITED",
      "createdAt": "1614670171075076861",
      "labels": {
        "io.kubernetes.container.name": "flexvol-driver",
        "io.kubernetes.pod.name": "calico-node-95wmh",
        "io.kubernetes.pod.namespace": "kube-system",
        "io.kubernetes.pod.uid": "f767ceed-5edc-4ef0-b404-2de6d50c4146"
      },
      "annotations": {
        "io.kubernetes.container.hash": "ed6cf793",
        "io.kubernetes.container.restartCount": "0",
        "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
        "io.kubernetes.container.terminationMessagePolicy": "File",
        "io.kubernetes.pod.terminationGracePeriod": "0"
      }
    }

I tried on my GKE cluster + containerd with ebpf enable and I can see container id without problem.

@holyspectral out of curiosity, what's your installation method?

@leogr
I have falco built from master branch with sysdig dev branch.
The ebpf program is built from source and kernel header.

This is what I saw after I switch back to the latest release of falco...I can still see k8s metadata without problem.
Environment: GKE v1.18.12-gke.1210
Node: Ubuntu + containerd + ebpf enabled
Install method: helm install falco -f values.yaml falcosecurity/falco --set ebpf.enabled=true
After exec into falco pod, I can see events with k8s metadata.
21:09:12.710210602: Warning Shell history had been deleted or renamed (user=root user_loginuid=-1 type=openat command=bash fd.name=/root/.bash_history name=/root/.bash_history path=<NA> oldpath=<NA> k8s.ns=default k8s.pod=falco-9j5l4 container=eaf7822a6d6a) k8s.ns=default k8s.pod=falco-9j5l4 container=eaf7822a6d6a

Even after I upgrade containerd to 1.4.3, I still can't reproduce the issue.  At this point, I become not so sure that it's related to containerd...
@zetaab @ottosulin when you see the issue, is the container ID always host?  As far as I know, when libsinsp fails to resolve container id, it will fallback to host.   I can't say something is definitely wrong there, but having more information on what cgroup path falco detects would be very helpful.
Could you get into one of the containers and run cat /proc/self/cgroup and attach its output here?  Also, if you have access to one of falco rules, adding memcgrp=%thread.cgroup.memory in output field and seeing what falco prints will be helpful too.

Here are the cgroups from one falco-sidekick:
11:memory:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 10:blkio:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 9:cpuset:/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 8:freezer:/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 7:net_cls,net_prio:/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 6:pids:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 5:rdma:/ 4:perf_event:/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 3:devices:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 2:cpu,cpuacct:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 1:name=systemd:/system.slice/containerd.service/kubepods-burstable-pod72ce270c_cf79_40c9_aa90_2ccfd43302bd.slice:cri-containerd:1691d28c1de74c74c91f3c0611b4d4c9fb12458a0760451f513cf7b5f2a8fa21 0::/system.slice/containerd.service
… and the alert with additional information:
11:17:32.711544377: Warning Shell history had been deleted or renamed (memcgrp=/user.slice/user-1000.slice/session-381.scope user=<NA> user_loginuid=1000 type=openat command=bash fd.name=/home/debian/.bash_history name=/home/debian/.bash_history path=<NA> oldpath=<NA> k8s.ns=<NA> k8s.pod=<NA> container=host) k8s.ns=<NA> k8s.pod=<NA> container=host k8s.ns=<NA> k8s.pod=<NA> container=host
Are these what you were looking for?

Thanks @ottosulin !  I put the logic here to my local and it couldn't parse the cgroup path you provide.  That's probably why you can't see k8s metadata in your scenario.  Probably something to be addressed in https://github.com/falcosecurity/libs
From your cgroup format and code here, I think systemd is used as your containerd's cgroup driver?
https://github.com/containerd/cri/blob/release/1.4/pkg/server/helpers_unix.go#L66

kOPS is enabling systemd cgroups automatically if k8s >= 1.20: https://github.com/kubernetes/kops/blob/87fadb106a11399522ef70b02008508b076d4119/pkg/model/components/containerd.go#L65-L66
Now, according to Otto's logs, shouldn't the suffix be empty string instead of .scope for systemd containerd?
https://github.com/falcosecurity/libs/blob/f6754c1658abaadbcf616211ea68282f99a6566b/userspace/libsinsp/container_engine/cri.cpp#L51

that system cgroups for kops was added between kops 1.20 alpha and 1.20 beta 1. So we need verify first in which mode this instance is.

It seems that containerd systemd cgroups were added between kops 1.20 alpha 1 and 1.20 beta
this is the output from machine which do have containerd systemd cgroups:
/app $ cat /proc/self/cgroup
11:blkio:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
10:cpuset:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
9:devices:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
8:memory:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
7:perf_event:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
6:rdma:/
5:cpu,cpuacct:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
4:freezer:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
3:pids:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
2:net_cls,net_prio:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
1:name=systemd:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod42d4123d_ae8b_4941_aead_64741a830402.slice/cri-containerd-790a0254dc76bfdbc6e218d1d3303585376a65eca0e4fc36bf7b4b9aaad39706.scope
0::/system.slice/containerd.service

so .scope do exists there and actually now in this cluster we can see the k8s metadata. So the problem is if the containerd systemd cgroups are not used.
this does not exist in nodes that does not work:
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

not working containerd config:
root@nodes-helpa-hgah1q:~# cat /etc/containerd/config-kops.toml
version = 2

[plugins]

  [plugins."io.containerd.grpc.v1.cri"]

    [plugins."io.containerd.grpc.v1.cri".containerd]

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]

        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"

working
root@nodes-helpa-zj2t5t:/home/debian# cat /etc/containerd/config-kops.toml
version = 2

[plugins]

  [plugins."io.containerd.grpc.v1.cri"]

    [plugins."io.containerd.grpc.v1.cri".containerd]

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]

        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"

          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

so our way to fix this is to roll all machines in clusters.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Add gitignore to ignore WebStorm files

Not merged due to uncomitted .gitignore to fix merge conflict added later.


fix Not Found link

https://docs.scandit.com/data-capture-sdk/flutter/release-notes.html is Not Found

Hi,
You can find the latest release notes for Flutter here: https://docs.scandit.com/sdks/flutter/release-notes/
In case you have any additional questions, please reach out to<EMAIL_ADDRESS>to create a ticket.


Document new webhook max_alerts config field

See https://github.com/prometheus/alertmanager/pull/2274
Signed-off-by: Julius Volz<EMAIL_ADDRESS>

Can you define uint64 at the top?

@roidelapluie Done. FWIW we also have a bunch of int fields in the main Prometheus configuration at https://prometheus.io/docs/alerting/configuration/#configuration-file that we don't define at the top. But I haven't checked yet if they are all different types of ints, etc.


Add Black History Facts to Open Data

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is ordered alphabetically
[x] My submission has a useful description
[x] The description does not end with punctuation
[x] Each table column is padded with one space on either side
[x] I have searched the repository for any relevant issues or pull requests
[x] Any category I am creating has the minimum requirement of 3 items
[x] All changes have been squashed into a single commit

Please arrange your entry in the alphabetical order and don't forget to squash all the commits into a single one after doing so.
Thanks.


Feature Request: use managed identity for ACR pull

Is your feature request related to a problem? Please describe.
https://github.com/microsoft/azure-container-apps/issues/16#issuecomment-1017511067 @inuvano-labs
Describe alternatives you've considered.
Currently only supports username and password.

@anthonychu can we close?

To the best of my knowledge this is not supported.
Managed identities work on the container level, not sufficient for pulling from an ACR. Unless I'm misreading something & testing things in the wrong way.

I noticed that az cli (containerapp extension) does have an option to use system assigned under the repo settings
az containerapp registry set --identity system
Help docs:
"The managed identity with which to authenticate to the Azure Container Registry (instead of username/password). Use 'system' for a system-defined identity or a resource id for a user-defined identity. The managed identity should have been assigned acrpull permissions on the ACR before deployment (use 'az role assignment create --role acrpull ...')."
I still need to test if it actually work, and if can be set in arm templates as well.

can confirm this works with AZ CLI

Enable system-assigned identity at the container app level
assign acrpull role to identity
authenticate container to ACR using "system" option instead of user

Some open questions

Will this work with user-assigned identities?
Can it be achieved in ARM?

I have been using it with user-assigned identities and Bicep templates for the last two weeks - no issues so far!

Weird this issue is open if it works? Did microsoft forget about it?

This feature exists today- closing to avoid confusion regarding the feature itself. If you have issues using it, or have doc suggestions please open an issue for those respective topics! Thanks


Language block update

issue #20413
/language ru

/assign @Potapy4
/assign @lex111

You can assign the PR to them by writing /assign @makoscafee in a comment when ready.

/assign @makoscafee

Prow didn't notice the last /approve

Echoing https://github.com/kubernetes/website/pull/20418#pullrequestreview-397052856
/approve


[Bug] Uncaught TypeError: Cannot read property 'sp' of undefined

When loading the app for the first time I am getting this error:

Uncaught TypeError: Cannot read property 'sp' of undefined @log.js:303

The code that is having this issue:
let ld = Log.data,
        sp = ld.sp,

        n = new Date(),
        y = new Date(n)

This blocks any input and can't use the app. I tried adding data to my log manually, but even after restarting this happened.
Versions:
<EMAIL_ADDRESS>node v7.7.2
electron 1.7.9
Mac OS X 10.12.6

Oops. I do apologise for this inconvenience. sp = ld.sp, is actually redundant but does not seem to cause any errors in Linux (which is why I missed it). I will push an update to fix this when I'm done with my classes today. In the meantime, you may delete that line and try again.
Thank you for bringing this to my attention and have a nice day

No need to apologize at all, thank you so much for open sourcing and sharing this with us. ✌


SVG logo

Firstly, thanks a lot for this chaos engineering tool/game. It's so much fun to teach folks about Kubernetes self-healing capabilities, and chaos engineering with a nice app like that.
Since I demo your applications in some of my talks, I would love if you have a SVG version of the logo (or any vector file type)? If not, I can easily convert the logo to vector, except the text: which font did you use?

logos.zip

Hi @fharper
thank you! I attached logos.zip that contains a vectore logo.
Regards,
Eugenio

Thanks a lot!


Fixed minor bad translations in README.no.md

Fixed minor bad translations in README.no.md. Mostly regarding the english term repo and issue.

Added issue for this, but not sure i done it in right order.
Issue: https://github.com/good-first-issues/good-first-issues.github.io/issues/202

@Hellestyle
Thanks for your contributions!