text:
v1.11 backports 2022-04-05

#19259 -- pkg/k8s: use a single HTTP Client for all kube-apiserver connections (@aanm)

Minor conflict on imports in pkg/k8s/init.go.

#19276 -- docs: Clarify use of the eni.subnetTagsFilter option (@gandro)
#19258 -- ipcache: Add test asserting out-of-order Kubernetes events (@christarazi)
#19290 -- k8s: Use kubelet's logic to close all idle connections (@christarazi)

Minor conflict on imports in pkg/k8s/init.go.

#19307 -- workflows: Use docker manifest inspect for waiting images (@YutaroHayakawa)

Minor conflicts on workflow files that don't exist in v1.11.

Once this PR is merged, you can update the PR labels via:
$ for pr in 19259 19276 19258 19290 19307; do contrib/backporting/set-labels.py $pr done 1.11; done

/test-backport-1.11

/test-1.20-4.9

/test-1.23-4.9

/ci-gke-1.11

/test-runtime

Runtime is broken with https://github.com/cilium/cilium/issues/18919. k8s-1.23-kernel-4.9 failed with known flake https://github.com/cilium/cilium/issues/18318. All reviews are in. Merging.

authors: YutaroHayakawa pchaigno


text:
DO NOT MERGE - testing Jenkins

Testing configuration of Jenkins using VBoxSVC as a systemd service.

Closing as VBoxSVC has been functioning well as a systemd service on the build slaves.

source: gharchive/pull-request

repo: cilium/cilium

license_type: permissive

license_source: github-api


text:
Add documentation about kvstoremesh

This PR extends the clustermesh documentation with information about the new Cilium CLI helm mode, and kvstoremesh. The PR is ready for review, but marked as blocked because the Cilium CLI has not yet been extended with the new --enable-kvstoremesh flag.

Last force push just added an additional note that kvstoremesh is a beta feature close to the instructions to enable it:
-  You can additionally opt in to :ref:`kvstoremesh` when enabling Cluster Mesh.
-  Make sure to configure the Cilium CLI in *helm* mode and run:
+  You can additionally opt in to :ref:`kvstoremesh` (beta feature) when enabling
+  Cluster Mesh. Make sure to configure the Cilium CLI in *helm* mode and run:

I've bumped the CLI version mentioned in the clustermesh docs to v0.14.8, as it will be the one supporting all clustermesh operations using helm, as well as including the --enable-kvstoremesh flag. I'm going to remove the blocked label from this PR once that gets released.

Cilium CLI v0.14.8 got released. Marking as ready to merge


text:
ci-ginkgo: conditionally skip fetching artifacts & junit report

Currently, the steps "Fetch artifacts" & "Fetch JUnits" always fail if previous steps failed or were skipped.
Example: https://github.com/cilium/cilium/actions/runs/5665714884/job/15351067055
Therefore, this commit skips the steps conditionally based on the preconditions:

"Fetch artifacts" -> "Privision LVH VM" was successful
"Fetch JUnits" -> "Run tests" was not skipped

/test


text:
endpointmanager: Simplify Conntrack garbage collection launch code

This code used a confusing bool and triggering global map CT inside an
endpoint loop. Shuffle the code around to make it easier to understand.

This change is

test-me-please

test-me-please

test-me-please

Failed to provision again. I realised it was because of go fmt.

test-me-please

test-me-please


text:
Fix monitoring BPF maps

Tetragon exposes metrics about BPF maps, defined in the mapmetrics package. There are a few issues with them:

[ ] Map capacity is exposed as total label in tetragon_map_in_use_gauge metric (and also, for eventcache it's set to "0"). This is against OpenMetrics conventions and makes it difficult (or impossible) to calculate the map utilization. Map capacity should be exposed as a separate metric. Alternatively, Tetragon could calculate the map utilization itself, but exposing the map capacity seems better.
[ ] The tetragon_map_in_use_gauge metric name is not very intuitive IMO and the gauge suffix is unnecessary.
[ ] processLru and eventcache are not BPF map, they're user-space caches, but info about them is exposed via mapmetrics too. This is confusing, it should be exposed as separate metrics.
[ ] tetragon_map_errors_total metric seems to have an incorrect help text.
[ ] tetragon_map_drops_total metric is incorrect. We get this from this callback. But this is not called only on evictions, it is also called when we remove elements normally, as we do here. The evictions are counted be the tetragon_errors_total{type="process_cache_evicted"} metric (defined here), so tetragon_map_drops_total can be just removed.
[ ] Metrics are not exposed for all maps: https://github.com/cilium/tetragon/issues/1775

/assign

@sadath-12 I've unassigned you from this issue because there are many different tasks that can happen in parallel I think. For example, @tpapagian already has a PR to address https://github.com/cilium/tetragon/pull/1949. If you want to work on this, I'd suggest pick a specific bullet point and we can create a separate issue for that.
Thanks!

source: gharchive/issue

authors: kkourt lambdanis sadath-12

repo: cilium/tetragon


text:
Did you find a way to have /dev/net/tun (tun module) in Debian Candyhouse kernel

http://www.wolfteck.com/projects/candyhouse/install/#comment-1975829450

Hi here !
It won't work anymore ... maybe it's my usb stick who need to be "reinstalled".
It worked with 3.13.7, what do you think ?
Thanks.

The image that I built at the airport didn't work because CONFIG_CMDLINE got reverted to looking for the rootfs in NAND instead of on USB.  I fixed that for this one and confirmed that it boots on my EA4500.  What symptoms are you seeing when it doesn't boot?  Have you poked through /var/log/[dmesg, kern.log, messages, syslog] to see if there's any hint there?  If none of the logs change (use checksums, timestamps aren't reliable during boot on this platform), then it might not be finding your USB.  Does your USB stick's activity light flash during the failed boot attempts?

After re-format my usb stick, it works fine !
Thanks for your support

This was fixed in 68e5165e310995a9ca6452396759e56ba91f4d9b -- thanks for the confirmation!

authors: bashou cilynx

repo: cilynx/Candyhouse-Linux

license_source: bigquery


text:
🛑 St. Lawrence Global Observatory Wordpress is down

In 5a2c250, St. Lawrence Global Observatory Wordpress (https://ogsl.ca/en/home-slgo/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: St. Lawrence Global Observatory Wordpress is back up in 630825b.

repo: cioos-siooc/cwatch-upptime

license: MIT


text:
⚠ Cioos Pacific CKAN has degraded performance

In 7108444, Cioos Pacific CKAN (https://catalogue.cioospacific.ca) experienced degraded performance:

HTTP code: 200
Response time: 8121 ms

Resolved: Cioos Pacific CKAN performance has improved in 0934a70 after 11 minutes.


text:
⚠ Cioos Pacific CKAN Sitemap has degraded performance

In 5eb8537, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 8207 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in 0180471 after 8 minutes.


text:
Can't build Style file

Hello,
Im using angular v10 ngx-simplemde v 10, and trying to build the lib, I got this error
SassError: SassError: Invalid CSS after "  min-height:": expected expression (e.g. 1px, bold), was "@simplemde-min-height"
on line 3 of node_modules/ngx-simplemde/styles/antd.less
from line 4 of node_modules/ngx-simplemde/index.less
from line 9 of src/assets/styles/style.scss
min-height: @simplemde-min-height;
in my style file, angular cannot find lib/index.less as described in the readme
// src/style.less
@import '~ngx-simplemde/lib/index.less';
so I changed it to
@import '../../../node_modules/ngx-simplemde/index.less';
Now angular can read the style file but cannot compile it's content,
Any ideas?
Thanks

My bad 🤦
I imported the index.less inside style.scss

repo: cipchk/ngx-simplemde


text:
Update sbt to 1.4.1

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

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

labels: library-update, semver-minor

Codecov Report

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

@@           Coverage Diff           @@
##           master     #220   +/-   ##
=======================================
  Coverage   90.98%   90.98%
=======================================
  Files           8        8
  Lines         122      122
  Branches        6        6
=======================================
  Hits          111      111
  Misses         11       11

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 d2570b4...ec1281c. Read the comment docs.

authors: codecov-io scala-steward

repo: circe/circe-jackson


text:
feat: updated node, npm, yarn to LTS

Npm is now 8.10.0
Node is now 16.15.0
Yarn is now included at 1.29.0 (The version that doesnt try to cache everything in the repo)
Next I will attempt to push all of our apps to these versions. is it going to break everything if this is tagged as latest when I havent touched circles_web yet?

Next I will attempt to push all of our apps to these versions. is it going to break everything if this is tagged as latest when I havent touched circles_web yet?

It shouldn't. Everything important should be pinned to an explicit version.
Changes look good to me - feel free to merge at your leisure.

authors: Lithial bernardd


text:
Export options revert to default when making selections

In the export window, making changes to either of the 3 sliders OR using either of the text fields will revert the following options to their default values:

imagesequence file type
resolution

I failed to notice this the first time and ended up exporting settings I didn't actually want.

Should be fixed in next release v1.1

authors: cirquit rorosaurus

repo: cirquit/trdrop

license: mit


text:
YAML data: Red Hat entries

🗣 Description
Re-populates Red Hat data.
💭 Motivation and context
When moved to YAML format, Red Hat data was removed
🧪 Testing
Minimum YAML lint.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[ ] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[ ] Tests have been added and/or modified to cover the changes in this PR.
[ ] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Add a tag or create a release.

failed CICD/linting


text:
[Feature] Propagate deployer agent creation errors to control plane

Is your feature request related to a problem? Please describe.
Currently, the status and errors of flamelet agent deployment is only visible in the deployer pod. Since we cannot assume that users will have access to the deployment errors, they should be sent back to the control plane / user so that next steps can be taken.
Describe the solution you'd like
The deployment status of all flame agents by each deployer (deployed, revoked or failed) should be propagated to the control plane. In case of failures, the status of agents (failed) should be sent to the control plane with an error message so that the admin can take necessary steps. An outline of the solution is as follows:

The status of each agent can be stored using the defined AgentStatus struct which has taskId as key and AgentState (Failed, Deployed, Revoked) as value.2.
The AgentStatus is in-turn maintained as an array in the DeploymentStatus struct. This stores jobId as an attribute and status of agents as an array.
To send this information to the control plane, the PutDeploymentStatus api can be used which uses computeId and jobId as an argument.
The calls to PutDeploymentStatus endpoints can be made where resource handler calls deployResources or revokeResources and has TODOs specified for propagating errors to the control plane.

Describe alternatives you've considered
Currently the APIs and struct specs are defined but not in use. They will have to be implemented in the apiserver, controller and the deployer's resource_handler.

a basic status check functionality is implemented in PR #262.

authors: dhruvsgarg myungjin

repo: cisco-open/flame


text:
Request vectors, test and validate

Hi,
I want to request test vectors, use them to run some tests on my system and generate results. Upload these results back so that they can be validated. How do I do that?

Our client doesn't support that at this time. You can plug your own crypto module's API into the client application code in app/app_main.c in place of the example openssl APIs, but we do not support what you are suggesting right now.

I had the same question.  I thought the ACVP system would generate .req files, give them to us to run, and then validate the results after we uploaded the .rsp files.  Is this functionality going to be available eventually?

Currently, this open source library only works in real time.  The flow is documented in the README.  The ACVP protocol does allow what you desire, however that is not a requirement in every environment. Since our library is designed for testing openssl or openssl FOM, real time operation is all that is needed.

OK, thanks.  What about testing other libraries?  Especially libraries that aren't written in C?  Is there a way to do that?

I would think its possible to take the callbacks in app_main.c and replace them with something that could call non-C code as long as you can link it in.

No, I'm not sure if kernel crypto has been tested. Maybe others on the call today may know.

I would think its possible to take the callbacks in app_main.c and replace them with something that could call non-C code as long as you can link it in.

Has this been tried by anyone?

This is open source code so I'm sure people take it do all sorts of things with it, but there is not way for us to track what they may be doing.

Agree with @bfussell . For instance, someone could try embedding Python within the callback function: https://docs.python.org/2/extending/embedding.html As far as we know, no one has tried using the library with other languages. It sounds feasible though and we encourage users to experiment according to their needs.

I would also be very interested in knowing if there is going to be non-real time functionality eventually. We almost exclusively test hardware modules and the module vendor normally produces the responses to the .req files on their own.  As it is we would need to make a lot of changes to produce the CAVS-like functionality we need and the switch from CAVS will be challenging for us (although many aspects of the new protocol will also be very time-saving for us as well).

Non-realtime is definitely on our roadmap. However, the primary goal of this open source project is to prove the ACV protocol is viable and provide NIST with interoperability feedback. We don't anticipate the project becoming the source for features for all possible deployment scenarios. It should be used as a reference implementation for all in the industry. We won't be bound by any publicized schedules and features will be added on a best effort basis.  Our team is simply not staffed to provide anything beyond that.  We do encourage participation from the community with bugfixes and even feature enhancements and we are currently working towards defining and communicating a process for that.

dear all
I want to request test vectors, use them to run some tests on my system and generate results. Upload these results back so that they can be validated. How do I do that?

As you can see in the above conversation, that capability is not yet available in our open source client.
Since it is open source you are welcome to enhance it to meet your needs.

This capability was added recently. By using the following commands it can be accomplished.  More details will be added to the README soon as well.
        To test offline:
           a) Download vectors on network accessible device
               ./app/acvp_app --<algs of choice or all_algs> --vector_req <filename1>
           b) Copy vectors and acvp_app to target
               ./app/acvp_app --all_algs --vector_req <filename1> --vector_rsp <filename2>
           c) Copy respones(filename2) to network accessible device
               ./app/acvp_app --all_algs --vector_upload <filename2>

