text:
All Embedded Device-side Code Needs to Be Scrubbed of Direct Heap Usage

Problem
The software produced by Project CHIP is consumed both inside and outside Project CHIP, across a variety of platforms. The capabilities of these platforms are broad, spanning soft real-time, deeply-embedded systems based on RTOSes that might cover life safety and/or physical security applications to richer, softly-embedded systems based on non-RTOS platforms such as Linux or Darwin. While the latter are apt to have fully-functional heaps, the former explicitly do not.
As a result, direct calls to malloc/free/new/delete and usage of C Standard Library, C++ Standard Library, C++ Standard Template Library (STL), or other library functionality that, in turn, call malloc/free/new/delete should be avoided and, ideally, eliminated.
Proposed Solution

Places where malloc/free/new/delete are explicitly invoked in embedded device-side code should be instead indirected through src/lib/support/CHIPMem.h, giving the stack configurator the option of how they want memory managed in their device.
Places where C++ STL are used should be replaced with a common singly- or doubly-linked list, implemented in src/lib/support or should a static bitmap or list allocator such as the attached, nldatastructures.zip.
Other patterns should be triaged and replacements designed with the appropriate indirections or other non-heap usage.

/cc/ @tcarmelveilleux, @woody-apple, @szatmz

I think once https://github.com/project-chip/connectedhomeip/issues/2736 is in place, we should measure and baseline on that in respect to code size and heap.
@andy31415 do we have a good way to test heap post a test run?

I'm starting to work on this. I'll make and mention explicit sub-issues so that it's clear what work is in progress and what is available.

