Determine what ambient telemetry will look like

In sidecars, we have reporter=source|destination. In ambient, things are a bit less clear.
We could have up to 4 proxies along the path, and 2 (ztunnel) may not be doing L4 processing at all.
However, the ztunnels can provide L4 telemetry and could even provide L4 traces to some extent (since we can propogate tracing headers via HBONE).
This issue tracks designing what telemetry should be emitted in ambient
size: L, type: design
related WI: https://github.com/istio/istio/issues/45676

For ztunnel, there's a gap with Telemetry API because there's no CEL in Rust so customizations are not available (cc @zirain ).

I think the limitations may be beyond Rust vs Envoy if we include the full scope of Telemetry customization. We probably don't want per-workload overrides on node proxy

Yes, I'm not suggesting that, but I think it's fairly straightforward to maintain Waypoint full support for telemetry API as server-side for the producer and client-side for the consumer.
For node proxies, I am not convinced we need to present L4 Istio metrics. The main audience would be the node operators since they are multi-tenant and perhaps not even visible to the application developers. The focus there should be on the infrastructure metrics, like the Envoy default metric set.

Lin and Ethan will find the right person to tackle this workitem.

ambient should take this opportunity to change the bootstrap histogram bucketing.
Best would be to not use Envoy defaults (Prom defaults would likely be better) and allow custom bucketing, if possible.

Custom bucketing is not (yet) possible, but will be available with the new native histogram metric type. This is available since Prometheus v2.40 as an experimental feature. I will check the design docs regarding compatibility questions.
Until that, fixed buckets is fine, with reasonable defaults (based on extensive testing).

Perhaps the L4 telemetry could add a label indicating whether it is strictly L4 or carries L7 info. That would make it easy to query for a complete L4 view, while also making it easy eliminate L4 metrics that would presumably be reported as L7 requests as well.

There's already a request_protocol label, but a new one dedicated to distinguish between L4 and L7 can make sense, and would not be an issue of cardinality. This way, users would be able to run the same queries regardless of the layer  and would be switch between the two "modes".

I think source and/or destination reporting should be the goal, no more than two reporters reflecting the source and destination "view" of a request.
Is this something that becomes less important with correlation IDs and baggage? That's sort of hard to
enforce/track/make assumptions about on the Istio data plane side, globally.

Here we are just talking about metrics, and that should be handled separately as that's one of the easiest, cheapest observability signal to get, and most users stop at this point (even if it's only temporarily), so they should be useful by themselves too.

collection and storage does impact users and many end up dropping metrics or turning off collection entirely

Only a reasonable set of metrics should be enabled by default. Regular Istio did not get this totally right, as these can scare people off (or they can ignore these and suffer the consequences).
This is another example that I feel like should be a default as only a very small subset of users would like to have this: https://docs.solo.io/gloo-mesh-enterprise/latest/observability/tools/prometheus/production-setup/#remove-cardinality-labels

this is where I think having a configurable collector that is separate from Istio makes a lot of sense. Istio emits what it knows, there's a collector that ingests the emitted metrics, and you can drop or exclude what you like there before the metrics are forwarded to your store, based on your needs.

OTel is just an implementation detail, and while it's getting more and more popular, most users are not using it yet but relying on Prometheus as that's still the de-facto standard. I think in terms of UX, we should focus on getting this right with Prometheus first, then OTel. It's quite easy as Prometheus Receiver is quite close to Prometheus.

@howardjohn, As a follow-up to the working group meeting, if you and Louis have information to share please add it here in some way, thanks!

Not stale

/no stale

@justinpettit can you identify some resource for this?  Would love to have a high level design for telemetry before ambient announces some sort of beta.

Thinking more on Ambient metrics I want to follow up on my initial comments.   I do think the existing, core Istio metrics should be maintained for the foreseeable future.  Doing this should be more seamless as people migrate to ambient, and also let OTel work evolve.  At the same time, for ambient namespaces maybe we can treat telemetry a little differently, and mostly leave sidecar proxy telemetry alone.  It seems to me that ambient users will move quickly to ambient, and mainly leave sidecars behind.  And from a telemetry perspective I think we can probably ignore telemetry from sidecars within an ambient namespace (will there even be sidecars in an ambient namespace?).
Eliminate Source/Dest Reporters
The source and destination reporting of sidecar proxies is rich, but wasteful.  For successful requests the source and dest reporting is mostly duplicated.  That results in double the processing, double the scraping, double the storage, and sometimes the need to de-dupe after querying.  The Ambient arch is different, there are no source and dest proxies and reporting should not try and emulate it.  A new "reporter" has been suggested in the past, and I now think that reporter = "ambient"makes sense, because it's accurate.  It also makes it easy to query ambient telemetry via a single label-value pair.  The reporter could also be set to "ztunnel" or "waypoint", but that may be better as something like reporter_app (Note, I think currently tcp metrics have app="ztunnel", I'd recommend that change to what's proposed above).
I believe today ambient is always using reporter="destination".  This may seem like a good idea for some amount of back-compat, but I think it's misleading.  For example, it's quite possible to have reporter="destination" yet no destination_workload, because in reality the request never made it to a dest workload.
If there is a sidecar proxy in an ambient namespace the telemetry could continue to report as it does today, independently of the ambient telemetry. Or, maybe it could be disabled completely, as some telem consumers, like Kiali, may elect to ignore it.
Removal of source and dest reporting will result in significant savings in telemetry capture, storage and processing.  The main concern is whether Ambient telem is able to capture the union of what the source and dest reporting did with sidecar proxies.   For example, sidecar client reporting captured requests that never made it to a destination proxy, and destination reporting provided security policy.
New bucketing for Histograms
A significant number of users disable Istio's histograms because they are too expensive.  Currently, Istio bootstraps using Envoy's default histogram bucketing, with 19 buckets:
[ 0.5, 1, 5, 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000, 60000, 300000, 600000, 1800000, 3600000 ]

Prometheus defaults cut the number almost in half:
[ .005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10 ]

OTel HTTP defaults are similar to Prom, but with 14 buckets:
[ 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ].

Each unique time-series gets one more dimension for each bucket (+ 1 more for "inf"), so in a simple case, say requests A->B, there are currently 20 bucket time-series generated, with each updated for a value <= the bucket value.  For example, using request_duration_milliseconds, for an 1100ms entry, the first 10 buckets are updated (+ 1 more).  And note, that is for each unique set of attributes.
In my opinion Envoy has too many buckets, bloating the storage and slowing down updates, queries and calculations. Prom and OTel are better but currently set for seconds, whereas  Istio is currently reporting in milliseconds.
It's not totally clear what to do here. Also, Prometheus has just introduced experimental support for "Native Histograms", which is different from what I described above, and may help out substantially.  It is something that should be tracked for possible use with ambient GA.  But for now, I'd suggest that when installing Istio with the ambient profile, we adhere to the OTel bucketing, adjusted for milliseconds.  This will still reduce the overall number of time-series while adding some standardization.  Id ignore support for custom bucketing and hope that native histogram support eventually solves the histogram problem.
Removals
This is biased towards what we currently need in Kiali, but I think some attributes could be removed from the standard metrics.  This may not help much with cardinality, but it would help with storage, and would simplify the metrics.  For Kiali users looking to save metric storage space, we recommend the following labeldrops:
chart|destination_app|destination_version|heritage|.operator.|istio.|release|security_istio_io_.|service_istio_io_.*|sidecar_istio_io_inject|source_app|source_version
Minimally, I think the "canonical" attributes remove the need for *_app and *_version.
Note that the nature of waypoints should already reduce cardinality significantly, as the podattribute should have far fewer values, especially for instances where app pods saw a lot of churn.
There are also a lot of metrics that could likely be turned off by default.  In Kiali the following metrics that are currently unused:
istio_agent_.|istiod_.|istio_build|citadel_.|galley_.|pilot_[^p].|envoy_cluster_[^u].|envoy_cluster_update.|envoy_listener_[^dh].|envoy_server_[^mu].|envoy_wasm_.
To summarize, the above doesn't recommend any sort of fundamental shift in telemetry for Ambient, but I think would let Ambient report in a more native way, address a legacy issue in histogram reporting, reduce the telemetry footprint, and require only modest changes for consumers.

Hi @jshaughn thank you so much for your analysis! Would it be possible for you to discuss your recommendation in an upstream ambient meeting?  I'm interested in reaching some consensus for beta for L4 and then L7 later. Wasn't clear to me which of your 3 major bullets apply to L4 also? Maybe only "Eliminate Source/Dest Reporters"?
@srampal  or @justinpettit do you have any update on this issue?

Overwriting the buckets is possible in multiple ways already, so I am not sure if it worth changing them this way. It's also a bit unrelated to Ambient itself.

Can I ask how this is done?  In my experience Istio always bootstraps back to the Envoy defaults.  If there is an easy way to customize the bucketing for istio_request_duration_milliseconds (and other histograms), then problem solved.
As for dropping metrics, I understand that there are lots of compat issues and in general this should just be made easily configurable.  My main theme is that many users experience overwhelming amounts of telem, and as such it becomes unusable.  As Istio pivots towards Ambient, it will be good to acknowledge this fact and work on trimming, as is possible.
In what I wrote above, with respect to what can be applied strictly to Ambient, the focus would be on maintaining existing metrics and the reporter attribute.

@jshaughn, I've had luck with reconfiguring it via the sidecar.istio.io/statsHistogramBuckets annotation previously.

Pinged @lei-tang @jshaughn on slack - can you give some update on ambient telemetry for beta in this week or an upcoming ambient meeting?

As (source, destination) pairs can have large cadinality, from the memory consumption and transmission costs perspective, it makes sense to remove them from metric labels. For example, if source and destination each has a cadinality of 20, having source and destination labels will lead to 20x20=400 times more memory consumption and transmission costs.
A major advantage of Ambient is its efficiency. Removing some high cardinality labels and some non-essential metrics will greatly improve the efficiency - less memory consumption, less metric transmission costs, and less memory-related crashes.

It seems that @lei-tang and I agree that in Ambient it doesn’t make sense to try and emulate source and destination reporting.  The idea of reporter=”source” and reporter=”destination” is tied to having source and destination proxies, each processing a request.  Although, I’m not sure the issue is as much the source X dest cardinality, we still need to know the source and destination information for the requests, but rather that with two reporters for the same request, the cardinality doubles (source X dest X 2).
Let me take a shot at a succinct set of metric telemetry suggestions for Ambient beta.