Note: if target device in step b does not have libcurl, build with libmurl and copy that as well.
We will be investigating how to minimize the library dependencies for step b soon.

@bfussell : Thanks so much for the update...

authors: Rasstrelnikov amrithathorath bfussell elliemdaw fadaile fliphil lisarabe

repo: cisco/libacvp


text:
KDF app support

Hello,
Is there any plan to add KDF app support for ssh, tls, snmp and ikev2 ?  if so when we can expect ?
Thanks,
Nag

There is no schedule for KDF app support mainly because neither openssl 1.1.1 or openssl 1.0.2 support those.
We will likely put together a schedule once 3.0.0 nears official release. If you have an implementation of those KDFs then
the app code shouldn't be extremely difficult to write since your apps have to write to those APIs as well.

authors: Nagarjuna-jantali bfussell


text:
Sync soversion in meson with autotools build

Soversion in autotools build was bumped to 5,
but the major version in meson build was not bumped at the same time.
Sync soversion in meson.

Duplicate of #3165

Wouldn't that be the other way round?
fre. 29. nov. 2019, 13:59 skrev Philippe Normand notifications@github.com:

Duplicate of #3165 https://github.com/cisco/openh264/pull/3165
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cisco/openh264/pull/3148?email_source=notifications&email_token=ABXE4PW6HSOZXT3ZFCWJDY3QWEG2FA5CNFSM4H63U4R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFOZS5Y#issuecomment-559782263,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABXE4PUQS5XB6ATWVUERSHTQWEG2FANCNFSM4H63U4RQ
.

Yeah but the other PR also bumps the version. Up to the maintainers to choose which PR to review I suppose :)

#3165 has been merged. please close this pull request. thanks.

authors: GuangweiWang philn zaitor


text:
Add Semantic Scholar s2id to biblatex mapping.

Akin to existing support for PMID and PMCID identifiers, this PR adds support for copying a s2id field in bibtex/biblatex to a corresponding S2ID key in CSL-JSON. This addition would allow Semantic Scholar identifiers to be preserved in the mapping process.

Thank you for your contribution.

Akin to existing support for PMID and PMCID identifiers, this PR adds support for copying a s2id field in bibtex/biblatex to a corresponding S2ID key in CSL-JSON. This addition would allow Semantic Scholar identifiers to be preserved in the mapping process.

The PMID and PMCID fields are part of the CSL-JSON specification, however S2ID is not. There's a new way to set custom fields in the new version of CSL-JSON but for now I would suggest renaming the field to _S2ID, that way it shows up in Cite(...).format('data').

Yes, s2id (BibTeX/BibLaTeX) to _S2ID (CSL-JSON). When generating output the CSL-JSON is cleaned and any unknown fields that do not start with an underscore should be removed.

Got it. I've updated the PR accordingly.

authors: jheer larsgw

repo: citation-js/citation-js


text:
0.2.2

Changes in this version

#20

@citkane would appreciate your eyeballs on this when you have the time

repo: citkane/typedoc-plugin-versions


text:
Reference Architecture returns a few errors

I ran into a few errors while I was testing the reference architecture for the v6.0 docs.
A few examples:-

SELECT expire_old_request_data() returns

ERROR:  COMMIT is not allowed in a SQL function
CONTEXT:  SQL function "expire_old_request_data" during startup

Errors in the CREATE AGGREGATE function

CREATE AGGREGATE sum (hll)
(
  sfunc = hll_union_agg,
  stype = internal,
);

sfunc should be a function and there is an extra , after stype.

A couple of queries refer to minute, however there isn't a minute column in the http_request_1min table.

We should have a look at these errors and fix them.

All of these are fixed and pushed to master.

authors: lithp samay-sharma


text:
Parking meter locations, rates, and schedules

From Socrata user Spot Angels:

Hi, I would love to get access to the parking meters locations, rates and schedules. A shapefile would be great but I would be ok with a CSV. Thank you

sent an email to City staff asking for advice on which department to hand this off to

repo: cityofaustin/open-data-suggestions

license: unlicense


text:
Added kafka

Thank you for wanting to submit a Pull Request to the Civo Kubernetes Marketplace repository!
If your pull request is to submit a new application to the marketplace, please answer the following questions:

[x] Have you followed the guidelines in our Contributing document in setting up the application?
[x] Have you checked that the application your submission is proposing to add does not yet exist on the Marketplace, or as a pull request to be processed?
[x] Have you tested your application on the Civo managed Kubernetes service? Please include a screenshot.
[x] Can you confirm that the software you are submitting licensed for use in a publicly-available Kubernetes marketplace?

repo: civo/kubernetes-marketplace


text:
opal/opal-webpack

This appears to be the most advanced shot at opal-webpack, how about moving it to the Opal organization and start looking for a maintainer?
@elia write on Gitter (Oct 07 2016 22:27):

I'd be happy to add an official opal/opal-webpack repo (with its official maintainer ), sprockets support has been extracted from opal@master to opal/opal-sprockets, paving the way exactly for this kind of things

I'd help out updating the documentation here and there, but lack the webpack insight to jump at the code. Nonetheless, webpack appears to be the future (given the challenges Sprockets is facing), so maybe it's time to push it a little more towards the spotlight. What do you think?

@fkchang FYI, not sure whether you're already working on this.

It makes sense to me. I just haven't had the time to work on this much. :(
sent from my mobile device
On Apr 23, 2017 8:15 AM, "Sven Schwyn" notifications@github.com wrote:

This appears to be the most advanced shot at opal-webpack, how about
moving it to the Opal organization and start looking for a maintainer?
@elia https://github.com/elia write on Gitter (Oct 07 2016 22:27):
I'd be happy to add an official opal/opal-webpack repo (with its official
maintainer ), sprockets support has been extracted from opal@master to
opal/opal-sprockets, paving the way exactly for this kind of things
I'd help out updating the documentation here and there, but lack the
webpack insight to jump at the code. Nonetheless, webpack appears to be the
future (given the challenges Sprockets is facing), so maybe it's time to
push it a little more towards the spotlight. What do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cj/opal-webpack/issues/39, or mute the thread
https://github.com/notifications/unsubscribe-auth/AASIo5F1ApbD-TCWUBU4d9k8Y0QzJtu2ks5ry1z0gaJpZM4NFa5H
.

repo: cj/opal-webpack


text:
JSDom + fakeXHR troubles

I'm attempting to write unit tests for jQuery ajax requests in a JSDom environment, but Sinon's fake XHR is not intercepting the requests. The exact same suite does work in the browser.
I know this can cause some folks trouble but I'm fairly certain that Ive got JSDom and jQuery correctly configured to be working in tandem. I've set the global.window and global.XMLHttpRequest object based on what is returned from JSDom so that jQuery can make XHR requests, and I've verified that it can. The issue comes in when I try to fake the requests with Sinon: they aren't intercepted.
It comes down to sinonXhr.supportsXHR being calculated as false. This follows from this line, where it looks for XMLHttpRequest on the local variable global. That local variable is passed in here. In Node, this is an empty object, while global is where it should be looking at for the xml http request.
It seems unlikely to me that this would go unnoticed for so long, so maybe I'm configuring things oddly. Has anyone had success with jQuery+JSDom+Sinon's FakeXHRs?

Interestingly enough, git reverting this commit solves the problem. If this is, in fact, a regression, then perhaps there's a way to fix #508 and #511 in some other way.

If, by some rare chance you read this and are experiencing the same issue, simply update your package.json:
"sinon": "git://github.com/jmeas/sinon.js.git#ajax-node"

That branch implements #659. I'll keep it around as long as this repo doesn't have the fix for the problem.