I think the following may be the remaining C library calls (not covering C++ libraries yet) that may use heap under the hood. (It's not actually obvious to me what code is meant to run on a device, but if it's not obvious to me I don't think it will be obvious to a device maker either.)
src/app/clusters/ias-zone-client/ias-zone-client.c
Calls
fp = fopen("iaszone.txt", "w");
fp = fopen("iaszone.txt", "r");
fscanf(fp, "%x ", &data1);
fscanf(fp, "%x %x %x %x ", &data2, &data3, &data4, &data5);
fscanf(fp, "%x ", &data1);

Build Condition
#if defined(EZSP_HOST) && !defined(EMBER_TEST) && defined(UNIX_HOST)

Notes

Some implementations of stdio may call malloc for the default buffer.
Some implementations of the scanf have a GNU extension m modifier that calls malloc().

src/inet/AsyncDNSResolverSockets.cpp
Calls
gaiReturnCode = getaddrinfo(resolver.asyncHostNameBuf, nullptr, &gaiHints, &gaiResults);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_INET_CONFIG_ENABLE_ASYNC_DNS_SOCKETS CHIP_INET_CONFIG_ENABLE_DNS_RESOLVER

src/inet/DNSResolver.cpp
Calls
gaiReturnCode = getaddrinfo(hostNameBuf, nullptr, &gaiHints, &gaiResults);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS

src/inet/InetInterface.cpp
Calls
int res = getifaddrs(&mAddrsList);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

src/inet/InetLayer.cpp
Calls
rv = getifaddrs(&ifaddr);
freeifaddrs(ifaddr);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

src/inet/tests/TapAddrAutoconf.cpp
Calls
const int err = getifaddrs(&addrsList);
tmp = (char *) malloc(strlen(buf));
freeifaddrs(addrsList);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

I think the following may be the remaining C library calls (not covering C++ libraries yet) that may use heap under the hood. (It's not actually obvious to me what code is meant to run on a device, but if it's not obvious to me I don't think it will be obvious to a device maker either.)
src/app/clusters/ias-zone-client/ias-zone-client.c
Calls
fp = fopen("iaszone.txt", "w");
fp = fopen("iaszone.txt", "r");
fscanf(fp, "%x ", &data1);
fscanf(fp, "%x %x %x %x ", &data2, &data3, &data4, &data5);
fscanf(fp, "%x ", &data1);

Build Condition
#if defined(EZSP_HOST) && !defined(EMBER_TEST) && defined(UNIX_HOST)

Notes

Some implementations of stdio may call malloc for the default buffer.
Some implementations of the scanf have a GNU extension m modifier that calls malloc().

src/inet/AsyncDNSResolverSockets.cpp
Calls
gaiReturnCode = getaddrinfo(resolver.asyncHostNameBuf, nullptr, &gaiHints, &gaiResults);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_INET_CONFIG_ENABLE_ASYNC_DNS_SOCKETS CHIP_INET_CONFIG_ENABLE_DNS_RESOLVER

src/inet/DNSResolver.cpp
Calls
gaiReturnCode = getaddrinfo(hostNameBuf, nullptr, &gaiHints, &gaiResults);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS

src/inet/InetInterface.cpp
Calls
int res = getifaddrs(&mAddrsList);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

src/inet/InetLayer.cpp
Calls
rv = getifaddrs(&ifaddr);
freeifaddrs(ifaddr);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

src/inet/tests/TapAddrAutoconf.cpp
Calls
const int err = getifaddrs(&addrsList);
tmp = (char *) malloc(strlen(buf));
freeifaddrs(addrsList);

Build Condition
#if CHIP_SYSTEM_CONFIG_USE_SOCKETS && CHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS

All of those would largely be on UNIX/POSIX/Linux/Darwin systems supporting a heap and malloc, so I don't think we have to deal with these.

Once I've got a similar list of config conditions for C++ library use, I intend to add a build-time check that they're combined with CHIP_CONFIG_MEMORY_MGMT_MALLOC.

For C++ new with constructors, is the preference for …?

placement-new into CHIPMem allocations
global :new calling CHIPMem

For the record, I'm currently looking through C++ library uses in the code to pick the next most important case to replace.

For C++ new with constructors, is the preference for …?

placement-new into CHIPMem allocations
global :new calling CHIPMem

IMO both are unacceptable because memory should be allocated statically by the linker and provided by the project-specific initialization code. (Basically like the current HomeKit ADK does it).
CHIPMem only changes the allocator function but doesn't eliminate the allocations.
Reasons for that:

there might not be a memory area which can be used be multiple libraries which defeats the purpose of allocations. Take a look at the Zephyr RTOS. The heap is disabled by default and things like bluetooth or the IP stack have usecase-specific private memory pools with a fixed data-type and number of elements
your app can never fail because it runs out of memory
you can see the max RAM usage at compile-time

Merely indirecting malloc etc. calls to a facade like CHIPMem.h as described above does not solve the problem, I'm afraid. As described above, that facade would still provide a general dynamic memory management API to the programmers.
In contrast, the HomeKit ADK protocol code implementation was designed to never allocate memory itself. It is sandwiched between a platform abstraction layer (PAL) below the protocol code, and the application above the protocol code. Depending on the platform, a PAL implementation may use malloc internally, and the application may pass memory to the protocol code that it has allocated using malloc. Makes sense for Linux-class devices with "infinitely large" memories.
However, this design allows resource-constrained PALs and apps for small microcontrollers to completely do away with dynamic memory management / a heap. For typical microcontrollers, both PAL and app statically pre-allocate memory in global variables as needed. As @M1cha said, this guarantees to never run into OOM conditions, which could otherwise easily happen with very small heaps. Works very well for HomeKit over a broad spectrum of microcontrollers.

ping because it's still an unresolved show-stopper

why did the stale bot close this? my post should've kept it active

authors: M1cha cpfister gerickson kpschoedel woody-apple


text:
[Build] Fuschia installation error in Mac OS - running app in docker container

Build issue(s)
1.Open connectedhomeip application in a docker container in VS code
2. Run the bootstrap.sh shell script
3. Get error failed to install Fuschia
Host OS: mac OS with intel chip. running big sur. docker container running on linux.
see error log below -
[P3522 17:06:42.453 deployer.go:409 I] [unzip  7/12] Deployed fuchsia/third_party/clang/linux-amd64:AD59JKqO1TWgxp7uA0Fq99aIrVCXG2i4HShWi6sFFV8C in 96.0s
Errors:
  failed to install fuchsia/third_party/armgcc/linux-amd64 in "arm": adding files to the site root: lstat /workspaces/connectedhomeip/.environment/cipd/packages/.cipd/pkgs/0/9z1FnQUHn-LGwcPNIsxnZzTE3HjoopYzwWlK3f1-HG0C/share/doc/gdb/qMemTags.html: no such file or directory
/workspaces/connectedhomeip/.environment/cipd/cipd ensure -ensure-file /workspaces/connectedhomeip/.environment/cipd/packages.ensure -root /workspaces/connectedhomeip/.environment/cipd/packages -log-level debug -json-output /workspaces/connectedhomeip/.environment/cipd/packages.json -cache-dir /home/vscode/.cipd-cache-dir -max-threads 0
[\]
None
Traceback (most recent call last):
  File "/workspaces/connectedhomeip/third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/env_setup.py", line 959, in <module>
    sys.exit(main())
  File "/workspaces/connectedhomeip/third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/env_setup.py", line 951, in main
    return EnvSetup(**vars(parse())).setup()
  File "/workspaces/connectedhomeip/third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/env_setup.py", line 558, in setup
    result = step(spin)
  File "/workspaces/connectedhomeip/third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/env_setup.py", line 671, in cipd
    if not cipd_update.update(
  File "/workspaces/connectedhomeip/third_party/pigweed/repo/pw_env_setup/py/pw_env_setup/cipd_setup/update.py", line 382, in update
    subprocess.check_call(cmd, stdout=outs, stderr=subprocess.STDOUT)
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/workspaces/connectedhomeip/.environment/cipd/cipd', 'ensure', '-ensure-file', '/workspaces/connectedhomeip/.environment/cipd/packages.ensure', '-root', '/workspaces/connectedhomeip/.environment/cipd/packages', '-log-level', 'debug', '-json-output', '/workspaces/connectedhomeip/.environment/cipd/packages.json', '-cache-dir', '/home/vscode/.cipd-cache-dir', '-max-threads', '0']' returned non-zero exit status 1.
Installing pip requirements for all...
DEPRECATION: distro-info 0.23ubuntu1 has a non-standard version number. pip 23.3 will enforce this behaviour change. A possible replacement is to upgrade to a newer version of distro-info or contact the author to suggest that they release a version with a conforming version number. Discussion can be found at https://github.com/pypa/pip/issues/12063

...
Platform
ameba, vscode
Anything else?
No folder inside /pkgs/0/
the following folder and file do not exist - 9z1FnQUHn-LGwcPNIsxnZzTE3HjoopYzwWlK3f1-HG0C/share/doc/gdb/qMemTags.html

same issue
do find the solution ?

unfortunately no.
I tried using a different commit and it seems to work one time randomly.

for me the build was successful in Virtual Box Ubuntu
any idea how to flash any one example to board?

I encountered this issue on /mnt/d on WSL but not in ~. Maybe long file paths or somesuch?

Closing older issues, trying to focus on current build failures

The issue still exist @woody-apple

source: gharchive/issue

repo: project-chip/connectedhomeip

license_type: permissive

license_source: github-api


text:
[Feature] Describe "endpoint added" scenario in spec

Feature description
For now the spec contains only notes about "power on" scenario for different clusters.
But in some cases the behavior on scenario "endpoint added" should be different from the scenario "power on".
For example: OTA happens and then 3 days later a new endpoint that has an On/Off cluster is added. What is the expected behavior of StartUpOnOff Attribute in such case?
Related issue: https://github.com/project-chip/connectedhomeip/pull/34160
Platform
all
Platform Version(s)
No response
Anything else?
No response

@j0tunn Spec issues should be filed in https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/

@j0tunn Spec issues should be filed in https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/

Yep. I saw such links, but got 404 trying to go there. Thought it was migrated elsewhere, but I don't know where.

It just means you don't have permissions to that repository... If you're a CSA member, please reach out to @clapre about access.  If not, please let me know and I can file the issue for you.

@bzbarsky-apple No, I'm not a CSA member.


text:
☂ Transition server-side logic to cluster objects

Problem
As per discussions with @bzbarsky-apple, once #8895 and #8893 are fixed, the server-side logic for both decoding InvokeRequests and dispatching them to the right command callbacks need to be updated in the following sequence:

#8971
#8972
#8974
#8977

As such, this issue is an umbrella issue that tracks broadly the above set of tasks needed to transition fully the server side logic.

S1 and S2 will be handled by @bzbarsky-apple.

All tasks are complete, closing this.


text:
[esp] Add status screen to all-clusters-app on M5Stack

Problem
It can be difficult to glean basic information about a physical Matter node.
Change overview
Add a "Status" screen to ESP / M5Stack platform.
This screen displays whether the device is commissioned or not, and if it is shows info about the first fabric in the table:

Fabric Index
Fabric ID
Node ID
UDP Port
IPv4 address
IPv6 Link Local address
IPv6 ULA address

Testing
Tested manually on desk:

Erase/flash.
Verify Fabric : none
Verify IP : none
Commission over BLE.
Verify Fabric : 1
Verify IP : [live address]
Factory reset.
Verify Fabric : none
Verify IP : none
Recommission over BLE.
Verify Fabric : 1
Verify IP : [live address]

CI should cover the rest.

/rebase

source: gharchive/pull-request


text:
Fix status response handling in write handler

Problem
Fix status response handler in ReadHandler
This PR is cut from https://github.com/project-chip/connectedhomeip/pull/19356
Change overview
When receiving unknown message in write handler, write handler would send status response with invalid action.
Testing
Write client sends out the chunked write request and receive response, then inject the unknown report message in write handler side, write handler would send status response with invalid action.

@yunhanw-google This is failing the nRF Connect unit tests, with this error:
2022-08-06T06:29:13.5184322Z 2022-08-06 06:28:12 INFO    ../../../../src/app/tests/TestWriteInteraction.cpp:588: assertion failed: "InteractionModelEngine::GetInstance()->GetNumActiveWriteHandlers() == 1"

I am guessing the PacketBuffers there are bigger, and we end up not chunking....  We should probably reserve an amount of space dependent on the packet buffer available space, not a hardcoded 900 bytes.

authors: bzbarsky-apple yunhanw-google


text:
Set navigation toggle button color to white

On small devices such as Android the nav toggle button is displayed but can't be seen because both masthead and bars icon are black.
To fix this, the bars icon color is set to white by changing the color to global_Color_light_100 in navToggle.

Deploy preview for koku ready!
Built with commit bd4e4638b2266375feb59846ff47ad4a18e7a3b0
https://deploy-preview-80--koku.netlify.com

Codecov Report

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

@@           Coverage Diff           @@
##           master      #80   +/-   ##
=======================================
  Coverage   85.72%   85.72%
=======================================
  Files          98       98
  Lines         918      918
  Branches       92       92
=======================================
  Hits          787      787
  Misses        122      122
  Partials        9        9

Impacted Files
Coverage Δ

src/components/masthead/masthead.styles.ts
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

@dlabrecq sure.
It was mentioned here and shown there

I don't want to hold up the PR, so I'll approve. @dmiller9911 can comment later...

ping @dmiller9911

repo: project-koku/koku-ui


text:
LUX should be able to redirect old YUIDs to new ones from a mapping (from 1477)

Problem Description:
The pipeline sometimes merges YUIDS when two records are determined to be about the same entity. For example currently we have for Larry:

https://lux-front-prd.collections.yale.edu/view/person/d0fa256d-e6ea-46a1-b101-b5f26ce2636a
https://lux-front-prd.collections.yale.edu/view/person/5333319b-3917-470c-9764-873674778212
https://lux-front-prd.collections.yale.edu/view/person/ec6f29b6-702e-403e-bf37-ff5415bfbb9e

Expected Behavior/Solution:
A future pipeline might merge these together. However, if someone has bookmarked (e.g. in a list of people in LUX who work at Yale) one of the records that gets merged, it would be nice if it redirected to the merged URI rather than getting a 404.  The pipeline can record when it merges YUIDs together and generate a map from the old to the new. When the old URI is requested, it could redirect to the new one.
Requirements:

Old YUIDs must redirect/map users to the new YUID.
Error 404's must not display when selecting an Old YUID that has a new YUID.

Needed for promotion:
If an item on the list is not needed, it should be crossed off but not removed.

[ ] To be designed where this occurs, and how the mapping is to be sent from pipeline to that place.
[ ] Examples for testing
[ ] Wireframe/Mockup - Mike
[ ] Committee discussions - Sarah
[ ] Feasibility/Team discussion - Sarah
[ ] Backend requirements - TBD
[ ] Frontend requirements- TBD
[ ] Questions
List of questions for discussions. Answers should be documented within the issue.

UAT/LUX Examples:
Search result of Lawrence Gall
All links below should redirect to the new YUID link:
https://lux-front-prd.collections.yale.edu/view/person/d0fa256d-e6ea-46a1-b101-b5f26ce2636a
https://lux-front-prd.collections.yale.edu/view/person/5333319b-3917-470c-9764-873674778212
https://lux-front-prd.collections.yale.edu/view/person/ec6f29b6-702e-403e-bf37-ff5415bfbb9e
Dependencies/Blocks:

[x] Blocked By:  https://git.yale.edu/LUX/pipeline/issues/358

Related Github Issues:
N/A
Related links:
N/A
Wireframe/Mockup:
N/A

https://git.yale.edu/LUX/pipeline/issues/358 is closed so this issue is no longer blocked.

@roamye I have no idea--I have not worked on this, it'll need to be answered by Rob.

UAT 9/27:

Blocked by the backends way of getting this information.
There needs to be data to move this ticket forward.
This issue would allow for My Collections to be reliable.

authors: gigamorph kkdavis14 roamye

repo: project-lux/lux-frontend


text:
test(blackbox): add multi-arch index creation and image attributes modification

What type of PR is this?
test

Which issue does this PR fix:
What does this PR do / Why do we need it:
The PR adds a new multiarch_test, which creates a multi-arch index for arch-specific images, and then modifies its attributes, to validate such operations are supported as expected.
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ossfellow thanks for the PR.

@sagikazarmark fyi, pls take a look at the test case in this PR wrt https://github.com/project-zot/zot/issues/2190 as a workaround. We can probably automate this in our release pipeline.

authors: ossfellow rchincha

repo: project-zot/zot


text:
Allow birth, death, and gender elements

We would like to add <birth>, <death>, and <gender> elements to use in PROS1. We haven't really developed PROS1 yet and we want to be set up to do so as we need better metadata capture for authors, printers, publishers, playhouse personnel, patrons, etc.
For <birth> and <death>, we would also like to add some of the suite of attributes that you created for MoEML: @when-custom, @not-before, and @not-after.

Elements added in rev 12001.

We need to figure out what the rather odd combination of custom and non-custom dating attributes is all about. Up to now, LEMDO only uses the standard @when, @notBefore, @from etc. attributes. If we're going to switch to using custom attributes and calendars as MoEML does, that's a fairly major change, and it comes with drawbacks:
https://www.researchgate.net/publication/287218344_Encoding_historical_dates_correctly_is_it_practical_and_is_it_worth_it
Meanwhile, I need to figure out why <gender> is not showing as available even though it's in the schema.

Figured it out. We had pinned our schemaSpec to P5 version 4.4.0 for some reason.

@JanelleJenstad @LEMDO-PM What's the plan for dating attributes? We currently don't use the custom dating attributes in LEMDO, I think on the basis that dates have not been particularly significant for this particular project and the messiness with Julian calendars is not worth poking at. Is that going to change?

It's potentially very messy! We have:

legacy files where there's no documentation about the treatment of dates or the source of the date
transcribed documents
critical paratexts
modernized editions

I don't think it's feasible to devise a dating system that will allow us to capture all the possible calendrical scenarios and ambiguities we are likely to encounter. Furthermore, as we discovered with MoEML, even major sources like the ODNB tend to treat proleptic and ahistorical dates as facts, with the maddening result that we don't know what dates signify in secondary sources. (The Queen Elizabeth I example comes to mind yet again. She died on March 24, 1602 by her calendar but no historian ever says that she died in any year other than 1603. It's now "fact" that she died in 1603.)
Furthermore, our research questions thus far haven't depended on precise understandings of dates and calendars. For LEMDO, it's more important to acknowledge our sources;
I think it's more important to:

indicate the source of the date (not necessarily on the date element itself; the parenthetical bibl ref will suffice);
indicate at the anthology level how dates are treated ("dates have been transcribed as they appear in the source documents; dates in critical paratexts are quoted from secondary sources / have been normalized to proleptic Gregorian" or something like that)

In short, it is worth having a suite of custom dating attributes for MoEML where we do documentary editions. LEMDO does not need them.

@JanelleJenstad @LEMDO-PM In that case, I believe this issue is complete, so I'll close it.

authors: JanelleJenstad LEMDO-PM martindholmes

repo: projectLEMDO/lemdoIssues

license: MIT


text:
Two-line annotation rendering not quite right

When annotations span multiple lines, the output is supposed to provide a single vertical line to the left of those lines, instead of underlining the linked text inline. This works perfectly except in the case of annotations which span only two lines; in that case, the relevant text in the first line is underlined, and the vertical line only begins to the left of the second line. See for example emdH5_FM.html#emdH5_FM_a1_s1_sp3.

On second thoughts, after looking at this, I began to wonder whether it was actually a bug; I thought that perhaps the intention was that when a block annotation begins in the middle of a line, then only that part of the line that is part of the annotation would be underlined, and then any subsequent lines would get the left-hand block line, because if both lines got the block line, then it would appear that the annotation applies to the entirety of the first line. However, that can't be the case because there are cases where the full block gets its left line even when the initial annotation anchor is not at the beginning of the line, as here:
emdH5_FM.html#emdH5_FM_a1_s1_sp12
where the annotation anchor is between "The" and "strawberry". So there's some inconsistency, and that's clearly a problem.

I think it would be better to run the vertical line along the full height of the lines even if only a part of the line is annotated. The consistency will help our users and the interface itself will teach them what to expect (i.e., that a vertical line means an annotation spans a line break).

I'm sure that's the original intention, but it's just not working for some cases of two-line annotations, but not all. That's a bit puzzling. I'm going to look at it today.

I've confirmed that the difference between the processing of the two example annotations is NOT due to the fact that one is @type='gloss' and the other @type='commentary'.

Fix committed in rev 10480. If all is well with Mr Jenkins, we can close this ticket.

Looks good. Closing.

authors: JanelleJenstad martindholmes


text:
stdin: on HUP, read everything

When we're polling to handle stdio for a container, when we detect a HUP on our stdin, read all that we can from stdin before closing it, instead of reading only, at most, a single chunk of bytes.

LGTM
@TomSweeneyRedHat @pixdrift @vrothberg @umohnani8 PTAL

Besides the two logs, LGTM :+1:

LGTM once questions are answered or addressed.

Rebased.

@rh-atomic-bot r+

authors: TomSweeneyRedHat nalind rhatdan vrothberg

repo: projectatomic/buildah

license_source: bigquery


text:
Check for mutually exclusive flags

Error out if more than one mutually exclusive flags are passed
in to kpod ps
Addresses issue @rhatdan raised in https://github.com/projectatomic/libpod/pull/123#pullrequestreview-82995550
Signed-off-by: umohnani8 umohnani@redhat.com

@rhatdan @mheon PTAL

LGTM

FWIW @umohnani8 looks like more fun with "unable to find image 'registry.fedoraproject.org/fedora:26' locally", not related to these changes.

@rhatdan PTAL

@rh-atomic-bot r+

authors: TomSweeneyRedHat mheon rhatdan umohnani8

repo: projectatomic/libpod


text:
Add more filters to interface names for IP guessing

Fixes #730

LGTM

authors: TrimBiggs robbrockbank

repo: projectcalico/calico-containers


text:
Containers cannot communicate when hosted on separate hypervisors

We have deployed a Rancher RKE1 Kubernetes cluster on VMWare with Calico and found that the containers running on one hypervisor cannot communicate with containers running on another hypervisor.
Network flow:
container1 ---> VM1(RHEL) --> ESX host1 --> physical switch --> ESX host2 --> VM2(RHEL) --> container 2
So far, we've determined that neither ICMP or TCP packets (ping, http) are working from one container to another.
Expected Behavior
I can ping and/or connect via TCP containers running from one hypervisor (ESX) to another.
Current Behavior
Pinging containers on the same hypervisor are 100% successfull
Pinging containers on different hypervisors results in 100% packet loss
Possible Solution
Unknown
Your Environment
Rancher RKE1 1.21.9 w/calico
RHEL 8.3

Further troubleshooting of this issue has led me to the IP in IP encapsulation calico uses. After editing the default IPPool configured by Calico and setting the "ipipMode" from "Always" to "CrossSubnet", communication began working again between pods.
I suspect that some device in the network path is having issues decapsulating the traffic? Would love to get more context on this.
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  annotations:
    projectcalico.org/metadata: '{"uid":"6dca6b31-1601-4205-b642-4552df28b603","creationTimestamp":"2022-02-24T21:59:28Z"}'
  creationTimestamp: "2022-02-24T21:59:28Z"
  generation: 6
  name: default-ipv4-ippool
  resourceVersion: "3060678"
  uid: 87a21d8e-24c9-48f7-b511-9a3134ed6c04
spec:
  blockSize: 26
  cidr: 10.245.0.0/16
  ipipMode: CrossSubnet
  natOutgoing: true
  nodeSelector: all()
  vxlanMode: Never

If you want faster support, consider the calico users slack: http://slack.projectcalico.org/

@lwr20 thanks for the info. We have a few support cases open with some of our vendors, we'll look into it and I will update this issue accordingly.

Alternatively, you might consider switching from IPIP to VXLAN encap (which is usually allowed by these sorts of things)

@lwr20, just ran a quick test. Disabling IPIP mode and using VXLan fails, using always or crosssubnet causes traffic to fail from pods running on 1 ESXi host to another.

FWIW, if you want to be certain what's going on, tcpdump is they way to go.
If, as I suspect, the packets are being dropped by something in VMWare, you'll see the encapped packets leaving one host VM and failing to arrive at the destination host VM.
If you see no packets leaving the source host, that would suggest a Calico problem.  Or arriving at the destination VM and not making it to the pod.

We've done a few packet captures. On the VM from which the traffic is originating, it does appear as though traffic is leaving the VM, but the capture is full TCP errors, specifically TCP [RST] (connection reset), followed by a flood of TCP retransmissions and out-of-order.
On the receiving VM, we see far few entries, but do see some TCP retransmission errors warnings.
What's strange is we have other Kubernetes environments running on these same ESXi hosts using Canal (vxlan) and these aren't experiencing any issues; those working clusters are running kubeadm vanilla clusters though, compared to these RKE1 clusters.

using Canal (vxlan) and these aren't experiencing any issues

That's extremely odd.  Calico's VXLAN implementation is almost identical to Flannel's.
@caseydavenport any ideas about TCP errors?

That's extremely odd. Calico's VXLAN implementation is almost identical to Flannel's.

To be fair, this isn't a like-for-like comparison. The VMs where canal is being used are running RHEL 8.5, whereas these VMs are running 8.3 as that is what is supported for RKE1.
Not going to lie though, was very surprised when VXLAN didn't work. I used the following config:
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  annotations:
    projectcalico.org/metadata: '{"uid":"6dca6b31-1601-4205-b642-4552df28b603","creationTimestamp":"2022-02-24T21:59:28Z"}'
  creationTimestamp: "2022-02-24T21:59:28Z"
  generation: 6
  name: default-ipv4-ippool
  resourceVersion: "3060678"
  uid: 87a21d8e-24c9-48f7-b511-9a3134ed6c04
spec:
  blockSize: 26
  cidr: 10.245.0.0/16
  ipipMode: Never
  natOutgoing: true
  nodeSelector: all()
  vxlanMode: Always

I wonder if its something to do with VXLAN checksum offloading in RHEL?  ISTR seeing something like that a while back.  @fasaxc or @tomastigera might know about that?

@lwr20 it's possible. We initially thought we ran into this issue: https://access.redhat.com/solutions/5881451. We tried disabling offloading for the different interfaces and that didn't seem to help. Later, it was confirmed that if that was the case, ICMP packets wouldn't be effected, but since our overlay tests reveal that both ICMP (ping) and TCP (http) packets are failing, this is not likely the case.
Hoping to run some packet captures at the ESXi level this week, will keep you posted.

Hi,
We experienced the same behaviors.
Redhat 8.5, rke2, calico 3.19.2.
When the 3vms are one same ESXI it works but no when on 2 separates ESXI.
We try to reproduce with 3 others VM and we do not success.
Before using Calico with VXLAN we are using Canal with VXLAN without any problems.
Regards

Hi,
For your information. We use Wireshark, and the behaviour not the good one.
The trafic is on a bad interface (we have several ethXXXX (xxx are a string).
So we edit the Installation CRD to set IP_AUTODETECTION_METHOD with the good interface (interface=ethMYXX.*) and it works !!!
Thanks for the help

Not convinced @dtrouillet's issue is the same as ours. Just as a follow up, working with VMWare we recently identified that VLAN tags are being stripped from one ESXi host to the other. So traffic appears to leave ESXi host 1 with VLAN tag "1234", but when traffic arrives on ESXi host 2, the VLAN tag has been stripped, therefor traffic gets lost.
They've confirmed the issue could be on the NIC Drivers or even some device on the physical network doing this - we still don't know. In either case, we aren't using encapsulation now so not as much of an issue for us.

authors: dtrouillet jeanluclariviere lwr20

repo: projectcalico/calico


text:
Edits to inline help topics

Alex wrote new inline help topics and asked for a copy edit.

Merge to nightly only
No back porting

Deploy preview for calico ready!
Built with commit 57a2415f75b089a4bd8f92a3abe18a79d8e2006d
https://deploy-preview-3244--calico.netlify.com


text:
Fix role name manager-role to contour-operator

Although ClusterRoleBinding changed ClusterRole to contour-operator  in this PR,
the ClusterRole still has the old name manager-role.
Due to this, operator always fails to start.
This patch fixes it by changing the name to contour-operator from manager-role.
Signed-off-by: Kenjiro Nakayama nakayamakenjiro@gmail.com
/cc @danehans @jpeach

Current operator always fails with the following error:
$ kubectl -n contour-operator  logs contour-operator-55d6c7b4b5-6qngz -c contour-operator
2020-11-27T01:43:27.732Z	INFO	controller-runtime.metrics	metrics server is starting to listen	{"addr": "127.0.0.1:8080"}
2020-11-27T01:43:27.732Z	INFO	setup	starting contour-operator
I1127 01:43:27.733012       1 leaderelection.go:243] attempting to acquire leader lease  contour-operator/0d879e31.projectcontour.io...
2020-11-27T01:43:27.733Z	INFO	controller-runtime.manager	starting metrics server	{"path": "/metrics"}
I1127 01:43:45.226131       1 leaderelection.go:253] successfully acquired lease contour-operator/0d879e31.projectcontour.io
2020-11-27T01:43:45.226Z	DEBUG	controller-runtime.manager.events	Normal	{"object": {"kind":"ConfigMap","namespace":"contour-operator","name":"0d879e31.projectcontour.io","uid":"28217062-a339-410e-9158-a49c9489f6e0","apiVersion":"v1","resourceVersion":"3953"}, "reason": "LeaderElection", "message": "contour-operator-55d6c7b4b5-6qngz_7c5c9016-880b-4f5e-a56d-613dfc36b235 became leader"}
2020-11-27T01:43:45.226Z	INFO	controller	Starting EventSource	{"reconcilerGroup": "operator.projectcontour.io", "reconcilerKind": "Contour", "controller": "contour", "source": "kind source: /, Kind="}
E1127 01:43:45.235162       1 reflector.go:127] pkg/mod/k8s.io/client-go@v0.19.2/tools/cache/reflector.go:156: Failed to watch *v1alpha1.Contour: failed to list *v1alpha1.Contour: contours.operator.projectcontour.io is forbidden: User "system:serviceaccount:contour-operator:default" cannot list resource "contours" in API group "operator.projectcontour.io" at the cluster scope: RBAC: clusterrole.rbac.authorization.k8s.io "contour-operator" not found
E1127 01:43:46.164486       1 reflector.go:127] pkg/mod/k8s.io/client-go@v0.19.2/tools/cache/reflector.go:156: Failed to watch *v1alpha1.Contour: failed to list *v1alpha1.Contour: contours.operator.projectcontour.io is forbidden: User "system:serviceaccount:contour-operator:default" cannot list resource "contours" in API group "operator.projectcontour.io" at the cluster scope: RBAC: clusterrole.rbac.authorization.k8s.io "contour-operator" not found

 ... continue same error ...

