"address-group" are missing/empty on antrea-agent pods which causing 100% traffic failure

Describe the bug
"address-group" are missing on antrea-agent pods which causing 100% traffic failure.
To Reproduce
- Deployed single large k8s-cluster having 3 masters and 1k worker nodes.
- Deployed 100k pods, 50k services and 50k network-policies
- Now, tried to access svc-ips from pods however its failing with timeout error.

kubectl exec -it -n scale-ns-1 coffee-rc-1-vqncb -- curl --connect-timeout 5 <IP_ADDRESS>
curl: (28) Connection timed out after 5000 milliseconds
command terminated with exit code 28

- Tried mesh ping from pods however mesh ping is failing from some pods.

kubectl exec -it -n scale-ns-10177 coffee-rc-2-wdpf9 -- ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
^C
--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
command terminated with exit code 1

Observed that "address-group" are missing/empty on antrea-agent pods

kubectl exec -it antrea-agent-74cz5 -n kube-system antctl get address-group
Defaulting container name to antrea-agent.
Use 'kubectl describe pod/antrea-agent-74cz5 -n kube-system' to see all of the containers in this pod.
[]

{
"agentVersion": "0.5.0-dev-5aeefb1.clean",
"antctlVersion": "v0.5.0-dev-5aeefb1"
}
Expected

"address-group" should updated properly on antrea-agent pods
All types of traffic should work properly without any failure

Actual behavior

Observed that "address-group" are missing/empty on antrea-agent pods
All types of traffic is failing

Versions:
Please provide the following information:

Antrea version (Docker image tag).
#######################
{
"agentVersion": "0.5.0-dev-5aeefb1.clean",
"antctlVersion": "v0.5.0-dev-5aeefb1"
}

#######################
Kubernetes version (use kubectl version). If your Kubernetes components have different versions, please provide the version for all of them.
#######################
kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
#######################
Container runtime: which runtime are you using (e.g. containerd, cri-o, docker) and which version are you using?
Linux kernel version on the Kubernetes Nodes (uname -r).
#######################
~# uname -r
4.4.0-131-generic
#######################
If you chose to compile the Open vSwitch kernel module manually instead of using the kernel module built into the Linux kernel, which version of the OVS kernel module are you using? Include the output of modinfo openvswitch for the Kubernetes Nodes.
#######################
modinfo openvswitch
filename: /lib/modules/4.4.0-131-generic/kernel/net/openvswitch/openvswitch.ko
license: GPL
description: Open vSwitch switching datapath
srcversion: B5716AFB39C1B8C5FBC323B
depends: nf_conntrack,libcrc32c,nf_defrag_ipv6
retpoline: Y
intree: Y
vermagic: 4.4.0-131-generic SMP mod_unload modversions retpoline
#######################
Additional context
Add any other context about the problem here, such as Antrea logs, kubelet logs, etc.
(Please consider pasting long output into a GitHub gist or any other pastebin.)

The connection issue is because the packets were dropped by openflows of networkpolicy. The networkpolicy are not supposed to drop them but are not enforced correctly due to missing address-group data.
kubectl exec -it antrea-agent-74cz5 -n kube-system antctl get address-group
Defaulting container name to antrea-agent.
Use 'kubectl describe pod/antrea-agent-74cz5 -n kube-system' to see all of the containers in this pod.
[]

The last logs of antrea-agent seems it has connected to antrea-controller but got no reply:
I0311 12:42:58.574508       1 networkpolicy_controller.go:263] Start watching AddressGroups
I0311 12:42:58.587958       1 networkpolicy_controller.go:208] Start watching AppliedToGroups
I0311 12:42:58.594813       1 networkpolicy_controller.go:318] Start watching NetworkPolicies
E0311 12:43:28.574969       1 networkpolicy_controller.go:267] Failed to watch AddressGroups: Get https://<IP_ADDRESS>:443/apis/networking.antrea.tanzu.vmware.com/v1beta1/addressgroups?fieldSelector=nodeName%3D<IP_ADDRESS>&watch=true: dial tcp <IP_ADDRESS>:443: i/o timeout
I0311 12:43:28.575008       1 networkpolicy_controller.go:263] Start watching AddressGroups
E0311 12:43:28.588289       1 networkpolicy_controller.go:212] Failed to watch AppliedToGroups: Get https://<IP_ADDRESS>:443/apis/networking.antrea.tanzu.vmware.com/v1beta1/appliedtogroups?fieldSelector=nodeName%3D<IP_ADDRESS>&watch=true: dial tcp <IP_ADDRESS>:443: i/o timeout
I0311 12:43:28.588314       1 networkpolicy_controller.go:208] Start watching AppliedToGroups
E0311 12:43:28.595099       1 networkpolicy_controller.go:322] Failed to watch NetworkPolicies: Get https://<IP_ADDRESS>:443/apis/networking.antrea.tanzu.vmware.com/v1beta1/networkpolicies?fieldSelector=nodeName%3D<IP_ADDRESS>&watch=true: dial tcp <IP_ADDRESS>:443: i/o timeout
I0311 12:43:28.595117       1 networkpolicy_controller.go:318] Start watching NetworkPolicies

But it was actually connecting to an old antrea-controller instance and can still got replies:
09:13:26.969527 IP <IP_ADDRESS>.33392 > <IP_ADDRESS>.443: Flags [.], ack 1, win 1444, options [nop,nop,TS val 258881088 ecr 258868395], length 0
09:13:26.969840 IP <IP_ADDRESS>.443 > <IP_ADDRESS>.33392: Flags [.], ack 1, win 252, options [nop,nop,TS val 258875915 ecr 258873908], length 0

09:16:10.490814 IP <IP_ADDRESS>.33058 > <IP_ADDRESS>.443: Flags [.], ack<PHONE_NUMBER>, win 1394, options [nop,nop,TS val 258913728 ecr 258910183], length 0
09:16:10.491233 IP <IP_ADDRESS>.443 > <IP_ADDRESS>.33058: Flags [.], ack 1, win 250, options [nop,nop,TS val 258917703 ecr 258887672], length 0

Node <IP_ADDRESS> and <IP_ADDRESS> ran antrea-controller before but became UnReady somehow.
I'm suspecting these Nodes suffered memory pressure because of antrea-controller ate too much, then antrea-controller became hanging but were able to keep connection with agents as the packets show.
We have two issues need to address:

Is it normal that antrea-controller use so many memory? The scale is 100k pods, 75k policies, 25k namespaces, and 50k addressgroups, 75k appliedtogroups, 75k internal networkpolicies are created.

- apiVersion: clusterinformation.antrea.tanzu.vmware.com/v1beta1
  connectedAgentNum: 25
  controllerConditions:
  - lastHeartbeatTime: "2020-03-12T12:56:03Z"
    status: "True"
    type: ControllerHealthy
  kind: AntreaControllerInfo
  metadata:
    creationTimestamp: "2020-03-02T05:43:36Z"
    generation: 14067
    name: antrea-controller
    resourceVersion: "121070029"
    selfLink: /apis/clusterinformation.antrea.tanzu.vmware.com/v1beta1/antreacontrollerinfos/antrea-controller
    uid: 174d9734-8141-4911-a0c4-555b95db0c12
  networkPolicyControllerInfo:
    addressGroupNum: 50000
    appliedToGroupNum: 75000
    networkPolicyNum: 75000
  nodeRef:
    kind: Node
    name: <IP_ADDRESS>
  podRef:
    kind: Pod
    name: antrea-controller-6946bdfb9-brc85
    namespace: kube-system
  serviceRef:
    kind: Service
    name: antrea
  version: v0.5.0-dev-618c11c

When there are only 25 agents connected, its memory has reached 2.5G
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3063 root      20   0 4004748 2.501g  28840 S 102.3 32.1  14:11.04 antrea-controll

When more agents connects to it, it would hang and a lot of processes got killed because OOM.

How to prevent the connection to antrea-controller hanging? The Watch method seems supporting timeout option, need to check whether it can fix this problem.

Checked kube-apiserver and kube-controller-manager memory usage, looks like caching resources in such scale indeed needs a lot of memory, 3 master nodes' memory stats as below:
27488 root      20   0 17.349g 9.730g  70524 S 218.6 15.5  24118:03 kube-apiserver
28046 root      20   0 3894800 2.942g  59368 S  12.6  4.7   1431:22 kube-controller
27504 root      20   0 19.033g 2.417g 1.397g S  17.6  3.8   2832:43 etcd
28519 root      20   0 1323688 1.021g  29280 S   1.0  1.6 286:07.13 kube-scheduler