Istio implementations of ztunnel and waypoints should maintain the current Istio metrics, with minor modifications, as described in following points.

This ignores my suggestions above, for slimming existing metrics by dropping fields and/or changing the bucketing for histograms.  While useful, that’s actually outside of Ambient proper.
This does not prevent additional, next-gen metrics being introduced as a result of other work, most likely based on emerging OTel standards for HTTP request reporting.  When ready, a crossover period could emerge where old and new metrics could both be generated (or easily disabled).  Non-Istio implementations may want to offer their own metrics, or focus solely on OTel, etc, but for continuity Istio impls should continue to be generated for traffic handled by Ambient telemetry.

Ztunnel and Waypoints should not use reporter=”source” or reporter=”destination”, as the Ambient components are neither a source or destination sidecar proxy (although, to some degree I guess it could be thought of that way if a request originates or terminates in a proxy, outside of the Ambient namespace). There are a couple of options but I think this one is probably sufficient:

Have ztunnel use reporter=”ztunnel” and waypoints use reporter=”waypoint”.

This should be sufficient if the different components report to distinct metrics.  For example, ztunnel writes just to TCP metrics and waypoints write only to request metrics.  Otherwise it may be best to have both use reporter=”ambient” and add a new label like reporter_component=”ztunnel | waypoint”.
This allows consumers to easily identify ambient telem in a query using a single label-value pair, and distinguish it from sidecar-proxy telem.

This idea is predicated on the idea that telemetry can be reliably generated one time for one request.  This already seems to be working for the L4 level.  The real question is whether it can be done by the waypoint?  I think it would mean that for a single request the waypoint would write telemetry only once, at one of these times:

Immediately for requests that failed to establish a destination workload
When an upstream connection is lost
After a request is received and all information is collected

Currently, I think all ambient telemetry is setting reporter=”destination”.  I think this is misleading and may cause confusion for legacy consumers.  But, if desired it could remain as long as there were another label identifying that ztunnel or waypoint were doing the reporting.

That's it, given the technical feasibility, especially for waypoints, I think for Ambient beta we could just be talking about existing telem with a little bit of label shuffling.  The nature of Ambient architecture would already cut telem reporting in 1/2.  The main thing to remember is that users need the telemetry to be as robust as possible, especially in failure scenarios and latency reporting.
@linsun It would be great if you could get some of the ztunnel and/or waypoint contributors to comment...

Adding a new label "reporter_component" to OSS ambient adds to its complexity and is not consistent with OSS Istio, which does not have this new label.
I prefer for ztunnel, reporter=”ztunnel”; for waypoint proxy, reporter=”waypoint”, because it is simple and clear.

Adding a new label "reporter_component" to OSS ambient adds to its complexity and is not consistent with OSS Istio, which does not have this new label.

That's not necessarily a problem, OSS ambient looks nothing like OSS sidecar in practical terms anyway.
My concern is if we (eventually) end up with something like

1 ztunnel (ztunnel A) per node
N waypoints per node

and ztunnel A is proxying L4 traffic to all ambient pods on the node as well as terminating HBONE traffic bound to those N waypoints - it gets potentially a bit trickier to collate the info.
Thinking about it, it's probably it's moot either way tho, as we will eventually have to append more specific context than reporter=waypoint|ztunnel for ambient.
My only concern is that when we are forced to do that, we will make it hard for ourselves to support parallel telemetry views for sidecar and ambient traffic in the same cluster.

I prefer for ztunnel, reporter=”ztunnel”; for waypoint proxy, reporter=”waypoint”, because it is simple and clear.
+1

Today, with sidecar injection, for a single request from A to B there are 2 time-series generated for each relevant metric (requests_total, tcp_sent_bytes, tcp_received bytes, etc), sidecar-A with reporter="source" and sidecar-B with reporter="destination.  Is there consensus that with Ambient, for a single request from A to B, that we would expect 1 time-series generated for each relevant metric?  Potentially with reporter="ztunnel" (for L4 metrics, like tcp_sent_bytes) or reporter="waypoint" (for L7 metrics, like request_total).