My working setup for a new redux project:
Sinon: 1.17.3
jQuery: 2.2.2
jsdom: 8.3.0
import 'babel-polyfill';
import chai from 'chai';
import chaiImmutable from 'chai-immutable';
import jsdom from 'jsdom';

global.jsdom = jsdom.jsdom;
global.document = global.jsdom('<!doctype html>');
global.window = global.document.defaultView;
global.XMLHttpRequest = global.window.XMLHttpRequest;

chai.use(chaiImmutable);

global.expect = chai.expect;
global.assert = chai.assert;

global.sinon = require('sinon');
global.sinon.useFakeXMLHttpRequest();

global.window.XMLHttpRequest = global.XMLHttpRequest;
global.$ = require('jquery')(global.window);

I bumped into this exact issue - the key was loading sinon after the globals have been set up (ie. XMLHttpRequest) so that XHR support check works as expected.
That means you won't be able to use ES6 import at the top of the file, as sinon will be loaded before the globals - so resorting to CommonJS require as in the example above.
global.XMLHttpRequest = global.window.XMLHttpRequest;
// ...
global.sinon = require('sinon');

@alistairjcbrown : have you tried Sinon 2? That version works with module bundlers and I think it should prove less bothersome.

I faced the same problem in https://github.com/yiisoft/yii2/pull/13160.
@fatso83 I tried the latest version (2.0.0-pre.4), the error persists. Used @alistairjcbrown solution as a workaround. Thanks for him for discovering this.

I use mocha-jsdom wrapper. In my case I predefined sinon variable without assigning value to it at the very top of test file:
var sinon;

Then I imported sinon to it after registering jsdom and testable code:
jsdom({src: fs.readFileSync('vendor/bower/jquery/dist/jquery.js', 'utf-8')});
before(function () {
    $ = window.$;
    registerTestableCode();
    sinon = require('sinon');
});

Then in specific test suite where fake server is needed I wrote:
describe('refresh', function () {
    var server;

    beforeEach(function () {
        server = sinon.fakeServer.create();
        window.XMLHttpRequest = global.XMLHttpRequest;
    });

    afterEach(function () {
        server.restore();
    });

    // Testing code
});

This works fine, however for convenience and speed on dev server I included only one file in tests suite. Tests were passing, when I added the rest of the files back, the same error appeared:

TypeError: Cannot read property 'respond' of undefined

coming from line:
server.requests[0].respond(200, {"Content-Type": "application/json"}, JSON.stringify(response));

So I had to import sinon in similar fashion in other files even there are no ajax related code at all and file with AJAX is tested **before ** the other ones.
Looking for a better fix.

authors: SokratisVidros alistairjcbrown arogachev fatso83 jmeas


text:
fixed typo, revised invertibility conditions

Regarding the special case with DIVU that is invertible, but should not occur according to the assumption: target != current output value.
So far this case is handled as not invertible. This is just a suggestion to handle it as invertible.
Also added parenthesis in REMU.
Summery of invertible, not invertible:
DIVU Lhs:
s = 0, t = ones      => invertible, but should not happen as this means currently t = ones already
s = 0, t != ones     => not invertible
t = ones, s != {0,1}  => not invertible, overflow
DIVU Rhs:
t = s = 0             => invertible, but again should not happen
t = 0, s != ones      => invertible
t = 0, s = ones       => not invertible
t = ones, (s = ones)  => invertible
t = ones, (s != ones) => invertible
s < t                 => not invertible

I overlooked the case s == t => invertible in REMU the first time.

repo: cksystemsgroup/monster


text:
Notify a captcha on purchase

Running the application couldn't purchase free games as expected for me. Both API purchase and puppeteer purchase failed.
Here are logs:
> epicgames-freegames-node@4.0.0 entrypoint-config /usr/app
> node dist/src/entrypoint-config.js

Setting timezone: UTC
Run on startup: true
[2021-12-15 15:13:58.572 +0000] INFO  (43 on 39ae1e32eb40): Checking free games for MY_EMAIL
[2021-12-15 15:14:09.199 +0000] INFO  (43 on 39ae1e32eb40): Successfully refreshed login
    user: "MY_EMAIL"                                                                                [2021-12-15 15:14:09.200 +0000] INFO  (43 on 39ae1e32eb40): searchStrategy is `all`: searching for weekly and promotional games
    user: "MY_EMAIL"                                                                                [2021-12-15 15:14:11.431 +0000] INFO  (43 on 39ae1e32eb40): Available free games
    user: "MY_EMAIL"                                                                                availableGames: [                                                                                "Godfall Challenger Edition",
      "Prison Architect"
    ]
[2021-12-15 15:14:12.203 +0000] INFO  (43 on 39ae1e32eb40): Unpurchased free games
    user: "MY_EMAIL"                                                                                purchasableGames: [
      "Godfall Challenger Edition"                                                                                ]                                                                                [2021-12-15 15:14:12.204 +0000] INFO  (43 on 39ae1e32eb40): Purchasing Godfall Challenger Edition
[2021-12-15 15:14:15.229 +0000] WARN  (HTTPError/43 on 39ae1e32eb40): Response code 400 (Bad Request)
    HTTPError: Response code 400 (Bad Request)
        at Request.<anonymous> (/usr/app/node_modules/got/dist/source/as-promise/index.js:117:42)
        at processTicksAndRejections (internal/process/task_queues.js:95:5)
[2021-12-15 15:14:15.229 +0000] WARN  (43 on 39ae1e32eb40): API purchase experienced an error, trying puppeteer purchase
[2021-12-15 15:14:20.313 +0000] WARN  (43 on 39ae1e32eb40): Error from hCaptcha get_cookie request, continuing without hCaptcha accessibility cookies
    status: 401
    errorBody: {
      "status": "error"
    }
[2021-12-15 15:14:59.479 +0000] ERROR (TimeoutError/43 on 39ae1e32eb40): waiting for function failed: timeout 30000ms exceeded
    TimeoutError: waiting for function failed: timeout 30000ms exceeded
        at new WaitTask (/usr/app/node_modules/puppeteer/src/common/DOMWorld.ts:788:28)
        at DOMWorld.waitForFunction (/usr/app/node_modules/puppeteer/src/common/DOMWorld.ts:710:22)
        at Frame.waitForFunction (/usr/app/node_modules/puppeteer/src/common/FrameManager.ts:1239:28)
        at Page.waitForFunction (/usr/app/node_modules/puppeteer/src/common/Page.ts:3263:29)
        at PuppetPurchase.purchaseShort (/usr/app/src/puppet/purchase.ts:149:10)
        at redeemAccount (/usr/app/src/index.ts:39:9)
        at async Promise.all (index 0)
        at main (/usr/app/src/index.ts:58:5)
Run once: true
Exiting...

When I opened the store and tried to purchase manually, I saw a captcha challenge.
I hope this application could detect the captcha and let me deal with it in the web portal, just like how it handles the captcha of login attempts.

Looks like they finally rolled out purchase captchas. Luckily I was prepared for this, so it was pretty simple to implement.

Works like a charm. Thank you!

authors: claabs zhyu

repo: claabs/epicgames-freegames-node


text:
Slow AST builds in code involving large array (e.g. 1000000 elements)

I am an algorithmic competition participant, and I have a VSCode workspace where I have organized my code from various online judging systems into folders. The directory tree looks roughly like this:
OI (Workspace Root)
- Codeforces
- - CF001A.cpp
- - CF002B.cpp
- ATCoder
- - abc001_a.cpp
- - abc002_b.cpp
- luogu
- - P1001.cpp
- - P1002.cpp

Clearly, my problem files are independent of each other, and I don't need or want to include the contents of other files in one file. I only need to include system header files like iostream and vector.
However, when my problem repository folder reaches a certain size, I noticed that the response time of clangd becomes significantly slower. Below is a part of the clangd log where it can be observed that many operations take several thousand milliseconds.
I[10:43:16.044] Indexing c++2b standard library in the context of d:/Coding/OI/atcoder/abc261_g.cpp
I[10:43:16.195] Built preamble of size 7253168 for file d:/Coding/OI/atcoder/abc261_g.cpp version 1 in 0.97 seconds
......
I[10:43:18.601] Indexed c++2b standard library: 14142 symbols, 958 filtered
I[10:43:19.203] --> textDocument/publishDiagnostics
I[10:43:19.205] --> reply:textDocument/documentLink(1) 3818 ms, error: Task was cancelled.
[Error - 10:43:19] Request textDocument/documentLink failed.
[object Object]
I[10:43:19.205] --> reply:textDocument/inlayHint(2) 3809 ms, error: Task was cancelled.
I[10:43:19.206] --> reply:textDocument/inlayHint(3) 3801 ms, error: Task was cancelled.
[Error - 10:43:19] Request textDocument/inlayHint failed.
[object Object]
[Error - 10:43:19] Request textDocument/inlayHint failed.
[object Object]
I[10:43:19.207] --> reply:textDocument/semanticTokens/full(5) 3382 ms
I[10:43:19.208] --> reply:textDocument/documentLink(6) 3210 ms
I[10:43:19.209] --> reply:textDocument/documentSymbol(7) 2103 ms
I[10:43:19.210] --> reply:textDocument/inlayHint(8) 1800 ms
I[10:43:19.210] --> reply:textDocument/inlayHint(9) 1800 ms
I[10:43:19.211] --> reply:textDocument/codeAction(11) 793 ms

When I created a workspace with only one file, the performance of clangd returned to normal.
Playground (Workspace Root)
- test1.cpp