29464 root      20   0 18.720g 8.865g  70396 S 213.0 14.1  22944:35 kube-apiserver
29808 root      20   0 19.354g 2.337g 1.397g S  19.3  3.7   2533:37 etcd
30751 root      20   0 1324072 1.026g  30304 S   1.0  1.6 294:23.84 kube-scheduler

28784 root      20   0 18.082g 8.429g  70308 S 126.6 13.4  23144:44 kube-apiserver
29037 root      20   0 20.391g 2.388g 1.397g S   9.3  3.8   2444:37 etcd
29718 root      20   0 1882860 1.251g  30624 S   0.7  2.0 335:49.16 kube-scheduler

Now I think we should try to schedule antrea-controller to master nodes only to see if the problem can still happen.

After scheduling antrea-controller to one of master nodes, it seems stable now, CPU and memory is not too high, compared with others:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29464 root      20   0 18.720g 8.930g  70524 S 147.2 14.2  23041:31 kube-apiserver
29808 root      20   0 19.354g 2.358g 1.397g S  10.0  3.7   2543:37 etcd
11886 root      20   0 5995396 1.459g  29060 S   5.0  2.3  34:36.12 antrea-controll
30751 root      20   0 1324072 1.026g  30304 S   1.3  1.6 295:34.17 kube-scheduler

It took 26min 47seconds to finish the calculation of  102k pods, 75k policies, 25k namespaces which generate 50k addressgroups, 75k appliedtogroups, 75k internal networkpolicies.
    State:          Running
      Started:      Thu, 12 Mar 2020 13:42:13 +0000

I0312 14:09:00.437411 1 networkpolicy_controller.go:364] Pod scale-ns-19946/coffee-rc-2-ctppb matched AddressGroup 36f16a32-469b-5abd-bfba-7fd48558acac

@rbhamre I found when antrea-controller runs standalone, it didn't consume that much memory, and did local tests and now think it should be the process of starting watch consumed that memory.
After optimizing it with #543, I can observe that memory usage has been reduced a lot with 100 agents (from 2G to 400M). I think it should fix the issue in your scale too.
Please let me know if you get a chance to try it out. With latest code, you can remove the restrict that controller must run on master nodes and there should be no more OOM.
Thanks again for finding this issue!


[Feature Request] Append "Task title" to the page title

Hello!
I have found that when we open any task page we have only project name in page title.
I mean: <title>prj name</title>
It's leads to inability to use "browser history" and "restore closed tab list", because all pages have the same title.
I suggest append "task id" and "task title" to the page title. Something like this:
<title> [prj name] [task number] [task title] </title>
example:
<title> My project, #136 - Change box shadow to red in one step chackout page</title>

This improvement is available in master. Thanks.


Add snapshotter interface and kopia implementation

Snapshotter interface describes an entity that can create,
restore, and delete snapshots, as well as manage a repository.
Add kopia implementation of the snapshotter interface.

Note: this PR will be part of a series that will eventually converge to https://github.com/kopia/kopia/compare/master...kastenhq:test-engine . See that comparison for the full context of how and where this change will be used.


Added interface to MiqPglogical through MiqRegion class

This will allow the UI easy access to the operations required for configuring replication.
@jrafanie @gtanzillo
@dclarizio @h-kataria
I can combine the predicate methods with .replication_type if you think you wont need both.
I think this should cover the following bit of @jrafanie's notes:

MiqRegion.remote?
.global?
.replicationNotEnabled?
replication_type => global|remote|nil

This looks good to me. :+1:

:+1: Looks good to me too.

:tada: Looks good


7311: add peertask foundation code

PR description
This PR adds the foundational code for the new peer task system. For details about how this is used, please see the spike PR proving the concept is workable.

I think it is missing an equivalent to EthPeer.hasAvailableRequestCapacity
I've added this check in getPeer, but it does mean we can't just reuse the bestPeerMatchingCriteria method as you suggested.

EthPeer.executePeerRequest
There definitely can be an equivalent in the new system. Alternative question though: Is that metric actually useful to anyone? The only metric I can find is just monitoring the size of the List, i.e. monitoring how many PeerRequests are "in flight".
The logic around minimum chain height, I did have implemented in PeerTaskExecutor when selecting a peer, but when we moved to the PeerTask providing a Predicate to filter EthPeers, it wasn't included. I'll have to find a way to get the required information into the places utilising GetReceiptsFromPeerTask so it can be passed in when the task is created.

We definitely need as many eyes on these changes as we can get. I think all that's really missing at the moment is the in-flight requests metric mentioned above.

I think all that's really missing at the moment is the in-flight requests metric mentioned above.

Is an equivalent of this logic needed too?https://github.com/hyperledger/besu/blob/aac7c63b0866d78edccdabace956c32947172090/ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/EthPeers.java#L268-L275

@siladu As that's a requirement of the individual task, I've handled in the EthPeer filter of each PeerTask. You can see an example in https://github.com/hyperledger/besu/pull/7638/files#diff-65888fb86ed73e694cc6171b8f99c9150241acb7edc94a575a0ea83b4b91849dR111-R115


nixos/postfix: allow custom smtp_tls_security_level

Motivation for this change
I run Postfix on my workstation as a smarthost, where it only ever talks to my SMTP server.  Because I know it'll only ever connect to this server, and because I know this server supports TLS, I'd like to set smtp_tls_security_level to "encrypt" so Postfix won't fall back to an unencrypted connection.
I’ve also removed services.postfix.useDane, because now that smtp_tls_security_level is using mkDefault, and therefore can
be overridden, there's no need for an option for overriding it to a specific value.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@OfBorg test postfix

@OfBorg test postfix


Update SSM param configuration to only use the ssm parameters from other stacks.

This change is to try to bring the project in line with the guidelines for ssm parameters and use of configurations.
The other params were removed because there is no current need to have those options be configurable.  Therefore they do not count as SSM configs.
I decided to copy config keys from other stacks over based on the suggestion from @jgondron

@ialford Yes.  I am following the recommendation that I got from Justin.  The basics are I removed all keys that are essentially not config options we want to allow change on.  But I kept the keys for options we may wish to be externally configurable.   So when this is merged I would currently consider that issue to be complete.


Error with AnnData.init(adata,asview = True)

Please make sure these conditions are met

[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of anndata.
[ ] (optional) I have confirmed this bug exists on the master branch of anndata.

Report
Code:
import anndata as ad
import numpy as np

adata = ad.AnnData(X = np.zeros((8,8)))
adata_view = ad.AnnData(adata,asview = True)

Traceback:
Traceback (most recent call last):
  File "/lab/solexa_weissman/wcolgan/treedata/test.py", line 5, in <module>
    adata_view = ad.AnnData(adata,asview = True)
  File "/home/wcolgan/miniconda3/envs/td-env/lib/python3.10/site-packages/anndata/_core/anndata.py", line 360, in __init__
    self._init_as_view(X, oidx, vidx)
  File "/home/wcolgan/miniconda3/envs/td-env/lib/python3.10/site-packages/anndata/_core/anndata.py", line 407, in _init_as_view
    obs_sub = adata_ref.obs.iloc[oidx]
  File "/home/wcolgan/miniconda3/envs/td-env/lib/python3.10/site-packages/pandas/core/indexing.py", line 1192, in __getitem__
    return self._getitem_axis(maybe_callable, axis=axis)
  File "/home/wcolgan/miniconda3/envs/td-env/lib/python3.10/site-packages/pandas/core/indexing.py", line 1750, in _getitem_axis
    raise TypeError("Cannot index by location index with a non-integer key")
TypeError: Cannot index by location index with a non-integer key

Versions
-----
anndata             0.10.5.post1
session_info        1.0.0
-----
cython_runtime      NA
dateutil            2.8.2
exceptiongroup      1.2.0
h5py                3.10.0
natsort             8.4.0
numpy               1.26.4
packaging           23.2
pandas              2.2.0
pyarrow             15.0.0
pytz                2024.1
scipy               1.12.0
six                 1.16.0
sphinxcontrib       NA
zoneinfo            NA
-----
Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0]
Linux-5.4.0-137-generic-x86_64-with-glibc2.31
-----
Session information updated at 2024-02-20 12:48

Thanks for opening an issue.
We don't document that argument and wouldn't consider it public API, so I'm inclined to say this isn't a bug.
What are you trying to do here?

I encountered this in a unit test for a new package I'm working on. Clearly this is not a typical use of the init.  Closing with no action seem reasonable to me.


Executors still not working in a multi-module project with more than one level of folders