@nak3 i just noticed this bug a few minutes ago while working on a PR. Thanks for catching and fixing it. These types of regressions should be prevented in the future when https://github.com/projectcontour/contour-operator/pull/133 merges.

/lgtm

repo: projectcontour/contour-operator


text:
Update scope.json

Add IBM Scope

Thank you @xEHLE, the change will reflect on the website on the next run.

Ok thanks
I'm @xElkomy not xEHLE
anyway thanks

authors: bauthard xElkomy


text:
Run interact server behing nginx proxy, real remote IP

If the Revheader is present, and the reverse proxy adds a header with the original IP (like X-Forwarded-For) you cna tun interact-sh server behing a proxy and get the real IP in the logs/client.

I dont know why it fails, because i have not touch the "interactsh-client" code, only in the server.

@dhd0004 Thanks for opening this PR. This is for sure an interesting use-case scenario. If I'm not mistaken, the information related to the original IP would be contained within the dumped request as we capture the whole HTTP interaction. I guess the use case you are describing is to place a reverse proxy in front of an interactsh instance for internal testing?

Hi!
The scenario i am using is havinf only one server, with NGINX configured as Reverse Proxy. Behind the proxy i have the interactsh serer, another web server, and one PHP application. If i acces for example web.mydomain.com, the nginx redirects the request to the internal web server. If i use interactsh.mydomain.com, the NGINX sends the request to the interactsh server.
The problem with this use case is that interactsh was showing always 127.0.0.1 as the remote address, because the nginx was between the real user and the interactsh server (is a rev proxy). So with this PR, my nginx sends the real remote IP addr to interactsh-server in an HTTP Header, and the interactsh server can show the real remote IP in the logs.
Regards