I suspect that Clangd scans the entire folder (or even the workspace) of code every time it performs autocompletion (even though I haven't included them). How can I change this behavior?

@HighCommander4 Shall we transfer this issue to the server repo?

Transferred.

Some other bugs we have on file about code involving large arrays: #967, #1087 .

Problem still NOT resolved with clangd 18.1.3（LLVM-Mingw Project）

#include <iostream>
using namespace std;
pair<int, int> arr[100000010];
int main() { return 0; }

And the problem occured even if using "-std=c++17".

I met the same problem.
clangd will become very slow when I define a large array of std::pair
This problem only occurs on std::pair
I am using clangd 18.1.3 with ubuntu 22.04

In my case, clangd only consumes a lot of CPU but doesn't consume much memory.

same #2231

you can use clang19 and add -fexperimental-new-constant-interpreter flag

repo: clangd/clangd


text:
Performance issue: high disk usage and long background indexing time

Please describe the problem.
For hints on what information is helpful, see: https://clangd.llvm.org/troubleshooting.html
Recently, I found clangd is using my disk insanely and taking really long time to finish background indexing. I have a Samsung SSD 980 1TB disk, and when clangd is up, its utilization reaches 100% until the background indexing finishes. However, it takes several hours to finish the background indexing process. Since the OS is also installed on this disk, this high ultilization affects other programs as well.
Actually, this problem has been around for 2~3 years, but it is not always such bad.
If you can, provide a minimal chunk of code that shows the problem (either inline, or attach it if larger).
I don't know how to locade such piece of the code causes the high ultilization or the long background indexing process.
Logs
Please attach the clangd stderr log if you can. (Usually available from the editor)
If possible, run with --log=verbose - note that the logs will include the contents of open files!
If this is a crash, try to put llvm-symbolizer on your PATH per the troubleshooting instructions.
I can not attach the whole log, becuase it contians the names of the source files and symbols. I am working on a proprietary project, so I guess I am not allowed to disclose such information to the public. Can you tell me what patterns I should seek in the log? If that is not possible, I may be able to remove the names of files and symbols from the log and share it.
System information
Output of clangd --version:
PS C:\Users\Administrator> clangd --version
clangd version 18.1.2
Features: windows
Platform: x86_64-pc-windows-msvc

Editor/LSP plugin:
Emacs LSP-mode
Operating system:
Windows

I have been tuning the settings for clangd and it seems that I have solved the problem.
My original arguments for clangd is:
          "--completion-style=detailed"
          "--header-insertion=never"
          "--function-arg-placeholders=0"
          "--background-index"
          "-j32"
          "--pch-storage=memory"

Though my PC has only 16 logical cores, but I still set the -j32 switch, hoping this is only a hint to the program.
Now I have replaced -j32 with -backgorund-index-priority=low. The disk utilization does not surge to 100% any more, and the indexing time also decreses. It seems that high utilization of the system disk is also preventing clangd from finishing indexing.


text:
[privacy] why do you use trackers?

Hey Casey,
thanks for your awesome app,
I really like it :slightly_smiling_face:
A scan with Warden brings up 3 trackers in the musikdroid application:

Google Firebase Analytics
Google AdMob
Google CrashLytics

I would love to know why you use these trackers,
because I can't find any information about that on https://musikcube.com.
Best,
Michael

Hello! These are used to monitor crashes and understand how many people are using the app. The good news is that if this concerns you, you can always grab the sources, rip out Firebase, and build the app yourself. If that interests you, and you have any additional questions, I'm happy to help you through it.

Hello! These are used to monitor crashes and understand how many people are using the app. The good news is that if this concerns you, you can always grab the sources, rip out Firebase, and build the app yourself. If that interests you, and you have any additional questions, I'm happy to help you through it.

Hey Casey,
thanks for your kind reply, I managed to remove the Google services, Firebase and the auto update.
Now the application is tracker-free and doesn't ping musikcube.com.
If someone wants to see the differences, have a look at the diff, it's pretty straight-forward.
Keep up the great work :+1:
Greetings
Michael

Hey Casey,
thanks for your kind reply, I managed to remove the Google services, Firebase and the auto update.
Now the application is tracker-free and doesn't ping musikcube.com.
If someone wants to see the differences, have a look at the diff, it's pretty straight-forward.
Keep up the great work :+1:
Greetings
Michael

repo: clangen/musikcube


text:
IntersectsFilter fails with NPE for geometry collection with empty polygons

relation/2668952 (European Union) is incomplete in germany.gol. Missing relation members are turned into empty geometries. This apparently causes problems for JTS.
An -a query for r fails with NPE thrown by JTS:
java.lang.NullPointerException: Cannot read field "y" because "p" is null
        at org.locationtech.jts.algorithm.locate.IndexedPointInAreaLocator.locate(IndexedPointInAreaLocator.java:88)
        at org.locationtech.jts.geom.prep.PreparedPolygonPredicate.isAnyTestComponentInTarget(PreparedPolygonPredicate.java:102)
        at org.locationtech.jts.geom.prep.PreparedPolygonIntersects.intersects(PreparedPolygonIntersects.java:68)
        at org.locationtech.jts.geom.prep.PreparedPolygonIntersects.intersects(PreparedPolygonIntersects.java:41)
        at org.locationtech.jts.geom.prep.PreparedPolygon.intersects(PreparedPolygon.java:87)
        at com.geodesk.feature.filter.IntersectsFilter.acceptGeometry(IntersectsFilter.java:34)
        at com.geodesk.feature.filter.SpatialFilter.accept(SpatialFilter.java:17)
        at com.geodesk.feature.filter.IntersectsFilter.accept(IntersectsFilter.java:42)
        at com.geodesk.feature.query.RTreeQueryTask.searchLeaf(RTreeQueryTask.java:179)
        at com.geodesk.feature.query.RTreeQueryTask.searchTrunk(RTreeQueryTask.java:86)
        at com.geodesk.feature.query.RTreeQueryTask.exec(RTreeQueryTask.java:56)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
        at java.base/java.util.concurrent.ForkJoinTask.awaitDone(ForkJoinTask.java:436)
        at java.base/java.util.concurrent.ForkJoinTask.join(ForkJoinTask.java:670)
        at com.geodesk.feature.query.TileQueryTask.exec(TileQueryTask.java:138)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

Polygon isn't actually empty, but an invalid geometry made from purgatory ways. PolygonBuilder should not produce such geometries.
The core issue appears that these polygons have 3 vertexes, which means they are clearly degenerate. Check if turning polygons with <4 vertexes into empty polygons avoids this issue.

repo: clarisma/geodesk


text:
CI for Node

CI for Node

Contains the compiled JavaScript
Initializes with two players
Starts the game with a random player
Sets the current player to be whoever it is not

repo: claudiokazuo/github-actions-for-ci


text:
Possible to crop from the center

Is it possible to crop with $img->crop(x,y,x2,y2) from the center of the image?

Yes, but you'll need to calculate it on your own.

repo: claviska/SimpleImage


text:
🛑 livevault is down

In 1f2679e, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 223692b.

repo: claytonplong/backup-uptime


text:
🛑 livevault is down

In 19a5f37, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 188898e.


text:
🛑 livevault is down

In f2dfa67, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in d576dd3.


text:
Add null-aware operator when calling componentWillUnmount

internal.component can be null within handleComponentWillUnmount. Use a the null aware operator so it doesn't throw
@aaronlademann-wf @greglittlefield-wf @clairesarsam-wf @joelleibow-wf

introduced by https://github.com/cleandart/react-dart/pull/123

+1

@jacehensley-wf Can you elaborate as to when this happens, and why it being null at that point is acceptable?
At first glance, it seems like this is caused by a bug in the component being nulled when it shouldn't have been.

@greglittlefield-wf Yeah I'm not entirely sure. I think it's happening when the prev component is nulled and then getting unmounted.

Yeah, I'd prefer it if we knew the root cause of this issue before putting this food in place.
Yeah, I'll pay those up when I get a chance.
You my also want to try just removing this line, and seeing if that fixes it: github.com/cleandart/react-dart/pull/123/files#diff-12ac054bb8b76f35c1035afef1d94396R308

@jacehensley-wf Here are those changes: https://github.com/cleandart/react-dart/compare/internal_instance_refactor
After thinking about it more, those changes shouldn't exhibit the issue you're seeing, since the component instance is never nulled out.

@greglittlefield-wf What do you want to do about this then? Maybe just put this fix in place till we can release a breaking change with those changes in the branch?

Like I said, I think it'd be a good idea to get a better understanding of this issue before putting this change in place.
If the component being null at that point is expected, and we do need a null-check, then I'm totally fine putting one in.
I just want to make sure that the problem described here isn't a symptom of some other underlying issue that should be fixed instead.

Also, see my previous message; that line I mentioned is probably not necessary, and may be causing issues..

@greglittlefield-wf @jacehensley-wf looks like the issue is present anywhere that internal.component is referenced...
VM290:1 Uncaught Unhandled exception:
NoSuchMethodError: The setter 'nextProps=' was called on null.
Receiver: null
Tried calling: nextProps=_LinkedHashMap len:9
#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:43)
#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:47)
#2      _dartInteropStatics.<anonymous closure>.handleComponentWillReceiveProps.<anonymous closure> (package:react/react_client.dart:264:9)
#3      _RootZone.run (dart:async/zone.dart:1366)
#4      _dartInteropStatics.<anonymous closure>.handleComponentWillReceiveProps (package:react/react_client.dart:261:126)

That makes the line I referenced earlier even more suspect. I wonder if
that's getting cleared during a rerender, and not updated due to
shouldComponentUpdate or something.
On Jul 5, 2017 8:54 AM, "Aaron Lademann" notifications@github.com wrote:

@greglittlefield-wf https://github.com/greglittlefield-wf
@jacehensley-wf https://github.com/jacehensley-wf looks like the issue
is present anywhere that internal.component is referenced...
VM290:1 Uncaught Unhandled exception:
NoSuchMethodError: The setter 'nextProps=' was called on null.
Receiver: null
Tried calling: nextProps=_LinkedHashMap len:9#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:43)#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:47)#2      _dartInteropStatics..handleComponentWillReceiveProps. (package:react/react_client.dart:264:9)#3      _RootZone.run (dart:async/zone.dart:1366)#4      _dartInteropStatics..handleComponentWillReceiveProps (package:react/react_client.dart:261:126)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cleandart/react-dart/pull/124#issuecomment-313145789,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABonL9tKorhckPdonGKp2GMQvQfhJIoSks5sK7GugaJpZM4OLCu4
.

@greglittlefield-wf Just tried removing this line and am still seeing the error.

@greglittlefield-wf we're going to revert #123 for now so that consumers aren't broken while we look into it more.

Gonna close this while we figure out a good solution

repo: cleandart/react-dart


text:
103% yarrow completion??

Exactly what it says on the tin, I have 103% Yarrow completion. I also don't have 100% West Desert completion despite there being no secrets left there.

I guess upgrades don't have all the same percentage value. Not sure I can fix that, and it doesn't seem important to fix.

authors: Traehgniw clementgallet


text:
feat(cdk/visit/lambda_code): add print statement for monitoring

Problem:
Successful lambda canary tests do not have any print statements that show up in the Cloudwatch logs for the TestAPI Lambda. It can be difficult to determine which logs contain successful test runs.
Solution:
By adding this print statement, the Cloudwatch logs should display the time and username for any successful tests.
Testing:
By adding this print statement in dev instances, the lambda functionality was not affected.
Issue:
N/A, No open issue.

@DillonRanwala when you updated the commit message it looks like you added a second commit instead of amending the first one. I'm going to squash & merge this PR which will clean that up a little bit, but in the future can you try to amend your commits so that if we rebase and merge the commit log will be exactly how you want it?
I'm not sure how trivial that is to do on GitHub. If it's a huge pain please let me know.

authors: DillonRanwala ophilli

repo: clemsonMakerspace/unified-makerspace


text:
Object type on metadata prevents getting values

When xMetadata is an object type, it prevents accessing properties in a type-safe way:

eslint recommends using Record<string, unknown> instead, based on this issue.

Here, I set it to {[key: string]: string} to be a little more restrictive and closer to how I've seen other metadatas used (i.e. Stripe's). Either works for my use case, curious to see what you guys think.