The PR #201 does not fully solve the detected issue #200.
It can't quite find the parent module. The reason: The pom.xml file needs to include the submodule path in the modules section, e.g.
<modules>
   <module>apps/demo</module>
</modules>

For gradle projects, the settings.gradle file includes the submodule path as well but using a colon as separator, e.g.
include 'apps:demo'

This PR tries to fix it.

closed since the solution will be a different one


Add override for CloudResourceManager API in discovery sample gen

Current coverage is 80.89% (diff: 100%)

Merging #594 into master will not change coverage

@@             master       #594   diff @@
==========================================
  Files           258        258
  Lines          9737       9737
  Methods           0          0
  Messages          0          0
  Branches       1282       1282
==========================================
  Hits           7877       7877
  Misses         1527       1527
  Partials        333        333

Powered by Codecov. Last update 48c4be2...662fdfa

lgtm

if compilecheck succeeds lgtm

I have been unsuccessful in getting useful output from the C# compile check, and the Java compile check is stuck on other errors. So I currently can't confirm that compile check errors are resolved.

Java compile check no longer shows these errors. Java and Python show new errors because CloudResourceManager discovery doc is out of sync with client libraries (and API documentation ... I can't even tell which is supposed to be right). Since @vchudnov-g will be running a full compile check again soon, I'll submit this for now so we can verify C#.


CARMIN specification : execution returnedFiles format

In CARMIN, execution contains a returnedFiles property that is a map from String to File
{Ascii parameterName,<File> returnedFile}[]
I don't get why the returned files are indexed by parameter names ? Should this be used in the rest specification or could it just be a file list (with the file represented as an url in a string).

A list of file is not enough when a pipeline returns several outputs. For
instance a process returning segmentation of the brain and hemispheres
would produce three images. If there is only a list of files, one cannot
know what is the file(s) for the brain for instance. This is what the
(output) parameter name is for.
But, I think the returndFile parameter is not a mapping from string to file
but a list of pairs of string+file. This is because each output parameter
(e.g. each image) can be composed of several files (depending on the
format).

I changed it to a map  String -> List<String> as an object. That way each output can be mapped to several files. I find it more expressive than a pair array.
returnedFiles:
        type: object
        additionalProperties:
          type: array
          items:
            type: string
            format: url
        readOnly: true
        description: absent when not available (e.g. execution still running). Empty if no returned file is produced


getByRoomId() Question

Situation - Was able to make messages (fixed to room1) to show up but cannot switch rooms. Couldn't get function getByRoomId() to work.
Complication -  When I try to use the function getByRoomId() the messages disappears.
Question -
Why isn't the function getByRoomId($stateParams.room_id) triggering the messages to change?
Should getByRoomId() be a local or global function?
Answer - I tried out two methods.

Leaving getByRoomId(); as a local function within messages.js. With this I would inject $stateParams into messages.js and just call the url directly with

var ref = firebase.database().ref().child('messages').orderByChild('room_id').equalTo('$stateParams.room_id');

Global function Message.getByRoomId(); then call getByRoomId in Homectrl.js

I am leaning towards solution 1 because it seems more direct, but I am not sure why the messages aren't showing up. I was able to get the messages (fixed to room1) to show up with solution 2, which is the most recent commit with links below:
https://github.com/bwann52/Bloc-Chat/blob/list-messages/app/scripts/controllers/HomeCtrl.js#L10
https://github.com/bwann52/Bloc-Chat/blob/list-messages/app/scripts/services/message.js#L6

I would go with the first solution, though it has two issues.

You are not returning anything in the getRoomById function. This is why you are receiving nothing back. Instead of setting the variable of ref, you can just return firebase data.

You need to wrap the result of getRoomById in a $firebaseArray, this puts the content in a form that your template can handle.

Let me know if you have any follow-up questions.

I keep getting the error, but I had already defined
this.messages = getByRoomId()

So I'm not sure why it says it is undefined. In getByRoomId() I tried to return the snapshot.val() or just set messages = snapshot.val(). But neither worked.
https://github.com/bwann52/Bloc-Chat/blob/list-messages/app/scripts/services/message.js#L15
ReferenceError: messages is not defined
at Object.Message (http://localhost:3000/scripts/services/message.js:15:16)


Fix: Paste not working on iOS and desktop (Right Click -> Paste)

PR Description
In iOS and Desktop, right click paste (double tap paste) was not working, along with no error was fired during the event.
Expected behaviour
The copied text should be pasted into the text field on right click paste event.
Related Issues
#490
Reason
ExtendedTextField used for highlighting the variables in the fields like url, header value, param value etc, but the widget does not have a default function like right click paste. Normal TextField works as intended but the text highlighting of variables to red like {{url}}/endpoint is not possible.
Added/updated tests?

Edited and extended the default TextEditingController class for highlighting the variables, and enabling the default Ctrl+V along with right click paste option.
Changed the ExtendedTextField to default TextField for fixing the issue.

Output
https://github.com/user-attachments/assets/a66f3126-6eb7-4381-97ca-45b6ca16000d

@ashitaprasad can you please review it.

Environment variable colouring is incorrect.
Kindly use the environment variables feature to understand how the colouring works.

Sorry but I don't quite understand, as I think the environment variables ( {{...}} ) should have red color.

Red color is only for those environments variables whose values are not defined.


add intro gif

Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #283 (e89bd32) into main (a9742bb) will increase coverage by 0.06%.
The diff coverage is n/a.

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #283      +/-   ##
==========================================
+ Coverage   42.24%   42.31%   +0.06%
==========================================
  Files          44       44
  Lines        5797     5797
==========================================
+ Hits         2449     2453       +4
+ Misses       3176     3172       -4
  Partials      172      172

see 1 file with indirect coverage changes


Ability to change scroll container

Is your feature request related to a problem? Please describe.
This is just requesting the ability to change the scroll container that the parallax observes.
Describe the solution you'd like
A prop that can be passed a ref/className of the overflow container with scroll capabilities.
Describe alternatives you've considered
Other parallax libraries.
Additional context
Example: https://codesandbox.io/s/parallaxbanner-e5006?file=/src/App.js

Hey, sorry for the delay. Isn't the parent prop the one you are looking for?

@rrutsche  But what would be the syntax to use the parent prop? I'm searching an example in the docs and issues here but I didn't found it. I'm trying to use with Typescript and I'm having to do a querySelector and type assertion to HTMLElement, which is working but I don't know if it's actually correct.
parent={document.querySelector("#content") as HTMLElement}

Hey. This kitchen sink has an example implementation: https://github.com/rrutsche/react-parallax/blob/master/src/kitchensink/p3.tsx#L76
Does this help?
Cheers


[Bug] [master] Handling 4 trigger(s) that missed their scheduled fire-time. Scheduled tasks missed during peak hours

Search before asking

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

What happened
调度高峰时存在某些任务到执行时刻后没有启动

What you expected to happen
高峰期时任务能正常按时启动 , 可能是quartz线程配置不足以同时处理太多任务的问题 ? 我无法确定
How to reproduce
两个master , 4C8G
同一时刻调度任务超300个
Anything else
No response
Version
2.0.x
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

Which version are you using? @CRUDKanade

2.0.6

Which version are you using? @CRUDKanade

2.0.6

Is the performance of the metabase db sufficient?


Read range from config.json and added checks as needed

@ramesh-jr Thanks for raising the PR. Will look into this soon.

@Kashish121 Please review this.


feat(CategoryTheory/Monoidal/Transport): generalize to a faithful functor

This is needed to transfer the monoidal structure from ModuleCat to QuadraticModuleCat.
The changes are:

A new CategoryTheory.Monoidal.induced definition, proven from scratch with slightly uglier proofs than what transport used. The new proofs use simp rather more than targeted slice commands, mainly due to lack of patience on my part.
CategoryTheory.Monoidal.transport now has a trivial implementation in terms of induced, as does CategoryTheory.MonoidalCategory.fullMonoidalSubcategory (though this was already fairly trivial)
CategoryTheory.Monoidal.laxToTransported has been removed, as it's just a less useful version of CategoryTheory.Monoidal.toTransported
CategoryTheory.Monoidal.toTransported has been golfed to oblivion, as it now falls out trivially by showing fromTransported first.

!bench

!bench

!bench

!bench

!bench

Oh, that's not so bad after all

This construction shall certainly have other applications in the future.)

An obvious one is that this should give us the monoidal structure of AlgebraCat for not much work.

Thanks!
bors merge


[Site] Minor fixes

Remove 40kb glitchy background under hero
(it was visible only on the homepage, in dark mode... and see pictures)
Before light:

Before dark:

After dark

Also:

fix package box titles
improve copy button colors

Thanks Simon!


load-aware: mix workloads in scale test

/test load-aware-e2e keep

/test load-aware-light

/test load-aware-light

/test load-aware-light

/test load-aware-light

/test load-aware-light

/test load-aware-light

test passed.
The time to prepare the first pod of each type on each node is now much closer to the rest, thanks to the image preloading. We can also see the workload pods being scheduled on their own test nodes in the scale test pod logs.
Should be good to merge @kpouget !

/test load-aware-light

@kpouget test passed. Plots are now generated for each type of workload in the report. The timeline combines all types of workloads.
This should include all of your suggestions!

thanks Drew, looks good :)  Artifacts are there.
Merging :)