repo: projectdiscovery/interactsh


text:
Add WriteAccessDirective and mark all input fields with that directive. Fixes #1163

any time there is an input field that needs to be disabled for source control it should have  [writeAccess]="functionApp"

:shipit:

authors: Tuesdaysgreen ahmelsayed

repo: projectkudu/AzureFunctionsPortal


text:
WEBSITE_RUN_FROM_PACKAGE does not work properly with REST API

Our Linux web app is deployed with WEBSITE_RUN_FROM_PACKAGE=1 setting via Azure Devops.
We are trying to run some post-deploy actions, however the zip file is not mounted when accessing the machine via Kudu and its REST API.
I verified this with the following:

Executed the command ls on an Azure Web App via REST API.
Verified that the contents were not the same as what we had deployed and what we were seeing when we SSH'ed through Kudu or Azure Portal.
Tried to delete the files inside wwwroot and was able to delete them, although it should have been impossible if we had accessed the machine with WEBSITE_RUN_FROM_PACKAGE=1 since that mounts the zip file via fuse on /home/site/wwwroot.

This issue is also I believe related to the issue I created on Azure Pipelines task repo at https://github.com/microsoft/azure-pipelines-tasks/issues/11440

I may be seeing something similar in https://github.com/microsoft/azure-pipelines-tasks/issues/11444
All my function apps no longer appear to work after being deployed via Azure Devops.

Facing the same issue

Include @sanchitmehta.   This usually means the zip file is corrupted or not deflateable.   please check if that is the case?

In my case, the zip is not broken and the app functions ok. It is only when accessing via kudu rest api that it sees the file system as if nothing has been mounted.

Thank you very much for confirming the issue @sanchitmehta .
Is implementing that on the roadmap?
What we are trying to achieve is to be able to run some one-off tasks (for example running migrations) when we deploy to a staging server. Can you suggest any workarounds for that then?
What we want is the equivalent of something like ssh server -c 'some command' for Azure Webapps. We were using kudu in Azure Devops for this, but this no longer works after we switched to using this flag (which sped up the deployment, down to 30 seconds from 17 mins)

I solved this issue via expect utility for now.
Here is some snippet for those interested:
     spawn az webapp ssh -g my-resource-group  --name my-app-service
     expect "root@"
     send "cd /home/site/wwwroot\r"
     expect "root@"
     send "node node_modules/sequelize-cli/lib/sequelize db:migrate\r"
     expect "root@"
     send "node node_modules/sequelize-cli/lib/sequelize db:migrate:status\r"
     expect "root@"
     send "exit\r"
     expect eof

I solved this issue via expect utility for now.

Hello @ustun , could you kindly provide more information about your workaround solution? I am also finding issues while running commands ("php artisan migrate" FWIW) in Kudu while the very same commands on the Web App SSH work just fine.
Where are you running these "expect" + "az webapp ssh" commands from? On the post deployment script (i.e. Kudu) or via Azure CLI task (bash) on DevOps pipeline?
If it is from the Azure CLI task, are you running it on a self-hosted VM? Because I am not able to install "expect" on the MS hosted DevOps agent (ubuntu-latest).
Thanks in advance!

Hi @garimpeirodouniverso unfortunately I run them from my laptop for now :)  Please let me know if you can find a workaround too.

Hi @ustun thanks for your response!

Maybe you could install expect inside the App Service from Kudu though

It seems like installing packages is locked down on Kudu, unfortunately. I have tried with "sudo apt-get install" and "apt-get install" but did not work.
Maybe I can make it work by using a self-hosted agent on an Ubuntu VM but I'd prefer a simpler route first :)

For what it's worth, I was able to install expect inside the Azure CLI task in YAML Pipelines (AzureCLI@2) and execute "spawn az webapp ssh" from there.
Not ideal, but gets the job done.

Oh nice find, I'll give it a go.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service

authors: damienwebdev garimpeirodouniverso jvano metu suwatch ustun

repo: projectkudu/kudu


text:
Windows App Service Zip Deploy

I usually deploy my angular application to windows app service manually as zip push deploy
now it is not working and the deploy goes to 50% and fails after with this log message:
Cleaning up temp folders from previous zip deployments and extracting pushed zip file C:\local\Temp\zipdeploy\ to C:\local\Temp\zipdeploy\extracted

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


text:
Deprecating Support Portal and created a Landing page

Removing the redirect for mawssupport.trafficmanager.net and created a landing page that helps customers find the Diagnostic tools easily.

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

We ended up backing this one out, and @puneetg1983 will change it to host image in CDN instead of embedded.

authors: davidebbo dnfclas puneetg1983


text:
Remove Subscription object from OLM deployment

By removing the Subscription we directly manage the CSV through Project Syn. This solves the current resolution failure caused by deploying both Subscription and CSV.
closes #50
Checklist

[x] PR contains a single logical change (to build a better changelog).
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog.
[x] Link this PR to related issues or PRs.

Tested on our 4.11 test cluster. Seems to just work? Will try to test an upgrade and then test on our APPUiO Cloud lab

Both minor and patch upgrades seem to just work.

repo: projectsyn/component-cilium


text:
Reevaluate default resource requests

Context
We've seen that the Ceph cluster doesn't really use the resources we request during normal operation, requiring us to provision relatively large storage nodes, which are then mostly idle. This is not great for financial reasons. We should reevaluate the component's default resource requests and limits based on actual usage numbers from production environments.
Since Rook now provides a ceph-cluster Helm chart which defines default resource requests for the Ceph components, we should also check if those default requests are suitable for us. See https://github.com/rook/rook/blob/1ae867049b49079b76696e68ee9b8f30216528bd/deploy/charts/rook-ceph-cluster/values.yaml#L233-L289
Alternatives
Don't do anything.

New default requests are more or less the recommended minimum https://github.com/rook/rook/issues/9858#issuecomment-1064354946 with a small increase for the prepareosd pod https://github.com/rook/rook/commit/bf1342b2b303ca204906f01ed5f43bacd338ad27 (https://github.com/rook/rook/issues/10477).

CPU load seems to spike pretty aggressively. Not sure if we should lessen CPU defaults.

MDS daemons already get OOMKilled from time to time with limits 8GB.
  - containerID: ...
    image: quay.io/ceph/ceph:v16.2.9
    lastState:
      terminated:
        exitCode: 137
        finishedAt: "2022-09-02T07:02:56Z"
        reason: OOMKilled
        startedAt: "2022-08-16T12:21:09Z"
    name: mds

Resolution not quite good enough to see if the OOM was because of active/passive failover. Or the failover was because of OOM.

OSD daemons seem to just use all memory to the limit.

The CPU load seems to be mostly related to iowait which is factored in on Linux systems. The last ~8 days the CPU was never fully used.

authors: bastjan simu

repo: projectsyn/component-rook-ceph


text:
"cluster" label unavailable for elasticsearch_snaphot_stats_*  metrics