even stranger, it seems like update calls only work if the publicMetadata is a stringified JSON instead of an object:
> users.updateUser(id, { balance: 35});
< error long_message: '`public_metadata` must be a `json`.',

> users.updateUser(id, JSON.stringify({ balance: 35}));
< success

@dvargas92495 Thank you for raising this.
We opted for Record<string, unknown> because we can't assume the values will be strings.
All your concerns are addressed in this PR.
I'll add you as a reviewer.

Took a look at the PR, looks great! I'll close this one!

repo: clerkinc/clerk-sdk-node


text:
Fixing error when running: bin/build-administration.sh

Module not found: Error: Can't resolve './service/ClerkApiTestService' in '/custom/static-plugins/ClerkShopware/src/Resources/app/administration/src' at /vendor/shopware/administratio n/Resources/app/administration/node_modules/webpack/lib/Compilation.js:925: 10

@CasperKN Not sure if you guys have seen the pull request thats why im tagging you. :)

Was fixed a couple of releases ago, will close ticket.
https://github.com/clerkio/clerk-shopware-6.4/blob/main/src/Resources/app/administration/src/main.js#L1C19-L1C38
Thanks for the report.

authors: mrn-rigtved stubbedev


text:
Accumulate "Platforms" on NCPI studies when studies are being built using build-ncpi-db

Need
On the NCPI-Catalog dx versoin studies that belong to multiple platforms are not combined to a single study with a list of platforms.
Should be like:

Instead, we have:

Approach
In the ncpi-catalog explorer, there is a script called  build-ncpi-catalog.ts that is run using npm run build-ncpi-db. This script iterates over the list of PlatformStudyStubs that make up the script's input and expands using the dbGaP FHIR API to into the studies and platforms that are displayed on the study and platform tabs in the ncpi-dataset catalog version of the explorer app. Studies and platform json files are written into the /out directory under /files/ncpi-catalog/files
Currently, this script outputs one study per row in the dashboard-source-ncpi.tsv file.
Some studies are in multiple "platforms," however, and the study then is duplicated in the out/ncpi-platform-studies.json file.
Instead, the studies as keyed by their dbGaPId fields need to be unique in the ncpi-platform-studies.json file and when a study belongs to two platforms, both platforms are listed in the platforms section so:
"platforms": [
      "AnVIL",
       "BDC",
    ]

Instead of
"platforms": [       "AnVIL"     ]
One way to do this is is to de-dupe ncpiStudies here before it is returned, and modify any studies that are duplicated to be a single study with both platforms added to the platform array.

@hunterckx when launching the application go http://localhost:3000/explore. There you will see two tabs, studies and platforms. The studies tab is the one we are interested in here e.g. http://localhost:3000/explore/studies
All these  "explorer" apps going to /explore will tell you the list of entities you can select from.

Done!

repo: clevercanary/data-browser


text:
Stripe donation page

See Week 24, exercises 23 and 24

works locally

repo: cliff-rosenberg/bootcamp-adventure


text:
Update Cloudy test and Cloudy notebook

Update Cloudy test to use lognormal priors.
Update Cloudy notebook such that it can be run with the current version of the CES code. @charleskawczynski: I know that you hate that notebook (or notebooks in general), but until we decide to delete it I'll keep updating it from time to time :-)

@charleskawczynski: I know that you hate that notebook (or notebooks in general), but until we decide to delete it I'll keep updating it from time to time :-)

I'm fine with keeping the notebook around if you find that it has value. It may be more efficient to use Literate to generate notebooks from the existing Julia script though, so that you don't need to maintain duplicate versions.

I will look into that, thanks!

bors r+

authors: bielim charleskawczynski


text:
build: only run build workflow for push events OR pull_request events from fork

When Travis submitted a PR a couple weeks ago from an external fork, I added a temporary fix to the build.yaml workflow so that it runs for both push and pull_request events, but this leads to redundant builds in the more typical case where the workflow is run for a branch of the primary SDEverywhere repo.
I'm attempting to address this by skipping jobs in the case where it's a pull_request event for a branch of this repo.  We'll see if it works after I open this PR.

This results in some "skipped" jobs being reported in the PR checks section, but seems like a small price to pay.  I will merge this and we'll see if it can be improved further later.

repo: climateinteractive/SDEverywhere


text:
User can view the source of metadata values

The user should be able to view the source of metadata values for any metadata filter. This should indicate next to each metadata value the source of that value. For example “CCLW”, “CPD”.
Should the user be able to filter the list of metadata values by a source? E.g. only view metadata values which have been received from CCLW?

@chrisaballard in response to a question on the Notion backlog for this requirement: agreed with @danny-waite-cpr that displaying and filtering by metadata source is not a priority for the Alpha given that we are only using data from CCWLW - provided that we are storing the metadata source anyway and that it won't be overly complicated to display it at a later stage!

authors: chrisaballard marcusodavies

repo: climatepolicyradar/navigator


text:
🛑 CCL Ergonomie is down

In f2bd26f, CCL Ergonomie (https://www.cclergonomie.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CCL Ergonomie is back up in a502a46 after 5 minutes.


text:
Adding ci tests for all current scenario on push to main or ci_tests

Description
Adding in Ci tests for all current scenarios and pushes to quay when main gets updates
See https://github.com/cloud-bulldozer/kraken-hub/actions/runs/1408404101 for latest successful run
Fixes
https://github.com/cloud-bulldozer/kraken-hub/issues/11

This would be instead of: https://github.com/cloud-bulldozer/kraken-hub/pull/18

repo: cloud-bulldozer/kraken-hub


text:
RFE: Ability to query cpu seconds metrics

I would like to see the "cpu seconds" counter metrics (added in kube-burner#454) trending over time.
Having all queries from that PR would be good:
* nodeCPUSeconds-Workers
* nodeCPUSeconds-Masters
* nodeCPUSeconds-Infra
* cgroupCPUSeconds-Workers
* cgroupCPUSeconds-Masters
* cgroupCPUSeconds-Infra
* cgroupCPUSeconds-namespaces

It will be helpful having the ability to query a single metric (i.e. a specific namespace of the metric cgroupCPUSeconds-namespaces) AND being able to query a metric and "group by" a field in the metric (i.e. group by "namespace" of cgroupCPUSeconds-namespaces).
The former allows us to track specific components, and the latter allows us to find issues in components we aren't explicitly tracking.
I am able to achieve this grouping vs filtering at the elasticsearch query level through touchstone-comparison (OK, maybe that's not a pure elasticsearch query in that case), like the following:
      {
        "filter": {
          "metricName.keyword": "nodeCPU-AggregatedWorkers"
        },
        "buckets": [
          "labels.mode.keyword"
        ],
...
      },

@afcollins nice, it appears we can use the report-mode metrics to do this.
https://github.com/kube-burner/kube-burner/blob/main/cmd/kube-burner/ocp-config/metrics-report.yml#L252-L279

Will have to look more into the bucket aggregation, but I was able to query the single metric just fine. So I think the current implementation is good.

I am able to aggregate with a sum, so I think anything required has already been done.
    - name:  apiserverCPU
      metricName : containerCPU
      labels.namespace.keyword: openshift-kube-apiserver
      metric_of_interest: value
      agg:
        value: cpu
        agg_type: sum
      labels:
        - "[Jira: kube-apiserver]"
      direction: 1

authors: afcollins jtaleric

repo: cloud-bulldozer/py-commons


text:
update ADR with decision and plan

Changes proposed in this pull request:

update ADR with decision and plan

security considerations
None

making sure to flag @pburkholder in case he wants to add anything :)

Discussed with @ccostino that before we move forward with the ADR, we should,  a) link to the FedRAMP document, and b)  map the FedRAMP requirements to those that our solution will provide (or not provide, so we’ll need to address them in some other manner).

repo: cloud-gov/product


text:
doc: hava=>have 和 readme文档

文档调整

Thinks


text:
Few smaller improvements, backward compatible

Fixed running role in check_mode, so it's not failing anymore
Added environment param for getting GPG key and installing Grafana - usefull, when you have to use PROXY
Added option to disable managing dashboards. Useful when you modify them manually via web interface.

This is great, could you rebase to fix git conflicts?

Merge conflicts resolved.

authors: krzyzakp paulfantom

repo: cloudalchemy/ansible-grafana


text:
FreeBSD support

Hi,
would you accept PRs to add FreeBSD support to your role?
thanks!

If it has systemd as an init it can be added.

Would you mind elaborating on why you feel that to be a requirement?
compared to using the provided 1.0.1 package
package:
  name: node_exporter
  state: enabled

service:
  name: node_exporter
  state: enabled

Roles in cloudalchemy are using advanced features of systemd to provide better security of running applications (for example in node_exporter: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/templates/node_exporter.service.j2#L36-L51). This means systemd is hard requirement and there are plans to even tighten that integration by using "dynamic users" feature.
IMHO if all you need to install and configure anything is 2-3 common tasks, I don't see any reason to use a role at all.

@paulfantom I am not sure if it's too much work, but one could use this role on BSD when we re-arrange some tags:

node_exporter_configure
node_exporter_run

And then stick systemd into its own file and tag it with node_exporter_run? ;) Then all BSD folks would have to do is --skip-tags="node_exporter_run" and start it themselves in post_tasks. I'd also love to keep using this role for my BSD servers, vs. others. :D

It's not that simple. For non-systemd installations to work we would need to

handle few of current preflight checks: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/preflight.yml#L2-L17
Disable creation of systemd file: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/configure.yml#L2-L9