Adding colorbar functionality to plot

PR Description
Fixes #79
now you can do:
my_spec.plot()
plt.colorbar()

I wonder what the return type of the plot method should be the figure, axis or the output from pcolor mesh? what does sunpy do?


Visual Basic .NET syntax highlight

I need Visual Basic .NET syntax highlight! Please.

You may want to search the packages listing. Someone has probably already built a package for it.
Also, we're trying to control the amount of Issues that we have to triage and track. For general questions, the Atom message board is where you'll probably be able to find answers faster.


Errors running EnviroPhat example

Following instructions at https://github.com/otcshare/iotivity-node/blob/master/js/envirophat/README.md went along OK through the command-line testing of the EnviroPhat LEDs.  The next step failed:
pi@raspberrypi:~/workspace/iotivity-node/js $ node server.envirophat.ocf.js
module.js:487
    throw err;
    ^

Error: Cannot find module '/home/pi/workspace/iotivity-node/js/server.envirophat.ocf.js'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

because the instructions put us in the wrong directory (should be down one more in the ~/workspace/iotivity-node/js/envirophat directory.  But even if we're in the right directory, starting up the server fails:
pi@raspberrypi:~/workspace/iotivity-node/js $ cd envirophat/
pi@raspberrypi:~/workspace/iotivity-node/js/envirophat $ ls
client.envirophat.ocf.js  enviro_phat.py  README.md  server.envirophat.ocf.js
pi@raspberrypi:~/workspace/iotivity-node/js/envirophat $ node server.envirophat.ocf.js
[ main ]: Starting OCF stack in server mode
[ main ]: Registerign device and platform information
/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:175
	iotivity.OCSetDeviceInfo( deviceInfo );
	         ^

TypeError: iotivity.OCSetDeviceInfo is not a function
    at main (/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:175:11)
    at Object.<anonymous> (/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:183:1)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

Not sure what to do now?

Here's what I get in the client.get.js window when I run the server/client.get.js example:
pi@raspberrypi:~ $ cd ~/workspace/iotivity-node/js
pi@raspberrypi:~/workspace/iotivity-node/js $ node client.get.js
Starting OCF stack in client mode
Issuing discovery request
Received response to DISCOVER request:
{
    "devAddr": {
        "adapter": 1,
        "flags": 98,
        "ifindex": 0,
        "port": 5683,
        "addr": "ff02::158"
    },
    "addr": {
        "adapter": 1,
        "flags": 98,
        "ifindex": 0,
        "port": 5683,
        "addr": "ff02::158"
    },
    "connType": 65634,
    "identity": [],
    "result": 29,
    "sequenceNumber": 0,
    "resourceUri": "/oic/res",
    "rcvdVendorSpecificHeaderOptions": []
}
Received response to DISCOVER request:
{
    "devAddr": {
        "adapter": 1,
        "flags": 32,
        "ifindex": 2,
        "port": 40833,
        "addr": "fe80::c7e5:1ab0:4459:479a%eth0"
    },
    "addr": {
        "adapter": 1,
        "flags": 32,
        "ifindex": 2,
        "port": 40833,
        "addr": "fe80::c7e5:1ab0:4459:479a%eth0"
    },
    "payload": {
        "type": 1,
        "sid": "5eda845f-d21f-5e91-9e7c-3f98e5841827",
        "resources": [
            {
                "uri": "/oic/sec/doxm",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.doxm"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/pstat",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.pstat"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/acl2",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.acl2"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/cred",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.cred"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/crl",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.crl"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/csr",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.csr"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/roles",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.roles"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/d",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.d"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/p",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.p"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/introspection",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.introspection"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/a/iotivity-node-get-sample",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "core.fan"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::c7e5:1ab0:4459:479a%25eth0",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            }
        ]
    },
    "connType": 65568,
    "identity": [],
    "result": 0,
    "sequenceNumber": 16777216,
    "resourceUri": "/oic/res",
    "rcvdVendorSpecificHeaderOptions": [
        {
            "protocolID": 2,
            "optionID": 12
        },
        {
            "protocolID": 2,
            "optionID": 2053
        }
    ]
}
Received response to DISCOVER request:
{
    "devAddr": {
        "adapter": 1,
        "flags": 64,
        "ifindex": 1,
        "port": 38630,
        "addr": "<IP_ADDRESS>"
    },
    "addr": {
        "adapter": 1,
        "flags": 64,
        "ifindex": 1,
        "port": 38630,
        "addr": "<IP_ADDRESS>"
    },
    "payload": {
        "type": 1,
        "sid": "5eda845f-d21f-5e91-9e7c-3f98e5841827",
        "resources": [
            {
                "uri": "/oic/sec/doxm",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.doxm"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/pstat",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.pstat"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/acl2",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.acl2"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/cred",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.cred"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/crl",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.crl"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/csr",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.csr"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/sec/roles",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.r.roles"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/d",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.d"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/oic/p",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.p"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/introspection",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "oic.wk.introspection"
                ],
                "interfaces": [
                    "oic.if.baseline",
                    "oic.if.r"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coaps",
                        "addr": "<IP_ADDRESS>",
                        "family": 80,
                        "port": 44242,
                        "pri": 1
                    },
                    {
                        "tps": "coaps",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 48,
                        "port": 57806,
                        "pri": 1
                    }
                ]
            },
            {
                "uri": "/a/iotivity-node-get-sample",
                "anchor": "ocf://5eda845f-d21f-5e91-9e7c-3f98e5841827",
                "types": [
                    "core.fan"
                ],
                "interfaces": [
                    "oic.if.baseline"
                ],
                "bitmap": 1,
                "secure": false,
                "port": 0,
                "eps": [
                    {
                        "tps": "coap",
                        "addr": "<IP_ADDRESS>",
                        "family": 64,
                        "port": 38630,
                        "pri": 1
                    },
                    {
                        "tps": "coap",
                        "addr": "fe80::b99f:10aa:ae8:c92%25lo",
                        "family": 32,
                        "port": 40833,
                        "pri": 1
                    }
                ]
            }
        ]
    },
    "connType": 65600,
    "identity": [],
    "result": 0,
    "sequenceNumber": 16777216,
    "resourceUri": "/oic/res",
    "rcvdVendorSpecificHeaderOptions": [
        {
            "protocolID": 2,
            "optionID": 12
        },
        {
            "protocolID": 2,
            "optionID": 2053
        }
    ]
}
Received response to GET request:
{
    "devAddr": {
        "adapter": 1,
        "flags": 32,
        "ifindex": 2,
        "port": 40833,
        "addr": "fe80::c7e5:1ab0:4459:479a%eth0"
    },
    "addr": {
        "adapter": 1,
        "flags": 32,
        "ifindex": 2,
        "port": 40833,
        "addr": "fe80::c7e5:1ab0:4459:479a%eth0"
    },
    "connType": 65568,
    "identity": [],
    "result": 46,
    "sequenceNumber": 16777216,
    "resourceUri": "/a/iotivity-node-get-sample",
    "rcvdVendorSpecificHeaderOptions": [
        {
            "protocolID": 2,
            "optionID": 12
        },
        {
            "protocolID": 2,
            "optionID": 17
        },
        {
            "protocolID": 2,
            "optionID": 2049
        },
        {
            "protocolID": 2,
            "optionID": 2053
        }
    ]
}
Received response to GET request:
{
    "devAddr": {
        "adapter": 1,
        "flags": 64,
        "ifindex": 1,
        "port": 38630,
        "addr": "<IP_ADDRESS>"
    },
    "addr": {
        "adapter": 1,
        "flags": 64,
        "ifindex": 1,
        "port": 38630,
        "addr": "<IP_ADDRESS>"
    },
    "connType": 65600,
    "identity": [],
    "result": 46,
    "sequenceNumber": 16777216,
    "resourceUri": "/a/iotivity-node-get-sample",
    "rcvdVendorSpecificHeaderOptions": [
        {
            "protocolID": 2,
            "optionID": 12
        },
        {
            "protocolID": 2,
            "optionID": 17
        },
        {
            "protocolID": 2,
            "optionID": 2049
        },
        {
            "protocolID": 2,
            "optionID": 2053
        }
    ]
}