Post migrating to ElasticSearch 7.10.2, we wanted to monitor the snapshot age. We have enabled "es.snapshots" and set it to true. The metrics are being exported as expected, however we cannot see the label 'cluster' in any of them.
Since we use the 'cluster' as a  filter for our Grafana dashboard, is there a way to add it to the labels ?
Following are the versions of our logging and monitoring stack -
Exporter Versioin - v1.1.0
Kibana - 7.10.2
ElasticSearch - 7.10.2
Prometheus - 2.32.1
Adding a sample screenshot with redacted data -

1.5.0 is the most recent version of the exporter. Please upgrade and check the data again.

I can confirm this issue using 1.5.0

authors: mlabouebe sameer-samant-sp sysadmind


text:
mangled emails

Hi,
We are running alertmanager 0.7.1 and we are receiving emails that have random characters missing or injected.
The Prometheus Alert that generated the example is as follows:
ALERT PrometheusInstanceDown
IF up{job!="kubernetes-nodes"} == 0
FOR 5m
LABELS {severity="critical"}
ANNOTATIONS {callout="true", description="{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes. This means that any alerts that utilize metrics from this target will be inaccurate.  If this is the openshift api for a cluster, a callout should be made if unable to resolve.", summary="Prometheus target {{ $labels.instance }} down"}
An example of the email body is included below as well as a screenshot.
MIME-Version: 1.0

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="viewport" content="width=device-width" style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; box-sizing: border-box; font-size: 14px; margin: 0;">

<title style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; box-sizing: border-box; font-size: 14px; margin: 0;">[FIRING:2] PrometheusInstanceDown cluster.example.com (staging kubernetes-service-endpoints critical)</title>

              2 alerts for
                alertname=PrometheusInstanceDown

                cluster=cluster.example.com

                    View in AlertManager

                    [2] Firing

                    Labels

                    alertname = PrometheusInstanceDown
cluster = cluster.example.com
cluster_env = staging
instance = 1.2.3.4:8080
job = kubernetes-service-endpoints
k8s_app = kube-state-metrics
kubernetes_name = kube-state-m
 etricskubernetes_namespace = kube-system
severity = critical

                    Annotations

                    callout = true
description = 1.2.3.4:8080 of job kubernetes-service-endpoints has been down for more than 5 minutes. This means that any alerts that utilize metrics from this target will be inaccurate.  If this is the openshift api for a cluster, a callout should be made if unable to resolve.
summary = Prometheus target 1.2.3.4:8080 down

                    Source

                    Labels

                    alertname = PrometheusInstanceDown
app = cephback
cluster = cluster.example.com
cluster_env = staging
instance = 1.2.3.4:9090
job = kubernetes-service-endpoints
kubernetes_name = cephback
kubernetes_namespace = cephback
severity = critical
template = cephback

                    Annotations

                    callout = true
description = 1.2.3.4:9090 of job kubernetes-service-endpoints has been down for more than 5 minutes. This means that any alerts that utilize metrics from this target will be inaccurate.  If this is the openshift api for a cluster, a callout should be made if unable to resolve.
summary = Prometheus target 1.2.3.4:9090 down

                    Source

              Sent by AlertManager

I should have mentioned that the error in this mail is at the text "kubernetes_name = kube-state-metrics".  There is an extra space in "m etrics" and also in the next font tag, which breaks the rest of that section.

Thanks for reporting!

I've experienced this as well. I'm seeing "!" or space characters injected randomly into label names or values.

Just a note to say that we are still seeing this issue.  We are now running alertmanager 0.9.1.

Hm, I'm looking at the default template shipping with alertmanager:
{{ range .Labels.SortedPairs }}{{ .Name }} = {{ .Value }}
{{ end }}

Nothing seems obviously wrong here, as it's just writing out the label pairs it received from prometheus.
Can you confirm that your labels look normal in prometheus, and that they're being sent correctly to alertmanager? Are there any patterns you're seeing in the labels that are incorrectly rendered?
This is difficult to reproduce as there are lots of variables.

It should help if the alertmanager were to encode the body as base64, split it into separate lines not more than 1000 bytes each (see RFC 2821 4.5.3.1) , and set the "Content-Transfer-Encoding" header to "base64".

Closing it as the issue is very old and the email notifier should be compliant now.

authors: aloucks jameseck mdevan simonpasquier stuartnelson3

repo: prometheus/alertmanager


text:
resolve_timeout documentation is outdated

From the documentation at alerting configuration page:
  # ResolveTimeout is the time after which an alert is declared resolved
  # if it has not been updated.
  [ resolve_timeout: <duration> | default = 5m ]

Looking at prometheus implementation, and this comment
it seems that this is not the case anymore.

Would you like to send a PR indicating this is merely a default if the client doesn't send it?
Given the amount of confusion this particular setting hurts, it's likely worth moving it from the top and mentioning that this has no impact on Prometheus.

Yes I will prepare a PR that will clear this up.

Hi Brian, I created #1492, please let me know if you have any notes on the wording(English is not my first language)

@stuartnelson3

PR merged.

authors: Shadi brian-brazil

repo: prometheus/docs


text:
Fix the sample for Apdex score

Please refer to the link of Apdex score:
https://en.wikipedia.org/wiki/Apdex
There is an example which demonstrate the score method:
if there are 100 samples with a target time of 3 seconds, where 60 are
below 3 seconds, 30 are between 3 and 12 seconds, and the remaining 10
are above 12 seconds, the Apdex score is:
Apdex3=(60+30/2)/100=0.75
So the sample need to fix against the method.
Signed-off-by: shangxdy shang.xiaodong@zte.com.cn

Sorry for late response. Just randomly stumbled upon this.
The original example is correct. That's because the Prometheus histogram buckets are cumulative. In your example, the calculation works out as follows:

The 3s bucket is 60 and the 12s bucket is 60+30=90.
60+90 = 150
150/2 = 75
75/100 = 0.75


text:
Add diskstats

Added parsing of /proc/diskstats and /sys/block/<device>/stat

Related to https://github.com/prometheus/node_exporter/issues/1179

Re-factored to use a single struct shared between procfs and sysfs since the fields should be identical.

repo: prometheus/procfs


text:
External labels hide metrics on the remote read endpoint

What did you do?
I tried the remote read API with the following master and slave configurations.
master (listening localhost:9090):
global:
  external_labels:
    role: master

remote_read:
- url: http://localhost:9091/api/v1/read

scrape_configs:
- job_name: prometheus
  static_configs:
  - targets:
    - localhost:9090

slave (listening localhost:9091):
global:
  external_labels:
    role: slave

scrape_configs:
- job_name: prometheus
  static_configs:
  - targets:
    - localhost:9091

Then, I ran a PromQL on the master Prometheus.
What did you expect to see?
We should get metrics ingested by both the master and the slave.
What did you see instead? Under which circumstances?
By running a query such as up{job="prometheus"}, I got only metrics ingested by the master.
$ curl -s 'http://localhost:9090/api/v1/query?query=up\{job="prometheus"\}' | jq .data.result[].metric
{
  "__name__": "up",
  "instance": "localhost:9090",
  "job": "prometheus"
}

NOTE: If we stop using the external labels on master Prometheus, the query shows both metrics by the master and the slave.
global:
  # external_labels:
  #   role: master

remote_read:
- url: http://localhost:9091/api/v1/read

scrape_configs:
- job_name: prometheus
  static_configs:
  - targets:
    - localhost:9090

$ curl -s 'http://localhost:9090/api/v1/query?query=up\{job="prometheus"\}' | jq .data.result[].metric
{
  "__name__": "up",
  "instance": "localhost:9090",
  "job": "prometheus"
}
{
  "__name__": "up",
  "instance": "localhost:9091",
  "job": "prometheus",
  "role": "slave"
}

Environment

System information:
Darwin 16.7.0 x86_64

Prometheus version:
prometheus, version 2.0.0-rc.2 (branch: master, revision: 7aa2930ac592f7ac94b7dc76669bf33b217fce4c)
build user:       kkohtaka@sirius.local
build date:       20171026-14:49:58
go version:       go1.8.3

Matchers for external labels are always added to a remote read query. Is that a correct behaviour?
https://github.com/prometheus/prometheus/blob/master/storage/remote/read.go#L70

This behaviour is correct and intended, as the data in the slave Prometheus does not have a role=master label and thus does not match the query up.
For this sort of setup to work your slaves need to have the same external labels as the master, plus an extra label to distinguish the slaves.

Thanks, I confirmed that I can fetch both metrics from the master and the slave by using the following configurations.
master:
global:
  external_labels:
    cluster: foo
...

slave:
global:
  external_labels:
    cluster: foo
    slave: 'true'
...

$ curl -s 'http://localhost:9090/api/v1/query?query=up\{job="prometheus"\}' | jq .data.result[].metric
{
  "__name__": "up",
  "instance": "localhost:9090",
  "job": "prometheus"
}
{
  "__name__": "up",
  "instance": "localhost:9091",
  "job": "prometheus",
  "slave": "true"
}

I understand the current behaviour and design but I don't know if they are the best. Adding the same external labels as the master to the slave seems unnecessarily large requirement because external labels are not only used for remote endpoints but also federations and alertmanagers.

slave: 'true'

This isn't quite right. You need a different value per slave. If you only have one slave, then you shouldn't be using remote read - rather merge the slave into the master.

Adding the same external labels as the master to the slave seems unnecessarily large requirement because external labels are not only used for remote endpoints but also federations and alertmanagers.

That is the whole point of external labels. They uniquely identify the Prometheus server, so data from different Prometheus servers doesn't get mixed up.

slave: 'true'

This isn't quite right. You need a different value per slave. If you only have one slave, then you shouldn't be using remote read - rather merge the slave into the master.

Aha. I will choose a different value per slave in an actual environment.

Adding the same external labels as the master to the slave seems unnecessarily large requirement because external labels are not only used for remote endpoints but also federations and alertmanagers.

That is the whole point of external labels. They uniquely identify the Prometheus server, so data from different Prometheus servers doesn't get mixed up.

OK. I understand that we should use a set of external labels as an identifier of Prometheus instance.

authors: brian-brazil kkohtaka

repo: prometheus/prometheus


text:
Failing with "opening storage failed: repair corrupted WAL"

I have a federated setup of Prometheus 2.15.2 which recently started to show gaps and throwing a lot of errors like:
caller=db.go:609
component=tsdb
msg="compaction failed"
err="reload blocks: head truncate failed: create checkpoint: read segments: corruption in segment /prometheus/wal/checkpoint.049194/00000000 at 96731136: unexpected non-zero byte in padded page"

