text:
v1.9: Update Go to 1.15.7

test-me-please

test-me-please

test-me-please

test-me-please

retest-4.9

retest-4.9

test-backport-1.9

test-backport-1.9

test-missed-k8s

test-missed-k8s

test-missed-k8s

test-missed-k8s

test-backport-1.9

test-backport-1.9

test-backport-1.9

test-backport-1.9

Not sure why Cilium-Ginkgo-Test-k8s  is in state _Waiting for status to be reported _ after https://github.com/cilium/cilium/pull/14665#issuecomment-766734280. Likely because I initially triggered CI using test-me-please? Given the reviews and the passing individual test I'll mark this as ready-to-merge.

Not sure why Cilium-Ginkgo-Test-k8s  is in state _Waiting for status to be reported _ after https://github.com/cilium/cilium/pull/14665#issuecomment-766734280. Likely because I initially triggered CI using test-me-please? Given the reviews and the passing individual test I'll mark this as ready-to-merge.

test-missed-k8s

test-missed-k8s

Not sure why Cilium-Ginkgo-Test-k8s  is in state _Waiting for status to be reported _ after #14665 (comment). Likely because I initially triggered CI using test-me-please? Given the reviews and the passing individual test I'll mark this as ready-to-merge.

@tklauser We had forgotten to update the regular expression to trigger Cilium-Ginkgo-Test-k8s from test-backport-1.9. I updated the regex in Jenkins, so it should work as expected now.

Not sure why Cilium-Ginkgo-Test-k8s  is in state _Waiting for status to be reported _ after #14665 (comment). Likely because I initially triggered CI using test-me-please? Given the reviews and the passing individual test I'll mark this as ready-to-merge.

@tklauser We had forgotten to update the regular expression to trigger Cilium-Ginkgo-Test-k8s from test-backport-1.9. I updated the regex in Jenkins, so it should work as expected now.

test-missed-k8s

test-missed-k8s

test-missed-k8s

test-missed-k8s

test-missed-k8s

test-missed-k8s

source: gharchive/pull-request

authors: pchaigno tklauser

repo: cilium/cilium

license_type: permissive

license_source: github-api


text:
v1.11 backports 2022-03-15

#18886 -- jenkinsfiles: bump runtime tests VM boot timeout (@nbusseneau)
#17851 -- Add support to connect Clustermesh clusters through Helm Chart (@samueltorres)
#18891 -- docs: update Azure Service Principal / IPAM documentation (@nbusseneau)
#18849 -- install/helm: Add Image Override Option to All Images (@nathanjsweet)
#18708 -- Add Amazon EC2 c7g instance configuration (@otterley)
#18877 -- hubble: Added nil check in filterByTCPFlags() to avoid segfault (@wazir-ahmed)
#18911 -- Fix IPsec in Azure's IPAM mode (@pchaigno)
#18952 -- pkg/maps: Fix data races around accessing nat maps (@aditighag)
#18975 -- cilium-cni: Call IPAMAllocate before creating veth (@michi-covalent)
#18897 -- helm: check for contents of bootstartFile (@aanm)
#19017 -- Fix 'node-init' in GKE's 'cos' images. (@bmcustodio)
#19036 -- docs: fix tip about opening the Hubble server port on all nodes (@rolinh)
#19053 -- helm: Remove Unnecessary RBAC Permissions for Agent (@nathanjsweet)
#19005 -- Policy fix mapstate owners (@jrajahalme)
#19031 -- selectorcache: Move identity alloc/release outside of critical section (@joestringer)
#19081 -- datapath/config: Fix L2 addr retrieval (@brb)
#19088 -- [Docs] Update docs to use enable endpoint route Azure cni (@nitishm)
#19100 -- Makefile: Fix TESTPKGS commandline (@joestringer)
#19076 -- clustermesh: fix: identities allocation range (@abocim)
#19108 -- bpf: Remove DNS quirk for monitor aggregation (@borkmann)
#18864 -- Prevent CiliumEndpoint removal by non-owning agent (@timoreimann)
#18783 -- accesslog: Pass destination identity from L7 proxies to access logs (@jrajahalme)

Once this PR is merged, you can update the PR labels via:
$ for pr in 18886 17851 18891 18849 18708 18877 18911 18952 18975 18897 19017 19036 19053 19005 19031 19081 19088 19100 19076 19108 18864 18783; do contrib/backporting/set-labels.py $pr done 1.11; done

/test-backport-1.11

/ci-gke-1.11

/test-backport-1.11

@jrajahalme latest test-runtime has failed with:
14:50:10      runtime: Mar 17 18:50:08 runtime cilium-agent[24010]: level=info msg="Cilium 1.11.2 b94d77d0d1 2022-03-17T10:08:24-07:00 go version go1.17.2 linux/amd64" subsys=daemon
14:50:10      runtime: Mar 17 18:50:08 runtime cilium-agent[24010]: level=fatal msg="Envoy: Binary \"cilium-envoy\" cannot be executed" error="exit status 1" subsys=envoy-manager
14:50:10      runtime: Cilium failed to start

Seems legitamate.

/ci-aks-1.11

/test-ci-aks-1.11

authors: ldelossa ti-mo


text:
docs: Add debugging guide for inspecting gops / pprof profiles

Document what is already known in the community for debugging CPU
bottlenecks and memory leaks within Cilium.
Fixes: https://github.com/cilium/cilium/issues/23004
Signed-off-by: Chris Tarazi chris@isovalent.com

/test

Netlify preview link: https://deploy-preview-26675--docs-cilium-io.netlify.app/contributing/development/debugging.html#cpu-profiling-and-memory-leaks
(Last build cancelled - as far as I understand - because the force-push didn't bring any new change to the docs)

/test

Marking ready to merge as it's a docs PR and the relevant CI jobs have passed + approving reviews. I'm not sure why there are required jobs for testing Cilum just for a docs PR.

authors: christarazi qmonnet


text:
[Docs] Clarify ClusterMesh troubleshooting steps when KVStoreMesh is enabled

when the KVStoreMesh is on, I find the debug steps are not in line with the facts, the hostAliases does not exist in Cilium DaemonSet, but exist in the clustermesh-apiserver deployment
the chart code
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cilium
  namespace: {{ .Release.Namespace }}
  labels:
    k8s-app: cilium
    .....
      {{- if and .Values.clustermesh.useAPIServer .Values.clustermesh.config.enabled (not .Values.clustermesh.apiserver.kvstoremesh.enabled) }}
      hostAliases:
      {{- range $cluster := .Values.clustermesh.config.clusters }}
      {{- range $ip := $cluster.ips }}
      - ip: {{ $ip }}
        hostnames: [ "{{ $cluster.name }}.{{ $.Values.clustermesh.config.domain }}" ]
      {{- end }}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: clustermesh-apiserver
  .......
      hostAliases:
      {{- range $cluster := .Values.clustermesh.config.clusters }}
      {{- range $ip := $cluster.ips }}
      - ip: {{ $ip }}
        hostnames: [ "{{ $cluster.name }}.{{ $.Values.clustermesh.config.domain }}" ]
      {{- end }}

and the remote cluster address does not exist in the secret cilium-clustermesh, but exist in the secret cilium-kvstoremesh
[root@master1 ~]# kubectl get secret -n kube-system cilium-clustermesh -o yaml | yq '.data' | awk '{print $2}' | base64 -d
endpoints:
- https://clustermesh-apiserver.kube-system.svc:2379
trusted-ca-file: /var/lib/cilium/clustermesh/common-etcd-client-ca.crt
key-file: /var/lib/cilium/clustermesh/common-etcd-client.key
cert-file: /var/lib/cilium/clustermesh/common-etcd-client.crt

[root@master1 ~]# kubectl get secret -n kube-system cilium-kvstoremesh -o yaml | yq '.data' | awk '{print $2}' | base64 -d
endpoints:
- https://cluster2.mesh.cilium.io:32379
trusted-ca-file: /var/lib/cilium/clustermesh/common-etcd-client-ca.crt
key-file: /var/lib/cilium/clustermesh/common-etcd-client.key
cert-file: /var/lib/cilium/clustermesh/common-etcd-client.crt

/test

@weizhoublue Could you maybe update the CODEOWNERS file to add sig-clustermesh as an owner of the docs you changed? That is:
Documentation/operations/troubleshooting_clustermesh.rst @cilium/sig-clustermesh @cilium/docs-structure

But it's only tangentially related to the change, so it's fine to merge the change as is IMO.

my pleasure, and updated

/test

the PR seems to have no business failing the connectivity test of the check
should I rebase the main branch ?

@weizhoublue yeah, the CI fail seems completely unrelated, it shouldn't block the merge I think

some connectivity case failed, I try to rebase again

/test

@weizhoublue It was probably a flake, don't worry about it. The checks relevant to your change passed, so once there is an approve from contributing the PR can be merged.

thanks

@weizhoublue It looks like this PR needs to be rebased to pick the latest CI changes

@weizhoublue It looks like this PR needs to be rebased to pick the latest CI changes

ok

/test

authors: giorio94 lambdanis weizhoublue


text:
policy: Add Port Range Support for Policies 3/3

See commits.
Fixes: #16622
Note: I'll address all missing documentation in a separate PR.
This builds on the following PRs:

https://github.com/cilium/cilium/pull/23885
https://github.com/cilium/proxy/pull/373
https://github.com/cilium/cilium/pull/29717
https://github.com/cilium/cilium/pull/32430
https://github.com/cilium/cilium/pull/32675

policy: Add support for port ranges in network policies.

/test

/test

The "ci-e2e-upgrade" is a known flake that is being investigated by the CI team.

/test

This branch of the cilium-cli has connectivity tests that use port ranges. I ran it locally, and all tests passed.

/test

This draft PR is a copy of this PR with an additional commit to use the cilium CLI that has port-range tests in the CI tests. It's passing on all tests, and the port-range tests are being run.

/test

https://github.com/cilium/cilium/pull/33238 is updated and green as well. This PR is ready to merge until it approved for release in 1.16 or the 1.16 release happens.

Summarazing the Slack discussion here: This feature was substantially completed already prior to feature freeze going into effect, and had just relatively minor feedback remaining prior to the date. The feature has been under high demand per the linked issue for at least a couple of years and we've finally got an implementation that the Cilium committers are happy with here. We had multiple committers and involved community members from different organizations advocating for a feature freeze exception for this feature, so it is included in the v1.16 release. We haven't yet branched off for v1.16 maintenance cycle, so the option is open for inclusion without additional backporting. Users are already taking mitigative actions due to the lack of support in Cilium. Assuming that we continue to validate & test the implementation through until release, it seems reasonable to grant an exception here and merge the PR during the feature freeze.

authors: joestringer nathanjsweet


text:
Prepare for release v1.5.2

Signed-off by: Ian Vernon ian@cilium.io

This change is

Superseded by #8204

authors: ianvernon tgraf


text:
Monitor: omiting panic when no events Fix #757

Hey!
My first PR :-)
This fix issue #757. The new output will be like this:
ubuntu-zesty ➜  cilium git:(757) ✗ ./cilium/cilium monitor
Error: Unable to get BPF events (Unable to get object: /sys/fs/bpf/tc/globals/cilium_events)