OCSetDeviceInfo() is deprecated. I'll update the example to use OCSetPropertyValue(), and I'll ask you to try again, because I don't have the hardware to reproduce.

@dbkinder could you please replace server.envirophat.ocf.js with this version and try again?

Nope:
/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:169
		csdk.OC_RSRVD_DATA_MODEL_VERSION, "abc.0.0.1" ].join( "," ) );
		                                  ^^^^^^^^^^^

SyntaxError: missing ) after argument list
    at createScript (vm.js:74:10)
    at Object.runInThisContext (vm.js:116:10)
    at Module._compile (module.js:533:28)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

Thinking the ].join( "," ) shouldn't be there, I removed that and tried again:
/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:169
		csdk.OC_RSRVD_DATA_MODEL_VERSION, "abc.0.0.1" );
		^

ReferenceError: csdk is not defined
    at main (/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:169:3)
    at Object.<anonymous> (/home/pi/workspace/iotivity-node/js/envirophat/server.envirophat.ocf.js:180:1)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

@dbkinder thanks for trying it out! I fixed the file now, and I added it to the linter script so I can avoid such syntax errors. Could you please grab the file again, and give it another whirl?

That worked better.  No syntax errors :)
But I don't think the sample is doing what's expected.
Here's the output from running the server in one terminal window:
pi@raspberrypi:~/workspace/iotivity-node/js/envirophat $ node server.envirophat.ocf.js
[ main ]: Starting OCF stack in server mode
[ main ]: Registering device and platform information
[ main ]: creating resources
[ createResources ]: Created resource with result: 0
[ main ]: Server ready

And then the client in another terminal window:
pi@raspberrypi:~/workspace/iotivity-node/js/envirophat $ node client.envirophat.ocf.js
[InterfaceConfig] In
[main] Starting OCF stack in client mode
[main] Issuing discovery request
[discoverResources]: In
[discoveryReqCB] Received response to DISCOVER request:
[discoveryReqCB] Received response to DISCOVER request:
[discoveryReqCB]: found led resource
[discoveryReqCB]: enter 0,1,2,3,4 or Ctrl+c
[discoveryReqCB] Received response to DISCOVER request:
[discoveryReqCB]: found led resource
[discoveryReqCB]: enter 0,1,2,3,4 or Ctrl+c
[ProcessKey] key = 0
[InitPostRequest] key: 0
[payloadCreate] state: 0
[responseCallback] Received response to request with result: 46
undefined
[ProcessKey] key = 1
[InitPostRequest] key: 1
[payloadCreate] state: 1
[responseCallback] Received response to request with result: 46
undefined
[ProcessKey] key = 2
[InitGetRequest] key: 2
[payloadCreate] state: 2
[responseCallback] Received response to request with result: 46
undefined
[ProcessKey] key = 3
[InitGetRequest] key: 3
[payloadCreate] state: 3
[responseCallback] Received response to request with result: 46
undefined
[ProcessKey] key = 4
[InitGetRequest] key: 4
[payloadCreate] state: 4
[responseCallback] Received response to request with result: 46
undefined
[ProcessKey] key =
[ProcessKey] SIGINT: Quitting the app gracefully...

I pressed 0, 1, 2, 3, and 4 and got the same response and no obvious changes to the EnviroPhat LEDs at any time.  There was no output in the server window other than what's shown above.
So, the sample doesn't seem to be doing what's advertised.

The requests are being denied. I'm guessing you're running version 1.3.1 of iotivity-node. Then you need to set up access control files before you can run the sample.
https://github.com/otcshare/iotivity-node/blob/master/js/README.md has instructions for creating the necessary files.

I followed the instructions Rami provided here: https://github.com/otcshare/iotivity-node/tree/master/js/envirophat (no mention of the instructions you referenced).  I see the first step of your instructions say, "In addition to iotivity-node, build iotivity with SECURED=1 and RD_MODE=all. Let the root of the iotivity repository be $iotivityRoot." but there are no command line instructions showing how to do that  :(

I modified the first instruction to point to https://wiki.iotivity.org/build. I also added a step to the envirophat instructions referring to the COAPS instructions.
Please have a look at
https://github.com/gabrielschulhof/iotivity-node/blob/gh-165/js/README.md
and
https://github.com/gabrielschulhof/iotivity-node/blob/gh-165/js/envirophat/README.md