So I removed /prometheus/wal/checkpoint.049194 but that just gave me these:
caller=main.go:740
err="opening storage failed: repair corrupted WAL: cannot handle error: open WAL segment: 0: open /prometheus/wal/00000000: no such file or directory"

Not sure what I'm supposed to do with that. I just fails every time I try to start it.

The documentation for 1.8 recommends:

If you suspect problems caused by corruption in the database, you can enforce a crash recovery by starting the server with the flag storage.local.dirty.
https://prometheus.io/docs/prometheus/1.8/storage/#data-corruption

But when I tried using --storage.local.dirty I got back:
Error parsing commandline arguments: unknown long flag '--storage.local.dirty'

So that option is no longer there, but I can't find an alternative here:
https://prometheus.io/docs/prometheus/2.16/storage/

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

authors: brian-brazil jakubgs


text:
Filter values when using range vectors

Hello,
I am using the following query in order to get a range vector:
api_timing{api_name="<NAME>"}[1d]
Next, I want to get the average of the range vector. To do that, I am using avg_over_time - BUT, when there is a single NaN value inside the range vector, the operation returns NaN. I tried to run:
avg_over_time(api_timing{api_name="<NAME"}[1d] >=0)
and got the following error:
Binary expression must contain only scalar and instant vector types

I think that it is very important to allow filtering values from range vectors. We would like to see it in the next versions of Prometheus.
Thank you!

The NaN result is correct, and in general averaging averages will produce incorrect results. More generally it makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

authors: amiryeshurun brian-brazil


text:
Remote write should best-effort start from a checkpoint instead of time.Now

Right now remote write starts sending samples with a timestamp after time.Now() when Prometheus started (more or less). On restart or config reload if remote write wasn't able to flush it's pending samples cleanly or was behind for some reason there will be samples missing in the remote storage. If remote write always starts from a checkpoint in some kind of checkpoint file for it's queue name/config hash we can avoid that situation.
see: https://github.com/prometheus/prometheus/pull/7710

I'm actually working on this at the moment, based on Nicole's original branch.
The main thing is that if the checkpoint file is not present, or if the segment mentioned in the checkpoint file no longer exists, we start from time.Now() as we do currently.

relevant "feature" requirements: https://github.com/prometheus/prometheus/pull/9862#issuecomment-979471947

Here is an idea how we can do it:
For alerting rules, we make use of TSDB to store the "for" state of alerting rules, and after a restart we use these metrics to restore the state. Note that this metric is not exposed, rather directly put into TSDB.
Similarly, how we expose the highest timestamp remote-written, we could ingest something similar to TSDB regularly (like the highest timestamp remote-written, or the WAL file number and the offset up to which it was written), and use this during startup to start remote-write from where we left. With the highest timestamp remote-written, we might still lose some samples (for example smaller timestamp present later in the WAL).
PS: it might not be a good idea to remove the highest timestamp metric from the /metrics output. So if we want to do it this way, we need to ingest the same metric under a different name into TSDB.