Regards

Changes done ;-)


text:
Lower default FQDN TTLs and update docs

The TTL can now be much shorter because we rely on the zombie management to keep in-use IPs around. I chose to lower it only to 1 hour but it can go much lower, and I'm happy to go further.
I also updated the docs to mention the zombies along with how to handle Alpine/musl and DNS Refused. I'm not sure that the latter is easy to find, though. The section is pretty non-descriptive :/

This change is

test-docs-please

test-me-please

Coverage decreased (-0.02%) to 45.785% when pulling 2bf6320dcdbb2715e4fef9049c2fc9e34b173cae on raybejjani:fqdn-docs-alpine into 9975bba1637c78446bcf39d5954ed9cfdcd0604a on cilium:master.

test-docs-please

test-me-please

authors: coveralls raybejjani


text:
⚠ Cioos National CKAN Sitemap has degraded performance

In d3d2060, Cioos National CKAN Sitemap (https://catalogue.cioos.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 6847 ms

Resolved: Cioos National CKAN Sitemap performance has improved in 95a1f74 after 5 minutes.

source: gharchive/issue

repo: cioos-siooc/cwatch-upptime

license: MIT


text:
ErrorAccumulatingUnmarshaller from akka-http-json lib no longer applying validations in 0.9.2

We have some Decoders with attached validations like this:
implicit val decodeSomething = deriveDecoder[Something].validate(..., ...)

And we use this for our akka-http routes (https://github.com/hseeberger/akka-http-json):
trait AkkaHttpCirceSupport extends BaseCirceSupport with ErrorAccumulatingUnmarshaller

And after updating to 0.9.2 that validation is no longer applied.
Switching to FailFastCirceSupport makes the validation run again. It's probably related to https://github.com/circe/circe/pull/838/files, but I'm not sure.
Reverting to 0.9.1 makes ErrorAccumulatingUnmarshaller run validations again.
I put together a couple of tests showing this here: https://github.com/yurique/akka-http-json-fail/tree/validation-fail (validation-fail branch)
sbt test fails in one of the cases; changing circe to v0.9.1 makes them pass.
I'm not sure if this is related to circe or to akka-http-json lib.
/cc @hseeberger

+1

Confirmed—this slipped by in #838. Publishing a fix this afternoon.

Okay, 0.9.3 is on its way to Maven Central. Thanks much for the report, and apologies for the inconvenience (I promise to be more vigilant about code review in the future!).

Thanks so much!

Thank you!

authors: mwielocha travisbrown yurique

repo: circe/circe

license_source: bigquery


text:
Update scalafmt-core to 3.3.0

Updates org.scalameta:scalafmt-core from 3.2.2 to 3.3.0.
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.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Codecov Report

Merging #1895 (ebdc31f) into main (f045f2c) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1895   +/-   ##
=======================================
  Coverage   86.29%   86.29%
=======================================
  Files          73       69    -4
  Lines        2532     2503   -29
  Branches      130      134    +4
=======================================
- Hits         2185     2160   -25
+ Misses        347      343    -4

Impacted Files
Coverage Δ

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
97.50% <0.00%> (-2.50%)
:arrow_down:

...es/core/shared/src/main/scala/io/circe/Error.scala
61.76% <0.00%> (-1.40%)
:arrow_down:

...core/shared/src/main/scala/io/circe/CursorOp.scala
54.16% <0.00%> (-1.39%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
83.12% <0.00%> (-0.56%)
:arrow_down:

...nter/src/main/scala/io/circe/pointer/Pointer.scala
89.34% <0.00%> (-0.13%)
:arrow_down:

.../src/main/scala-2/io/circe/EnumerationCodecs.scala
100.00% <0.00%> (ø)

...rc/main/scala-2/io/circe/EnumerationDecoders.scala
100.00% <0.00%> (ø)

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
87.71% <0.00%> (ø)

...rc/main/scala-2.12/io/circe/FactoryInstances.scala

...in/scala/io/circe/pointer/PointerSyntaxError.scala

... and 2 more

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 f045f2c...ebdc31f. Read the comment docs.

authors: codecov-commenter scala-steward


text:
Update scodec-bits to 1.1.34

Updates org.scodec:scodec-bits from 1.1.30 to 1.1.34.
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.scodec", artifactId = "scodec-bits" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Codecov Report

Merging #1986 (f93c319) into main (08c0e0c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1986   +/-   ##
=======================================
  Coverage   86.06%   86.06%
=======================================
  Files          74       74
  Lines        2554     2554
  Branches      132      136    +4
=======================================
  Hits         2198     2198
  Misses        356      356

Flag
Coverage Δ

2.12.15
85.89% <ø> (+0.03%)
:arrow_up:

2.13.8
86.09% <ø> (-0.08%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
88.30% <0.00%> (ø)

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 08c0e0c...f93c319. Read the comment docs.


text:
Set up permanent hosting server

Since there is a Express Backend, this project cannot be hosted on github pages. Find an alternate place to host the project to showcase it for prospective users and employers.

Heroku

Possible options include Heroku and DigitalOcean, so far

repo: cireneirbo/Earth-Observation-System


text:
prerequisite setup for ubuntu

since only macOS setup was available.

Codecov Report

Merging #136 (9b171bd) into main (16bd171) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #136   +/-   ##
=======================================
  Coverage   21.37%   21.37%
=======================================
  Files          34       34
  Lines        1497     1497
=======================================
  Hits          320      320
  Misses       1167     1167
  Partials       10       10

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 16bd171...9b171bd. Read the comment docs.

authors: codecov-commenter ritvik-verma

repo: cisco-open/flame


text:
Functional Enhancements (v2)

Enhance vector processing --

Modify main vector processor to extract vsId from filename if not found in file.  Proxy-style files do not have vsId in the file, and libacvp requires vsId for processing.  If a vsId does not exist in the file, the filename will be searched for "vs" followed by digits, which will be interpreted as a vsId.  This was an early patch for proxy-style files that works well enough.

New function to process vectors that specifically supports acvpproxy-style vector files.  It is a 1st attempt at a "universal" vector file processor.  The function is named "offline" because it ignores the header (jwt, vsid, etc) and gets right to processing whatever it finds. It will process an array of algorithms (libacvp-style) or a single algorithm (acvpproxy style).  It is resilient to the occasional degenerate case of a naked (non-arrayed) json object. It is called "offline" since we're not tracking any of the session data.  The function is probably not usable (and indeed isn't required) in the case of a single-command full-round-trip testing session. That said, I have not blocked it off with ACVP_OFFLINE.

Add domain-type for PT length in symmetric ciphers -- Protocol allows domains, libacvp allowed only value arrays.
Add ACVP "health check" function -- An easy way to verify stable communications to an ACVP server without invoking any vector processing
Minor other tweaks and typos

the "universal" vector set parsing works fantastically, thanks! After we sort out the other comments, can you re-open this PR against 2_2_0-throttle? Typically, we want to keep API additions and changes to new minor release versions when possible.
Thanks,
Andrew

Closed to be re-open against 2_2_0

authors: RandallSteck abkarcher

repo: cisco/libacvp


text:
Updated CIC Chart to allow for complex version strings

Fixes #96

The issue been fixed in the latest Chart.
Please try and let us know if anything more is required.

authors: priyankash-citrix warrenrees

repo: citrix/citrix-helm-charts


text:
Update InitSDK.md

changed Init note.

Then why it is not advised to initialise citrus client on app launch ??

authors: MangeshKadam buildunr

repo: citruspay/citrus-android-sdk


text:
Can only generate images with a size of 1024x1024.

测试了一下，只能生成1024x1024的图片，其规格的图片比如1024x768，或者768x1024的图片，

测试了一下，只能生成1024x1024的图片，其规格的图片比如1024x768，或者768x1024的图片，

Error occurred when executing HYDiTTextEncoderLoader:
We couldn't connect to 'https://huggingface.co' to load this file, couldn't find it in the cached files and it looks like Tencent-Hunyuan/HunyuanDiT is not the path to a directory containing a file named t2i/tokenizer\config.json.
Checkout your internet connection or see how to run the library in offline mode at 'https://huggingface.co/docs/transformers/installation#offline-mode'
亲，你有碰到这个问题吗？怎么解决的？谢谢啦

@hexi2024hexi @EvanZouQ  I have pushed a fix to both issues. Please update and try again!


text:
add examples

add examples for each status/command that shows a request and the corresponding respons.

Json examples for each status/command has been added

great, thanks!

authors: emiltin otterdahl

repo: cityofcph/rsmp


text:
Create Event Category model

This model should be referenced by an Event (to categorize it) and by a NotificationZone (to specify which categories result in notifications being generated for that zone. Could probably suffice with a single category_name=django.CharField() attribute.

@brisandbeans I see the javascript label, but I'd nominate this for a python label as well because it needs to be a Django model as well.  How do Django and Backbone models interface with each other?

That's right. Whoops.
I'm inclined to agree that the category_name solution will suffice. No need to overcomplicate things prematurely. Unless we want events to have multiple categories.
I'm not sure yet how much Backbone needs to know about Events.

no action needed

authors: brisandbeans challyed wrightgd

repo: cityofsomerville/citydash

license: mit


text:
Feature request 'Poe'

can you add support for Poe platform which include some useful AI bots, here's the api https://github.com/ading2210/poe-api

Hi there,
As I don't use Poe frequently, I currently do not have any plans to include Poe functionality. However, you may want to try out this repository as an alternative solution.

Thanks bro for your time and hard word , and also for the repo you recommended for me

authors: ciuzaak m-kaissi

repo: ciuzaak/Claude-Telegram-Bot


text:
🛑 Dodmets API is down

In 5a51595, Dodmets API (https://api.dodmets.com/hello/world) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Dodmets API is back up in b4cc629 after 1 day, 20 hours, 55 minutes.

repo: civcicd/uptime-monitor


text:
Azure staging deployment broke due to missing variable

Describe the bug
Staging deploy for azure broke due to:
╷
│ Error: No value for required variable
│
│   on variables.tf line 63:
│   63: variable "email_provider" {
│
│ The root module input variable "email_provider" is not set, and has no
│ default value. Use a -var or -var-file command line argument to provide a
│ value for this variable.
╵
This most likely is  related to the recent work done for azure email sending.
To Reproduce
Visit the latest deployment action at:
https://github.com/civiform/civiform-staging-deploy/actions/workflows/azure_deploy.yaml
View the failed deployment action log
Expected behavior
Deployment should succeed

File link to error line https://github.com/civiform/cloud-deploy-infra/blob/8db6a50bee8e742a1d61bd48fda8e71405a88bed/cloud/azure/templates/azure_saml_ses/variables.tf#L63

repo: civiform/civiform


text:
Simple Album classification

Create a simple Album classification class.

Commit:
https://github.com/cjcodeproj/medialibrary/commit/b8c592d2203b1289d11540dfdaa6d371a763d920

Closing Notes

It's missing some data points, but they can be filled in later.

repo: cjcodeproj/medialibrary


text:
用于谣言识别或检测是否可行

请问作者如果想要将CNN/RNN用于谣言的识别应该怎么去实践？

有兴趣的组个团啊


text:
Fullscreen error on double click

Browser: Chrome 77.0.3865.90
OS: Windows 10
Clappr Version: 0.3.9
Steps to reproduce:

first step
Open console then double click on player:

Uncaught (in promise) TypeError: fullscreen error
Did you try to reproduce this issue at http://cdn.clappr.io/

Thank you @fabioricali , i confirm the issue.
WIth Chrome 77.0.3865.90, double-clicking player switch player to fullscreen mode and trigger an "Uncaught (promise) TypeError: fullscreen error"
It seems not to be a critical issue because fullscreen feature still works. (may be a Chrome temporary issue).

@fabioricali as @kslimani answered it seems to be a Chrome issue. I checked the event handler chain and the fullscreen call is being done directly on the event handler stack.
I'll close this issue for now since the feature is working and the problem seems to be related directly to Chrome (and Chromium-based browsers). If the problem persists or the feature breaks we can revisit it.

@kslimani just so you know, we're splitting the Clappr codebase into separate projects: one with the core components and another with the main plugins, which will be converted into a monorepo.
The playbacks are being split into their own projects as well: hlsjs-playback, flashls-playback and flash-playback.
This will allow us to release more fine-grained package updates, and allow us to better keep track of issues and pull requests. Another upside from this is that users can build their own versions of Clappr without being burdened with unused plugins.

Hi! I opened a PR on @clappr/core which I think solves this issue. Feel free to discuss the solution on the PR (:

authors: fabioricali joaopaulovieira kslimani towerz

repo: clappr/clappr


text:
Update our HLSPlayer.swf with latest FlasHLS (v0.4.4.5)

maybe refs #631

closed by b798074734995339cddd99a4f0fe28b6c91f0c23


text:
Can i change position of export buttons other than top/bottom?

Seems there are 2 options to position default export buttons (Top/Bottom).
Is there a way i could position them anywhere else on the page, like may be in another div on the top of the page ?
This would be in a way resolved by: https://github.com/clarketm/TableExport/issues/40
But i was wondering if there is already an option for it ? I would like to use the existing export buttons.

There isn't an efficient way to do this as of yet, aside from the very hacky DOM manipulation solution of moving the <caption> element after running tableExport().
Something along the lines of this would work (using jQuery):
var $myTable = $('table');
$myTable.tableExport();
var buttons = $myTable.find('caption').html();
$('#someOtherDiv').html(buttons);

Dude, you are fuc***ing awesome. Thanks

There isn't an efficient way to do this as of yet, it a WIP though as you pointed out in #40 .
...although it is still possible. You could do a somewhat "hacky" DOM manipulation by moving the <caption> html (i.e. buttons) at some point after running tableExport() on your table.
Something along the lines of this would work (using jQuery):
// Define the table you want to export
var $myTable = $('#table');
// Run `tableExport()`
$myTable.tableExport();
// Detach the `buttons` html
var $buttons = $myTable.find('caption').children().detach();
// Append the buttons to an element of your choosing
$buttons.appendTo('#someOtherDiv');

Dude, you are fuc***ing awesome. Thanks

authors: bhumis clarketm phbrazil

repo: clarketm/TableExport


text:
Not displaying preview of the dragging item when in a virtualized list

I'm having an issue of displaying the preview of a dragging item in a virtualized list.
It's when I removed this line https://github.com/clauderic/dnd-kit/blob/05d6a78a17cbaacd8dffed685dfea5a6ea3d38a8/stories/2 - Presets/Sortable/5-Virtualized.story.tsx#L91
After dragging and scrolling passes the initial view, the preview of the dragging item will be disappeared.
I am using latest versions:

@dnd-kit/core 4.0.3
@dnd-kit/sortable 5.1.0

Demo
https://user-images.githubusercontent.com/38782010/143559073-465d3219-ec12-4233-9d36-fe2bf3bf158b.mp4

This isn't a bug with @dnd-kit, this is just how virtualized lists work. When items scroll out of view, they get unmounted by the virtual list component.
If you're using react-tiny-virtual-list, you can use the stickyIndices prop to prevent the item from unmounting when it goes off screen:
<VirtualList
  stickyIndices={activeId ? [items.indexOf(activeId)] : undefined}

这不是一个错误@dnd-kit，这就是虚拟化列表的工作方式。当项目滚动出视图时，它们会被虚拟列表组件卸载。
如果您使用的是react-tiny-virtual-list，则可以使用stickyIndicesprop 来防止项目在离开屏幕时卸载：
<VirtualList
  stickyIndices={activeId ? [items.indexOf(activeId)] : undefined}

If using another virtual library such as react-virtuoso, is there a solution for @dnd-kit?

This isn't a bug with @dnd-kit, this is just how virtualized lists work. When items scroll out of view, they get unmounted by the virtual list component.
If you're using react-tiny-virtual-list, you can use the stickyIndices prop to prevent the item from unmounting when it goes off screen:
<VirtualList
  stickyIndices={activeId ? [items.indexOf(activeId)] : undefined}

If using another virtual library such as react-virtuoso, is there a solution for https://github.com/dnd-kit?

authors: clauderic danglduy hanmaker-s1

repo: clauderic/dnd-kit


text:
Move Python code to riemann/riemann; keep fortran code in riemann/src.

This replaces https://github.com/clawpack/riemann/pull/141.  It is backward compatible as it doesn't move any of the Fortran code.

Thanks for fixing that.  I think this just needs to get updated.

This is replaced by #147.

authors: ketch mandli

repo: clawpack/riemann


text:
🛑 livevault is down

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

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in ce5a01b.

repo: claytonplong/backup-uptime


text:
🛑 livevault is down

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

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 9c7ab4a.


text:
Classes of a SoundClass

Is there a better way of getting the classes inventory of a sound class system than by
sca = pyclts.SoundClasses('sca')
set(value['grapheme'] for value in sca.data.values())

and if not, should there be?

what do you mean by inventory?

The result of the second line, so eg.
{'2', '1', '5', 'I', 'E', 'C', '6', 'L', 'A', 'T', 'G', 'O', '9', '4', 'Y', 'W', 'P', 'K', 'B', '_', 'D', 'S', 'J', 'N', '0', 'U', '!', 'H', '3', 'R', 'M'}

Ah, no, not that I knew of. But LingPy has:
>>> m = Model('sca')
>>> m.chars2int

But only as long as sound classes are derived from lingpy, and I assume, they won't in the future, as we can imagine systems that are just based on the sounds in clts...

BTW: adding this to the library is a good idea. In fact: whe reading the file IN to the system, it could just be collected. If you want to go ahead with this, please do so.

authors: Anaphory LinguList

repo: cldf/clts


text:
Update file-level discovered licenses

Type: Incorrect
Summary:
Update file-level discovered licenses
Details:
Some of the discovered licenses at the file-level are incorrect.
Resolution:
Update cases of incorrect file-level licenses. Here, these are files that are discovered NOASSERTION or multi-license (AND) when they should actually be dual-license (OR).
(See bottom of https://github.com/stuk/jszip/)
Affected definitions:

jszip 265c959b1f15f8cd5ebe152154b88796e4a82f42

The file /lib/zipEntry.js was discovered as "NOASSERTION" initially by the tooling, and set as "OTHER" by me. But upon further inspection there are no license details in the file, so value should be "NONE". I can create a new curation for this one change if required.

@bduranc - do you think the curation for this file - https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/dist/jszip.js - would be (MIT OR GPLv3) per row 7 "AND Zlib" per row 5687-5701 (and in other sections of this file)?

@bduranc, @royaljust, or @AE49  - two other files I have questions on.

https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/test/jquery-1.8.3.min.js - this is curated as MIT, but the file points to "jquery.org/license," which says multiple things, so do you think this would be "OTHER?"
https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/lib/license_header.js - this is curated as "MIT OR GPL-3.0," but since there are two different things referenced on this file, do you think it would be (MIT OR GPL-3.0) AND MIT?

@bduranc - do you think the curation for this file - https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/dist/jszip.js - would be (MIT OR GPL-3.0) per row 7 "AND Zlib" per row 5687-5701 (and in other sections of this file)?

BD: @ariel11 : Yes, the license should also include ZLib.

@bduranc, @royaljust, or @AE49 - two other files I have questions on.

https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/test/jquery-1.8.3.min.js - this is curated as MIT, but the file points to "jquery.org/license," which says multiple things, so do you think this would be "OTHER?"
https://github.com/Stuk/jszip/blob/265c959b1f15f8cd5ebe152154b88796e4a82f42/lib/license_header.js - this is curated as "MIT OR GPL-3.0," but since there are two different things referenced on this file, do you think it would be (MIT OR GPL-3.0) AND MIT?

BD: @ariel11 : For the first one, looks to me like the core of jQuery is licensed under MIT. But sample code is under CC0. I don't believe the Sample Code portion affects the compressed file under review, but perhaps someone else knows different.
For the second point, that is a good question. I'd be interested in hearing other people's thoughts.
I can see why adding AND MIT would make sense as Pako is a separate component.
I think this shows that we need to improve the visibility between the license expression and the actual line(s) of code that were identified. In the case of the first file, there is some Zlib-licensed code but it is lower down in the file and not in the header.

@bduranc - We just had a steering committee call and agreed to curate "(MIT OR GPL-3.0) AND MIT," as discussed above.  I will update the curation and merge.  Thanks!!

repo: clearlydefined/curated-data


text:
fix(chrome-extension): Align env variable with dashboard example

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[x] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/clerk-js
[ ] @clerk/clerk-react
[ ] @clerk/nextjs
[ ] @clerk/remix
[ ] @clerk/types
[ ] @clerk/themes
[ ] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/fastify
[x] @clerk/chrome-extension
[ ] gatsby-plugin-clerk
[ ] build/tooling/chore

Description

[x] npm test runs as expected.
[x] npm run build runs as expected.

I will open a PR in dashboard to update the env examples

repo: clerkinc/javascript


text:
Bug in basic,  selected date is not shows properly its take previous date

selected date is not shows properly its take previous date , can't able to use the date picker completely
Update need

Same problem here

same problem here

Html Code

                            Schedule From*

                                    <input type="text" class="form-control" datepicker-popup="dd-MM-yyyy" ng-model="schedule.from_date" is-open="schedulestatusfrom.opened" datepicker-options="dateOptions" close-text="Close" placeholder="Select Date" required/>
                                    <button type="button" class="btn btn-default" ng-click="openScheduleFrom($event)"></button>

Date Picker code
    $scope.initiateScheduleFromDatepicker = function () {
      $scope.clearFrom = function () {
        $scope.schedule.from_date = null;
      };
      $scope.openScheduleFrom = function($event) {
        $scope.schedulestatusfrom.opened = true;
      };
      $scope.dateOptions = {
        formatYear: 'yy',
        startingDay: 1
      };
      $scope.schedulestatusfrom = {
        opened: false
      };

      var tomorrow = new Date();
      tomorrow.setDate(tomorrow.getDate() + 1);
      var afterTomorrow = new Date();
      afterTomorrow.setDate(tomorrow.getDate() + 2);
      $scope.events = [
        {
          date: tomorrow,
          status: 'full'
        },
        {
          date: afterTomorrow,
          status: 'partially'
        }
      ];
      $scope.getDayClassFrom = function(date, mode) {
        if (mode === 'day') {
          var dayToCheck = new Date(date).setHours(0,0,0,0);

          for (var i=0;i<$scope.events.length;i++){
            var currentDay = new Date($scope.events[i].date).setHours(0,0,0,0);
            if (dayToCheck === currentDay) {
              return $scope.events[i].status;
            }
          }
        }
        return '';
      };
    };
    $scope.initiateScheduleFromDatepicker();

If i select 3rd Jan it recogonises as 2nd january

That's a timezone related problem.
As an example: My current timezone is CEST (Central European Summer Time) which equals GMT + 2 (Greenwich Mean Time). If I pick a date, let's say 2016-04-12 it is stored as a Javascript Date object: Tue Apr 12 2016 00:00:00 GMT+0200 (CEST). The Problem is, that this equals Mon Apr 11 2016 22:00:00 GMT. Whoops ...
But you can fix it by converting it to UTC:
.on 'changeDate', (e) ->
  year = e.date.getFullYear()
  month = e.date.getMonth()
  day = e.date.getDate()
  date = new Date(Date.UTC year, month, day)

  scope.$apply ->
    scope.dpModel = date

Now my selected date 2016-04-12 would be stored as Tue Apr 12 2016 02:00:00 GMT+0200 (CEST) which equals Tue Apr 12 2016 00:00:00 GMT.

@fkammer Where do I need to change the code and add the Date.UTC? Because this problem still occurs.. You should update the library so that this problem does not exist anymore..

@suriyabalakrish @marco-mascia @riginoommen @Sef1995
I started a new repository wich fixes this bug (and a few more). More infos here #17 and here.

How can I resolve without starting with a new repository?

@Aragorn1992 , you don't have to start a new repository. Just switch from the angular-bootstrap-datepicker npm-package to my new ng-eternicode-datepicker repo

authors: Aragorn1992 Sef1995 fkammer marco-mascia riginoommen suriyabalakrish


text:
[AnVIL DX] Track entity table sorted

Currently blocked by #813 .
Approach

See #802  for implementation and modeling.
Add trigger and tag in GTM.

Definition of Done

Tag fired on sort of entity table column.

@frano-m I've pushed the code to your PR. While tracking for Table Sort (#802) & pagination (#807 ) in packages/data-explorer-ui/src/components/Table/table.tsx it throws an error. While my other tracking for Entity Tab selected (#809) & (#808) working properly on packages/data-explorer-ui/src/views/ExploreView/exploreView.tsx.  Although I have created tracking in GTM to handle the tracking for the site.
I'm not sure what's causing the issue, as the tracking codes are working properly fine for tab selection and Table filtration.
I've attached the image file showing the exact error that it's throwing. It throws this error after I do npx tsc in data-explorer-ui.

Can you also please confirm if line no 98, 162 & 182 will cause problem in packages/data-explorer-ui/src/components/Table/table.tsx.  I'm getting the entity tab value from exploreState and it might not be updated with the latest values.

@AyyazAli, as discussed, to resolve the above error we need to change the imports to relative paths. ⭐

Completed as per https://github.com/clevercanary/data-explorer/pull/63.

repo: clevercanary/data-browser


text:
Update wechat.go

Support the display of message detail

@all-contributors please add @pigcsy for code.

authors: pigcsy sevennt

repo: clickvisual/clickvisual


text:
Custom dataset use

How to use TabLLM on my dataset, I am unable to figure out how to do so, any help?

Hi @anukriti15 ,
thanks for your interest in TabLLM. Basically I would start with putting it into the datasets folder and follow the instructions for the other datasets. There are some adjustments you have to make to the code to work with a new dataset. I would also recommend following the code for the existing datasets. I cannot list all potential changes here.
If you encounter any specific problems with this proceeding, please let me know.
Best,
Stefan

repo: clinicalml/TabLLM


text:
Bring deviation request story to the JAB

In order to maintain a health compliance stance, we need to file all the necessary deviation request materials with the JAB for our impacted cluster.
Acceptance Criteria

[ ] State of K8s is discussed at JAB TRs meeting
[ ] JAB has all the DR materials, included what we prepared for CoalFire

Security considerations
We need to be circumspect about particularities of any issues in non-CUI services.

We need to submit FedRAMP DRs for:
CG04 Network Daemons
CG171
CG177
CG212 RA-5
CG213 RA-5
CG176
CG224-RA-5
CG231-RA-5
CG215
CG163
CG190

repo: cloud-gov/product


text:
Default module configuration missing status codes

When deploying the exporter by default the module configuration looks like below:
modules:
  http_2xx:
    http: null
    prober: http
    timeout: 5s

When it is like this all Prometheus queries from the exporter return 0, whether or not they are reachable. This happens because most of the config for the variable blackbox_exporter_configuration_modules in the defaults file is commented out, and the README doesn't specify that variable as something that must be defined. There should be some sane values in the defaults file, eg:
blackbox_exporter_configuration_modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: []
      method: GET

Could you create a PR to fix this?

repo: cloudalchemy/ansible-blackbox-exporter


text:
Update or remove sig/amqp-client.rbs

What can sig/amqp-client.rbs be used for? Do we need it in the repo? Currently I think it is a bit outdated (after running typeprof lib/amqp-client.rb > sig/amqp-client.rbs there's quite the diff)
https://github.com/cloudamqp/amqp-client.rb/blob/9b0662288d96b57cf331a494b469e23273886315/sig/amqp-client.rbs#L1-L4

fixed

authors: carlhoerberg dentarg


text:
🛑 puskomedia.id is down

In cb16dd9, puskomedia.id (https://puskomedia.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: puskomedia.id is back up in 1201180.

repo: cloudbip/upptime


text:
🛑 myrepublic.co.id is down

In a2fd171, myrepublic.co.id (https://myrepublic.co.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: myrepublic.co.id is back up in 3ae5a0b after 8 minutes.


text:
🛑 connectindo.com is down

In 139e51c, connectindo.com (https://connectindo.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: connectindo.com is back up in d5c0fa9.


text:
🛑 connectindo.com is down

In c44b321, connectindo.com (https://connectindo.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: connectindo.com is back up in 83c588b.


text:
🛑 cbn.id is down

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

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 9aed793.


text:
🛑 cbn.id is down

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

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 1787a8d.


text:
Minor changes after Blazor update

simplify usage of IJSProcesRuntime
minor .csproj cleanup

Thanks!

This is awesome!
Just one minor thing, i will change the safe cast back to a non safe cast. The error that the cast did not work is better than null reference errors in my opinion.

Sure, thanks!

authors: LunicLynx peterblazejewicz

repo: cloudcrate/BlazorStorage


text:
openapi.json: oauth2 securityDefinitions 'firebase-##'

For some reason the securityDefinitions of the openapi.json for firebase auth is generating as:
"securityDefinitions": {
  "firebase-115e09da": {
   "type": "oauth2",
   "authorizationUrl": "",
   "flow": "implicit",
   "x-google-issuer": "https://securetoken.google.com/project-id",
   "x-google-jwks_uri": "https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com",
   "x-google-audiences": "project-id"
  },
  "api_key": {
   "type": "apiKey",
   "name": "key",
   "in": "query"
  }
 },

Why does it generate as "firebase-115e09da"? The developer portal can't detect it's from firebase unless I rename all instances to "firebase".
My @Api is:
@Api(
  name           = "name",
  title          = "Project Title",
  version        = "v1",
  description    = "Project Description",
  apiKeyRequired = AnnotationBoolean.TRUE,
  authenticators = {EspAuthenticator.class},
  clientIds      = {
    Constant.API_EXPLORER_CLIENT_ID
  }, // clientIds //
  namespace = @ApiNamespace(
    ownerDomain = Core.PROJECT_DOMAIN,
    ownerName   = Core.PROJECT_DOMAIN,
    packagePath = ""
  ), // namespace //
  issuers = {
    @ApiIssuer(
      name    = "firebase",
      issuer  = "https://securetoken.google.com/" + Core.PROJECT_ID,
      jwksUri = "https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com"
    ) // ApiIssuer //
  }, // issuers //
  issuerAudiences = {
    @ApiIssuerAudience(name = "firebase", audiences = Core.PROJECT_ID)
  } // issuerAudiences //
) // Api //

It's done this way because during config generation, we have no idea of knowing how many auth configs there will be for an issuer config. Each set of target audiences requires a different auth config in OpenAPI. Therefore, we just generate a hash for all of them. We currently don't have any sort of normalization phase, which is where we would go back and eliminate the hash when it's unnecessary. @inklesspen

You'd have to maybe do a quick scan for each auth name to see if there are duplicates first before making hashes. Would be plausible as it's used as an "offline" app.

@cyraid this should be fixed in developer portal soon so you don't have to edit your spec.

Oh, excellent! Thank you for looking into this.

authors: cyraid tangiel

repo: cloudendpoints/endpoints-java


text:
[AUT-4038] Added possibility to define certificates for Ingress

Jira task - AUT-4038
Description
Added possibility to define certificates in Values.yaml to be used in Ingress later.
Type of changes
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Tests (extending the test suite)
[ ] Refactor (internal improvement that doesn't change product functionality)
[ ] Other (if none of the other choices apply)
Implementation details

Screenshots (if appropriate):

The change will be covered by that PR: https://github.com/cloudentity/acp-helm-charts/pull/114
Closing this one.

repo: cloudentity/acp-helm-charts


text:
Cant change datalake image to CentOS 7

I am currently automating the creation of a Cloudera CDP environment with Azure as the cloud provider. I have to use CentOS7 as the operating system. To change the operating system and the corresponding image of the data lake, I would use the ‘datalake_image’ variable of the cdp-deploy module. However, to be able to use this, ‘datalake_version’ must be set to null. When compiling, I always get the error that ‘datalake_version’ must not be null. How else can I change the image of the datalake?
Error message:
│ Error: Invalid function argument
│
│   on modules\terraform-cdp-deploy\variables.tf line 226, in variable "datalake_version":
│  226:     condition     = (var.datalake_version == "latest" ? true : length(regexall("\d+\.\d+.\d+", var.datalake_version)) > 0)
│     ├────────────────
│     │ while calling regexall(pattern, string)
│     │ var.datalake_version is null
│
│ Invalid value for "string" parameter: argument must not be null.

Hi @hndordix,
As part of PR #68, we've updated the validation on the datalake_version input variable to allow null.
We have also created a 0.7.1 release tag for this version of the modules.
When you get a chance can you test if this resolves your issues?
I suspect you may also need the changes in PR #57 as this allows the major OS version to be specified. We hit some issues when testing this which might require an update on the CDP provider.

authors: hndordix jimright

repo: cloudera-labs/terraform-cdp-modules


text:
added new variables that allow to disable the installation of some parts …

…(like java, rngd, mysql)
Motivation:

Allow to switch of the deployment parts we want to handle outside this playbook, in a more customized way
disable Java installation: the included OracleJDK-7 deployment is outdated, and most people that deploy a new cluster are much better off with a JDK-8 (even openjdk8 is perfectly fine), more infos: https://github.com/cloudera/cloudera-playbook/issues/24
disable Mysql installation: Useful if you want to use postgresql instead

for this see also https://github.com/cloudera/cloudera-playbook/pull/30

Would tags / skip_tags be a better way of achieving this?
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html

Would tags / skip_tags be a better way of achieving this?

Simply using tags can be good enough in some cases, but it often gets problematic with tags outside the main playbook ( which would be required for the cluster_install_groups_users toggle)
To avoid creating a bunch of new 'group vars' (in the all file .. we should add the '.yml' extension btw for proper yml handling in editors, like VScode), I could make undocumented vars by changing the when check(s) to:
      when: cluster_install_rngd | default(true)

authors: dbeech lhoss

repo: cloudera/cloudera-playbook


text:
Marcio/registrar revamp

1st draft for Registrar's documentation revamp

Weird conflict with file, so closing this and moving all the changes to another PR.

repo: cloudflare/cloudflare-docs


text:
Add docs for Oblivious DNS over HTTPS

cc @Lekensteyn @chris-wood @grittygrease

hey @Lekensteyn I see there are some changes still pending - happy to chat about them if needed, but I'd like to close out/merge this one!

Closing as this is outdated

authors: abracchi-tw marciocloudflare tanyav2


text:
Invalid state: chunk ArrayBuffer is zero-length or detached React 18 renderToReadableStream

Hi,
I don't know if this bug is related to React or is an issue with miniflare.
React 18 now support a new API for server side rendering in a worker context, this is the sample code:
import ReactDOMServer from 'react-dom/server'

async function handler() {
  const stream = await ReactDOMServer.renderToReadableStream(

Hello

  )
  return new Response(stream, {
    headers: {
      'content-type': 'text/html;charset=UTF-8',
    },
  })
}

addEventListener('fetch', async (event) => {
  event.respondWith(handler(event.request))
})

The first request is ok, the second time you get:
TypeError: Invalid state: chunk ArrayBuffer is zero-length or detached
    at new NodeError (node:internal/errors:371:5)
    at ReadableByteStreamController.enqueue (node:internal/webstreams/readablestream:1109:13)
    at writeChunk (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:81:1)
    at flushSubtree (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6312:1)
    at flushSegment (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6334:1)
    at flushSubtree (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6307:1)
    at flushSegment (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6334:1)
    at flushSegment (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6387:1)
    at flushSubtree (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6307:1)
    at flushSegment (/Users/fuma/projects/snext/node_modules/react-dom/cjs/react-dom-server.browser.development.js:6334:1) {
  code: 'ERR_INVALID_STATE'
}

Which version of React 18 are you using?  This might be a bug in latest React RC. Are you using any ReadableStream polyfills to make this work?

I was running  0.0.0-experimental-05c283c3c-20220302.
No i do this test with no polyfills ReadableStream are built-in in worker (but i don't know how miniflare provide this).
https://developers.cloudflare.com/workers/runtime-apis/streams/readablestream/
I will re-try with the new version of React and let you know i can also try on a real Cloudflare instance.

I filed a bug upstream in React. That's really the cause of the bug.

@gffuma the issue should be fixed on main with commit https://github.com/facebook/react/commit/e09518e5bbb78447d6c86481cf0dcafb4b09c734

Once on experimental tag i will retry. In the meantime thanks for the awesome work 🙏 🙏 🙏

authors: gffuma gnoff sebmarkbage

repo: cloudflare/miniflare


text:
FFI: Change SendInfo to return in nanoseconds instead of timespec

Motivation
Currently, we are returning a timespec in the SendInfo struct from the FFI interface. To construct that timespec we are copying over the bytes from a Rust Instant to the timespec struct. This runs into undefined behaviour since Instant is an opaque type and might not have the same layout as timespec. We have noticed this being a problem where Quiche is returning us timespecs with the nanosecond part being multiple days.
Modification
This PR changes the way we return the "write at" information by changing it to a "write in" property. This allows wrapping libraries to use their native Instant types to get the current time and then add the returned nanoseconds value to it. This also aligns the interface with how we expose timeout information through the FFI layer.
Result
We are no longer running into undefined behaviour.
cc @normanmaurer

Returning the amount of nanos sounds like a step backwards, the caller has to convert it to a timestamp at the earliest point possible anyway, because code that runs will otherwise affect the timing itself.

I understand your position here but there is no way to convert an Instant safely to a timespec as far as I know since the Instant type is opaque. We could change the internals of Quiche away from Instant and to something else but that just feels wrong. Furthermore, going to nanos here aligns it very nicely with the timeout methods where users also have to convert it to a point in time.

but there is no way to convert an Instant safely to a timespec as far as I know since the Instant type is opaque.

I also couldn't find such a way, unfortunately.

Furthermore, going to nanos here aligns it very nicely with the timeout methods where users also have to convert it to a point in time.

The Rust API recently started providing a timeout_instant method. I guess in order to address this issue.

Curious what folks think about changing SendInfo to not use Instant in the first place: #1409. SendInfo would contain the amount of time after "now" (whenever the SendInfo was generated) that the packet should be sent. This avoids FFI issues and allows the app to use whatever clock it wants

Curious what folks think about changing SendInfo to not use Instant in the first place: #1409. SendInfo would contain the amount of time after "now" (whenever the SendInfo was generated) that the packet should be sent. This avoids FFI issues and allows the app to use whatever clock it wants

As I said above, I think this would a step backward. In the FFI case, it seems unavoidable, but in Rust it isn't. You can already use whatever clock you want by calculating other_timekeeping::now() + (send_info.send_at - Instant::now()), but by returning an Instant, it does not matter how long you take to process it, it's valid forever.

Did we have any "outcome" here ? Without a fix we cant implement pacing when using the C api

Another valid way to solve this is to remove the at field altogether and let quiche do the pacing. The API is already there, quiche can communicate timeouts to the user of the API. What's the advantage of the at field? Does it help because there's kernel support on Linux?

FTR, we just merged https://github.com/cloudflare/quiche/pull/1483 which should fix the immediate problem of invalid timespec values. That said, I think it would still be useful to move away from Instant, though it should be on both the Rust as well as C sides (e.g. using Duration in the Rust API) like what Eric was doing in https://github.com/cloudflare/quiche/pull/1409 (though not sure what the status of that PR is), but need to think about what the consequences will be.

Thanks for the update. Going to close this PR then

authors: FranzBusch ehaydenr ghedo normanmaurer tbu-

repo: cloudflare/quiche


text:
Page rule validation error message not being returned

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.1.9
on darwin_amd64

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

Affected resource(s)
cloudflare_page_rule
Terraform configuration files
resource "cloudflare_page_rule" "this" {
  zone_id  = module.cloudflare_stro_debug.website.zone.id
  target   = "${module.cloudflare_stro_debug.website.zone.zone}/test"
  priority = 1

  actions {

    always_use_https = true

    cache_key_fields {
      header {}
      query_string {}
      user {}
      cookie {}
      host {}
    }
  }
}

Debug output
---[ RESPONSE ]--------------------------------------
HTTP/2.0 400 Bad Request
Connection: close
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cf-Cache-Status: DYNAMIC
Cf-Ray: 7017f3c91ba9e3ca-ATL
Content-Type: application/json
Date: Mon, 25 Apr 2022 15:01:09 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Expires: Sun, 25 Jan 1981 05:00:00 GMT
Pragma: no-cache
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU4vq74ZFe3sNVUZaMRnT3FnvWR; SameSite=Lax; path=/; expires=Mon, 25-Apr-22 17:31:10 GMT; HttpOnly
Set-Cookie: __cfruid=fb89178db7f78f805459602d86f6c6a8d414fd04-1650898869; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Strict-Transport-Security: max-age=31536000
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

{
 "success": false,
 "errors": [
  {
   "code": 1004,
   "message": "Page Rule validation failed: See messages for details."
  }
 ],
 "messages": [
  {
   "code": 1,
   "message": ".settings: \"always_use_https\" may not be used with \"any setting\"",
   "type": null
  }
 ],
 "result": null
}

Panic output
No response
Expected output
Expected messages field to be returned with error message
Actual output
Received vague error message:
│ Error: failed to create page rule: Page Rule validation failed: See messages for details. (1004)
│
│   with cloudflare_page_rule.this,
│   on stro-debug.tf line 108, in resource "cloudflare_page_rule" "this":
│  108: resource "cloudflare_page_rule" "this" {
│
╵

Steps to reproduce

Build zone
Apply a page rule that fails validation

Additional factoids
No response
References
No response

Please fix this asap, this is making working with page rules a real pain.

We have a very hard time at pulumi-cloudflare because of this.

Assume that cloudflare-go needs to be bumped to v0.53.0 as well?

yes, this requires the upstream release and then it will be included in the provider.

authors: brandonstrohmeyer etienne-napoleone jacobbednarz reedloden roger-5899


text:
Add is_deleted filter option to tunnel data source

This PR solves a problem we're having onboarding our services to Cloudflare. The problematic behaviour is already described in #3069.
With the addition of a is_deleted filter we can now ignore soft-deleted entities and get the correct tunnel back from the API.
The filter is utilising the already available IsDeleted parameter of the ListTunnel API.
make test and TESTARGS='-run ^TestAccCloudflareTunnel_Match' make testacc have been running successfully.
I have left the original functionality intact to not force anyone to adopt setting the parameter.
Closes #3069.

I'm unsure about the deletion make docs created for docs/resources/hyperdrive_config.md.
Should I drop them from my PR to make it simpler?

I'm unsure about the deletion make docs created for docs/resources/hyperdrive_config.md.
Should I drop them from my PR to make it simpler?

that looks to be because your branch is out of date with the upstream. if you update it, it should be present.

thanks for the contribution here!
looking at your test though, it doesn't actually do anything. if i comment out your newly added lines, the tests are still passing. i suspect it's related to https://github.com/cloudflare/terraform-provider-cloudflare/pull/3201/files#diff-3efcea7c71b17ecec6cfec3258b6a7d07026abc92fae723c69bad61941b1faeaR59 not actually doing anything.

Even after a rebase the make docs task does not change for me. Since this looks to be a problem for me locally I will remove the change.
The test case is weird. In theory the 3rd step removes the resource as well which is when you comment out the 2nd step you still see the same result. I added the 2nd step to ensure that the 3rd step runs after the resource has been fully removed from state and got deleted from the API. It basically should guard against a race condition for the delete - I hate flaky tests 😄

I have reworked the tests if you don't mind giving it another glance over.

thanks - i went ahead and tidied up the test assertions here as much of it wasn't needed for a minimal test case and was a little confusing as to what was trying to be achieved there.
acceptance tests are all passing
TF_ACC=1 go test ./internal/sdkv2provider -v -run "^TestAccCloudflareTunnel_Match" -count 1 -timeout 120m -parallel 1
=== RUN   TestAccCloudflareTunnel_MatchName
--- PASS: TestAccCloudflareTunnel_MatchName (9.63s)
=== RUN   TestAccCloudflareTunnel_MatchIsDeleted
--- PASS: TestAccCloudflareTunnel_MatchIsDeleted (22.83s)
PASS
ok  	github.com/cloudflare/terraform-provider-cloudflare/internal/sdkv2provider	33.431s

authors: MerlinDMC jacobbednarz


text:
Improves error messages when fetch fails due to TLS errors.

When running wrangler dev (or running workerd locally directly), it is possible for fetch to fail with an "internal error". This can likely happen for many reasons, but in my case it was because I was using WARP and had misconfigured TLS certs. The error I was running into was this one: https://github.com/capnproto/capnproto/blob/6e071e34d88a8fc489638535899cd9d02e55bf76/c%2B%2B/src/kj/compat/tls.c%2B%2B#L221.
I noticed that we already have some custom logic to catch certain exceptions raised from kj and report them back to the user in a more friendly manner. What I'm curious about is why we don't simply report all errors. I think that matching on strings here is fragile, so I went for a bit of a compromise and changed the code to report any error that occurred in kj. But perhaps that will expose far more than we want.
Test Plan

Added a KJ_FAIL_REQUIRE to tls.c++ that always fails
Ran workerd via LLVM_SYMBOLIZER=llvm-symbolizer-14 bazel run --config=release @workerd//src/workerd/server:workerd --     serve $PWD/deps/workerd/samples/pyodide/config.capnp --experimental
Modified pyodide sample to remove python_external_bundle compat flag and to fetch inside the worker instead
Re-ran workerd

@kentonv since you've had thoughts when this was modified previously in https://github.com/cloudflare/workerd/pull/2111#discussion_r1599006089. I wonder if you have any concerns about this change. Could we even maybe go further and expose all exception messages to the user?

Yeah this is a problem. KJ errors should absolutely should not be indiscriminately exposed to applications. At best, they are unlikely to be formatted appropriately; they usually contain a semicolon-delimited list of debug context which would look very strange in a JavaScript error. At worst, they may contain information which is inappropriate to reveal, like internal IDs or something. I apparently failed to chase @jasnell on this last time but this code needs to change back to hide the error.
What we usually do instead is instrument the lower-level systems with some way to provide an exception callback which can format exceptions more appropriately. E.g. the HTTP API has HttpClientErrorHandler. Maybe TLS needs one of these as well.

repo: cloudflare/workerd


text:
🐛 BUG: d1 execute command fails reading sql file which ends with comment line

Which Cloudflare product(s) does this pertain to?
D1
What version of Wrangler are you using?
2.14.0
What operating system are you using?
Mac
Describe the Bug
SQL file:
DROP TABLE IF EXISTS comments;
-- Optionally, uncomment the below query to create data

command:
wrangler d1 execute db --local --file schema.sql

👋🏻 Greetings,
I appreciate the report. This is the repo and issues for Wrangler (Cloudflare Worker CLI) Pages, & Other SDK tooling, this seems D1 specific.
Feel free to check out the Cloudflare Discord where there is a channel for D1 as well: https://discord.com/invite/cloudflaredev
To report issues related to D1 specifically:
https://community.cloudflare.com/c/developers/d1/85/l/latest
Cc: @nevikashah @rozenmd

Thanks for reporting this @reta-ygs, we'll take a look

Wrangler now handles this correctly.
Consider upgrading to either wrangler@beta or wrangler@3.0.1

authors: JacobMGEvans reta-ygs rozenmd

repo: cloudflare/workers-sdk


text:
🐛 BUG: Workerd errors swallowed in 3.5.0

Which Cloudflare product(s) does this pertain to?
Pages
What version(s) of the tool(s) are you using?
3.5.0
What version of Node are you using?
20.4.0
What operating system are you using?
Mac
Describe the Bug
Wrangler is not logging an error message if the previous instance of it is running in version 3.5.0 but however, it is in 3.4.0 and 3.3.0
Version 3.5.0

Version 3.4.0

Version 3.3.0

Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
No response

This was reported by another user in the Discord today too: https://discord.com/channels/595317990191398933/799437470004412476/1140359620620202085
It seems like wrangler 3.5.0 is swallowing some of these workerd errors that it didn't previously.

This should be resolved now. Feel free to re-open if this is still causing issues

authors: Cherry penalosa vineelsai26


text:
Local dev server does not start

I started this project using the create-remix with Cloudflare Pages template. The npm run dev script used to start a local server, but now it just builds the files without a server.
❯ yarn run dev
yarn run v1.22.17
$ cross-env NODE_ENV=development run-p dev:*
$ remix watch
$ wrangler pages dev ./public --watch ./build --kv snow
(node:37225) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Watching Remix app in development mode...
💿 Built in 193ms

I'm not sure when this stopped working, there was a week or so where local dev wouldn't work at all, and now it does this. The deployed version in Cloudflare Pages is still working fine, this is a local-only issue.
Wrangler version: 0.0.0-8ab7d2e

Hi! What operating system are you using?

MacOS Monterey

Successfully reproduced this. Not quite sure what's going on, but upgrading to node 16.7.0+ and installing the latest wrangler@beta (0.0.7) seemed to fix things, so give that a go and let me know if you're still having issues. Thanks!

@GregBrimble My understanding was that the Pages functionality was in the pages tag and not yet merged into beta

The pages tag is just an experimental playground for us testing things out. The beta tag does have the wrangler pages dev command 😊

authors: GregBrimble kyeotic


text:
Micro deploy  error

My micro_deploy config is:
name: firstbosh
logging:
level: DEBUG
network:
type: dynamic
vip: 10.255.254.4
cloud_properties:
network_name: vx_siz
resources:
persistent_disk: 40960
cloud_properties:
instance_type: Small Instance
cloud:
plugin: cloudstack
properties:
cloudstack:
endpoint: http://10.255.254.233:8080/client/api
api_key: **************************************
secret_access_key: ***********************************
default_key_name: bosh_test
private_key: ~/.ssh/vkey.pem
state_timeout: 600
state_timeout_volume: 1200
stemcell_public_visibility: true
default_zone: s_cloud
registry:
  endpoint: http://admin:admin@10.255.254.20:25889
  user: admin
  password: admin

My Error is:
Connect to agent timeout
I can see create vm and bind float ip to the vm, but inception server always connect the agent timeout
I can see the log is:
https://vcap:b00tstaroop:10.255.254.4 :6868
user: vcap
password: b00tstraoop
and also I try use this account and password but can't to ssh successfully!
I try to use root to ssh it by a method successfully and 6868 port is listen, but every micro bosh is stoped in waiting for the agent

update & use the latest stemcell please

authors: hanxy resouer


text:
Add version numbers to blob names

Because blobs can be named anything which makes it hard to track it's origins (src and version), most folks have adopted a pattern that would suggest naming the two blobs something more like:

golang/go1.9.2-linux-amd64.tar.gz
runc/runc-1.0.0-rc4-linux-amd64

Sounds like a good idea but we'll need to work out how to make this work with our auto-updating dependencies.

authors: kdykeman xoebus

repo: cloudfoundry-incubator/bpm-release


text:
build loops with node 7

Abacus build goes into endless loop with:
OS Darwin ... 15.6.0 x64
Node v7.5.0
Npm 4.1.2

Closing in favor of #534

repo: cloudfoundry-incubator/cf-abacus


text:
updated get-events plugin

Updated to 0.5.4

Thanks!

authors: akoranne dkoper

repo: cloudfoundry-incubator/cli-plugin-repo


text:
receptor domain and callback issues

hi guys, I've uploaded a the diego release .789 and .817 to my microbosh and have deployed both successfully.  I've noticed that there are numerous references to the services.dc1.consul domain in various spec files, likely for dev purposes but not sure.  in my manifest, I've had to change the diego_api_url to reference the actual IP of the receptor server (cell_z1) in order for my cf push's to get partially completed.  They get through the retrieval of the buildpacks but fail at the callback to the stager.  I see this reference in the stager logs.
"callback_url":"http://stager.service.dc1.consul:8888",
Should this domain be an attribute in the manifest so that I can easily use the domain of my cf releases haproxy?  Also, I've tried adding the domain of the haproxy as the diego_api_url but have run into issues where the haproxy doesn't know where to even send it.  Maybe I'm just doing it wrong. Thoughts?

You have to be current on both cf-release and diego-release to make things work.
Our latest green build for diego-release was 0.843 which was paired with cf-release@a43654bfa526c9bf9162932c1c1364c7f43cdb18
That callback_url is correct. We are using consul as a means for service discovery which is internal only.
Everything should just work if you are following the README in diego-release.
You will need to provide more details as to what is failing. But first I would upgrade to the latest code on both sides.

@davebotelho - let us know if you still have issues after upgrading.

authors: davebotelho fraenkel onsi

repo: cloudfoundry-incubator/diego-release


text:
feat: chart: add labels to QuarksStatefulSets

Description
Add the standard labels to the generated QuarksStatefulSets, so that we can see the version when examining a live deployment easier.  The selector are unaffected, as we want to be able to use the previous version for a bit during an upgrade.
Motivation and Context
When examining an upgrade, it is difficult to figure out what version of KubeCF corresponds to each pod.
How Has This Been Tested?
Deployed during an upgrade (HA). I have confirmed that:

The StatefulSets are updated, not recreated (their creation timestamp is from before the upgrade took place).
The existing pods are rolling as expected — api-1 is upgraded and ready before api-0 is upgraded.

(Actually, the upgrade never completes because api-1 is not counted for bootstrap, so DB migration never takes place, and therefore api-1 can never get ready.  But that's an existing issue outside this PR.)
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code has security implications.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

@mook-as Can this be an annotation rather than a label?

@f0rmiga Sure, but the actual labels are all pretty standard.  It's not really a problem to move them, but it seems odd to put them under annotations unlike every other resource.

@f0rmiga Sure, but the actual labels are all pretty standard. It's not really a problem to move them, but it seems odd to put them under annotations unlike every other resource.

I see. Indeed we have the rest as labels.

repo: cloudfoundry-incubator/kubecf


text:
fix: CI: Add owner name to cluster name

Description
This attaches the (sanitized) owner name to the cluster name; this does not remove the existing owner label on the cluster.
Motivation and Context
This is necessary because we don't get any information other than the cluster name with looking through DNS record sets; so we need something there to be able to identify entries that are safe to remove.
How Has This Been Tested?
Deployed locally a few times (via GitHub Actions, of course).
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code has security implications.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

I would also prefer not relying on the cluster name for DNS; however, as far as I can tell we don't have any other way to tie a DNS entry to an already-deleted cluster.  It should (but doesn't) have any way to attach tags to the record.


text:
Bug/dashboard

Bug description:

Dashboard rendering fails when service plan is updated as the corresponding dashboard URL is not updated in cloud controller.
In case of migration from one bosh to other, dashboard rendering code might query to older bosh to get tasks hence the dashboard rendering would fail.

To resolve the part 1 of the bug, a call to cloud controller to get the current plan of the instance was added in both DockerInstance and DirectorInstance.

To resolve part 2 of the bug, a new function getTasksForDashboard was added in BoshDirectorClient which queries only correct director instead of looping through all the primaryConfigs as original getTasks does. The 'correct' director is fetched from the cache using deployment name.

Minor modification in docker dashboard acceptance test to accommodate extra call to CC.

Added one unit test for getTasksForDashboard.

Pull Request Test Coverage Report for Build 1030

10 of 13 (76.92%) changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.006%) to 88.295%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

broker/lib/fabrik/DirectorInstance.js
1
4
25.0%

Totals

Change from base Build 1016:
-0.006%

Covered Lines:
6382

Relevant Lines:
6996

💛  - Coveralls

@abh1kg and @sauravmndl : please review this PR.

@sauravmndl has requested for changes. Further, there are some JSHint issues with this pull.

Yes, I will look into why the build is failing, I think it's the trufflehog issue. Will finalise it ASAP.

authors: abh1kg coveralls jayeshjk kamath-prasad


text:
create route - owned domains not proposed

stratos 2.4.0
Frontend Deployment type

[ X] Cloud Foundry Application (cf push)
[ ] Kubernetes, using a helm chart
[ ] Docker, single container deploying all components
[ ] npm run start
[ ] Other (please specify below)

Backend (Jet Stream) Deployment type

[ X] Cloud Foundry Application (cf push)
[ ] Kubernetes, using a helm chart
[ ] Docker, single container deploying all components
[ ] Other (please specify below)

Expected behaviour
I expect all the possible domains to be proposed when creating/mapping a route.
Actual behaviour
The http owned domains of the org are not proposed in the dropbox
Steps to reproduce the behavior
Log output covering before error and any error statements
Insert log hereCopy

Detailed Description

Context

Possible Implementation

It looks like we use the shared_domains endpoint instead of domains to populate the drop down, I don't think this includes those owned by an organisation. Not sure why historically this is the case, needs some investigating.

authors: poblin-orange richard-cox

repo: cloudfoundry-incubator/stratos


text:
LinuxOptions.BindMountPersistentDisk used for tmpfs mounts

The agent settings for the linux platform includes the following:
	// When set to true persistent disk will be mounted as a bind-mount
	BindMountPersistentDisk bool

When that option is enabled, it uses the linuxBindMounter for more than persistent disks. In my case, it's attempting to create and mount a tmpfs at /var/vcap/data/sys/run with the --bind option; this doesn't work:
2016-11-17_19:56:25.34094 [main] 2016/11/17 19:56:25 ERROR - App setup Running bootstrap: Setting up data dir: Mounting tmpfs to /var/vcap/data/sys/run: Shelling out to mount: Running command: 'mount tmpfs /var/vcap/data/sys/run -t tmpfs -o size=1m --bind', stdout: '', stderr: 'mount: special device tmpfs does not exist
2016-11-17_19:56:25.34095 ': exit status 32
2016-11-17_19:56:25.34098 [main] 2016/11/17 19:56:25 ERROR - Agent exited with error: Running bootstrap: Setting up data dir: Mounting tmpfs to /var/vcap/data/sys/run: Shelling out to mount: Running command: 'mount tmpfs /var/vcap/data/sys/run -t tmpfs -o size=1m --bind', stdout: '', stderr: 'mount: special device tmpfs does not exist
2016-11-17_19:56:25.34099 ': exit status 32

Mounting without the bind option works:
/:/var/vcap/bosh# mount tmpfs /var/vcap/data/sys/run -t tmpfs -o size=1m
/:/var/vcap/bosh# ls -l /var/vcap/data/sys/
total 4
drwxr-x--- 2 root vcap 4096 Nov 17 19:53 log
drwxrwxrwt 2 root root   40 Nov 17 21:52 run
/:/var/vcap/bosh#

i think this was fixed some time ago in 3363.x stemcells: https://github.com/cloudfoundry/bosh-agent/blob/master/platform/disk/linux_bind_mounter.go#L13

authors: cppforlife sykesm

repo: cloudfoundry/bosh-agent


text:
remove xenial, bionic, jammy references from noble stemcell branch

as we are preparing for the new stemcell line 24.04
it would make sense to finally cleanup references and switches to xenial/bionic.
there was a idea where we had one master branch to support multiple builds.
but it has never been implemented. (up for discusion)

this has been done in the noble branch


text:
Deployment fails with stemcell ubuntu-trusty version 3363.9

Our latest deployment in Softlayer tried using the newest ubuntu-trusty stemcell version 3363.9 and failed with the error
CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '5285bda5-41d6-44d6-bb5c-db06ae7aff4d': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method

Do we have to change something in the Cloud Config with this new stemcell version?
Help is appreciated. Thanks,
Peter
Full deployment log here:
Deploying
---------

Director task 6860
  Started preparing deployment > Preparing deployment. Done (00:00:01)

  Started preparing package compilation > Finding packages to compile. Done (00:00:00)

  Started compiling packages
  Started compiling packages > nginx/1c8867c98ccd77c9f8d5509ec8e6993681125bf3
  Started compiling packages > bits-common/31323f35fea0d06665c3ffdd9019605655cdcb99
  Started compiling packages > ruby-2.3/af291eea8a7bf463720143128a1f25a7b6e9f56c
  Started compiling packages > yajl/0508cba03499f6efc467759285a1ef8b34838450
  Started compiling packages > python/484075d81d41ce3985fa299004a82d96c9a24aa7
   Failed compiling packages > ruby-2.3/af291eea8a7bf463720143128a1f25a7b6e9f56c: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '5285bda5-41d6-44d6-bb5c-db06ae7aff4d': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method (00:11:36)
   Failed compiling packages > nginx/1c8867c98ccd77c9f8d5509ec8e6993681125bf3: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '1cdc9ebb-a866-448d-bde6-d45b035d3296': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method (00:11:43)
   Failed compiling packages > yajl/0508cba03499f6efc467759285a1ef8b34838450: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '041d1de8-87fb-48b4-8a3e-7e15eec40c2f': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method (00:11:47)
   Failed compiling packages > python/484075d81d41ce3985fa299004a82d96c9a24aa7: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '71e9a0a5-4e7a-4608-b980-cea1f005a8ca': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method (00:11:48)
   Failed compiling packages > bits-common/31323f35fea0d06665c3ffdd9019605655cdcb99: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '1d6be408-c678-48f4-b480-1193073d1b25': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method (00:13:37)

Error 100: CPI error 'Bosh::Clouds::CloudError' with message 'Creating Virtual_Guest with agent ID '5285bda5-41d6-44d6-bb5c-db06ae7aff4d': Updating VM's agent env: Updating Agent Env timeout. : Upload to "/var/vcap/bosh/user_data.json" failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain' in 'create_vm' CPI method

Task 6860 error

For a more detailed error report, run: bosh task 6860 --debug
command 'bosh -n --color -t https://10.155.171.25 -d /tmp/bosh_manifest20170315-6-oswicm deploy --no-redact' failed!

/cc @suhlig @smoser-ibm

Is #131 related to this issue?

@gu-bin have we tested stemcell version 3363.9 with our pipeline? Did not see this.
/cc @mattcui @zhanggbj

Yes, It's a known problem with the stemcell 3363.9, but since the sha1 can't be overridden on bosh.io once it's already uploaded, we can't upload the good stemcell there. In addition, we are still working on the new pipeline for building the stemcell for catching up the community. In the meantime, you could try with the stemcell below, please let us know if you meet any problem. Thanks.
https://s3.amazonaws.com/bosh-softlayer-stemcells-candidate-container/light-bosh-stemcell-3363.12-softlayer-xen-ubuntu-trusty-go_agent.tgz

In the meantime, you could try with the stemcell below, please let us know if you meet any problem. Thanks.
https://s3.amazonaws.com/bosh-softlayer-stemcells-candidate-container/light-bosh-stemcell-3363.12-softlayer-xen-ubuntu-trusty-go_agent.tgz

@mattcui That's not really a viable option, because we're using concourse's stemcell resource. For the time being we're using the old stemcell version.
Can you add information to the broken stemcell version on bosh.io to make it obvious that there is an issue? It took me several hours to find out that it's the stemcell and not something else.

@petergtz  I totally agree, and sorry for wasting your time. @jianqiu tomorrow it's your last day working in Pivotal, possible to talk to the pair chair (or some senior guy there) to see if it's possible to fix this issue, or if it's possible to add some warning messages there at least? Thanks.
/cc @maximilien

@petergtz We have a new stemcell 3363.12.1 published on bosh.io. Please note that there requires to to add keep_root_password property under resouce_pool due to a change in bosh-agent, you could reference the sample docs/sl-bosh.yml

@mattcui How do I specify keep_root_password: true in v2 manifests? Is the property under instance_groups? Thanks.

@valeriap Yes, I think so.

@valeriap Maybe I'm missing something, but aren't you confusing the deployment manifest with a bosh director manifest? docs/sl-bosh.yml is a sample manifest to deploy a bosh director. Hence, there's no Cloud Config to update.
@mattcui Thanks for the update. We'll this one as soon as possible.

@petergtz Since the property is used by the bosh agent I supposed the change to be needed on each deployment, not specifically on the bosh director deployment. Am I wrong?

@valeriap No idea. @mattcui?

@mattcui Would it make sense to update the cloud_config.yml template to make it clear then?
Also, you wrote you "think" it has to be defined there. Does that mean it is unclear at this point?

@petergtz I am working on this these days, just submitted PR 55, you or @valeriap could reference cpi.yml and cloud-config.yml in  softlayer. The property keep_root_password has to be defined under instance_groups, reference -> concourse_sample_v2_schema.yml

authors: mattcui maximilien petergtz valeriap

repo: cloudfoundry/bosh-softlayer-cpi-release