ElasticSearch v6 - unable to set elastic.SetURL

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[ ] elastic.v2 (for Elasticsearch 1.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[x] elastic.v6 (for Elasticsearch 6.x)
Please describe the expected behavior
Being able to connect to a remote ES cluster
Please describe the actual behavior
client, err := elastic.NewClient(
	elastic.SetSniff(false),
	elastic.SetHealthcheck(false),
	elastic.SetURL("http://myIP.amazonaws.com:9200"),
)
if err != nil {
	log.Fatal("Client: ", err)
}

Any steps to reproduce the behavior?
I simply tried to set up a new connexion to an external cluster.
Now, you have to know that I can ping the server (I used telnet with the port), I can even do a:
curl -X POST 'http://myip.amazonaws.com:9200/indexname/_count'
Which returns:
{"count":9445,"_shards":{"total":5,"successful":5,"skipped":0,"failed":0}}
and the:
curl 'http://myIp.amazonaws.com:9200/_nodes/http?pretty'
returns:
{
  "_nodes" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "cluster_name" : "docker-cluster",
  "nodes" : {
    "YQ9PlmEPS7O1D787jnLRvQ" : {
      "name" : "YQ9PlmE",
      "transport_address" : "<IP_ADDRESS>:9300",
      "host" : "<IP_ADDRESS>",
      "ip" : "<IP_ADDRESS>",
      "version" : "6.0.0",
      "build_hash" : "8f0685b",
      "roles" : [
        "master",
        "data",
        "ingest"
      ],
      "attributes" : {
        "ml.max_open_jobs" : "10",
        "ml.enabled" : "true"
      },
      "http" : {
        "bound_address" : [
          "<IP_ADDRESS>:9200"
        ],
        "publish_address" : "<IP_ADDRESS>:9200",
        "max_content_length_in_bytes" : 104857600
      }
    }
  }
}

So I've tried pretty much everything I could come across and it's still not working..
Any ideas?

That's strange. If you disable sniffing and health checks, the requests should just use the provided URL(s) passed into NewClient. Does it fail when creating the Client, or does it fail on the first request? If it does fail with NewClient, can you try to figure out where exactly it is failing (or try NewSimpleClient which does not do any sniffing/healthchecks whatsoever)?

Hey you know what, I don't really know what happened, but since I added authentication and rewrote my port and accesses to ES - it's working.
Thus, until I find a way of undoing my changes I can't reproduce it.
So let's say that if one isn't respecting the best practice for elasticsearch (like keeping it's direct ip:port private) they might experience some troubles in general, even with your plugin.
But this is just assumptions as it's now working for me.

So let's say that if one isn't respecting the best practice for elasticsearch (like keeping it's direct ip:port private) they might experience some troubles in general, even with your plugin.

What do you mean by that?

By that I mean that elasticsearch ip should be accessible internally only.
I set it public at first (public-ip:9200) and I had troubles connecting to it through your (very cool!) library.
But since I put a basic auth + nginx proxy and restricting the access to 'internal-only' everything works far better.

I see. I have several users working with Elastic Cloud offerings here, which offers a public IP. Works fine so far. So it's probably not a public IP vs. internal IP issue.
Anyway. Just reopen if you see it again.


add sentinel error to allow direct deadlettering

In some scenarios we want to send messages to the deadletter queue without retrying them first. This is especially useful for non-transient errors that needs redeploys or config changes to be fixed.

Ok, but that should be easily fixed. Probably best to replicate the header structure that rabbit uses when deadlettering.

@hugowetterberg We now store original information in "old-death" header when deadlettering on first delivery.


Downgrade from 452 to 45

This is meant to allow the library to work with 4.5 and greater.
I don't know if these changes specifically did it, though.  Perhaps the versioning update fixed it, or perhaps the previous build was just against 4.5.2.  But the main point is that the lib was assigned to "45" instead of "452" so it seems to work.

I believe this should help resolve #7 and resolve #8


Refactor Results to Response (#2050)

As described by @pauldix in #2050, refactor client.Results and influxdb.Results struct to client.Response and influxdb.Response, respectively. This is purely change in the name of those two structs plus minor changes in comments + variable names in order to be in line with the type name change.
Testing performed:
$ go test ./...
ok  	github.com/influxdb/influxdb	3.990s
ok  	github.com/influxdb/influxdb/admin	0.018s
ok  	github.com/influxdb/influxdb/client	0.013s
ok  	github.com/influxdb/influxdb/cmd/influx	0.012s
ok  	github.com/influxdb/influxdb/cmd/influxd	72.731s
ok  	github.com/influxdb/influxdb/collectd	0.016s
ok  	github.com/influxdb/influxdb/graphite	0.009s
ok  	github.com/influxdb/influxdb/httpd	1.380s
ok  	github.com/influxdb/influxdb/influxql	0.019s
ok  	github.com/influxdb/influxdb/messaging	5.602s
ok  	github.com/influxdb/influxdb/raft	7.339s
?   	github.com/influxdb/influxdb/statik	[no test files]
?   	github.com/influxdb/influxdb/test	[no test files]
?   	github.com/influxdb/influxdb/tests/urlgen	[no test files]
?   	github.com/influxdb/influxdb/udp	[no test files]
?   	github.com/influxdb/influxdb/uuid	[no test files]

@peekeri would you mind rebasing this on master so that we can merge?
@pauldix can you review this?

@toddboom rebased on master.

Yep, looks good. Thanks @peekeri!


[Question]: How to choose house?

Ask your question
Hi,
I am not quite sure what is the problem here - I suppose it is just me and my non-understanding ;-)
When I integrate the adapter, connection is established, all green, but the log shows:
No devices found.
No stations found.
When switching to debug logging there is also a line:
Houses - house name: xxx***'s Home
The adapter seems to choose a house. However in the app we use a different house with a different name "Guesthouse", not "xxx***'s Home".
Might this be a reason why no stations nor devices can be found? Because stations/devices are queried from the wrong house?
Also when I add a new Eufy user<EMAIL_ADDRESS>and share our "Guesthouse" with him, the adapter's log shows:
Houses - house name: abc***'s Home.
Thanks for any help!
APi

I have the same problem. the logs shows:
No devices found.
No stations found.
The instance is green. But i dont understand why. My account has two factor authentication enabled. But the instance is green without entering two factor code. In the logs there was no request for the verification code.
Maybe this is the problem?
In the documentation https://bropat.github.io/ioBroker.eusec/#/configuration there was recommended to use a separete account.  I also tried to invite a separate account and login this separete account in the adapter. But there was the same result.

@api2001 @royakaacky
The adapter does not select a specific house, but it corresponds to the "All devices" view of the Eufy app.
The adapter uses the country setting under ioBroker to find the devices. If you have registered the Eufy devices under a different country than you have set in ioBroker, the adapter will not find your devices.


Change base upperbound for ghc 8.4

Thanks, and sorry for the delay (end of semester craziness).  I've revised the package on Hackage so it should build with GHC-8.4 now.  I prefer to change the upper bound to base < 4.12 instead of < 5 (if you're going to do < 5 then you might as well just not put an upper bound).


Question:  Is it possible to contribute to this project?

Why
Because only developers PR's from PayPay are reviewed, approved.
If so or if there are any contribution rules, it is better to add a contribution guideline for non-PayPay developers.
This is a public repository so if it is possible, I want to contribute.
Thanks in advance.

Thank you so much @KeisukeYamashita for your interest in our SDK project, I really appreciate your time and efforts on this.
I have been tracking your issues and open pull requests and those are amazing!
However as of now, we are still setting up unit tests, CI/CD pipeline, contributor's legal agreement from our side, the basic stuff to provide a better environment for you and rest of developers, and we have a target to finishing those in next couple of weeks, I would definitely respond back on this thread when we are done with that, in the meantime I would also go through your open PR's and close this issue for now
Feel free to reach out to us if any issue or queries!

Thank you for the reply! The SDK is great and I'd like to contribute again!


Installation Steps Notes

Hi,
Thanks a lot for making the code open source and sharing :)
Is it possible to give few steps on how to install this script? I tried hosting on my server but its throwing some weird errors.
Parse error: syntax error, unexpected T_STRING in /....../AssetStorePublisherClient.class.php on line 520

Added the requirements to the README file.


set default WebVRConfig options in src/main and extend them based on user-defined window.WebVRConfig (fixes #49)

issues about config changes can be addressed in this PR: #53 but keeping it there is fine. I'll fix them both up.

@cvan Sorry for delays, was busy with VR Views, etc. Could you revisit these conflicts so we can merge?

@borismus updated, thanks

Thanks!


Support queuing pending deployment requests affecting multiple apps

Running two consecutive deployments against Marathon quickly enough can lead to a 409 error response containing the message

App is locked by one or more deployments. Override with the option '?force=true'. View details at '/v2/deployments/<DEPLOYMENT_ID>'.

As the force option is only meant to be used for failed deployments according to the official docs (see the Force a Deployment section), I would argue that a more reasonable way to deal with this is to queue up all pending deployments and apply them successively. This also offers the possibility to "skip" waiting deployment requests as newer ones are overtaking.

Conflicts (409) should only happen if the apps in the deployments overlap. Does it really make sense to queue them up? I have trouble coming up with a suitable use case.
The idea of Marathon (as I understand it) is that the user specifies the desired state and Marathon calculates the steps necessary to reach that state.
If you have a quick succession of updates which affect the same application, it is probably either

an error
or you only want the last one (which force should do)

Do you disagree?

Indeed, we only want the last update as per your second case. Reading the official documentation I linked on my original posting, however, I am concerned that force may not be the right option. Quoting (emphasis by me):

If a force flag is set, then all deployments that are affected by this deployment are cancelled. This leaves the system in a possible inconsistent state.

I am not exactly sure how the inconsistent state could look like, but my worst-case expectation is that the service would become unavailable. This is certainly not what we want and the reason for this issue request.
(However, if Marathon was capable of cancelling the ongoing deployment in terms of rolling back to the previous (i.e., about-to-be-replaced) version safely, followed up by the deployment of the waiting update, it would be equally fine with us.)
Does that make sense?

An inconsistent state can be reached, when the to be canceled deployment affects more apps than the one you are forcing, because the whole deployment will be canceled. When an app is in the middle of a rolling upgrade and the deployment is canceled, it will stay in a state where some old and some new tasks are running. If the newer deployment does not update that app, it will stay in that state until a new deployment is being made for that app.

@drexin: How can an app affect other apps? Is this just about groups, or possibly something else, such as dependencies specified in an app's Marathon configuration file?

Every app runs in a group, on the top level there's the / group. So if you have a deployment running that affects more then one app and then force update one of those apps, the whole deployment will be canceled.

After reading up again on the topic of application groups, let me make sure I got this right: Could you say that force-updating can only lead to an inconsistent state if (and only if) you are either using non-trivial groups (i.e., groups containing more than one app) or specify non-empty dependencies (either on the application or application group level)?
(Paraphrased: Apps which are not part of a (non-root) group that also do not specify any dependencies can be force-updated without any risk of becoming inconsistent.)
Would that be correct?

Lets say it that way. Every deployment that only affects a single app (this can also be true for apps with dependencies) can safely be force updated upon.

Gotcha, thanks. Do you mind if I submit a PR that clarifies in the docs what constitutes an inconsistent state and the circumstances under which it can be reached?
As we are (currently) deploying single apps only, the potential dangers surrounding force-updating shouldn't affect us. The bigger question may then be whether Marathon should still implement queuing (or something different) to avoid 409 errors for deployments that cannot be force-updated safely (assuming that other Marathon users actually care about this scenario.) If you deem so, you may want to keep this issue open.

Pull requests are highly welcome. I'm not sure we want to implement something like this in the near future, but we can keep this open for now.

Quick idea: Could marathon distinguish these "single apps" and not require you to set the force option in that case?

If we are absolutely sure, that it is safe, I support that idea.
Ideally, I think, you should always be able to update any app definition and the system should converge to that configuration. That means changing the way deployments are done, though, and the steps that Marathon executes might be harder to understand :(

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-3381. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.


refactor: move limit query from state to urlParams

Description
This PR refactors how the limit query state is stored across the application. Now we have the limit in the url of the pages

What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[x] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents
closes #2154

Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[x] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

@OgDev-01 I think the changes are good, but using strings as something that should be a number seems off. I know that's how they are in the URL, but I think we should convert them to a numbers at some point.

@OgDev-01 I think the changes are good, but using strings as something that should be a number seems off. I know that's how they are in the URL, but I think we should convert them to a numbers at some point.

Yeah it seemed off to me too. I mentioned it in the changes for the range changes PR as well although it wasn't blocking the PR. Agree with Brandon here even if they become strings in the end.
We can revisit it for range after.

Hey @open-sauced/engineering, I've reverted the limit type to number and converted it to string in the appropriate areas. this is ready for a second review 🍕


Undo correctly the docker-env eval.

To undo the the minikube docker-env correctly

This change is

This is a duplicate of PR #2127, so whichever one goes through first, I will close the other(s).

@ehernandez-xk We will need you to sign the CLA before we can merge your PR. Thx


TPIU not found for STM32H753VITx

I'm trying to set up some ITM functionality for my STM32H753VIT6.
On the session I call setup_swv:
session.setup_swv(
            &SwoConfig::new(cpu_frequency)
                .set_mode_uart()
                .set_baud(interface_frequency),
        )?;

At some point this will call: https://github.com/probe-rs/probe-rs/blob/043b1b49bf83a14e321d05269e8db083d31fde2b/probe-rs/src/architecture/arm/memory/romtable.rs#L451
This function will not find the TPIU for the H753, but does work for my F407.
The function searches for a component part with value 0x9A1, defined here: https://github.com/probe-rs/probe-rs/blob/043b1b49bf83a14e321d05269e8db083d31fde2b/probe-rs/src/architecture/arm/memory/romtable.rs#L607.
I don't know where these values come from, so I can't check if it's the same for the H7 series.
These are the part codes found on the H7 (read from the log output):
0x00C, 0x002, 0x00E, 0x001, 0x975, 0x906

On the F4:
0x00C, 0x002, 0x003, 0x001, 0x9a1, 0x925

Desktop:

Windows 10

Additional context
Probe: STLINKv3

Did you setup the TPIU properly? If the debug facilities on the core are not activated the TPIU will not be found (yes, the ROM tables are not immutable as ROM might suggest ...). I am not sure how much is required for the H7. Might well be mich more init sequence things required than for the F4.
Also, I just tested this with an F407 and an nRF52840, so I would not claim for this to be 100% working on all targets.
The 0x9A1 code can be found at various places, I can't tell you where exactly I took it from. Even with ARM there is very cluttered docs.
I think all the CoreSight components are "documented" in pyOCD. But even tho those guys work for ARM it was determined a bit empirically too :D

So, what I've found now (a bit rambly):
The H7 docs say: The TRACECK output must be enabled by setting the TRACECLKEN bit in the DBGMCU_CR register before trace is sent to the TPIU.
That seems to be the only setup required.

The H7 has a different DBGMCU address.
Probe-rs defines the CR register as:
const DBGMCU: u32 = 0xE004_2004;

This is consistent with the F4: https://docs.rs/stm32f4/0.12.1/src/stm32f4/stm32f407/mod.rs.html#511
The H7 however, has a different location: https://docs.rs/stm32h7/0.12.1/src/stm32h7/stm32h743/mod.rs.html#3226
(I'm linking to the docs, because I can give actual links)
Looking up a random F7, it has the same address as the F4. So it's not a Cortex M4/7 thing.

The DBGMCU layout is different.
So not only is the location different, the bits are as well.
The F4 and F7 have the same layout.

Even if I change the probe-rs code to use the H7 location and H7 bits, the TPIU is still not found in the rom table.
It appears that the rom table is read before the DBGMCU register is set.
But even if I reread the rom table after DBGMCU register is set, it still doesn't show any new part.

Any idea what I could now look at? They don't make it easy to make stuff like this work, now do they? 😜

Wait a minute:

Why are they not present?

I believe that's because they're instead described in the System ROM table 2; the TPIU is associated with the chip-wide debug subsystem rather than the Cortex-M7 core debug system. Or something like that.

Oh, that'd be annoying!
But what does entry_present even mean?
Looking at the RomTable::try_parse method, I can see that the value is false for some, but the address is valid:

It means there's no TPIU accessible via the AHB-AP debug system or through the Cortex-M7 PPB, instead the TPIU must be accessed via the APB-AP and that's why it's described in the System ROM table 2 instead of the Cortex-M7 ROM table.
However I don't know how to turn this annoying knowledge into getting probe-rs to actually talk to the TPIU...

D6.2.2 ROM Table entries that are marked not present
The descriptions of the debug components are stored in sequential locations in the ROM Table, starting at the ROM
Table base address. However, a ROM Table entry can be marked not present by setting the PRESENT field of the
entry to a value that indicates that the entry is not present.
When scanning the ROM Table, an entry that is marked as not present must be skipped. Unless the entry has the
value 0x00000000, however, you must not assume that an entry that is marked not present represents the end of the
ROM Table. For example, a ROM Table might be generated using static configuration tie-offs that indicate the
presence or absence of particular devices, giving not present entries in the ROM Table.

From the reference manual ;)

The values in Table 589 (the System ROM table 2) are the right ones for the TPIU, saying its address from a debugger's point of view is 0xE00F5000 and from the system bus (i.e. over AHB-AP, I guess) is 0x5C015000. The "TPIU" entry in the Cortex-M7 PPB ROM table which has an address of 0xE0041000 is not valid (since it's marked as not-present).
So I think in principle if you hardcoded probe-rs to access the TPIU at E00F5000, that should work, or if you wrote to it from your own firmware at 0x5C015000, that should also work. I'm not sure if probe-rs picks up the second set of ROM tables (on the APB-AP) or how to make it do so if it doesn't, though.

Well, I think parsin the ROMtable is important such that wer actually check if there is a TPIU present. We could add an override tho.
I am not sure how we access the APB-AP but it should 100% be possible. It is just work :)

It may not even have to be hardcoded, though.
The address of the system rom table is given by the ArmProbeInterface of StlinkArmDebug.
The function ap_information when using access_port 2 gives back the correct address.
So what if not only the first ApInformation is used, but all?
Don't know if that would work with non-stlink probes, though.

Yes! That seems to work.
I forced the system to use the ap index 2 instead of 0.
I get back a part with the code 0x912.
According to blackmagic, that's a TPIU. It's also at the correct address.
https://github.com/blacksphere/blackmagic/blob/9cd3193a89ef075cc3f24963503a2118d5fa0e4b/src/target/adiv5.c#L210

YAAAY! Nice :) Yes, so we only used the first AP (MemoryAP) for simplicity reasons in the past :) And especially in recent months I didn't have much time to get into things again :/ So this was def. the plan from the get go :) Great to hear it works :)