From a cursory glance (caveat that I haven't fully read all the comments) I'd expect that reporter="source" and reporter="destination" should generally retain similar usage and not be overloaded with a less descriptive new term for Ambient - reporter="ztunnel" fails to describe whether the ztunnel is reporting from the source or destination, and the actually becomes more important for ambient data flows due to the possibility of waypoint hops.
I'd be supportive of adding something like a reporter_component label and using reporter_component="sidecar" for consistency with the traditional model to address @lei-tang's concern. With this, a typical flow (using a "sandwich" deployment) may look like:

client zt
waypoint zt -> waypoint
waypoint -> waypoint zt
destination zt

reporter="source"
reporter="destination"
reporter="source"
reporter="destination"

reporter_component="ztunnel"
reporter_component="ztunnel"
reporter_component="ztunnel"
reporter_component="ztunnel"

I'd expect the same-node waypoint <-> ztunnel hops to be negligible, but the biggest gap here is the processing time within the waypoint itself. For this reason, I think there should ideally be a "parent" tracing span capturing the entire client zt -> destination zt timing, although that's likely only possible to emit from the destination zt, and only if the waypoint forwards timing information from the first leg.

client sidecar
destination sidecar

reporter="source"
reporter="destination"

reporter_component="sidecar"
reporter_component="sidecar"

I don't think we need reporter_component - all monitoring systems allow tagging metrics with the component the metrics  come from. This is usually referred to as a "monitored resource".
The main value of the two reporters is that it provides an easy way to compare and the difference is meaningful since it reflects the network impact. There's not much value in comparing ambient telemetry to sidecar telemetry, so I think you can pick a completely different set of labels.

From a cursory glance (caveat that I haven't fully read all the comments) I'd expect that reporter="source" and reporter="destination" should generally retain similar usage and not be overloaded with a less descriptive new term for Ambient - reporter="ztunnel" fails to describe whether the ztunnel is reporting from the source or destination, and this actually becomes more important for ambient data flows due to the possibility of waypoint hops and therefore multiple source and destination points within a single flow.

Yes +1 on this, this is my main concern. Component != direction or origin, as long as we aren't conflating those things, we should be good.

Chatted with @louiscryan a bit, here is where we arrived. Primary focus is retaining metrics value while keeping cost reasonable.
I setup a small spreadsheet to put in theoretical numbers and analyze different approaches. Here are the primary approaches I considered:

Here the boxes are the actual proxy reporting the metric, and the source.
Note: the ones with empty spot are derived from others.
For some reason I cannot upload to the team drive with some permission issue, so attached here
Ambient telemetry analysis.xlsx
Summarized (waypoint double == top option, waypoint single == bottom in the picture)

Metric types
Reporting Pods
Reporters
Metric count
Destinations
Sources
Series
Cost

Sidecar HTTP
1000
2
64
7
1
896,000
$7,168

Sidecar TCP
1000
2
4
7
1
56,000
$448

Ztunnel
25
2
4
100
25
500,000
$4,000

Waypoint double (client part)
30
1
64
1
70
134,400
$1,075

Waypoint double (server part)
30
1
64
10
1
19,200
$154

Waypoint double

153,600
$1,229

Waypoint single
30
1
64
10
70
1,344,000
$10,752

Waypoint single + ztunnel

1,844,000
$14,752

Waypoint double + ztunnel

653,600
$5,229

Broad notes:

Histograms are killer. Native histogram support, or even dropping buckets, may yield huge wins -- but they scale linearly so its not foundational
Ztunnel cost is pretty small relative to waypoints
An 'off the shelf' waypoint implementation outside of Istio would likely report only the right side of the 'waypoint double'
Much of the cost comes from reporting pod_name in the label. This cannot be dropped out of the box in simple prometheus setup, but it is possible with prometheus https://karlstoney.com/federated-prometheus-to-reduce-metric-cardinality/ and generally any metric backend.

There is discussion about consolidating {workload, canonical service, app} and {version, canonical revision}; since these are generally the same values, these do not meaningfully impact cardinality which is the primary driver for costs in metrics. Given this, its probably best to keep all the labels for compatibility.

"Waypoint-double" reporting is qualitatively different since you cannot correlate the two metrics easily. Intuitively, for full fidelity with sidecars, you need a series per every network hop so it's always O(hops). You can sacrifice some fidelity via an intermediary LB service (so instead of M*N tuples you have M+N tuples), but it is not equivalent.

I prefer the "waypoint single" approach over the "waypoint double" approach because:

The "waypoint single" approach provides the source -> destination information. The "waypoint double" approach does not provide the source -> destination information.

Take the following data points in the "waypoint double" approach as an example: source 1 -> waypoint, waypoint -> destination 2, source 2 -> waypoint, waypoint -> destination 1. Such data points do not provide the source -> destination information: e.g., from these data points, a user can not tell the actual source and destination is source 1 -> destination 1 or source 1 -> destination 2.

The "waypoint single" approach is simpler than the "waypoint double" approach.

Would it be worthwhile to consider some labeling scheme and configuration such that it could be possible to enable "waypoint double" telemetry even if "waypoint single" is default and recommended for cost control in production?

@mikemorris is there a material difference between the "double" telemetry and a "single" telemetry with cardinality reduction techniques applied (e.g. erasing destination labels, grouping of response codes, etc)?

@mikemorris is there a material difference between the "double" telemetry and a "single" telemetry with cardinality reduction techniques applied (e.g. erasing destination labels, grouping of response codes, etc)?

I think I don't have a deep enough understanding to answer that well tbh.

if the waypoint is having issues we are likely to use a more operation metric (CPU, queue lengths, etc) to diagnose issues

My concern is mostly around whether ^ is sufficient (and an expected triage workflow) for Istio operators in this situation.

I prefer waypoint-single as I don't think that in general users want to see the infrastructure in the telemetry.  They want to see that traffic between service A and service B was successful, or not.  As @lei-tang notes, I'm not sure how we would correlate the two legs in waypoint-double to show the request and its response time etc.  I do see in both diagrams that src and dst workloads as noted as pods, is that correct?  I don't think we'd want pods.

src and dst workloads as noted as pods, is that correct? I don't think we'd want pods.

This was a bit of a misnomer, it would be the standard app/canonicalservice/workload labels ,not a new 'pod' one.

It seems like there is some consensus building around the "waypoint single" option, with the ztunnel metrics also shown there (which also happen to be what ztunnel implements today).

Is it correct to think waypoint double (top diagram) provides time spent in a given waypoint while waypoint single (botoom diagram) doesn't provide that info?
Personally i found this is very hard to compare with sidecars because waypoint single or double doesn't report time spent between source and destination.

Is it correct to think waypoint double (top diagram) provides time spent in a given waypoint while waypoint single (botoom diagram) doesn't provide that info?

I don't think it provides much meaningful information. The waypoint itself is reporting it during its processing; its hard to accurately observe your own latency.
For example, consider a request takes 10ms of processing

0ms: request packet hits waypoint
5ms: waypoint done processing it, reports it got it
6ms: waypoint about to send upstream request, reports its sending
10ms: request finally leaves the waypoint fully

In reality it was 10ms, but we observe 1ms

Thank you @howardjohn and @kyessenov - I agree waypoint double doesn't provide meaningful latency within waypoint itself.  And latency within waypoint is out of scope for this WI.

We drafted a "Plan for OSS ambient mesh beta - telemetry" (https://docs.google.com/document/d/15bW22HxuB9F-TIDy4h_YCBsUb8usbaurx8-DrXcL3_Q/edit). Please take a look.

I've temporarily lost write access to docs, so will comment here:

Ztunnel should write some logs, but not envoy logs format which were designed for HTTP. We can provide a far better log.
Waypoint should support tracing just like Istio Gateway does.
-1 to decision to not do Telemetry API. Its probably more work to not support it
Should remove "Additional stats for waypoint" or make it clear its just providing more context, not proposing we do that

Looks good though, thanks for pulling that together.

John, thank you for your comments! I agree with your points and have updated the doc accordingly. PTAL.

To recap what we discussed recently in ambient meeting, I think we have a plan for ambient beta, which is to go with waypoint single for reporting (bottom of this diagram and not support Telemetry API.  We need to identify an owner for #50225.


[BUG] Arithmetic_ops_test failure for Spark 3.4

Describe the bug
When running arithmetic_ops_test, there are 3 tests that are failing
FAILED ../../src/main/python/arithmetic_ops_test.py::test_cast_neg_to_decimal_err - pyspark.errors.exceptions.captured.ArithmeticExce...
FAILED ../../src/main/python/arithmetic_ops_test.py::test_div_by_zero_ansi[1/0] - pyspark.errors.exceptions.captured.ArithmeticExcept...
FAILED ../../src/main/python/arithmetic_ops_test.py::test_div_overflow_exception_when_ansi[true-CAST(-9223372036854775808L as LONG) DIV -1][INJECT_OOM]

Steps/Code to reproduce bug
Run integration tests for failing tests
cd $SPARK_RAPIDS_HOME/integration_tests/
./run_pyspark_from_build.sh -k test_cast_neg_to_decimal_err

-12 cannot be represented as decimal(7, 7), since that decimal can only represent values -1 < x < 1.  I get a similar exception on Spark 3.2.1 as well:
$ ~/src/spark321/bin/pyspark --conf spark.sql.ansi.enabled=true
Python 3.9.1 (default, Dec 11 2020, 14:32:07)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
23/04/26 10:31:32 WARN Utils: Your hostname, jlowe-ldt resolves to a loopback address: <IP_ADDRESS>; using <IP_ADDRESS> instead (on interface eno1)
23/04/26 10:31:32 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
Using Spark's default log4j profile: org/apache/spark/log4j-defaults.properties
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
23/04/26 10:31:34 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
23/04/26 10:31:36 WARN Utils: Service 'SparkUI' could not bind on port 4040. Attempting port 4041.
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /__ / .__/\_,_/_/ /_/\_\   version 3.2.1
      /_/

Using Python version 3.9.1 (default, Dec 11 2020 14:32:07)
Spark context Web UI available at http://<IP_ADDRESS>:4041
Spark context available as 'sc' (master = local[*], app id = local-1682523096560).
SparkSession available as 'spark'.
>>> spark.sql("select cast(-12 as decimal(7, 7))").collect()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jlowe/src/spark321/python/pyspark/sql/dataframe.py", line 693, in collect
    sock_info = self._jdf.collectToPython()
  File "/home/jlowe/src/spark321/python/lib/py4j-<IP_ADDRESS>-src.zip/py4j/java_gateway.py", line 1321, in __call__
  File "/home/jlowe/src/spark321/python/pyspark/sql/utils.py", line 111, in deco
    return f(*a, **kw)
  File "/home/jlowe/src/spark321/python/lib/py4j-<IP_ADDRESS>-src.zip/py4j/protocol.py", line 326, in get_return_value
py4j.protocol.Py4JJavaError: An error occurred while calling o33.collectToPython.
: java.lang.ArithmeticException: Decimal(compact,-120000000,20,0}) cannot be represented as Decimal(7, 7).
	at org.apache.spark.sql.errors.QueryExecutionErrors$.cannotChangeDecimalPrecisionError(QueryExecutionErrors.scala:97)
	at org.apache.spark.sql.catalyst.expressions.CastBase.changePrecision(Cast.scala:744)
	at org.apache.spark.sql.catalyst.expressions.CastBase.$anonfun$castToDecimal$12(Cast.scala:777)
	at org.apache.spark.sql.catalyst.expressions.CastBase.nullSafeEval(Cast.scala:923)
	at org.apache.spark.sql.catalyst.expressions.UnaryExpression.eval(Expression.scala:481)

You can see in Spark-3.2.1 as you have shown, you are getting a Py4JJavaError but if you do the same thing in Spark-3.4.0 you will not get the same exception.
$ bin/pyspark
Python 3.8.10 | packaged by conda-forge | (default, May 11 2021, 07:01:05)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
23/04/26 09:01:19 WARN Utils: Your hostname, raza-linux-2 resolves to a loopback address: <IP_ADDRESS>; using <IP_ADDRESS> instead (on interface enp13s0)
23/04/26 09:01:19 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
23/04/26 09:01:20 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /__ / .__/\_,_/_/ /_/\_\   version 3.4.0
      /_/

Using Python version 3.8.10 (default, May 11 2021 07:01:05)
Spark context Web UI available at http://<IP_ADDRESS>:4040
Spark context available as 'sc' (master = local[*], app id = local-1682524881638).
SparkSession available as 'spark'.
>>> spark.conf.set('spark.sql.ansi.enabled', 'true')
>>> spark.sql("select cast(-12 as decimal(7, 7))").collect()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rjafri/spark-3.4.0-bin-hadoop3/python/pyspark/sql/dataframe.py", line 1216, in collect
    sock_info = self._jdf.collectToPython()
  File "/home/rjafri/spark-3.4.0-bin-hadoop3/python/lib/py4j-<IP_ADDRESS>-src.zip/py4j/java_gateway.py", line 1322, in __call__
  File "/home/rjafri/spark-3.4.0-bin-hadoop3/python/pyspark/errors/exceptions/captured.py", line 175, in deco
    raise converted from None
pyspark.errors.exceptions.captured.ArithmeticException: [NUMERIC_VALUE_OUT_OF_RANGE] -12 cannot be represented as Decimal(7, 7). If necessary set "spark.sql.ansi.enabled" to "false" to bypass this error, and return NULL instead.
== SQL(line 1, position 8) ==
select cast(-12 as decimal(7, 7))
       ^^^^^^^^^^^^^^^^^^^^^^^^^^

OK, so this is a change in Spark that was introduced to avoid throwing Py4JJavaError as part of this.
This means that we will see more of these types of errors in the future as Spark is moving away from throwing a generic Py4JJavaError to a more Spark exception, similar to how they are moving away from throwing generic Java exceptions and wrapping them in their own versions

Yes, we should have the tests special-case for this new exception path/type.  Would be awesome if we could do this generically through the existing assert error methods so it "just works" regardless of how Spark wants to throw the exception.  If not, then we can add an assert utility for pyspark exceptions separate from the py4j error exception assert.


JWT issued-at (iat) and expiration (exp) claims should allow for clock skew

As per RFC 7519 and Google's own JWT docs, JWT's issued-at (iat) and expiration (exp) claims should allow for up to 30 seconds of clock skew:
https://cloud.google.com/iap/docs/signed-headers-howto#verifying_the_jwt_payload
https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4

JWT Payload Claims
exp Expiration time Must be in the future. The time is measured in seconds since the UNIX epoch. Allow 30 seconds for skew. The maximum lifetime of a token is 10 minutes + 2 * skew.
iat Issued-at time Must be in the past. The time is measured in seconds since the UNIX epoch. Allow 30 seconds for skew.

However, ServiceAccountCredentials currently assumes zero seconds of clock skew:

https://github.com/googleapis/google-auth-library-java/blob/95d70ae0f5f4c985455f913ddef14ebe75500656/oauth2_http/java/com/google/auth/oauth2/ServiceAccountCredentials.java#L576
https://github.com/googleapis/google-auth-library-java/blob/95d70ae0f5f4c985455f913ddef14ebe75500656/oauth2_http/java/com/google/auth/oauth2/ServiceAccountCredentials.java#L882
https://github.com/googleapis/google-auth-library-java/blob/95d70ae0f5f4c985455f913ddef14ebe75500656/oauth2_http/java/com/google/auth/oauth2/ServiceAccountCredentials.java#L883

This means if (for example) lifetime is the default (3600 seconds) and the two servers have just 1000 ms of clock skew between them, the server receiving the JWT will think the JWT expiration is 3601 seconds into the future, and reject it for having an expiration too far into the future.

Turns out this was actually a serious clock skew issue on the host issuing the JWT, and there's nothing to do here. Apologies for the noise.


CVE-2018-1000654 vulnerability with openjdk:alpine image

Hi
When we scan the docker images produced with openjdk8:alpine and openjdk:appine3.8 with microscanner there is one high vulnerablity CVE-2018-1000654. Apparently there is still no fix for that? Is there a way to avoid the problematic library libtasn1 while building the image ?

I can see that CVE alert from openjdk:8-jdk-alpine (sha256:2e9b153526a4f3c6991cd1f02326be8ee0c984d727c659ab8ab2dabd57582f8d). I don't really want to get into the nitty gritty of which base image to use in such a tiny "getting started" guide though. The best advice I could give would be not to use docker at all, and out source the base image decision to a build tool.


New UI Compatibility

I was testing the New UI beta and noticed that a lot of tool windows from this theme do not have the correct background. I haven't seen this issue with the other themes I've tested (including nightfall and One Dark) so I thought I'd flag it even though it's still in beta.
Actual: Affected tool windows (in WebStorm)

Project (modes: Project)
NPM
Structure
Bookmarks
Notifications
Services
TODOs
Problems
Search Everywhere Popup

All of them use the default background color #2D2A2E instead of the list background color #221F22 making the content a bit difficult to read. I've also notice this happening in some plugins like the TeamCity tool window, suggesting that there might be some global default to set all of them correctly.
Expected: Tool windows that appear to behave correctly (in WebStorm)

Project (modes: Project Files, Tests, Open Files, All Changed Files, Scratches and Consoles)[1]
Commit
Pull Request
Settings Window
Run/Debug Configurations Window

[1] Small note. After a restart, this stopped working for a reason. Now all modes behave the same (badly). Weird....

Another issue I have noticed is that heading texts are very dim which can be awkward when they are used for buttons like on the various tabs displayed in the IDE (see my previous screenshots) as they look like they are disabled buttons.

Late to respond, but thanks for putting this on my radar. I will look into this.

The same problem affects also the other variants like "Spectrum".
DataGrip has the same issue.
Thanks for this great theme!

If I remember correctly, I have put a fix for this in the existing pending PR.


Make TextFsmParse recognise URLs

hey @carlmontanari ,
something like this does the trick.

LGTM after making linters stfu :) (nolint is totally chill, esp for the gosec), and pending any follow up from the other thread!
Thanks a ton for this Michael -- I think this is a super smart/good addition. Also screw you because now I need to go put this into scrapli python 🤣 !

@networkop let me know if updates look chill and ill get this merged. think it should be just cosmetic stuff appeasing linters. thanks again, this is a cool addition -- so cool in fact, that somebody also added it to python scrapli already! 😁

yep, lgtm @carlmontanari


log writing failed. can't be called from trap context

I frequently see the message log writing failed. can't be called from trap context when invoking bosh-bootstrap. Typically I notice it when something fails but I have also seen the message when my command executes successfully.
One example:
      Started deploy micro bosh
      Started deploy micro bosh > Unpacking stemcell. Done (00:00:02)
      Started deploy micro bosh > Uploading stemcelllog writing failed. can't be called from trap context
    create stemcell failed: Timed out reading instance metadata, please make sure CPI is running on EC2 instance:
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/helpers.rb:14:in `cloud_error'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:65:in `rescue in current_vm_id'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:46:in `current_vm_id'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:422:in `block in create_stemcell'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_common-1.2798.0/lib/common/thread_formatter.rb:49:in `with_thread_name'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:410:in `create_stemcell'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:228:in `block (2 levels) in create_stemcell'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:85:in `step'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:227:in `block in create_stemcell'
    /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/tmpdir.rb:88:in `mktmpdir'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:213:in `create_stemcell'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:118:in `create'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:98:in `block in create_deployment'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:92:in `with_lifecycle'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:98:in `create_deployment'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/cli/commands/micro.rb:179:in `perform'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/lib/cli/command_handler.rb:57:in `run'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/lib/cli/runner.rb:56:in `run'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/lib/cli/runner.rb:16:in `run'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/bin/bosh:7:in `<top (required)>'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh:23:in `load'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh:23:in `<main>'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in `eval'
    /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in `<main>'
    /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:54:in `block in create_shell_runner': Command failed with status (1): [bosh -n micro deploy --update-if-exists /U...] (RuntimeError)
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:45:in `call'
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:45:in `sh'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/helpers/bundle.rb:18:in `block in run'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:236:in `block in with_clean_env'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:223:in `with_original_env'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:229:in `with_clean_env'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/helpers/bundle.rb:16:in `run'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:54:in `block in deploy_or_update'
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in `chdir'
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in `cd'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:52:in `deploy_or_update'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:42:in `block in deploy'
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in `chdir'
            from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in `cd'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:40:in `deploy'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/commands/deploy.rb:77:in `perform_microbosh_deploy'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/commands/deploy.rb:24:in `perform'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/thor_cli.rb:11:in `deploy'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/bin/bosh-bootstrap:13:in `<top (required)>'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh-bootstrap:23:in `load'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh-bootstrap:23:in `<main>'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in `eval'
            from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in `<main>'

    mkb@beemo

Would love a fix for this annoyance, yeah.
On Fri, Jan 9, 2015 at 3:11 PM, mkb<EMAIL_ADDRESS>wrote:

I frequently see the message log writing failed. can't be called from
trap context when invoking bosh-bootstrap. Typically I notice it when
something fails but I have also seen the message when my command executes
successfully.
One example:
Started deploy micro bosh
Started deploy micro bosh > Unpacking stemcell. Done (00:00:02)
Started deploy micro bosh > Uploading stemcelllog writing failed. can't be
called from trap context
create stemcell failed: Timed out reading instance metadata, please make
sure CPI is running on EC2 instance:
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/helpers.rb:14:in
cloud_error'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:65:inrescue in
current_vm_id'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:46:in
current_vm_id'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:422:inblock in
create_stemcell'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_common-1.2798.0/lib/common/thread_formatter.rb:49:in
with_thread_name'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_aws_cpi-1.2798.0/lib/cloud/aws/cloud.rb:410:increate_stemcell'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:228:in
block (2 levels) in create_stemcell'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:85:in
step'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:227:in
block in create_stemcell'
/Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/tmpdir.rb:88:inmktmpdir'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:213:in
create_stemcell'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:118:in
create'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:98:in
block in create_deployment'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:92:in
with_lifecycle'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/deployer/instance_manager.rb:98:in
create_deployment'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_cli_plugin_micro-1.2798.0/lib/bosh/cli/commands/micro.rb:179:in
perform'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/lib/cli/command_handler.rb:57:in
run'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh_cli-1.2798.0/lib/cli/runner.rb:56:inrun'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/lib/cli/runner.rb:16:in
run'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh_cli-1.2798.0/bin/bosh:7:in'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh:23:in load'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh:23:in'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in eval'
/Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in'
/Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:54:in block
in create_shell_runner': Command failed with status (1): [bosh -n micro
deploy --update-if-exists /U...] (RuntimeError)
from
/Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:45:in
call'
from
/Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/rake/file_utils.rb:45:in
sh'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/helpers/bundle.rb:18:inblock
in run'
from /Users/mkb/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:236:in
block in with_clean_env'
from /Users/mkb/.rvm/gems/ruby-2.1.5@global
/gems/bundler-1.7.6/lib/bundler.rb:223:inwith_original_env'
from /Users/mkb/.rvm/gems/ruby-2.1.5@global/gems/bundler-1.7.6/lib/bundler.rb:229:in
with_clean_env'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/helpers/bundle.rb:16:in
run'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:54:in
block in deploy_or_update'
from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in
chdir'
from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in
cd'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:52:in
deploy_or_update'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:42:in
block in deploy'
from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in
chdir'
from /Users/mkb/.rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/fileutils.rb:125:in
cd'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/microbosh.rb:40:indeploy'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/commands/deploy.rb:77:in
perform_microbosh_deploy'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/cli/commands/deploy.rb:24:in
perform'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/bosh-bootstrap-0.15.0/lib/bosh-bootstrap/thor_cli.rb:11:in
deploy'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/thor-0.19.1/lib/thor/command.rb:27:inrun'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor/invocation.rb:126:in
invoke_command'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/thor-0.19.1/lib/thor.rb:359:indispatch'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/gems/thor-0.19.1/lib/thor/base.rb:440:in
start'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh
/gems/bosh-bootstrap-0.15.0/bin/bosh-bootstrap:13:in'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh-bootstrap:23:in load'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/bosh-bootstrap:23:in'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in
eval'
from /Users/mkb/.rvm/gems/ruby-2.1.5@bosh/bin/ruby_executable_hooks:15:in'
—
Reply to this email directly or view it on GitHub
https://github.com/cloudfoundry-community/bosh-bootstrap/issues/298.

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1<PHONE_NUMBER>
twitter @drnic

+1 for a fix

I think this is a bug in"bosh micro deploy" upstream as I saw it the other day without bosh-bootstrap
On Wed, Apr 1, 2015 at 10:36 AM, Mark Carlson<EMAIL_ADDRESS>wrote:

+1 for a fix
Reply to this email directly or view it on GitHub:
https://github.com/cloudfoundry-community/bosh-bootstrap/issues/298#issuecomment-88568423

I'm hitting it during the terraform-was-cf-install template during the deploy micro bosh step.
aws_instance.bastion (remote-exec):   Started deploy micro bosh > Creating VM from ami-b88da7d0 light
aws_instance.bastion (remote-exec): log writing failed. can't be called from trap context

It is an ignorable warning/error and shouldn't stop anything from working subsequently.
But it's ugly.
On Wed, Apr 1, 2015 at 10:41 AM, Mark Carlson<EMAIL_ADDRESS>wrote:

I'm hitting it during the terraform-was-cf-install template during the deploy micro bosh step.
aws_instance.bastion (remote-exec):   Started deploy micro bosh > Creating VM from ami-b88da7d0 light
aws_instance.bastion (remote-exec): log writing failed. can't be called from trap context
Reply to this email directly or view it on GitHub:
https://github.com/cloudfoundry-community/bosh-bootstrap/issues/298#issuecomment-88570540

Ah, good to know.   I do see that the real error is an "Address in use" issue.  I'll chase that separately.

Created upstream ticket


[BEAM-10545] Added the inspector of PCollections and pipelines

Added the InteractiveInspector component and its sub components. The
hierarchy can be found in the code documentation.
The component allows listing all user defined pipelines and
PCollections in the kernel of the current notebook session,
displaying pipeline graphs, and visualizing PCollection data.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @prodonjs
PTAL!

R: @pabloem
PTAL, thx!
Do we have a way to re-trigger Python tests / Python Unit Tests (macos-latest, 3.6, py36) (pull_request)  and Python tests / Python Unit Tests (macos-latest, 3.7, py37) (pull_request) without having to close and re-open the pull request?

Run Python PreCommit

Run Python2_PVR_Flink PreCommit

Rebased to head to resolve failures in Python tests.

Run Typescript PreCommit

@KevinGG - so IIUC, all of these elements will eventually be used once the side panel is activated here: https://github.com/apache/beam/blob/dc3144d54c1f2adcc4f71520d5c1468a4a48e735/sdks/python/apache_beam/runners/interactive/extensions/apache-beam-jupyterlab-sidepanel/src/index.ts#L26 - is that correct?

@KevinGG - so IIUC, all of these elements will eventually be used once the side panel is activated here:
https://github.com/apache/beam/blob/dc3144d54c1f2adcc4f71520d5c1468a4a48e735/sdks/python/apache_beam/runners/interactive/extensions/apache-beam-jupyterlab-sidepanel/src/index.ts#L26

is that correct?

Yes. The next PR will bring in all the boilerplates to use all these components.


migrate to ssh2 0.5+

Yeah, this was fun. Fixes:
https://github.com/uProxy/uproxy/issues/2320
Summary:

no need for the ssh2-streams alias
implement randombytes' callback (forgot to do this first time around, I guess - ssh2 0.5+ uses it)
I had to monkey patch browserify's process shim (otherwise ssh2-streams won't load)

The monkey patching stuff isn't great. Rather than getting it perfect I'd like to start moving the ssh module into its own browserified file which could be included by whichever module wants it - this would also avoid duplicating the source (1MB+) between the digitalocean and cloudsocial modules.
Note that while this gets us closer to EC support, some quick hacking suggests there are still some missing pieces: namely, I think ssh2 wants Node.js 5+ but browserify currently gives us Node.js 4. Still, getting closer :-)

This change is

Comments added, some thoughts/TODOs but nothing blocking (monkey patching is always a bit ugly regardless as you said). Let me know if you'd like me to take a stab at using core.crypto for randombytes, since I've worked with it in a few other places.

Please take a look at using core.crypto, that would be great!
I'm investigating Travis failures...this all works fine for me locally, in any version node...then will submit. Thanks!


[TODO] Make ChainIndexers'  Add/Remove internal

https://app.clickup.com/t/1vqt5h1
Addresses the following TODO's:

Closing PR based on comment.


task run failed when i excut the testing

error: code=0, message=metric type not found or not supported, supported: [L2 IP]
WARNING: pre run case error: <MilvusException: (code=0, message=metric type not found or not supported, supported: [L2 IP])> (task_runner.py:92) (546)
2024-06-19 07:49:05,797 | WARNING: [1/1] case {'label': <CaseLabel.Performance: 2>, 'dataset': {'data': {'name': 'Cohere', 'size': 1000000, 'dim': 768, 'metric_type': <MetricType.COSINE: 'COSINE'>}}, 'db': 'Milvus'} failed to run, reason=<MilvusException: (code=0, message=metric type not found or not supported, supported: [L2 IP])> (interface.py:187) (546)
Traceback (most recent call last):
File "/opt/code/vectordb_bench/interface.py", line 168, in _async_task_v2
case_res.metrics = runner.run(drop_old)
^^^^^^^^^^^^^^^^^^^^
File "/opt/code/vectordb_bench/backend/task_runner.py", line 96, in run
self._pre_run(drop_old)
File "/opt/code/vectordb_bench/backend/task_runner.py", line 93, in _pre_run
raise e from None
File "/opt/code/vectordb_bench/backend/task_runner.py", line 86, in _pre_run
self.init_db(drop_old)
File "/opt/code/vectordb_bench/backend/task_runner.py", line 77, in init_db
self.db = db_cls(
^^^^^^^
File "/opt/code/vectordb_bench/backend/clients/milvus/milvus.py", line 64, in init
col.create_index(
File "/usr/local/lib/python3.11/site-packages/pymilvus/orm/collection.py", line 1371, in create_index
return conn.create_index(self._name, field_name, index_params, timeout=timeout, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pymilvus/decorators.py", line 147, in handler
raise e from e
File "/usr/local/lib/python3.11/site-packages/pymilvus/decorators.py", line 143, in handler
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pymilvus/decorators.py", line 182, in handler
return func(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pymilvus/decorators.py", line 122, in handler
raise e from e
File "/usr/local/lib/python3.11/site-packages/pymilvus/decorators.py", line 87, in handler
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pymilvus/client/grpc_handler.py", line 987, in create_index
check_status(status)
File "/usr/local/lib/python3.11/site-packages/pymilvus/client/utils.py", line 63, in check_status
raise MilvusException(status.code, status.reason, status.error_code)
step:
git clone https://github.com/zilliztech/VectorDBBench.git
cd VectorDBBench
pip install -e ".[test]"
init_bench

@ZhangTomLiang The execption is rasied by Milvus. Seems like you're using an earlier verision of Milvus that doesn't support COSINE metric type.
Milvus supports COSINE metric type on 2.3.0 and later.
You could use an earlier version of vdbbench that would normolize cohere data and work with Milvus<2.3.0

/assign @ZhangTomLiang

thank you XuanYang for the reply. but i tried the following commands, still have the same problem. Can we provide us the latest mirror image of milvus？it would be great.
commands:
pip install vectordb-bench==0.0.2
init_bench
error:
File "/usr/local/lib/python3.11/site-packages/pymilvus/client/utils.py", line 63, in check_status
raise MilvusException(status.code, status.reason, status.error_code)
pymilvus.exceptions.MilvusException: <MilvusException: (code=0, message=metric type not found or not supported, supported: [L2 IP])>
2024-06-20 03:43:18,205 | INFO |Task summary: run_id=783c0, task_label=2024062003 (models.py:289)
2024-06-20 03:43:18,205 | INFO |DB     | db_label case                 label      | load_dur    qps        latency(p99)    recall        max_load_count | label (models.py:289)
2024-06-20 03:43:18,206 | INFO |------ | -------- -------------------- ---------- | ----------- ---------- --------------- ------------- -------------- | ----- (models.py:289)
2024-06-20 03:43:18,206 | INFO |Milvus |          Performance1536D500K<PHONE_NUMBER> | 0.0         0.0        0.0             0.0           0              | x     (models.py:289)
2024-06-20 03:43:18,206 | WARNING: Replacing existing result with the same file_name: /opt/code/vectordb_bench/results/Milvus/result_20240620_2024062003_milvus.json (models.py:143) (1910)
2024-06-20 03:43:18,206 | INFO: write results to disk /opt/code/vectordb_bench/results/Milvus/result_20240620_2024062003_milvus.json (models.py:147) (1910)
2024-06-20 03:43:18,207 | INFO: Succes to finish task: label=2024062003, run_id=783c0641179f4e94a5f22671241b7294 (interface.py:207) (1910)

@ZhangTomLiang Please use vectordb-bench==0.0.1 for Milvus that doesn't support COSINE.
Or you could also using the latest Milvus 2.4.5 that supports the COSINE metrics.


Custom breakpoints

When I have @include breakpoint(brkpt_name) { } everything works fine. But when I use @include breakpoint(brkpt_name down) { } sass generates in css @media screen and (max-width: ) { }
http://foundation.zurb.com/sites/docs/media-queries.html#the-breakpoint-mixin

This happens if brkpt_name is the largest breakpoint in the list. There's no higher breakpoint to use as the ceiling of the media query. I added a warning to the breakpoint() function to explain this behavior.

This seems to be happening in the Foundation files—in _top-bar.scss:

@designerdean Fixed in the develop branch via 8252c2ba8f2703a377dc0cf594aa5a2e3ab2ad7a and 8b2f710a9dd3ebd6bf194b5e561c46ef0acf016c

Thanks, @gakimball! Loving the quick responses to all the issues. Will this fix be in the version 6.2 release?

Yep! We just published a release candidate for 6.2 if you want to give it a try.


Removed transition and reverese transition durations on BeamPage

When BeamPage is BeamPageType.noTransition

Thanks for the PR @busslina
Nice find! 👌


SecretExpiryInMinutes does not work

You can set 12 hours as the standard time provided in the environment but your link will expire just after the first read.

Thank you for trying my project out!
Yes, indeed, SecretExpiryInMinutes only sets expiration date. Notes are going to be burned after the first read. It's implemented as a security measure.

This is intended behavior. Did you expect anything else? I'll be sure to modify README to state that this is a "one-time note" service.


Add broken site report pixel

Task/Issue URL: https://app.asana.com/0/361428290920652/1137628760317279
Grafana: https://grafana.duckduckgo.com/d/sawhWhOWk/mobile-sre
Description:
Add a simple pixel to the broken site reports so we can visualize these in Grafana and add alerts should the numbers unexpectedly rise.
Steps to test this PR:

Run the app and browse to a site
Tap the browser settings button and select "Report Broken Site"
Enter "test.com" for the url and "TEST" in the comment section
Submit the report and ensure the "m_bsr" pixel fires, checking Kibana https://kibana.duckduckgo.com/goto/6bf29a6e1d9053c7395b9ddcf2338371

Internal references:
Software Engineering Expectations
Technical Design Template

Sorry used the old branch naming convention on this one!


fixing sysctl command to take whitespace-separated multi values for a key

https://github.com/ceph/ceph-ansible/issues/397

Thanks @Abhishekvrshny


Alt-Tab is not working on Windows Server 2012 (in virtual environment)

Alt-Tab is working on my machine with Windows 10, but not working on Windows Server 2012 which is running in something like virtualbox.
Your Environment

RobotJS version: 0.5.1
Node.js version: v10
npm version:
Operating System: Windows Server 2012 (in virtualbox possibly)

        robot.keyTap("tab", "alt"); // nothing happens
        robot.keyTap("tab"); // this works

This issue has been closed because it has been inactive for > 180 days.
You may reopen this issue if it has been closed in error.

I have the same problem on Linux Mint Cinnamon (Linux 5.0.0-32-generic x86_64). Should this be reopened or should I create a new issue (because the problem is on Linux)? If I install from npm, alt-tab works, but not if I download from GitHub and install from folder (this version is necessary for my app since it fixes keystroke delays).


Fuse Multiply Add Accumulator

ReduceSpecialization Test fail due to a bug fix in CanFuseFMA setter.
In AccumAnalyzer need to match on the multiply add with mux structure instead of FMA directly because previously FMA was incorrectly fused.

Fixed in c7a50b18.  RewriteAnalyzer now looks for either mul.consumers.size == 1 OR mul.consumers.size == 2 and everything fits into the reg = mux( _, a * b, reg + a * b) pattern


Syndicate surplus crates

About the PR
Add syndicate surplus (cost 20 TC, 50 TC content inside) and super surplus crates (cost 40 TC, 125 TC content inside). I just copied TC values from TG wiki, no idea how it will work with SS14 uplink pricing.
Still it good way to risk all TCs and get some good weapon bundle.
Screenshots

Changelog

:cl:

add: Attention syndicate agents! We have found some old crates with random junk inside. We are ready to sell it for 20 telecrystals while content inside cost 50 telecrystals.

125 TC worth of items for 40TC feels clinically insane.

125 TC worth of items for 40TC feels clinically insane.

it will force antag syndies learn to do teamwork if they want the good stuff

Zombie bundle has just shown that a 40TC will be powergamed by 2 syndie players every single round. Allowing just 2 players to buy the national armaments of iraq with literally no downside (as you would most likely get everything you wanted) seems like it would only result in chaos.

Zombie bundle has just shown that a 40TC will be powergamed by 2 syndie players every single round. Allowing just 2 players to buy the national armaments of iraq with literally no downside (as you would most likely get everything you wanted) seems like it would only result in chaos.

I think that's the point of the super surplus crate.
It's only a problem if it happens super often, which if it does, the price can be tweaked.

What im saying is, it will happen super often. The fact that any syndie, at the beginning of a round, can roll the die to get random loot thats double the value of what he could otherwise get normally. Thats overpowered enough. The fact that 2 syndies, (which isnt that hard to arrange due to protect objectives) can get triple the value of loot from one purchase just further highlights the rediculous upsides of this bundle. It needs a significant TC nerf, imo.

Excuse my ignorance but do traitors know who the other traitors are at round start? If no that needs changed to code words then we have less traitor cooperating.

Isn't protect objective admin-only?, it is in ss13 iirc.

Traitors don't know other traitors at start, but theres a protect objective that will inform you of one other traitor that you'll need to protect. Usually 1-2 players a round will have this objective. I personally have had rounds with 2 people i have to protect.

Here is some rolls for super surplus crate.
Roll 1:
[INFO] root: syndicate hardsuit bundle
[INFO] root: nuclear authentication disk
[INFO] root: syndicate EVA box
[INFO] root: holoparasite box
[INFO] root: flashbang
[INFO] root: syndicate rubber stamp
[INFO] root: speed loader (.40 magnum)
[INFO] root: C-20r bundle
[INFO] root: soap
[INFO] root: black shoes
[INFO] root: energy sword
[INFO] root: C-20r bundle
[INFO] root: Predator
[INFO] root: pistol magazine (.25 caseless)
[INFO] root: cap gun
[INFO] root: Syndicate Smokes packet
[INFO] root: blood-red magboots
[INFO] root: box of .30 rifle bullets
[INFO] root: blood-red magboots
[INFO] root: composition C-4
[INFO] root: suspicious toolbox
[INFO] root: syndicate rubber stamp
[INFO] root: suspicious toolbox
[INFO] root: nuclear authentication disk

Roll 2:
[INFO] root: China-Lake bundle
[INFO] root: syndicate zombie bundle
[INFO] root: syndicate jaws of life
[INFO] root: pen
[INFO] root: syndicate hardsuit bundle
[INFO] root: C-20r bundle
[INFO] root: pen
[INFO] root: clarissa

Roll 3:
[INFO] root: Bojevic bundle
[INFO] root: box of .30 rifle bullets
[INFO] root: Predator
[INFO] root: clarissa
[INFO] root: pistol magazine (.35 auto)
[INFO] root: nocturine bottle
[INFO] root: pistol magazine (.25 caseless)
[INFO] root: speed loader (.40 magnum)
[INFO] root: mandella
[INFO] root: holoparasite box
[INFO] root: Predator
[INFO] root: clown costume duffel bag
[INFO] root: pen
[INFO] root: Syndicate minibomb
[INFO] root: flashbang
[INFO] root: C-20r bundle
[INFO] root: soap

Roll 4:
[INFO] root: syndicate rubber stamp
[INFO] root: health analyzer
[INFO] root: soap
[INFO] root: assistant ID card (assistant)
[INFO] root: cryptographic sequencer
[INFO] root: syndicate surgical duffel bag
[INFO] root: box of .30 rifle bullets
[INFO] root: Cybersun pen
[INFO] root: clown costume duffel bag
[INFO] root: black shoes
[INFO] root: energy sword
[INFO] root: soap
[INFO] root: Kardashev-Mosin
[INFO] root: syndie balloon
[INFO] root: Kardashev-Mosin
[INFO] root: syndicate EVA box
[INFO] root: syndie balloon
[INFO] root: pen
[INFO] root: pen
[INFO] root: composition C-4
[INFO] root: explosive grenade
[INFO] root: blood-red magboots
[INFO] root: flashbang
[INFO] root: Kardashev-Mosin
[INFO] root: composition C-4
[INFO] root: pen
[INFO] root: box of .30 rifle bullets
[INFO] root: black shoes
[INFO] root: blood-red magboots

Traitors don't know other traitors at start, but theres a protect objective that will inform you of one other traitor that you'll need to protect. Usually 1-2 players a round will have this objective. I personally have had rounds with 2 people i have to protect.

That's a problem with the protect objective, not this pr.

Theres nothing wrong with having to team and protect another player.

Traitors don't know other traitors at start, but theres a protect objective that will inform you of one other traitor that you'll need to protect. Usually 1-2 players a round will have this objective. I personally have had rounds with 2 people i have to protect.

That's a problem with the protect objective, not this pr.

There's nothing wrong with traitors working together and protecting each other. The issue is being able to effectively double the contents you could buy in a round.

This will only get more unbalanced as more effective and useful traitor items are added.

This will only get more unbalanced as more effective and useful traitor items are added.

The question is whether the traitors (plural) can effectively agree on and use the items given.
Different items require different strategies and this throws any pre-built strats out the window as you can't rely on it
I believe at minimum testing this out on live would be a good idea.

If we want some funky but still useful results before it’s added there are a few ways to do it
One is to do some calculations but I’m doin something right now so I’ll say how well can do it later.

lets see how this goes, it's a lot of TC but the fact that it isn't coordinated at all means its a lot more worthless than it looks


Print PDU

Hello and thank you for this wonderful library, i have an small issue.
Sometimes our providers ask for the PDU when submitting a ticket, they have often sent us what is appears is the PDU in hex, can this be done with this library? i cant find any methods for this.
Best Regards,
Reinaldo

Hi Reinaldo, thanks for the feedback. I think this a nice feature to add. I will implement it with the next release.

Implemented full logging of the SMPP PDU at debug log level.


StAfter must accept a list of shifts

We have StAfter, which encapsulates just one shift to be applied "after". Let's improve current design and make it possible to encapsulate a list of shifts:
new StAfter(
  shift,
  new StLambda(..),
  new StLambda(..),
  new StLambda(..)
)

@rultor release, tag is 0.13.0

@rultor release, tag is 0.13.0

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.13.0

@yegor256 Done! FYI, the full log is here (took me 10min)


how can I disable the lsp-config's progress report in the status line

this plugin is great, but now how can I disable the lsp-config's progress report in the status line?

oh ,sorry ,i found i open the lualine-lsp-progress


Failing nodes make CI pipeline timeout instead of erroring out when detected

When a node crashes (e.g. an assert is triggered), the CI pipeline will timeout after its defined timeout (currently 60 minutes), needlessly stalling the pipeline.

This was fixed, probably by one of the assertHandler fixes. It only ever triggers for Flash tests from time to time, but because of some patterns there, not in the general case.


Update ONLINECOURSES.json

You haven't made any changes, You have to update the database if you want to merge your req in this repo


Scheduler: Updates cron library to include staging queue

Updates the go-etcd-cron library to add support for the staging queue.
When a daprd Job or Actor Reminder is triggered but that job type is not
supported, the job is added to the staging queue. Once a daprd connects
to scheduler which implements that type, the job will be immediately
triggered to that host.
The WatchJobsRequestResultStatus proto has been added for the watch
jobs response to signal whether a job has succeeded or failed. This has
not been wired up with daprd yet.
Tests have been added for staging, and the default failure policy which
is built in to the cron library.

/cc @alicejgibbons


Add Backbase

Adding Backbase as a user of TestContainers in our testing pipelines and SDLC

@torrespro nice! Thank you! I hope you're enjoying it :)


[resolves #433] Explicitly mark versions that need to be aligned with th...

...e Karaf runtime

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/303/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/304/
Test PASSed.


Client Side Exception after upgrading to v 4.0.0

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
4.0.0
Link to runnable example
No response
Steps to reproduce
When using in combination with react-markdown:
<ReactMarkdown ... remarkPlugins={[remarkGfm]}>
  {markdown}
</ReactMarkdown>

Expected behavior
Markdown should render
Actual behavior
After upgrading package to 4.0.0, I'm getting a client error:

Runtime
Node v14
Package manager
yarn 1
OS
macOS
Build and bundle tools
No response

Duplicate of https://github.com/remarkjs/remark-gfm/issues/57


Release 1.16.0 to pypi

Credstash package is still on 1.15.0, we could use some of the new features.
Please release 1.16.0 to pypi.

Hello, sorry for the delay, it took a little while to get permissions on the credstash PyPi project. v1.16.1 has been released with fixes for v1.16.0 and is available on PyPi: https://pypi.org/manage/project/credstash/release/1.16.1/


Add: da2x.edgedeflector v<IP_ADDRESS>

[X] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

URI: https://github.com/da2x/EdgeDeflector/releases/download/v<IP_ADDRESS>/EdgeDeflector_install.exe, Validation result: Failed, Report feedback: https://feedback.smartscreen.microsoft.com/feedback.aspx?v=6&t=16&result=block&type=top&url=aHR0cHM6Ly9naXRodWIuY29tL2RhMngvRWRnZURlZmxlY3Rvci9yZWxlYXNlcy9kb3dubG9hZC92MS4yLjIuMC9FZGdlRGVmbGVjdG9yX2luc3RhbGwuZXhl
https://www.virustotal.com/gui/url/3d47f00b467adf10c15636e994ef156344b80c48bfb365bedbca01954c0793c5/detection
https://www.virustotal.com/gui/file/3b1cb1e9a8187e16f6447b81785632fa5989d72a0475d82390ba52448a5defa5/detection

cba


Fix compilation error in events/events_test.go

Compilation was failing
# github.com/docker/containerd/events
events/events_test.go:25: ctx.fmt undefined (type context.Context has no field or method fmt)
events/events_test.go:25: not enough arguments in ca

The test passes now, but maybe I'd better fix events.go rather than events_test.go?
Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

LGTM


REF: make validate_asyn_ports raise with helpful message

[Current coverage][cc-pull] is 84.19% (diff: 100%)

Merging [#345][cc-pull] into [master][cc-base-branch] will decrease coverage by <.01%

@@             master       #345   diff @@
==========================================
  Files            30         30
  Lines          4488       4486     -2
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           3779       3777     -2
  Misses          709        709
  Partials          0          0

Powered by Codecov. Last update [d45bb4c...e9f9f4b][cc-compare]
[cc-base-branch]: https://codecov.io/gh/NSLS-II/ophyd/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/NSLS-II/ophyd/compare/d45bb4c49f10d5bf95b6690047a3fcbbaa718561...e9f9f4bf99e7cd8d83b281778b8d30a0f039c78c?src=pr
[cc-pull]: https://codecov.io/gh/NSLS-II/ophyd/pull/345?src=pr


Request to Approve the Workflow by Manager and above

Below are my requirements, As an end-user, I have to place a request to my manager to approve my request.

I have to trigger create a new workflow and when I place a leave request from my application this workflow should get triggered.
Once the workflow triggered, the request has to go to my manager for approval with mail. Once, he approves then my request is fulfilled.

Another case:
If the leaves applied are more than 5days then the request goes to my manager's manager once my manager approves.
Can you please suggest some examples here if you have. I tried with the ApproveRecord but still, I am not able to achieve this with the users we have.

I have to trigger create a new workflow and when I place a leave request from my application this workflow should get triggered.

You can use Wexflow API to do that from your application.

Once the workflow triggered, the request has to go to my manager for approval with mail. Once, he approves then my request is fulfilled.

You can create a record and use ApproveRecord task and start the workflow as manager user using Wexflow API. You must create a new user in Wexflow for the manager. Here is a walkthrough on how to use ApproveRecord task.

If the leaves applied are more than 5days then the request goes to my manager's manager once my manager approves.

This use case is not supported for the moment.

@aelassas Thanks for the update. I have one more question.
Is it possible to approve multiple approvers at the same level? Because I was doing some integration work and both the team managers need to approve then only I should proceed to the next step? is it possible?

@Chengal1207 It will be possible in the v5.7. The v5.6 only supports one approver per record.

@Chengal1207 I released the v5.7 today. Now, you can have multiple approvers per record. Check out the documentation.

@Chengal1207 can I close this issue?

Thanks @aelassas. you can close this


Missing libm linkage when building with INTERFACE64=1

I'm building openblas with
  cmake -B build64 -S OpenBLAS \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DBUILD_SHARED_LIBS=ON \
    -DBUILD_WITHOUT_LAPACK=ON \
    -DBUILD_WITHOUT_CBLAS=ON \
    -DBUILD_TESTING=OFF \
    -DNO_AFFINITY=ON \
    -DUSE_OPENMP=1 \
    -DCORE=CORE2 \
    -DDYNAMIC_ARCH=ON \
    -DINTERFACE64=1

and the resulting libopenblas64.so library is not linked to libm.so, even though it calls libm functions, such as sqrt.
Building without -DINTERFACE64=1 produces a library which is correctly linked to libm.so

What is your operating system please ? I cannot seem to reproduce this on Linux.

Arch Linux x86_64

Tried both, same result

Hmm, what compiler (and version) ?

gcc 12.2.1

Got it now - appears to be independent from the INTERFACE64 setting. The changed CMakeLists.txt from #3895 should address it (and I am currently doubting if the EXTRALIB that gets so painstakingly set as in the gmake build is actually used anywhere in the cmake build at all...)

Got it now - appears to be independent from the INTERFACE64 setting.

Right, sorry for the confusion - I was actually testing an older build made with the plain Makefile


⚠ Bofrost.de has degraded performance

In b86035c, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1613 ms

Resolved: Bofrost.de performance has improved in 6c9781b.


binary search tree implemented

@surya76657 can you review this?

@surya76657 can you review this?

Done


Commands::send_event

Objective
sending events tends to be low-frequency so ergonomics can be prioritized over efficiency.
add Commands::send_event to send any type of event without needing a writer in hand.
i don't know how we feel about these kind of ergonomic things, i add this to all my projects and find it useful. adding mut this_particular_event_writer: EventWriter<ThisParticularEvent> every time i want to send something is unnecessarily cumbersome.
it also simplifies the "send and receive in the same system" pattern significantly.
basic example before:
fn my_func(
    q: Query<(Entity, &State)>,
    mut damage_event_writer: EventWriter<DamageEvent>,
    mut heal_event_writer: EventWriter<HealEvent>,
) {
    for (entity, state) in q.iter() {
        if let Some(damage) = state.get_damage() {
            damage_event_writer.send(DamageEvent { entity, damage });
        }

        if let Some(heal) = state.get_heal() {
            heal_event_writer.send(HealEvent { entity, heal });
        }
    }
}

basic example after:
import bevy::ecs::event::SendEventEx;

fn my_func(
    mut commands: Commands,
    q: Query<(Entity, &State)>,
) {
    for (entity, state) in q.iter() {
        if let Some(damage) = state.get_damage() {
            commands.send_event(DamageEvent { entity, damage });
        }

        if let Some(heal) = state.get_heal() {
            commands.send_event(HealEvent { entity, heal });
        }
    }
}

send/receive in the same system before:
fn send_and_receive_param_set(
    mut param_set: ParamSet<(EventReader<DebugEvent>, EventWriter<DebugEvent>)>,
) {
    // We must collect the events to resend, because we can't access the writer while we're iterating over the reader.
    let mut events_to_resend = Vec::new();

    // This is p0, as the first parameter in the `ParamSet` is the reader.
    for event in param_set.p0().read() {
        if event.resend_from_param_set {
            events_to_resend.push(event.clone());
        }
    }

    // This is p1, as the second parameter in the `ParamSet` is the writer.
    for mut event in events_to_resend {
        event.times_sent += 1;
        param_set.p1().send(event);
    }
}

after:
use bevy::ecs::event::SendEventEx;

fn send_via_commands_and_receive(
    mut reader: EventReader<DebugEvent>,
    mut commands: Commands,
) {
    for event in reader.read() {
        if event.resend_via_commands {
            commands.send_event(DebugEvent {
                times_sent: event.times_sent + 1,
                ..event.clone()
            });
        }
    }
}

FYI, #13818 adds another little helper for sending and receiving events in the same system.

This pattern is indeed extremely common. Here's a few cursed variations from my game:
impl Command for MyEvent {
    fn apply(self, world: &mut World) {
        world.send_event(self);
    }
}

commands.add(|world: &mut World| world.send_event(event));

One possible footgun here could be that DeferredWorld has send_event but would also get commands().send_event, which would be less efficient.

FYI, #13818 adds another little helper for sending and receiving events in the same system.

sorry, i don't see it?

One possible footgun here could be that DeferredWorld has send_event but would also get commands().send_event, which would be less efficient.

i can rename - i generally call it fire_event but i was trying to be a bit more vanilla with the naming..

i can rename - i generally call it fire_event but i was trying to be a bit more vanilla with the naming..

I think send_event is fine, it does match better with the other ones, we can either assume people will know commands are slower, or have the docs tell people to use the one on World or DeferredWorld instead if they have access to it.

If this is merged, would it be the default way to send events or would there be 2 ways of doing the same thing? If so, which one would be preferred?

The EventWriter approach is preferred: it has much lower overhead. The commands approach is good for lazy prototyping, cold loop code where you prefer the ergonomics, or working with heterogeneous event types.

thoughts on automatically registering the event type as well? So that people who use this pattern won't have to call App::add_event.

We definitely shouldn't do that: add_event configures a specific kind of event clearing that not every event wants.

We definitely shouldn't do that: add_event configures a specific kind of event clearing that not every event wants.

we could add it only if Events isn't found; i believe the way to configure events manually is by adding the resource so it shouldn't interfere?

Merging once CI is green: suggestions probably broke formatting.


Release artifacts for release v1.2.0

Description of changes:

Release artifacts for release v1.2.0

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

/hold


add twitter link to ignore list. standard GET are being rejected

@jongio

@scbedd thanks for ignoring the twitter issue. We should file an issue on that. I pushed 2 other fixes to other broken links to your branch to hopefully get this repo clean.

@scbedd thanks for ignoring the twitter issue. We should file an issue on that. I pushed 2 other fixes to other broken links to your branch to hopefully get this repo clean.

Issue filed Wes


Add an instruction for cluster endpoint option

This feature has been added since this workshop has last been updated

Resolved by @kmadel

We should update the screenshot to include the new field


Failed to compile on Ubuntu 18.04.6

Hi,
I'm trying to compile zrenderer on Ubuntu 18.04.6 but I'm having trouble trying to do it.
Follow some informations:
OS
Ubuntu LTS 18.04.6
DUB
DUB version 1.8.0-2, built on Mar 27 2018
LDC / LDC2
LDC - the LLVM D compiler (1.8.0): based on DMD v2.078.3 and LLVM 5.0.1
OpenSSL
OpenSSL 1.1.1  11 Sep 2018
Command Line
sudo dub build --compiler=ldc2 --build=release :server

After uninstalling the libraries and installing again, it took a few steps but gave the error.

Hi @tidre unfortunately ubuntu 18 uses a too old version of dub and ldc.
I recommend downloading a newer version directly from the ldc release page: https://github.com/ldc-developers/ldc/releases
Assuming you're running x64 linux you would need to download something like ldc2-1.32.2-linux-x86_64.tar.xz.
In the provided archive you will find all the tools required under the bin directory.
If you run dub from that archive I believe you will have to add the ldc2 executable to your PATH environment variable so that it can be picked it. For that to work you'll probably also need to uninstall your current dub and ldc2 which you got from the package manager.
Sorry for all the trouble but the D language and its tooling is sadly not very backwards compatible.

Hi @zhad3,
Thank you for your help.
After updating ldc and dub my versions are:

LDC (1.24.0)
DUB (1.19.0)

But now I have the following problem:

After updating LDC, DUB, DMD, OpenSSL, still the error persists.
Versions:

Error:

I was having issues compiling. curl -fsS https://dlang.org/install.sh | bash -s ldc allowed me to compile successfully


Revert "Add subscription scope to assessment metadata API"

Reverts Azure/azure-rest-api-specs#6445

Automation for azure-sdk-for-python

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go


Uploaded documents not accessible

Error message instead:
This XML file does not appear to have any style information associated with it. The document tree is shown below.

NoSuchKey
The specified key does not exist.
uploads/16145548887_72f2c144aa_o.jpg
E3DBC384DCD056C9

DPwd0U3nnOqxOvwHJUbsIUoG8TDmS43Qk+U9nlXQlLXbRMt4wmjUQICO6QaBnf1q

No this is actually all working. The missing files you're seeing are those, where the documents came from my local instance. I only copied the database to Heroku, not the uploaded files.
You should either re-upload those files, or delete the instances.
I've uploaded new files and they're working fine.

I can confirm this is resolved. I just tested by uploading a photograph resource and it worked.


Keycloak auth manager

Integrate with CWBI keycloak.
Iteration 1 will use existing CWBI test environment setups. We will likely expand to more generic OpenID Connect workflows in the future.

This is in place. NOTE: not integrated into the automated test sequence yet.


made fatalError() drop-in replacement internal (instead of public)

It's a very bad idea to introduce public function with the exact same name as standard Swift function. Declaring such function does not override system function Swift.fatalError(), but merely creates a new function SwiftAA.fatalError() with the same signature. Since local scope take precedence, calling unqualified fatalError() from SwiftAA module will call local function. However, if you call unqualified fatalError() from other module which has SwiftAA imported, swift compiler would not be able to infer which function to call, Swift.fatalError() or SwiftAA.fatalError() and you'll get Ambiguous use of 'fatalError(_:file:line:)' error on every fatalError call.

You are perfectly right, thanks for checking this out.


Merge in translations

Translations have been merged. There are still some untranslated strings for Japanese, but we do not want to hold back 1.11.2 because of this.


[6.4.x] GUVNOR-2030: Guided Decision Table: Empty field results in all Conditions being cancelled

See https://issues.jboss.org/browse/GUVNOR-2030
Corollary of https://github.com/droolsjbpm/drools/pull/652 for 6.4.x
(cherry picked from commit 07748111bb51b482b3eb7ffa83e0010ad6d663c1)

+1


BthPS3 installer breaks/uninstall ViGEmBus

Tested on v2.1.153
This issue is currently a draft
Installing or uninstalling BthPS3 (can't remember right now) causes ViGEmBus to not be detected anymore by applications looking for it. I'm not sure if the driver itself does not get loaded anymore by Windows or if it's loaded but applications can't find it.
Regardless, it's possible to just re-install the ViGEmBus without major problems.
To-do
Reproduce the issue again to check if the ViGEmBus still appears as installed on windows' Apps and Features list or is present in the Device Manager

I had a look at this a few weeks (months?) back but need to investigate again, I think it is due to some reused code/scripts in the setup that accidentally nukes the wrong device.

Can we somehow get a playlist on how to exactly reproduce it? It is still happening, observed on the Discord, but with just text search I can't find any references to ViGEmBus and its setup in the BthPS3 installer sources whatsoever 🤔 So best chance might be to reproduce it and log what happens during it with Process Monitor to find the originating process that kicks off the uninstall command.

It also seem to break "Hide DS4 Controller" option in DS4Windows, as I can't hide my DS4 anymore, 2 of them appears. Reinstalling or toggling the option doesn't help.

It also seem to break "Hide DS4 Controller" option in DS4Windows, as I can't hide my DS4 anymore, 2 of them appears. Reinstalling or toggling the option doesn't help. Getting: Could not open DS4 90:89:5F:94:7C:65 exclusively. You must quit other applications like UWP apps (Netflix), Steam, Uplay, Edge, NVIDIA IN-GAME before activating the 'Hide DS4 Controller' option

Having a hard time believing that since I see no relation to that feature whatsoever.

Could be related to dshidmini, as I install them together. But this problem has been reproduced on 3 completely different systems.

Could be related to dshidmini, as I install them together. But this problem has been reproduced on 3 completely different systems.

DsHidMini currently doesn't ship with an installer and on its own doesn't have any code or logic shipped that interfaces with what you described.

Hi everyone
Same here, I'll try to reproduce my steps
I had already installed DS4Windows in my PC, for my Dualsense Controller:

Installed dshidmini_v2.2.282.0 x 64
Connected Via USB my 2 Dualshocks 3
Connected my Bluethooth device
Activated DS4Windows Mode
Installed BthPS3 v2.5.148 x64
My PC Reboots
Opened DS4 Windows and ViGEMUSB is not installed
Installs ViGEmBus and everything works fine EXCEPT BthPS3 appears as not installed in my DsHidMini Control
I tried again, and checked BthPS3 installation without installing ViGEmBus and still as not installed

I can not reproduce it whatsoever. Maybe it's code in DS4Windows? @Kanuan does DS4Windows silently invoke any related setup on initial start?

Goodness, copypasta bug hiding in plain sight for quite some years 🤦 new release has that fixed!


[Provider Audit] provider.medas-digital.io

Prerequisite Steps:
1. Make sure your provider has community provider attributes and your contact details (email, website):
  Example:
  $ provider-services query provider get akash1<REDACTED> -o text
  ...
  attributes:
  ...
  - key: host
  value: akash
  - key: tier
  value: community
  info:
    email: "<your email>"
    website: "<your website>"

Ref documentation:.
2. Make sure your provider *.ingress resolves to your provider IP (ideally worker node IP)
host <anything>.ingress.<yourdomain>

Example:
$ host anything.ingress.akash.pro
anything.ingress.akash.pro is an alias for nodes.akash.pro.
nodes.akash.pro has address <IP_ADDRESS>

More info on what DNS records should look like are available in the Akash Documentation here.

3. Please make sure your Akash provider doesn't block any Akash specific ports.

If you are using a firewall, please follow this doc:
https://akash.network/docs/providers/build-a-cloud-provider/akash-cloud-provider-build-with-helm-charts/#step-11---firewall-rule-review
If you are behind NAT, then you need to make sure these ports are open between your provider worker nodes and the internet.

Audit Steps:
1. Title the issue: " [Provider Audit]: Provider Address" (e.g. "[Provider Audit]: provider.europlots.com")
2. Wait for response via comments. If no issues during provider Audit, process will be complete, provider should start bidding on leases, and Audit ticket will be closed.
3. If there are issues during the provider Audit, debug those issues, and Audit will be complete.
4. Audit Issue will be closed by core team member.
Leave contact information (optional)

Eike Janssen
@xgn_MedasDigital
<EMAIL_ADDRESS>

hi @oxygene76 ,
Your provider is not responding on status endpoint / port 8443:
curl -sk https://provider.medas-digital.io:8443/status | jq
returns an empty response
The GRPC endpoint is not working / port 8444:
grpcurl -insecure provider.medas-digital.io:8444 akash.provider.v1.ProviderRPC.GetStatus
Failed to dial target host "provider.medas-digital.io:8444": dial tcp <IP_ADDRESS>:8444: connect: connection refused
Please fix those issues before we can continue.
thank you!

Hi,
is running again, I got
akash-provider-0                              0/1     CrashLoopBackOff   1187 (21s ago)   15d
Investigating the cause
Freundliche Grüße
Eike Janßen
Medas Computers GmbH
Im Ziegelhaus 13
63571 Gelnhausen
Fon: 06051 / 91669-0
Fax: 06051 / 91669-29
http://www.medas-computers.dehttp://www.medas-computers.de/
@.***
Von: shimpa @.>
Gesendet: Mittwoch, 8. Mai 2024 15:41
An: akash-network/community @.>
Cc: Eike Janssen (medas Computers GmbH) @.>; Mention @.>
Betreff: Re: [akash-network/community] [Provider Audit] provider.medas-digital.io (Issue #558)
hi @oxygene76https://github.com/oxygene76 ,
Your provider is not responding on status endpoint / port 8443:
curl -sk https://provider.medas-digital.io:8443/status | jq
returns an empty response
The GRPC endpoint is not working / port 8444:
grpcurl -insecure provider.medas-digital.io:8444 akash.provider.v1.ProviderRPC.GetStatus
Failed to dial target host "provider.medas-digital.io:8444": dial tcp <IP_ADDRESS>:8444: connect: connection refused
Please fix those issues before we can continue.
thank you!
—
Reply to this email directly, view it on GitHubhttps://github.com/akash-network/community/issues/558#issuecomment-2100606695, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A2T3XC3UL5X7GEL2UHQQQZTZBITQFAVCNFSM6AAAAABGSMGWIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBQGYYDMNRZGU.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

Hi @oxygene76
your provider won't bid to my deployment order:
profiles:
  compute:
    app:
      resources:
        cpu:
          units: 4
        memory:
          size: 8Gi
        storage:
          size: 20Gi

Please check your provider logs for dseq 16922520 to see if you have any relevant logs.
Example command to check the logs for that dseq:
kubectl -n akash-services logs akash-provider-0 --tail=10000000 | grep 16922520

Your provider should have enough capacity for my request though.
$ provider_info2.sh provider.medas-digital.io
PROVIDER INFO
BALANCE: 9.338558
"hostname"                   "address"
"provider.medas-digital.io"  "akash1rlkx7vef3h2jaz33ru0axhggmt6gyq35xevg5x"

Total/Available/Used (t/a/u) per node:
"name"   "cpu(t/a/u)"        "gpu(t/a/u)"  "mem(t/a/u GiB)"       "ephemeral(t/a/u GiB)"
"node1"  "16/13.33/2.67"     "0/0/0"       "31.24/27.7/3.54"      "43.13/43.13/0"
"node2"  "64/53.895/10.105"  "0/0/0"       "125.68/106.41/19.27"  "882.71/882.21/0.5"

ACTIVE TOTAL:
"cpu(cores)"  "gpu"  "mem(GiB)"  "ephemeral(GiB)"  "beta1(GiB)"  "beta2(GiB)"  "beta3(GiB)"
0.5           0      0.5         0.5               0             0             0

PERSISTENT STORAGE:
"storage class"  "available space(GiB)"

PENDING TOTAL:
"cpu(cores)"  "gpu"  "mem(GiB)"  "ephemeral(GiB)"  "beta1(GiB)"  "beta2(GiB)"  "beta3(GiB)"

provider is still no responding.
closing due to inactivity.
please feel free to re-open when ready.