Bear in mind that a plan is to wait for more widespread adoption of systemd version which includes dynamic user feature (I don't remember version now). Which will allow getting rid of user management in this role (those won't be necessary anymore: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/install.yml#L2-L18)
Additionally, since node_exporter is configured via CLI flags and role won't have any control over those (due to different init system), we are left with a quite complicated role to only download a binary from internet.

authors: appliedprivacy paulfantom till

repo: cloudalchemy/ansible-node-exporter


text:
[Bug] test case segwalrep/dtm_recovery_on_standby hang

Cloudberry Database version
PostgreSQL 14.4 (Cloudberry Database 1.0.0+5d6f0e9a24 build commit:5d6f0e9a247ffe695377867ba351f1f4db060210) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit compiled on Oct 18 2023 14:11:14 (with assert checking)
What happened
run icw test case on kylin os use x86_64 cpu
Test cases hang to death

Killed by signal 15 because the CI/CD pipeline timeoutd
What you think should happen instead
No response
How to reproduce
rerun icw test case on kylin10 os  use x86_64 cpu
Operating System
kylin10 x86_64
Anything else
No response
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

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

Does it happen frequently?

Yes, they must appear, and they all hang in the dtm_recovery_on_standby case  @my-ship-it

Just fyi, I was told this issue is blocking subsequent ICW test. Thus I would suggest priority of this issue could be raised.

can you offer me the ci pipeline ?
@smartyhero

authors: congxuebin my-ship-it smartyhero yjhjstz

repo: cloudberrydb/cloudberrydb


text:
🛑 cbn.id is down

In 923b795, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 16b0f55.

repo: cloudbip/upptime


text:
🛑 biznetgio.com is down

In 105b7da, biznetgio.com (https://biznetgio.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: biznetgio.com is back up in b8159da.


text:
🛑 rad.net.id is down

In a0b2787, rad.net.id (http://rad.net.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rad.net.id is back up in 12e367b.


text:
🛑 cbn.id is down

In ab16587, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 5f7040e.


text:
🛑 detik.com is down

In 345f431, detik.com (https://detik.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: detik.com is back up in c7257ba.


text:
How to use the '/desktop/metrics/'  REST API endpoint

The HUE instructions describe "A REST API endpoint '/desktop/metrics/' to get all the metrics dump as json is also exposed".
But I can't get the metrics using following code:
import requests

next_url = "/"
login_url = "http://localhost:8888/accounts/login"

session = requests.Session()
response = session.get(login_url)

form_data = {
    'username': 'username',
    'password': 'password',
    'csrfmiddlewaretoken': session.cookies['csrftoken'],
    'next': next_url
}
response = session.post(login_url, data=form_data, cookies={}, headers={'Referer': login_url})

print('Logged in successfully: %s %s' % (response.status_code == 200, response.status_code))

cookies = session.cookies
headers = session.headers

response = session.get('http://localhost:8888/desktop/metrics/')

print(response.status_code)
print(response.text)

Could someone can help me?

Did you enable the metrics endpoint in the config file under [[metrics]] @plusplusjiajia ??
It can be found in desktop/conf with the name of pseudo-distributed.ini which is the config file for your local Hue

Please post the Hue logs too

authors: Harshg999 plusplusjiajia romainr

repo: cloudera/hue


text:
Fixing broken tests.

Tests were failing:
There were 5 errors:

1) CF\WordPress\Test\PluginActionsTest::testReturnApplyDefaultSettingsWithZoneWithPlanBIZ
Undefined offset: 1

/CloudFlare-Wordpress/src/WordPress/PluginActions.php:40
/CloudFlare-Wordpress/src/Test/WordPress/PluginActionsTest.php:83

2) CF\WordPress\Test\PluginActionsTest::testReturnApplyDefaultSettingsWithZoneWithFreePlan
Undefined offset: 1

/CloudFlare-Wordpress/src/WordPress/PluginActions.php:40
/CloudFlare-Wordpress/src/Test/WordPress/PluginActionsTest.php:107

3) CF\WordPress\Test\PluginActionsTest::testReturnApplyDefaultSettingsZoneDetailsThrowsZoneSettingFailException
Undefined offset: 1

/CloudFlare-Wordpress/src/WordPress/PluginActions.php:40
/CloudFlare-Wordpress/src/Test/WordPress/PluginActionsTest.php:120

4) CF\WordPress\Test\PluginActionsTest::testReturnApplyDefaultSettingsChangeZoneSettingsThrowsZoneSettingFailException
Undefined offset: 1

/CloudFlare-Wordpress/src/WordPress/PluginActions.php:40
/CloudFlare-Wordpress/src/Test/WordPress/PluginActionsTest.php:137

5) CF\WordPress\Test\PluginActionsTest::testReturnApplyDefaultSettingsCreatePageRuleThrowsPageRuleLimitException
Undefined offset: 1

/CloudFlare-Wordpress/src/WordPress/PluginActions.php:40
/CloudFlare-Wordpress/src/Test/WordPress/PluginActionsTest.php:153

Removed createWordPressClientAPI() because since you don't mock the class under test you can't mock that method and since it has logic (creating the client) it breaks.  Replaced with the setter
Mocked $this->request.  I know you stole this approach from me so fixing my own mistake here.  Its better to mock it though because you can modify the request on a per request basis.
Use real constructor for CF\WordPress\PluginActions
Moved setClientAPI() into the setup() since every class needs it.

I haven't tested this on an actual WordPress blog but I'm assuming its fine because composer test passes.  If anything breaks (I dont think it will) lets try to write tests to cover those edge cases.

I'm not sure whats wrong with the formatting in the PR, if its still broken after merging I'll fix.

repo: cloudflare/CloudFlare-Wordpress


text:
Limits update

This PR is to update the limits page
Do not merge yet

Cool - this page looks pretty much ready to go. Will just need to update with the metadata limit once we have that

Metadata limit still not added.

authors: daisyfaithauma kathayl

repo: cloudflare/cloudflare-docs


text:
struggling to understand the demo

what does this piece of code do? how should it behave? how can I increment value of A and B?

See the updates to the bottom of the readme

authors: bkyerv koeninger


text:
Added custom callback to parse input files

This adds a new parser argument to schema driver to be able to give a
custom parser instead of the regular JSON one (this is still the
default).
My use case that I have quite lengthy descriptions in my schema which makes easier for me to write them in YAML. The new callback is called with the file name as second argument so the custom parser can figure out what to do depending on file extension for instance.

Btw, I've found really good JSON Schema resolver: https://github.com/BigstickCarpet/json-schema-ref-parser - it supports both YAML and JSONs, external URIs, cycles... and it has an extensive test suite. I am now experimenting with this https://www.npmjs.com/package/@pr0da/json-schema-loader which is using the library above. It works really good (hot reloading, caching, partial builds, tracking dependencies...). I want to combine it with another webpack loader that will use code from our transformer - it will turn resolved schemas from json-schema-loader into examples (transformed links, object definitions...etc).

That sounds interesting! I would be happy to test that as soon as you have something working :)

authors: jdesgats tajo

repo: cloudflare/json-schema-docs-generator


text:
Can't use for server-side rendering

I just stumbled across this package while looking at react-modal2 (while researching an alternative for react-modal and I really like the philosophy of creating small, dumb components that do one thing.
However, I'm working on an isomorphic app and this package currently can't be used server-side, since it dies on this error:
./node_modules/react-gateway/index.js:20
      to: document.body
          ^

ReferenceError: document is not defined
    at Function.module.exports.React.createClass.getDefaultProps (./node_modules/react-gateway/index.js:20:11)

This is pretty logical of course, but it would be excellent if this package could be used server-side too so it can be used in isomorphic apps.

I needed fix asap so my fork is here https://github.com/brabeji/react-gateway/tree/server-renderable , I could submit PR when I'm able to fix tests.

@brabeji out of curiosity, how do you use this on serverside? check if document is defined, and if not, don't pass anything?

Didn't get his far yet :)) On a second thought, I will maybe omit react-gateway and render modals in proper location in the first place.

I was experimenting with a way to render a container element that gateway can use, but didn't get it working.
function Application() {
  return (

        <ReactGateway to="global">
          ...
        </ReactGateway>

      <ReactGateway.Dest name="global"/>

  );
}

I'm happy to work on a pull request for this if I roughly know what to do
or where to start looking. I know more or less how react's rendering
process works but not really in detail.
I'm just wondering how you'd work this out serverside. Using that unsafe
subtree render, I guess you'd want to render multiple trees, potentially,
and then dump them into the body of yiur output. Question is how would the
client side code react to this...
Looking forward to your insights!
On Thu, 17 Dec 2015, 00:09 James Kyle notifications@github.com wrote:

I was experimenting with a way to render a container element that gateway
can use, but didn't get it working.
function Application() {
return (

...

  <ReactGateway.Dest name="global"/>

);
}
—
Reply to this email directly or view it on GitHub
https://github.com/cloudflare/react-gateway/issues/1#issuecomment-165277818
.

This is the basic idea: http://jsbin.com/xebizav/edit?js,output
I'll try putting something together tonight

Ah, so you'd create one child for all used gateways, and then render that one into the server response alongside the rest of your app? Will react "understand" this and simply re-use the markup, or?

I have it working already, React doesn't throw any warnings so I think it works fine. I'm testing a bunch of different scenarios now and making sure I'm not creating any memory leaks, but I think this is the right solution.

Oh that is awesome! So from what I'm seeing here, you'll need to render the GatewayProvider alongside your App inside a root element so that you can then use it, not being dependent on document body?
That's a really elegant solution, very nice!

The only reason for the <GatewayProvider> is to instantiate a registry that gets passed in through childContext. I'm trying to understand the implications of that fully as I've never used context before.

I think this is also the cleanest way to handle this though, since you don't have to do any weird/disgusting workarounds server-side, and you can use the same logic on both client and server.
Any idea of when you'll be releasing this? I'd really prefer to use this rather than react-modal or react-portal which do a lot more than I'd like.

I'm trying to finish it tonight to open a PR, but it'll probably take me a day or two before releasing it.

D'awh okay. That's too bad. Looking forward to the release! :+1:

Ugh, so I just discovered context doesn't work in between components.
So you couldn't do:
function HomePage() {
  return (

      <Gateway into="global">...</Gateway>
      <GatewayDest name="global"/>

  );
}

function Application() {
  return (
    <GatewayProvider>
      <Application/>
    </GatewayProvider>
  );
}

I need to figure out a better way of doing this.

I'm sure that's just pseudo code, but you can't render <Application /> in its own render function I would imagine?
If you have something like this:
function App() {
    return (
        <Gateway into="global">

I'm on a boat, err gateway

        </Gateway>
    );
}

function Root() {
    return (
        <GatewayProvider>
            <App />
            <GatewayDest name="global" />
        </GatewayProvider>
    );
}

GatewayProvider would provide the context, and everything in its subtree should be able to access said context. Do you have some code somewhere in a branch or something that I can look at?

I'm just throwing something together in a jsbin, will update shortly.

I think I'm almost there: http://jsbin.com/qavule/1/edit?js,output
Problem I'm facing now is that the GatewayDest has not yet registered itself when it needs to be rendered into. Wondering if stuffing it inside of another lifecycle hook would help, so it can register itself in the context before the App uses it.
Thoughts?

Alright, I've made a little more progress: http://jsbin.com/qavule/2/edit?js,output
Now, upon mounting the GatewayDest a ref is saved to the div, and then that is registered into this.context.gateways with the given name.
The problem now is that the GatewayDest needs to be defined before it is used as a Gateway's into. I'm not really sure if there's any obvious way around this, but I don't see it.
I don't really know if it really matters too much if the GatewayDests are above the application, but it seems a bit limiting and error-prone.
Also, I'm curious if this is actually what you were doing in your stuff or that I'm on a completely wrong path, haha.

Both the <Gateway> and the <GatewayDest> need to be able to grab the context from <GatewayProvider> but the way React is designed is to only pass context within the same component which is not a limitation that will be okay for this library

The only alternative here is to have a singleton in the library, I'm afraid of doing that and opening up memory leaks

Yeah for sure, I agree. But the question is, is there any way around this
in the current solution I have?
On Thu, 17 Dec 2015, 20:22 James Kyle notifications@github.com wrote:

The only alternative here is to have a singleton in the library, I'm
afraid of doing that and opening up memory leaks
—
Reply to this email directly or view it on GitHub
https://github.com/cloudflare/react-gateway/issues/1#issuecomment-165554705
.

What you have is extremely similar to what I created which doesn't work

Haha okay. That's too bad really, it feels like the only thing that's
lacking in this solution is that the dests need to be defined before they
are used.
Do you have any other ideas?
On Thu, 17 Dec 2015, 21:32 James Kyle notifications@github.com wrote:

What you have is extremely similar to what I created which doesn't work
—
Reply to this email directly or view it on GitHub
https://github.com/cloudflare/react-gateway/issues/1#issuecomment-165574694
.

Never mind, I was just being dumb. I've pushed new changes. I will write tests tomorrow (seeing star wars tonight) and new docs and publish.

Ah! I was supposed to see star wars yesterday evening but had a christmas
party from my new work. Enjoy!
Gonna have a look at the code when I get to work. :)
On Fri, 18 Dec 2015, 03:50 James Kyle notifications@github.com wrote:

Closed #1 https://github.com/cloudflare/react-gateway/issues/1.
—
Reply to this email directly or view it on GitHub
https://github.com/cloudflare/react-gateway/issues/1#event-495419510.

The code looks great - you did a really nice job man. The only thing I don't quite understand is why it works for you, defining the gateways later, but I guess it's cause you use the registry as a middleman and don't directly refer to the gateways.
Awesome job, thanks for picking this up so fast, helps me out a ton.

react-gateway@2 and react-modal2@3 have been published

Awesome! Thanks again for your hard work mate. :)

authors: brabeji chielkunkels thejameskyle

repo: cloudflare/react-gateway


text:
Changes in the validity of a origin_ca_certificcate is not triggering a replacement of the resource

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.3.5
on linux_amd64

provider registry.terraform.io/cloudflare/cloudflare v3.28.0

Affected resource(s)
cloudflare_origin_ca_certificate
Terraform configuration files
resource "cloudflare_origin_ca_certificate" "example" {
   csr                = tls_cert_request.example.cert_request_pem
  hostnames          = "redacted.domain.tld"
  request_type       = "origin-rsa"
  requested_validity = 90
}

Link to debug output
tflog.out
Panic output
No response
Expected output
cloudflare_origin_ca_certificate.origin-certificate must be replaced
+/- resource "cloudflare_origin_ca_certificate" "origin-certificate" {
~ id     = 710620734040230398620075686393988983954432376974-> (known after apply)
~ creation_timestamp = "2022-11-21T10:38:37.693-08:00" -> (known after apply)
~ requested_validity = 365 -> 90
# (3 unchanged attributes hidden)
}
Actual output
cloudflare_origin_ca_certificate.origin-certificate will be updated in-place
~ resource "cloudflare_origin_ca_certificate" "origin-certificate" {
id                 = "710620734040230398620075686393988983954432376974"
~ requested_validity = 365 -> 90
# (5 unchanged attributes hidden)
}
Steps to reproduce

Create a origin_ca_certificate with any validity
Change the validiy
Execute a plan

Additional factoids
Doing some research I believe that this will be fixed adding the modifier "ForceNew: True" for the field validity in the file https://github.com/cloudflare/terraform-provider-cloudflare/blob/master/internal/provider/schema_cloudflare_origin_ca_certificate.go
References
This may be related to https://github.com/cloudflare/terraform-provider-cloudflare/issues/1007

log file available at https://gist.github.com/peruzzof/2e7e49185f6f4f05e0d3c72d6d6bb461


text:
[Stream] WebRTC Template Improvements

What this PR solves / how to test:

The example we have to kick off WebRTC testing isn't super clear, pull those variables up and label them.

Starting it up on StackBlitz doesn't work without specifying a port number.

How to test --- compare these two:

https://stackblitz.com/fork/github/cloudflare/workers-sdk/tree/main/templates/stream/webrtc?file=src%2Findex.html
https://stackblitz.com/fork/github/tsmith512/workers-sdk/tree/tsmith/stream-fixes/templates/stream/webrtc?file=src%2Findex.html
(DM tsmith internally if you need a WebRTC live input to test)

Associated docs issue(s)/PR(s):

[insert associated docs issue(s)/PR(s)]

Author has included the following, where applicable:

[ ] Tests
[ ] Changeset (Changeset guidelines)

Reviewer is to perform the following, as applicable:

Checked for inclusion of relevant tests
Checked for inclusion of a relevant changeset
Checked for creation of associated docs updates
Manually pulled down the changes and spot-tested

Note for PR author:
We want to celebrate and highlight awesome PR review! If you think this PR received a particularly high-caliber review, please assign it the label highlight pr review so future reviewers can take inspiration and learn from it.

Oh. ref #2314 is what causes the example to be broken.

I rebased and fixed the formatting issues here.
To test it I logged into the "Workers DX" Cloudflare account and created a "Testing workers-sdk issue 4157" live stream input.
The link given above https://stackblitz.com/fork/github/tsmith512/workers-sdk/tree/tsmith/stream-fixes/templates/stream/webrtc?file=src%2Findex.html appears to "sort of" work?
I can see the webpage appears and the local and remote live stream players show video from my laptop.
But I notice that wrangler pages dev is consistently displaying a warning
▲ [WARNING] Failed to get worker definitions TypeError: fetch failed

but I see that this is happening on the previous link too, so perhaps it is not relevant?
So generally I am happy to approve this PR if the warnings we are seeing are just red herrings.

I managed to run the template code locally, which seems to work fine. So perhaps it is just an oddity of Stackblitz with Miniflare?
I note that the template is pinned to Wrangler v2, so I tried updating to v3, but this still had similar errors.

repo: cloudflare/workers-sdk


text:
bump node.js to v.20 for all C3 workflows

The C3 e2es (both experimental and not) tests for Nuxt using yarn under ubuntu seem to be consistently failing on every PR that runs them.
By looking at the logs it looks like Nuxt is incompatible with the version of node that we're using in our workflows:

So in this PR I am simply bumping the node version used by all the C3 workflows as that should be pretty safe to do I think.
I did not change the default node version for all workflows as I assume that we have a specific reason as to why we want to use 18.20.2 there (if not I am happy to change that value instead)

Tests

[ ] TODO (before merge)
[ ] Tests included
[x] Tests not necessary because: this is just a CI change

E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)

[ ] I don't know
[x] Required
[ ] Not required because:

Public documentation

[ ] TODO (before merge)
[ ] Cloudflare docs PR(s):
[x] Documentation not necessary because: this is just a CI change