I'll try putting some time into this.

To use all Memory APs
To better integrate part codes (probably by looking at what BlackMagic does)
To support the H7's DBGMCU

That's not gonna be today, though. Monday evening is the first time I can spend with it again

Sounds great, thanks!
No hurry, we all have other stuff to do unfortunately :/

Ok, so I have done some work on this and I quite like the results. But I'm running into another issue.
Sometimes the rom table can't be read properly.
2020-11-16 20:45:55,723 INFO  [probe_rs::architecture::arm::memory::romtable] Reading rom table entry at e00e0018
2020-11-16 20:45:55,723 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e0018, length=1
2020-11-16 20:45:55,735 INFO  [probe_rs::architecture::arm::memory::romtable] Entry consists of all zeroes, stopping.
2020-11-16 20:45:55,735 INFO  [probe_rs::architecture::arm::memory::romtable] Parsing entry at e00e1000
2020-11-16 20:45:55,735 INFO  [probe_rs::architecture::arm::memory::romtable] Parsing entry at e00e2000
2020-11-16 20:45:55,736 INFO  [probe_rs::architecture::arm::memory::romtable] Parsing entry at e00e3000
2020-11-16 20:45:55,736 INFO  [probe_rs::architecture::arm::memory::romtable]  Reading component data at: e00e3000
2020-11-16 20:45:55,736 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e3ff0, length=4
2020-11-16 20:45:55,737 DEBUG [probe_rs::architecture::arm::memory::romtable] CIDR: [0, 0, 0, 0]
2020-11-16 20:45:55,737 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e3000: CIDR0 has invalid preamble (expected 0xd, got 0x0)
2020-11-16 20:45:55,738 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e3000: CIDR2 has invalid preamble (expected 0x5, got 0x0)
2020-11-16 20:45:55,738 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e3000: CIDR3 has invalid preamble (expected 0xb1, got 0x0)
2020-11-16 20:45:55,739 DEBUG [probe_rs::architecture::arm::memory::romtable] Reading debug id from address: e00e3fd0
2020-11-16 20:45:55,739 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e3fd0, length=4
2020-11-16 20:45:55,739 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e3fe0, length=4
2020-11-16 20:45:55,739 DEBUG [probe_rs::architecture::arm::memory::romtable] Raw peripheral id: [0, 0, 0, 0, 0, 0, 0, 0]
2020-11-16 20:45:55,741 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e3fcc, length=1
2020-11-16 20:45:55,741 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e3fbc, length=1
2020-11-16 20:45:55,742 DEBUG [probe_rs::architecture::arm::memory::romtable] Dev type: 0, arch id: 0
2020-11-16 20:45:55,742 INFO  [probe_rs::architecture::arm::memory::romtable]  Component class: GenericVerificationComponent
2020-11-16 20:45:55,743 INFO  [probe_rs::architecture::arm::memory::romtable]  Component peripheral id: PeripheralID { REVAND: 0, CMOD: No, REVISION: 0, JEP106: None, PART: 0, SIZE: 1, dev_type: 0, arch_id: 0 }
2020-11-16 20:45:55,754 INFO  [probe_rs::architecture::arm::memory::romtable] Parsing entry at e00e4000
2020-11-16 20:45:55,754 INFO  [probe_rs::architecture::arm::memory::romtable]  Reading component data at: e00e4000
2020-11-16 20:45:55,754 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e4ff0, length=4
2020-11-16 20:45:55,755 DEBUG [probe_rs::architecture::arm::memory::romtable] CIDR: [0, 0, 0, 0]
2020-11-16 20:45:55,755 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e4000: CIDR0 has invalid preamble (expected 0xd, got 0x0)
2020-11-16 20:45:55,757 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e4000: CIDR2 has invalid preamble (expected 0x5, got 0x0)
2020-11-16 20:45:55,757 WARN  [probe_rs::architecture::arm::memory::romtable] Component at 0xe00e4000: CIDR3 has invalid preamble (expected 0xb1, got 0x0)
2020-11-16 20:45:55,757 DEBUG [probe_rs::architecture::arm::memory::romtable] Reading debug id from address: e00e4fd0
2020-11-16 20:45:55,757 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e4fd0, length=4
2020-11-16 20:45:55,758 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e4fe0, length=4
2020-11-16 20:45:55,760 DEBUG [probe_rs::architecture::arm::memory::romtable] Raw peripheral id: [0, 0, 0, 0, 0, 0, 0, 0]
2020-11-16 20:45:55,773 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e4fcc, length=1
2020-11-16 20:45:55,774 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e4fbc, length=1
2020-11-16 20:45:55,774 DEBUG [probe_rs::architecture::arm::memory::romtable] Dev type: 0, arch id: 0
2020-11-16 20:45:55,776 INFO  [probe_rs::architecture::arm::memory::romtable]  Component class: GenericVerificationComponent
2020-11-16 20:45:55,776 INFO  [probe_rs::architecture::arm::memory::romtable]  Component peripheral id: PeripheralID { REVAND: 0, CMOD: No, REVISION: 0, JEP106: None, PART: 0, SIZE: 1, dev_type: 0, arch_id: 0 }
2020-11-16 20:45:55,776 INFO  [probe_rs::architecture::arm::memory::romtable] Parsing entry at e00e5000
2020-11-16 20:45:55,776 INFO  [probe_rs::architecture::arm::memory::romtable]  Reading component data at: e00e5000
2020-11-16 20:45:55,792 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e5ff0, length=4
2020-11-16 20:45:55,792 DEBUG [probe_rs::architecture::arm::memory::romtable] CIDR: [d, f0, 5, b1]
2020-11-16 20:45:55,792 DEBUG [probe_rs::architecture::arm::memory::romtable] Reading debug id from address: e00e5fd0
2020-11-16 20:45:55,792 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e5fd0, length=4
2020-11-16 20:45:55,793 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e5fe0, length=4
2020-11-16 20:45:55,809 DEBUG [probe_rs::architecture::arm::memory::romtable] Raw peripheral id: [1, b1, 1b, 0, 4, 0, 0, 0]
2020-11-16 20:45:55,809 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e5fcc, length=1
2020-11-16 20:45:55,810 DEBUG [probe_rs::probe::stlink] Read mem 32 bit, address=e00e5fbc, length=1
2020-11-16 20:45:55,811 DEBUG [probe_rs::architecture::arm::memory::romtable] Dev type: 0, arch id: 0