@codesome We've been calling this feature "remote write checkpointing" so I'll refer to it as that here. Regardless of the mechanism we use for deciding what to write (I still think either just the segment # or a bytes/record offset into a segment is the most accurate) the main source of complexity is going to be indicating from remote write to the checkpointing code that up to that offset has been successfully written to the remote endpoint. IMO Right now we don't have boundaries we can easily delineate on except segment files, and because data coming into remote write is split across all shards we would need to accept a signal from the Watcher saying "I've sent you all the data for segment X" and then ensure that all the buffered samples from that point in time have been batched within a shard and successfully sent.

I would suggest extending this idea to allow a queue to prevent the deletion or truncation of the WAL to prevent data loss, I wasn't aware myself that it was this easy to skip/lose data in remote write.
Postgres has this feature called “slot”, which, when activated, ensures that the sender does not delete the WAL until it has been received: https://www.postgresql.org/docs/16/warm-standby.html#STREAMING-REPLICATION-SLOTS

Remote write has no ownership over the WAL, that would have to be okay-ed by the TSDB maintainers. If we were to have something like that it would need some kind of a time or size limit, the WAL should not be allowed to consume disk endlessly.

Yes, Postgres ended up adding some safeguards for that:  max_slot_wal_keep_size e.g.

@codesome @bwplotka @jesusvazquez are TSDB maintainers, they have final say on something that would change the WAL behaviour

Hello from the bug scrub: this seems like an important issue considering it can lead to data loss. @cstyan @codesome @bwplotka @jesusvazquez @rfratto do you agree it can lead to data loss? In which case we should find an owner to push this.

I agree this can cause data loss. The most obvious instances are due to a crash or restart, but a "restart" can also include surprising cases like Kubernetes moving a pod to a new node, where a user may not expect data loss to occur.

Hello from the bug scrub: this seems like an important issue considering it can lead to data loss. @cstyan @codesome @bwplotka @jesusvazquez @rfratto do you agree it can lead to data loss? In which case we should find an owner to push this.

Yes, 100% it can cause data loss. Making an improvement here is most relevant for agent-mode, Grafana Alloy/Agent, and components like Loki rulers, since in those modes there's no persistent storage of TSDB data but only the WAL. In these cases the WAL is not useful after a restart of the process. This has lead to less than ideal operations when on-call, like just deleting the entire WAL when the disk is nearing capacity or the process is OOM crashing.
I would be more than happy to guide someone through an implementation here, but I may not be able to until after the summer since I have already committed to a mentorship each for GSoC and LFX. I'd appreciate if anyone else could step in in the meantime if someone does express interest in working on this.

I would be more than happy to guide someone through an implementation here, but I may not be able to until after the summer since I have already committed to a mentorship each for GSoC and LFX. I'd appreciate if anyone else could step in in the meantime if someone does express interest in working on this.

@cstyan I'd be more than happy to learn and collaborate in this one, I'm not that much active in the conversation since I've been selected as Grafana Champion so I had other commitments as well, but I'd try my best to take out my time to contribute to this one.

Seems like this directly affects the Prometheus Agent mode and any configuration with remote-write (the DaemonSet model which we are working on over at Prometheus-Operator, for example). I am wiling to contribute as well!

It would impact Prometheus in either mode (the agent is really only used for remote write) when using remote write, as well as Grafana Agent + Grafana Alloy, or anything else that imports and uses Prometheus' Remote Write code.
Anyone who wants to work on this is welcome to. Ping me here or in the #prometheus-dev channel on the CNCF slack if you have questions.

Anyone who wants to work on this is welcome to. Ping me here or in the #prometheus-dev channel on the CNCF slack if you have questions.

@cstyan I would like to work on this

And I can help push this.
I'll start a doc to summarize all of what was tried before (I can see at least 3 closed PRs that tried to address this in different ways), and to initiate a discussion about how we want to proceed.

I believe this is impacting us in our largest Prometheus instances. Here, WAL replay can easily take 2+ minutes for our largest instances. In this circumstance, we see a gap similar to the WAL replay duration where metrics have not been shipped.

I pushed https://github.com/prometheus/prometheus/pull/14829 (for the first step: having a stateful watcher)
I'll share the doc explaining what's going there and the next steps.

authors: Sheikh-Abubaker codesome cstyan djluck krajorama machine424 mviswanathsai rfratto


text:
Preallocate Labels in labels.Builder

This tries to avoid re-allocations of labels slice since we know possible max size
Signed-off-by: Łukasz Mierzwa l.mierzwa@gmail.com

Thanks!

Whilst I think this is probably the right thing to do, I don't find the description a slam-dunk: potentially this is over-allocating hence making the whole Prometheus heap bigger, which will slow it down and stop it working at all in some situations.
Can you show some benchmarks?

We're appending in a loop so I don't think there's any risk of over-allocating. Unless you're referring to the second change here?

If the label already exists then an entry in ‘add’ is actually an ‘overwrite’ so the destination will not need to grow.

If the label already exists then an entry in ‘add’ is actually an ‘overwrite’ so the destination will not need to grow.

Raised #10756 to revert that, thanks

authors: bboreham prymitive roidelapluie


text:
Discovery: Add support for NS records to DNS Discovery

I need the ability to monitor dynamic nameservers for a DNS zone.
This PR  adds the ability to get a list of targets based on NS records.

Thanks!

authors: djcode roidelapluie


text:
Consul SD: Include health check information in meta data

This is a first sketch of an implementation of #770. May need some more work. I'd appreciate some early feedback.
Fixes #770

I think you've got your labels the wrong way around, this should go from check -> state.
How many additional RPCs to consul does this add?

I'll double check the labels.
The number of RPCs is a valid concern which I also noticed. I'd say it's about two additional RPCs per Node and Service. Which is quite a lot. Don't know if this is worth it. Will try to clean this up as much as possible within the next days.

We've had other issues where it appears that the consul client isn't reusing tcp connections, so I'd be very wary of adding more RPC until that is fixed on their end.

Did some more testing (no code changes so far).
The label mapping of state -> checks is implemented as suggested by @fabxc in https://github.com/prometheus/prometheus/issues/770#issuecomment-112062345. I can turn it around to be __meta_consul_health_<check>=<state> if you think that makes more sense. IMHO both ways have some merit.
The current implementation allows for relabeling rules like:
    - source_labels: ['__meta_consul_health_passing']
      regex: '.*,serfHealth,.*'
      action: keep

The downside of this implementation is definitely the additional RPC calls to Consul. Given a large number of Consul services this may very well be an issue.
If you think the general approach makes sense we should keep it around until we're sure the Consul issues are fixed on their side.

Hi, where are we with this PR? This is one of our missing puzzle pieces to have this information. Regards Per

Larger users are running into performance issues with Consul, so more RPCs does not seem wise. In addition you should be trying to scrape targets even if some are reported as unhealthy. Thus I don't think this makes sense on balance.

authors: brian-brazil dominikschulz perbly


text:
initial service discovery extension

This is basically working (minus tests) but not meant to be a finished PR. Just a base for discussion.
Prometheus should be able to integrate with different discovery services, which requires some external changes.

Counters: changing prometheus' internal counters should be straightforward
Config: I think my general idea is easy to understand. Being able to provide a list of servers instead of a config filepath is probably more reasonable for ZK, consul and etcd, though.
Integrating consul and ZK as well should be straightforward.

The roadmap mentions a possible plugin system for discovery. Are there any existing ideas. Providing a generic target provider which queries a set of urls for lists of targets (in some predefined formats) would be straightforward.
Thoughts?

Hey, interesting, thanks! I'll take a look at this later, but needless to say, how we will integrate different service discovery mechanisms is a pretty major decision that is going to affect Prometheus for years to come (especially since SD details leak through to a lot of other implementation details - what labels to attach, etc.) and won't be easy to change once we decide to go one way. So expect this to take a bit of time to get figured out... but it's definitely something we need to address soon. In general though, for major things like this it probably makes sense to start a small design doc first. That is, just a Google doc outlining the goals, the approach (how to solve different aspects: configuration / actual SD implementation / label attaching / handling commonalities and differences between different SD types...), and open questions, and then having people comment on that.

I'm using https://github.com/kelseyhightower/confd to generate my prometheus.conf from etcd data. Only (minor) issue right now is that prometheus needs a full restart when config changes.
Using tools like this and adding config reload signals (like nginx) might help you prevent SD details/implementation leaking into prometheus itself. Adding a config validation command (like nginx and others) would make it even better.
Just my two cents, thanks for a great tool!

@jimlar Thanks! Yes, restartless config changes are on the roadmap (http://prometheus.io/docs/introduction/roadmap/). Mainly, they'll need a bit of refactoring to swap out all the in-process state in-flight. Also on the roadmap is more generalized support for different types of SD. We will have a certain number of core mechanisms built in, while we'll have generic support via a textfile SD mechanism. We've already hashed out parts of the design, but need to pick it up again. Hopefully will happen soon[tm].

Closing in favor of new SD design that @fabxc is working on.

authors: fabxc jimlar juliusv


text:
Increment dirty counter only if setDirty(true) is called.

Currently, we increment the counter even if setDirty(false) is called,
which sets the storage clean.
@juliusv

:+1:


text:
Upload of output directories within container

Currently the upload of output files & directories is done outside the container. In some cases it may make sense to do this from within the container (?) However, if there are multiple tasks, what to do?

Closing this. Will re-open if there is an actual use case for this.

repo: prominence-eosc/prominence


text:
ci: fix deprecation messages

@gechetspr this fixes the deprecation warnings in GitHub actions.

Hey! Sorry for long responses. Last week before Christmas is a bit busy. I'll check your PRs next week or first week next year if you don't mind.
Regarding access to the repo, @PhilinTv is your man :)

authors: gechetspr smhg

license: mit


text:
Split lint commands

fixes #776
restructures the linting (eslint+prettier) into scripts specific to each package. This allows for overriding how the linting is done per package, what files are included, etc. Also simplifies the top-level linting scripts
blocked by #904
fixes #609
fixes #608
blocked by #902

superseded by #909

repo: prosopo/captcha


text:
🛑 drand.love is down

In e58fbaf, drand.love (https://drand.love) was down:

HTTP code: 522
Response time: 166 ms

Resolved: drand.love is back up in ac9acae after 7 minutes.

repo: protocol/upptime-pln


text:
🛑 dist.ipfs.io is down

In c56a3cc, dist.ipfs.io (https://dist.ipfs.io) was down:

HTTP code: 504
Response time: 5044 ms

Resolved: dist.ipfs.io is back up in 8beca2d after 1 hour, 34 minutes.


text:
Send a notification to the 'old' email address

Inspired by this tweet:
https://twitter.com/HelloAidanCasey/status/1427700895513464841

+1

@pascalbaljet sorry about the ping but I couldnt tag brady in here for some reason and I can see you updated his feature/notify-old-email branch. Any chance of getting this in? This is the only thing missing for me

@pascalbaljet sorry about the ping but I couldnt tag brady in here for some reason and I can see you updated his feature/notify-old-email branch. Any chance of getting this in? This is the only thing missing for me

You probably couldn't tag me because I haven't created an issue or commented on one before. I'm also no longer working at Protone Media.
Just realized I also implemented a feature in this branch to recover an account after their email address has been changed. I believe this needs some more testing, because of the risks it could bring if there's something wrong or not working.
I'm also hoping this will get merged soon 😁

authors: aeq-dev bradyrenting mattvb91 pascalbaljet

repo: protonemedia/laravel-verify-new-email


text:
fix(erc777) <- rm bytecode generator since it's no longer used.

...per title.
The core no longer accepts a bytecode argument and so this feature is now superfluous.

Closed in #26.


text:
Change the "Back to custom filters" link text within Saved filters

[ ] Breaking change? (if so, please describe the impact and migration path for existing application instances)

What changes did you make? (Give an overview)
Change the "Back to custom filters" link text within Saved filters
Is there anything you'd like reviewers to focus on?
How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

[ ] No need to
[x] Manually (please, describe, if necessary)
[ ] Unit checks
[ ] Integration checks
[ ] Covered by existing automation

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
[x] My changes generate no new warnings (e.g. Sonar is happy)
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged

Check out Contributing and Code of Conduct
A picture of a cute animal (not mandatory but encouraged)

@winnie-chiu thank you

authors: Haarolean winnie-chiu

repo: provectus/kafka-ui


text:
feat(azure): add new check related with Public IPs in Shodan.io

Context
This pr adds a new check:

network_public_ip_shodan

and fixes typo in all tests that don´t include azure_fixtures
Description
This check ensures that no public ip addresses are shown in shodan
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

No merge until https://github.com/prowler-cloud/prowler/pull/3432 is merged

repo: prowler-cloud/prowler


text:
Allow leading underscores for idents

As briefly discussed on discord, this adds support for leading underscores in front of any idents.
In my case, this will allow us to get rid of a lot of s-strings!
This is my first rodeo both with prql's code base as well as Rust & pest – a through review is probably wise.

Great, thanks @mklopets !

authors: max-sixty mklopets

repo: prql/prql


text:
Discussion: better (?) typing suggestion for AbstractController::createForm

Current definition is the following:
https://github.com/psalm/psalm-plugin-symfony/blob/fb801a9b3d12ace9fb619febfaa3ae0bc1dbb196/src/Stubs/5/Bundle/FrameworkBundle/Controller/AbstractController.stubphp#L18-L26
I suggest to change it to:
    /**
     * @template TData
     * @template TFormType of FormTypeInterface<TData>
     *
     * @psalm-param class-string<TFormType> $type
     * @psalm-param TData $data
     *
     * @psalm-return FormInterface<null|TData>
     */
    protected function createForm(string $type, $data = null, array $options = []): FormInterface {}

What has changed:

TData $data parameter added
null|TData generic parameter changed for the return type

Why: this would allow check the $this->createForm(FormType::class, ['rubbish']) compatibility: if the FormType does not extend AbstractType<array{0: 'rubbish'}> then it will be marked as incompatible.
Thoughts?

Good idea, it makes perfect sense. But why return nullable FormInterface<null|TData>?
FormInterface:getData already returns null|TData. It has to, because create methods don't pass $data parameter, which then triggers empty_data callback.

But why return nullable FormInterface<null|TData>

Because createForm's second argument $data is declared as having = null by default in symfony, and having generic parameter nullable was the only way I could find working to make psalm happy about type-checking it.

FormInterface:getData already returns null|TData. It has to, because create methods don't pass $data parameter, which then triggers empty_data callback.

Indeed, but psalm wasn't accepting it :shrug: So it was more like - overcoming the psalm limitation, than a thoughtful decision :-D

authors: zerkms zmitic

repo: psalm/psalm-plugin-symfony


text:
Question about auto reconnect

Hi,
I'm using the ESP32-A2DP library and i'm not sure about the auto reconnect feature.
I try to build a speaker with a power save mode and therefore  i want to stop Bluetooth sink when entering power saving. It works for me when using a2dp_sink.end(false) and restart it with a2dp_sink.start(true, true) which sould use the auto reconnect feature (but it doesn't work).
Isn't it working as aspected or do i use the functions not as intended?
Kind regards
Franz

By calling end() you basically indicate that you do not want to reconnect.
What happens if you don't call end ?

If I don't call end the device will stay connected. Any other options to disable bluetooth and activate it later again?

You can try disconnect() ?

I'm getting core panic exceptions as soon as i call end method (without any own code).
Is there an option to make device not visible?

Depends what you mean with this and your IDF release.
Maybe you look for set_discoverability()

Thx. When i manage visibility, scan_mode and last connection on my own everything works as aspect. Shall i close the issue or do you want to look after twice end call?
Really appreciate your help :)

I suggest that you close.

authors: franzSusemichel pschatzmann


text:
Pull in updates from upstream.

This is a rather ham-fisted way of requesting that changes made in the upstream repo be pulled in, and an updated package published.
Of particular interest is commit 7047832, which fixes a TLS issue with the latest i7 firmwares.
Home Assistant makes use of the published python package, which causes it to bomb out for users of the newer vacuums.
I would have settled for opening an issue, but that doesn't seem to be enabled on this repo.

This isn't mergable right now. Can you resolve the conflicts, @crkochan ?

For what it is worth I just pulled in the TLS changes and released 1.4.2.
Please rebase this PR.

Actually changes which @crkochan requires already in repo.
Package was released few days ago and version also updated in home-assistant. Just wait for release

Actually changes which @crkochan requires already in repo.
Package was released few days ago and version also updated in home-assistant. Just wait for release

öhm, what?

Actually changes which @crkochan requires already in repo.
Package was released few days ago and version also updated in home-assistant. Just wait for release

öhm, what?

just ignore, didn't see you previous comment about changes and release :)

authors: crkochan freekode pschmitt

repo: pschmitt/roombapy


text:
Import Special Member names

LionPATH will soon be providing us the names of Special Members in a new column in the committee member CSV they provide.  We should adjust our importer to store this data so authors do not have to input it themselves.  Waiting to hear back from the LionPATH group.  They will let us know when they have implemented this on their end.

The LionPATH team has completed this work and released the changes to their production SFTP server.  A couple things to note:

The new headers are "Special Member First Name" and "Special Member Last Name"
Many of the names are in all-caps.  I don't think we should store these this way in ETDA.  We may want to confirm that changing these is OK with the grad school, but we should apply some algorithm to make the names properly name-cased.


text:
manual annotations

Dear psweens,
First of all, I want to thank you for your significant contribution to the vessel segmentation community.
One question: Are you willing to share your manual annotations with the community?
I would highly appreciate this and obviously also reference your work adequately.
Thanks in advance for your time and effort.
Best,
Bastian

Hi Bastian,
Thanks for your interest.
Which manual annotations are you referring to?
Cheers,
Paul

Dear Paul,
Sorry for being so vague.
Specifically, I am referring to the experimental photoacoustic datasets (Table 6 in supplement).
Would be highly appreciated!
Best,
Bastian

Hi Bastian,
No problem. You'll need to email Sarah Bohndiek (emails are here https://www.bohndieklab.org) to request the photoacoustic datasets as sadly they're not mine, and the biological study for the PDX tumours models has yet to be published. Feel free to cc me in the email.
The simulated photoacoustic images as well as the synthetic vascular labels will be released when the VAN-GAN manuscript is published - I hoping this will be in the next month or two.
Cheers,
Paul

authors: bwittmann psweens

repo: psweens/VAN-GAN


text:
Implement From instead of Into

This should work with Rust 1.37.0

Thanks!

authors: dalcde psychon


text:
Update config.json

feat cdn &tags

抱歉！该站点已经被管理员停止运行，请联系管理员了解详情！🤔

www.ptzone.xyz 似乎也可以访问

这是7月新开的站啊，在运营啊。只是加了个cdn

你是sysop？cdn是另一个宝塔？现在没开起来，是这个意思？

site尾缀前段时间用来升级测试的，现已完成，昨晚已经恢复正常使用了。2个网址同一个网站了。

像我之前说的，现有的url也要写到cdn里。
并且最前面的会在扩展里最优先使用（虽然这一块造成了一点问题）

repo: pt-plugins/PT-Plugin-Plus


text:
nvim-base16 not loaded before lualine

Plugin affected: nvim-base16 & lualine
Nixpkgs channel: nixpkgs-unstable
Home-manager version: Release 23.11
Description
I get the following warning from Lualine when opening a file.
theme(base16): nvim-base16 is not loaded yet, you should update your configuration to load it before lualine so that the colors from your colorscheme can be used, fallback to "tomorrow-night" theme.
Config
{ config, pkgs, ... }:

{
  programs.nixvim = {
    #
    enable = true;

    #
    colorschemes.base16 = {
      enable = true;
      colorscheme = "${config.colorScheme.slug}";
    };

    #
    plugins = {
      ... # (shortened for brevity)
      lualine.enable = true;
    };
  };
}

I was not able to reproduce with the following minimal config:
      {
        # inherit pkgs;
        module = {
          colorschemes.base16 = {
            enable = true;
            colorscheme = "circus";
          };
          plugins = {
            lualine.enable = true;
          };
        };
      };

What is the value of your ${config.colorScheme.slug} ?

I was not able to reproduce with the following minimal config:
{
  programs.nixvim = {
    colorschemes.base16 = {
      enable = true;
      colorscheme = "circus";
    };
    plugins = {
      lualine.enable = true;
    };
  };
};

What is the value of your ${config.colorScheme.slug} ?

That's strange. I'm able to replicate the issue just adding enable = true to that config.
programs.nixvim = {
  enable = true;
  colorschemes.base16 = {
    enable = true;
    colorscheme = "circus";
  };
  plugins = {
    lualine.enable = true;
  };
  extraPlugins = with pkgs.vimPlugins; [
    nvim-base16
  ];
};

Ok, I was indeed able to reproduce.
The message could be seen by calling :LualineNotices.
Intuitively, you could think that this error makes no sense because you added nvim-base16 to your extraPlugins.
However, the error happens because both base16-vim and nvim-base16 are installed simultaneously.
If you remove nvim-base16 from extraPlugins and instead you set colorschemes.base16.package = pkgs.vimPlugins.nvim-base16, the error will be gone !
I have just proposed to switch to nvim-base16 as a backend in #474. Hence, you would not have to do anything :)

authors: GaetanLepage omernaveedxyz


text:
feat(VsForm): create vs-form component & form composable

Type of PR (check all applicable)

[x] Feature (feat)

Summary
vs-form component와 form-composable을 추가
Description

input component들이 form spec을 이용할 수 있도록 form-composable을 추가

Venus에서는 input composable 로직에 섞여 있었으나 form spec만 별도 파일로 분리

vs-form component와 test 추가
Random ID를 만들기 위해서 nanoid 를 dependency로 추가
string util test code 추가

사소한거긴 한데 다른 MR들에서는 컴포넌트 추가는 주로 'add' 로 시작도록 작성한 것 같아요

authors: smithoo yeriiiii

repo: pubg/vlossom


text:
hi can someone help me i want to ask questions in github but iam lost

Thanks for looking to open an issue for this project.
If you are opening an issue to suggest adding a new entry, please consider opening a pull request instead!

?

authors: SecHex rtretrtet

repo: public-apis/public-apis


text:
KVB: Fix typo in bitmask for regional transit

I noticed that the KVB HAFAS bitmask for regional transit didn't look quite right when importing it into https://github.com/derf/Travel-Status-DE-DeutscheBahn. According to my tests, the bitmask should be 16 instead – 64 does not give any results.

can confirm, thanks!

authors: derf vkrause

repo: public-transport/transport-apis


text:
Fix CI

Currently, your GitHub Actions is kinda broken due to a missing library.
My PR resolves this.

Thanks for pointing it out!

repo: pudnax/pilka


text:
WebSocket connection Error

In chrome://extensions/?errors=onpiiolicjjcilbnkdgkajnpknndneom:
WebSocket connection to 'ws://localhost:8000/socketcluster/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

Do I have to run websocket server locally somehow? I just followed the installation steps:
npm install
npm run build
chrome://extensions
LOAD UNPACKED

FYI: I picked the directory <path>/hls-downloader-chrome-extension/build/ when loading unpacked extension. Since the readme doesn't mention which directory to load, I guess it's the build directory, but not sure.

Hi, it's caused by the remote redux Dev tools.
src/modules/store/index.js
const composeEnhancers = composeWithDevTools({ realtime: true, port: 8000 });

@puemos thank you very much for your quick reply. I am not a nodejs developer so I am not sure what the real problem is. Since you add a bug label here, does it mean I just need to wait until the bug gets fixed? :) thanks a lot.

yeah sure! probably this weekend

Solved!
you can ignore the error msg or use remotedev-server

repo: puemos/hls-downloader-chrome-extension


text:
Angular.js Integration with NgRoute

Hi,
I am using your template for my project... when I try integrate Angular.js Routing then UI css behaves strange, it works perfectly if i remove ngRoute but in my application I need to use ngRoute. you can see the result in screen short which I took.. plus signUp page doesn't even appear too

Hi,
I just came to know about the problem but couldn't figure out how to solve it.....
The issue is that when I try to use ngRoute of Angular so my login Template behaves as a div and and the class login doesn't works in the div as body class overrides it. I have the screen shot to show you more clearly

http://stackoverflow.com/questions/20943820/angularjs-changing-body-class-using-global-variable

Unfortunately we do not have a AngularJS version for this and since you got some guidance we will close this ticket for now.

authors: AndreiCN atais hrizvi

repo: puikinsh/gentelella


text:
Unable to Run floogen Command with Example Configuration

I am unable to run the floogen command as described in the README. I installed Bender and added a few print and debugging statements to link.py to understand the issue. However, I am encountering the following errors when I run the command. I used the example provided in the README as my configuration file.

Any guidance on how to resolve this issue would be greatly appreciated. Thank you for your help.

The issue was resolved by updating the protocol names in the Example configuration file to adhere to the naming conventions expected by the code. By ensuring that the protocol name is axi, the tool could correctly process the configuration and generate the desired NoC architecture. If you encounter similar issues, please ensure your protocol names in the configuration file follow the required naming conventions.

repo: pulp-platform/FlooNoC


text:
[FEATURE] Differential Equations

Desired Feature
Enable definition of [partial] derivatives with an arbitrary number of infinite parameter dependencies.
Where would this be applicable?
This is relevant in dynamic and space-time problems with ODEs and/or PDEs.
What is currently done?
Currently these have to be transcribed manually using user-defined point variables to implement, methods such as finite differences. Measures can also be used for ODEs.

Proposed additions:

Add DerivativeVariables, ReducedDerivativeVariables, and PointDerivativeVariables with associated references
Add @derivative_variable() to symbolically add derivative variables outside of expressions
Add derivative() to define derivatives in constraints including parsing expressions appropriately into derivative variables (e.g., using the product rule)
Extend the operators to handle the new variable types
Extend is_used, parameter_refs, and similar appropriately
Extend measure expansion methods to handle the new types


text:
Optimization for SEO

@cnunciato this page is already quite well optimized; the main changes are to get the primary focus KW in the metadata ("Azure provider"). "Azure resource group" and "Azure support" are secondary keywords that we are trying to tackle, so if I mislabeled the example by calling it a resource group, hopefully there's a way to fix that while still keeping the keyword.

Proposed changes

Unreleased product version (optional)

Related issues (optional)

PR now being tracked in https://github.com/pulumi/docs/pull/2514. Closing

repo: pulumi/docs


text:
The resourceCollectionEnabled setting does not work

What happened?
The resourceCollectionEnabled does not work as expected.
Example
Here is my code:
const awsDatadogIntegration = new datadog.aws.Integration('aws-datadog-integration', {
      accountId: accountId,
      roleName: 'datadogIntegrationRole',
      resourceCollectionEnabled: 'true',
      })

then apply with pulumi up and double-check to see the setting has been toggled or not in Datadog Web Console.
Expected: The toggle is set to Enabled
Actual: The toggle is still sitting as Disabled
Output of pulumi about
% pulumi about
CLI
Version      3.111.1
Go Version   go1.22.1
Go Compiler  gc

Plugins
NAME    VERSION
nodejs  unknown

Host
OS       darwin
Version  14.3.1
Arch     arm64

This project is written in nodejs: executable='/Users/tle/.asdf/shims/node' version='v20.11.1'

The @pulumi/datadog is 4.27.0
Additional context
I have not verified whether this might be the bug of upstream 3.38 tf plugin driver.
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @runlevel5. Thanks for raising this issue and providing a clear repro. We'll take a look as soon as possible.

Hi @runlevel5. That property has been deprecated in the latest version of this provider. Can you upgrade to pulumi-datadog v4.28.0 and try again? resourceCollectionEnabled has been deprecated in favor of extendedResourceCollectionEnable.

Great thanks. I confirm the 4.28 fixed the issue.

repo: pulumi/pulumi-datadog


text:
update to 1Password logo

Description
Update to 1Password logo
fixes https://github.com/pulumi/pulumi-hugo/issues/3962

I think we need to update the other graphic on this page too:

authors: interurban isaac-pulumi

repo: pulumi/pulumi-hugo