Wrangler v3 currently supports Node v16+ as stated in the docs. But we are changing it to 18+ in v4 following the Nodejs support window (https://nodejs.org/en/about/previous-releases). So the wrangler workflow should probably stay in node16 for now.
But if we are just changing the c3 tests for frameworks to use node 18, i think it is fine?

Wrangler v3 currently supports Node v16+ as stated in the docs. But we are changing it to 18+ in v4 following the Nodejs support window (https://nodejs.org/en/about/previous-releases). So the wrangler workflow should probably stay in node16 for now.

The value I was referring to is the default one for the install-dependecies action:
https://github.com/cloudflare/workers-sdk/blob/ab7204a6eb8f5bab00172a6a2623251ba2d757ba/.github/actions/install-dependencies/action.yml#L6
So, I think that it should be the one most commonly used across all the various GitHub workflows.
There are a few gh workflows that use the action: GitHub search, I am not too involved/familiar with the monorepo so I cannot really say what default would make most sense without digging deeper into things a bit.
Interestingly the wrangler e2es are already purposely run under node 18 actually (instead of 16):
https://github.com/cloudflare/workers-sdk/blob/ab7204a6eb8f5bab00172a6a2623251ba2d757ba/.github/workflows/e2e.yml#L23

But if we are just changing the c3 tests for frameworks to use node 18, i think it is fine?

yeah I do think so, alternatively we skip the nuxt+yarn+ubuntu tests for the time being, but I would personally prefer to just bump the node version as I think we can reasonably expect people to use a relatively newer version of node when scaffolding a new application.
Actually 20 is not an LTS, so I wonder if it would be better to just straight jump to 22 🤔

One thing to note is that c3 has support for node 18 and up:
https://github.com/cloudflare/workers-sdk/blob/ab7204a6eb8f5bab00172a6a2623251ba2d757ba/packages/create-cloudflare/package.json#L91
Anyways I am fine with whatever the team prefers 🙂

One thing to note is that c3 has support for node 18 and up:

In that case I think c3 workflow should use node 18 in general, but node 20+ just for framework tests. We have no control over the node version requirements of the frameworks but the rest of the template should remain supported with node 18.

In that case I think c3 workflow should use node 18 in general, but node 20+ just for framework tests. We have no control over the node version requirements of the frameworks but the rest of the template should remain supported with node 18.

This makes sense to me 👍 , unfortunately C3 e2es run all together, we don't currently have a way to run separately the ones that use frameworks from the ones that don't 🥲
Of course we could implement that, but it would, in my opinion, require quite some refactoring and make the e2es process generally more complicated, so I don't think that it would be worth it 😕
Personally I would go with just using node 20+ (or 22+ as I mentioned) and:

as I mentioned assume that people do use modern node versions for new apps scaffolding
assume that if things work fine with node 20+/22+ then most likely they run well with node 18+ (since we don't use any newer fancy node feature as far as I know)
on the next major version of C3 we bump the node requirement accordingly realigning everything

Closing in favour of #7649 (turns out a non-controversial patch bump was enough 🤦)

authors: dario-piotrowicz edmundhung


text:
Chore: refactor api/unstable_dev()'s types

At the moment, unstable_dev takes an object of options, with the following type:
interface DevOptions {
	env?: string;
	ip?: string;
	port?: number;
	localProtocol?: "http" | "https";
	assets?: string;
	site?: string;
	siteInclude?: string[];
	siteExclude?: string[];
	nodeCompat?: boolean;
	experimentalEnableLocalPersistence?: boolean;
	_: (string | number)[]; //yargs wants this
	$0: string; //yargs wants this
}

We should let folks use all options that wrangler dev exposes.

Closing this as it's not actually necessary - we can add types as necessary (and the existing types are already minimal and won't be removed)


text:
Prefer eiriniv1 (the custom resources) types over api (REST) ones

Provided that the REST API is sort of deprecated, we should look into preferring the custom resources data types over REST data types (for example, prefer eiriniv1.LRP over api.LRP). This means that api data types should be only used in the ("deprecated") REST layer, and the REST layer should be converting eiriniv1 to api types and vice versa.
In order to achieve this we could refactor the LRPClient and the TaskClient to be using the eiriniv1 data types.
Also, we may even end up with deleting the API data types completely as after the refactoring above, they would be just an unnecessary intermediate step between CC request types and eiriniv1 types.

It looks like as part of #216 we've removed the lastUpdated field from the CRD, which makes this change very difficult. We'll close this issue in favour of splitting out the CRD reconcilers in their own project

authors: danail-branekov mnitchev

repo: cloudfoundry-incubator/eirini-release


text:
Eirini-loggregator-bridge is missing logs

Describe the bug
https://github.com/SUSE/eirini-loggregator-bridge/issues/6
To Reproduce
Deploy Kubecf with latest eirini-loggregator-bridge code
Expected behavior
Logs shouldn't be lost, but at most be delayed because with the EiriniX bump, the watcher implementation is bookmarked.

Looking for an update @mudler when you get a chance :)

I think we can close this, I've bumped the dependencies in EiriniX here: https://github.com/SUSE/eirinix/pull/31 which includes a bunch of fixes also regarding watchers. The fix isn't in KubeCF yet as the bosh-release was removed as part of the Eirini native chart integration, so we have to wait for https://github.com/cloudfoundry-incubator/kubecf/pull/771 to be in

authors: gaktive mudler

repo: cloudfoundry-incubator/kubecf


text:
kube-apiserver should use a different certificate for the requestheader-client-ca-file

The API server should have a specific CA certificate for the Aggregator rather than reusing the kubo_ca. By reusing kubo_ca we're blurring trust boundaries and possibly opening up new attack vectors that wouldn't otherwise exist.
Configure the aggregation layer: Enable apiserver flags
Serving Certificates, Authentication, and Authorization: RequestHeader Authentication

Does Service-catalog use API-extensions?
Who uses Aggregator API?
How do they provide the certificate for it?
What is an upgrade path for such people?

authors: alex-slynko tvs

repo: cloudfoundry-incubator/kubo-release


text:
Failure on initial install to AWS

Following the instructions at https://github.com/cloudfoundry-incubator/lattice/tree/v0.2.1#clustered-deployment - I'm at the lattice apply stage, and this is the tail end of the output:
module.lattice-aws.aws_instance.lattice-coordinator (local-exec): Downloading Lattice Release tar from https://s3-us-west-2.amazonaws.com/lattice/releases/v0.2.1-14-g9bccdc0/lattice.tgz => /usr/local/home/silarsis/git/aws_lattice/.lattice/lattice.tgz
module.lattice-aws.aws_instance.lattice-coordinator (local-exec): Download complete
module.lattice-aws.aws_instance.lattice-coordinator: Provisioning with 'file'...
module.lattice-aws.aws_instance.lattice-coordinator: Provisioning with 'file'...
module.lattice-aws.aws_instance.lattice-coordinator: Provisioning with 'remote-exec'...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connecting to remote host via SSH...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Host: 52.64.49.88
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   User: ubuntu
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Password: false
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Private key: true
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connected! Executing scripts...
module.lattice-aws.aws_instance.lattice-coordinator: Provisioning with 'remote-exec'...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connecting to remote host via SSH...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Host: 52.64.49.88
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   User: ubuntu
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Password: false
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Private key: true
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connected! Executing scripts...
module.lattice-aws.aws_instance.lattice-coordinator: Provisioning with 'remote-exec'...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connecting to remote host via SSH...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Host: 52.64.49.88
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   User: ubuntu
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Password: false
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec):   Private key: true
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): Connected! Executing scripts...
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): tar: This does not look like a tar archive

module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): gzip: stdin: not in gzip format
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): tar: Child returned status 1
module.lattice-aws.aws_instance.lattice-coordinator (remote-exec): tar: Error is not recoverable: exiting now
module.lattice-aws.aws_instance.lattice-coordinator: Creation complete
Error applying plan:

1 error(s) occurred:

* Script exited with non-zero exit status: 2

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

hey @silarsis -- did you try this more than once? It looks like a download flaked out on you.

I deleted the .lattice directory and re-ran the apply, and got the same error.
I also tried to run a terraform destroy (after all the above) and got the following:
Error creating plan: Resource 'aws_instance.lattice-coordinator' does not have attribute 'public_ip' for variable 'aws_instance.lattice-coordinator.public_ip'

Yes, sadly terraform destroy is somewhat janky.  It doesn't handle dependencies correctly.
Looking carefully at your output  it looks like you're downloading https://s3-us-west-2.amazonaws.com/lattice/releases/v0.2.1-14-g9bccdc0/lattice.tgz
which doesn't actually exist.
A few questions:

Did you download the lattice.aws.tf file from the releases page (it links to this: https://cdn.rawgit.com/cloudfoundry-incubator/lattice/v0.2.1/terraform/aws/example/lattice.aws.tf)?

What os are you running on?  We use grep plus some funky regexp to parse the url in the .tf file and pick the correct asset to download.  There might be an issue peculiar to your platform in that codepath.

/cc @davidwadden could this be a regexp issue?

BTW When terraform destroy fails in this way you'll need to use your AWS console to destroy the VMs (EC2) and the remove the VPC (https://console.aws.amazon.com/vpc/home)

Downloaded the .tf file from the releases page, yes.
Running in a debian-based docker image. That image is a bit reliant on local environment so I can't easily share it, but if it's useful I can throw together a simple clean image to replicate the problem...?
I note, I'm running against ap-southeast-2, in case that makes a difference.
Expected to do manual clean-up after destroy broke, yes ;)

Actually, I may have lied - I used the .tf file from the git repo, not from the release. That may be the problem - sorry, I forgot that I'd done that :( Just re-running now with the adjusted source url...

...and that appears to have worked. Many apologies for the spurious issue - closing now :)

authors: onsi silarsis

repo: cloudfoundry-incubator/lattice


text:
Change database link so it can consume cf-mysql-release

This change allows a MySQL instance from cf-mysql-release to be consumed by the notifications release. It changes the link type to internal-database, which matches the link type provided by cf-mysql-release.

@oppegard This breaks the ability to consume the link from the proxy job from cf-mysql-release, which seems like a much more common practice. CC @joerodriguez

@davewalter Thanks for that info! We reverted and cut a new release.

authors: davewalter iplay88keys oppegard


text:
Fix device discovery through iSCSI for SoftLayer

iSCSI device discovery could not be called a second time after disk partioning,
since code was refactored for IaaS-native disk resize.
Here we modify slightly the algorithm so that a never-mounted but
already-partitioned disk doesn't trigger any unnecessary iSCSI restart.
Fixes #252.
While working on this fix, I've reviewed other strategy classes implementing the DevicePathResolver interface. Conclusion is that only the iSCSI strategy is dependant on whether the disk device is partitioned or not, which leads to different results when called before or after partitioning.

@donacarr Could you verify this change indeed fixes #252?

Looks good to me, let's wait for feedback from @donacarr.
@bgandon Out of curiosity, is iSCSI only used on SoftLayer?

The fix is partially working... I put comment here #252

We need still the fix.
Thx

Hello @donacarr, as discussed last month I've implemented a small cache in order to fix the issue pointed in your https://github.com/cloudfoundry/bosh-agent/issues/252#issuecomment-977712657. I've also added more unit tests in order to cover the issue that had been identified.
Could you please give it a shot and provide feedback? Thank you!

@donacarr were you able to test the changes made by Benjamin?

I plan to test it in the next two weeks

@donacarr, any new on testing the new updated code?

@donacarr, any new on testing the new updated code?

Hi @bgandon , sorry for late answer ... I was sick..
Btw my collegue tried your updated code but he got a failure:
Failures:

  1) with release and stemcell and subsequent deployments with persistent disk size changing should migrate disk contents
     Failure/Error: expect(persistent_disk('colocated', 0, deployment: deployment)).to_not eq(@size)

       expected: value != "20509264"
            got: "20509264"

       (compared using ==)
     # ./spec/system/with_release_stemcell_spec.rb:103:in `block (3 levels) in <top (required)>'

Unfortunately he did not collect new logs, so if you need it then the next time we build new stemcell, we will collect it...

Hello @donacarr,
With the issue you've encountered, it seems that growing the disk size using the classical disk migration process has failed in the Bosh Acceptance Tests.
It's not easy to relate that with the fix in this PR for resolving iSCSI device paths.
Yes, we would need the Agent logs in order to investigate the problem that prevented the disk from being properly resized.
Could you please provide these? Thank you.

@bgandon could you rebase these changes against master?

ping @bgandon

Sorry for late reply, will rebase soon!

All right, it's rebased!

Has this been validated to fix the problem? @donacarr created the original issue, but I haven't seen confirmation that these changes fix things.

@jpalermo yes the issue was fixed by the new code.
thank you

authors: bgandon donacarr friegger jpalermo rkoster

repo: cloudfoundry/bosh-agent


text:
Unable to go get bosh-cli package

I need to work on a contribution to the Terraform provider for cloud foundry which lists this package as a dependency.  Upon trying to go get the package I run into the following error:
What's Wrong
bash-3.2$ go get -d github.com/cloudfoundry/bosh-cli
go: downloading github.com/cloudfoundry/bosh-cli v0.0.159
go: downloading github.com/cloudfoundry/bosh-cli v6.4.1+incompatible
go get: github.com/cloudfoundry/bosh-cli@v6.4.1+incompatible: stream error: stream ID 9; NO_ERROR

What's Expected
I expect the package to be installed similar to this example from Google
bash-3.2$ go get github.com/google/codesearch/index
go get: added github.com/google/codesearch v1.2.0

Versions of Tools listed as Dependencies according to the README
bash-3.2$ go version; hg version; git version
go version go1.16.4 darwin/amd64

Mercurial Distributed SCM (version 5.9)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2021 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

git version 2.31.1

If you want to use the bosh cli, please follow the installation instructions as documented here: https://bosh.io/docs/cli-v2-install/.
This is also mentioned in the README: https://github.com/cloudfoundry/bosh-cli#install
Instruction on how to use it as a library are documented here: https://github.com/cloudfoundry/bosh-cli#client-library

authors: Anthonyhawkins rkoster

repo: cloudfoundry/bosh-cli