Some CIDR's are read as all 0. It usually only breaks or starts working again when it is reflashed, but there's no guarantee and I can't find the pattern...
I've made #431 to show the progress so far. When it works, it works. But I don't know if this bug is my new code, in existing code or a hardware bug (either STM's or mine).

The PR looks nice already! Thanks for the hard work :)
I have seen CIDRs read all 0 already. So I think there is a bug in the Romtable parsing I once fixed and ill-merged somehow, that's in again. I cannot remember what it was tho. I will have another look some day. There is an open issue about it (#320).

For anyone that comes here after the fact, for the STM32H7xx components, you still need to explicitly enable the debug component clocks in the DBGMCU to get them to show up in the ROM table. Otherwise, even with the fixes to search all ROM tables, the entries will be zero and the TPIU may not be found
Specifically, enable the D3DBGCKEN and D1DBGCKEN bits in the DBG MCU to get the TPIU to show up.
The TPIU is part of the D1 domain and SWO etc. are part of D3.

I wonder if it would be feasibly doable to enable DBGMCU when we can for romtables or if that is bad. because we read some components when we connect. we could disable it after reading them.

The reason we don't is because the DBG-MCU is a vendor-specified component, and indeed changes between variants (e.g. F4/F7 have different DBGMCU than H7). We'd have to encode information about DBGMCU layouts into probe-rs, which I believe there's aversion to.

@Yatekii ... why could we not use a custom sequence for this?

yup, sequences are the way to go here :) there might even be a fitting one already :)


Adding / removing sbml:compartment nodes

= Description =

Provide the API for adding or removing compartments in SBML models through the Change mechanism in SED-ML.

= Context =

Compartments are an important element of the SBML language, as they allow the definition of space and container in a SBML model; it should be made possible to manipulate them through the SED-ML language in !BioPreDyn, using the elementary XML manipulation tools it provides.
The sedml:Change object (and all its derived classes) encodes for a modification to be applied to a sedml:Model before a simulation run. Writing a Change element requires a deep understanding of both the SBML model (the user usually has it) and the XML philosophy (the user does not necessarily have it).

= Success criteria =

High-level API exists for adding / removing sbml:compartment nodes from a SBML model through the use of sedml:change-derived nodes attached to a sedml:model node.

= Expected issues =

None.

Imported from trac issue 43.  Created by bmoreau on 2014-06-10T16:05:55, last modified: 2014-06-10T16:05:55


IATP: extend configuration for multiple trusted issuers

WHAT
Currently, a connector can only have one "allowed issuer", i.e. it can only accept credentials created by one entity. In preparation for adopting the Identity And Trust Protocols (IATP), we need to extend this to allow multiple issuers.
WHY
Ultimately, we will have multiple issuers (~operating companies), so we need to prepare for that.
HOW
There are two general ways to approach this:

add the allowed issuers via configuration: this is how we do it currently (with one issuer), and it's by far the easiest way.
download a list of allowed issuers: this raises the difficult question of how the authenticity and integrity of such a list can be verified, and as of now, there is no agreed-upon way of doing that. It may come at a later point in time.

We will go with approach 1 for now.
Specifically, this means that the SsiCredentialIssuerValidationRule now has to be able to deal with a List<String> instead of a String. Configuration-wise, it should just be a comma-separated list.
FURTHER NOTES

issuer-IDs are in practice DID's

Please be sure to take a look at
our contribution guidelines and
our PR etiquette.

@matgnt FYI

related upstream EDC: https://github.com/eclipse-edc/Connector/issues/3531

Thanks!
I guess you know, but just in case, it seems we need to do this for both settings:
tx.ssi.miw.authority.id=BPNLissuer
tx.ssi.miw.authority.issuer=did:web:dev%3A9000:BPNLissuer

This will be moved into the upstream implementation
https://github.com/eclipse-edc/Connector/issues/3602


Display pretty alert popups when reaching data sources limits

Task here, issue here
Notes

Google Drive Shows the alert after the disclosure, IMHO it is fine
Alert limits Currently different from what is written in our plans; not in this PR's scope, I will follow up with a slack thread
managed.tsx diff => looks large, but due to a change in identation / div wrapping => fear not :)

All  adressed! Thanks

Naice