v5 browser support tradeoff is problematic for RUM scripts

Hey folks! 👋
We're currently building the next version of our RUM script on top of web-vitals, in order to ensure that our handling of CWV metrics is as consistent as possible with CrUX's. CWV metrics aren't the only thing our script collects, but are obviously an important part of it.
We have two main priorities with our RUM script: keeping it as small as possible, to avoid interfering with page performance; and having it work in as many browsers as possible, so that at the very least we have an awareness of the prevalence of older browsers, even if the data we collect on those is limited.
In order to do this, we transpile to older syntax, which works quite well with web-vitals v4. If we upgrade to the v5 RC, however, our bundle size increases by approximately one quarter. The main reason behind the size increase appears to be helpers for new syntax such as for ... of and object spreads, which was added in #525 to take advantage of the reduced browser support, even though the prior code worked correctly.
I don't think our script is alone in trying to gather data from as many browsers as possible; having browsers in which your script breaks means having no awareness of those visits, which is an issue when trying to get a global picture of your audience. Furthermore, the size benefits of switching to the reduced browser support are fairly limited: per bundlephobia, v4.2.3 is about 2.6KB, whereas the v5 RC is 2.2KB;  indeed smaller, but by only around 400 bytes or 15% (at least some of which may be due to other changes anyway, such as dropping FID). Don't get me wrong: it's a nice savings! But unfortunately dependants that need ES5 are left with a 1KB increase, rather than a 0.4KB decrease. And as far as I'm aware, things could get significantly worse still if syntax like async / await ever makes its way into the codebase.
As such, since we don't want to lose visibility on older browsers, our only options are to accept the bundle size increase (and the risk of it becoming even larger over time); or alternatively to fork and maintain a parallel web-vitals internally.
Would it be possible to reconsider the browser support decision?

Hey Sergio! 👋
Can you talk a bit more about what specific performance data your script is collecting from ES5-only browsers? None of the Core Web Vitals metrics are supported in any ES5-only browser, and the only metric exposed by the web-vitals library that is supported is TTFB, which we see as primarily valuable as a diagnostic of LCP.

I don't think our script is alone in trying to gather data from as many browsers as possible; having browsers in which your script breaks means having no awareness of those visits, which is an issue when trying to get a global picture of your audience.

I get the motivation to collect usage data from as many visitors as possible. I don't think that's the same use case as wanting to collect performance-specific data, in order to improve the experience for those users. I don't believe it's critical (nor is it possible) to do that for all users, which is why even in the initial release of web-vitals we recommended that folks load it using <script type="module">, to avoid requiring older browsers to download a script that couldn't really benefit those users.
I understand that if you want to bundle the web-vitals library into another analytics script you're serving—and you want that script to be able to run in ES5-only browsers—then that will require the entire script to be downleveled to ES5 syntax, which can incur a size penalty.
However, I'm sure you know that there are ways for site owners to mitigate that cost by conditionally serving only the ES5 syntax to ES5 browsers—and that's the approach recommend.
You could also potentially dynamically import the web-vitals script in a try/catch and only invoke the onXXX() functions if the load succeeds. That way you're reducing the total script load for those users.

Would it be possible to reconsider the browser support decision?

My position (as I've written about recently) is that it should be up to site owners to make browser support decision, rather than JavaScript library authors. I fully acknowledge your specific desire to support ES5 browsers, but this is not something that all site owners need, and we do not want to impose additional, unnecessary code on users who do not need it.
Of course there are trade offs here, but we believe it's in the best interest of the web ecosystem to keep pushing forward, and we don't think we're pushing too early.

Can you talk a bit more about what specific performance data your script is collecting from ES5-only browsers? None of the Core Web Vitals metrics are supported in any ES5-only browser, and the only metric exposed by the web-vitals library that is supported is TTFB, which we see as primarily valuable as a diagnostic of LCP.

Of course, happy to provide some more details!
Our goal is to have a single, small script that collects various kinds of performance data, together with other data such as UA string and URL path, as well as other service-level info, in order to enable aggregating performance data in various useful ways.
The data includes:

CWV metrics (including the web-vitals-reported TTFB)
Navigating Timing metrics
A boolean indicating whether the page was served from our edge cache
A boolean indicating whether the visitor was signed in (relevant because of caching concerns)
ECT, downlink, and estimated RTT
Origin and path
Which of our "providers", and which of our "services" served the request (to distinguish between different systems and sub-systems)

ES5-only browsers are generally only expected to report the Navigation Timing data, which is useful on its own for network and server performance analysis; but even if they didn't, just having an awareness of these page visits, as well as the URL, origin, and system that they're hitting, is incredibly helpful in getting an idea of what we don't know. Having a conspicuous hole in the performance data is valuable in and of itself, so we need a mechanism to make that hole as visible and measurable as possible.

I get the motivation to collect usage data from as many visitors as possible. I don't think that's the same use case as wanting to collect performance-specific data, in order to improve the experience for those users.

I wasn't too clear above, so I apologise for the misunderstanding. The data we're collecting is all performance-focused, consisting of either performance metrics or other markers that help us aggregate that performance data in different ways. This system doesn't handle general analytics aspects at all.
It's certainly possible to split the data collection into two scripts (or one script and one server-side logger), but that means either dropping the service-level data and losing the ability to aggregate in that way; or alternatively, duplicating that data collection between the two systems and finding mechanisms for cross-referencing the data across both systems to avoid duplicates.
Having a single, standalone script is incredibly simpler and has been a fairly robust approach so far, which is why we're inclined to continue pursuing it.

I don't believe it's critical (nor is it possible) to do that for all users

The main goal isn't to gather all performance data for all users; we know that's impossible, so we try to get just as much as is possible. It's better to know TTFB, Navigation Timing info, and whether the request hit the edge cache, than to know nothing at all — or worse, to be unaware of the visit.
And for that, the main thing we need to ensure is that the script does not fail during parsing. As I'm sure you're aware, it's impossible to defend against unsupported syntax, since parsing happens before execution; which means short of using eval and potentially causing CSP violations, there's no way for a script to guard against its own syntax being unsupported.

which is why even in the initial release of web-vitals we recommended that folks load it using <script type="module">, to avoid requiring older browsers to download a script that couldn't really benefit those users.

There are a few issues with using this approach for differential script loading.
First of all, module scripts come with additional restrictions, particularly around cross-origin concerns. Using a module script would mean moving to serving them in-origin, or alternatively setting up CORS headers for the common origin that currently serves them. Not an insurmountable challenge by any means, but a difficult one to justify on an otherwise working system.
But more importantly, the module / nomodule approach to differential builds is fixed to a particular point in time, which grows increasingly irrelevant as time goes by. It would certainly solve the ES5 issue, yes, but as more and more supported syntax makes its way into the Baseline Widely Available profile and inevitably web-vitals, so too would more and more syntax need to be transpiled to match the module support line in the sand — which I believe is already approximately 4 years old?
Which means that while it would mostly solve our issue now, we would likely end up with similar issues soon enough, given that our transpilation would by necessity be fixed to an immutable profile, while web-vital's would be a moving target in a constantly evolving platform.

I understand that if you want to bundle the web-vitals library into another analytics script you're serving—and you want that script to be able to run in ES5-only browsers—then that will require the entire script to be downleveled to ES5 syntax, which can incur a size penalty.

Again, I wouldn't call it an analytics script; it's entirely performance-focused. Sorry for the confusion. Other than that, yes, that is a correct summary.

However, I'm sure you know that there are ways for site owners to mitigate that cost by conditionally serving only the ES5 syntax to ES5 browsers—and that's the approach recommend.

Unfortunately, in our experience there aren't any good primitives on the web for client-side differential script loading.
I'm sure we agree that the server-side UA-based approaches are fundamentally flawed, so I won't go into detail there.
As for client-side, the module / nomodule approach has the issues I mentioned above.
Other approaches are theoretically possible, but extremely high-maintenance in practice. We could, for example, have a build that matches web-vitals's browser support (Baseline Widely Available), and another one for older browsers than that. In theory, we'd have a preliminary script that checks whether the browser supports Baseline Widely Available, and depending on the result of that check dynamically loads the appropriate script.
However, what exactly would that check be? We can't check for syntax because of the aforementioned reasons (unsupported syntax fails during parsing, and eval often runs afoul of CSP), so we'd need to look for web features that correlate to syntax support instead (e.g. whether something like Array.prototype.flatMap is present). This would mean handcrafting new checks whenever new syntax makes its way into the Baseline Widely Available (or at least into web-vitals), bearing in mind that different browsers adopt new syntax at different times and in different orders.

You could also potentially dynamically import the web-vitals script in a try/catch and only invoke the onXXX() functions if the load succeeds. That way you're reducing the total script load for those users.

There are two mechanisms that you could be referring to here: either real, browser-level dynamic import; or a more classic dynamic import that's implemented through some sort of bundler-provided or custom-coded helper. I'll cover both, since I don't know which one you were referring to.
For the former (real browser import), a try/catch could work as a mechanism for statically identifying browsers without dynamic import support, since in theory they'll complain about import being undefined (even though import is a syntax construct, not an actual function, but of course they don't know that). I'd have to double-check, but I'd expect it to work, yes. However, it wouldn't work as the actual loading mechanism because of the cross-origin concerns I mentioned before. Additionally, a separate mechanism (such as transpilation) would be needed to handle any syntax that falls between dynamic import() support and Baseline Widely Available anyway — a gulf that again, will only grow over time.
As for the latter ("fake" dynamic import via helpers), it would be worth testing. It would have to be callback-based, of course, not a static try-catch, but assuming that the script's error handler is fired and makes its way to a callback somehow (even in a cross-origin context), it could serve as a signal to try loading the other script instead. I'm concerned about the potential fragility, and whether the build system can successfully be massaged to produce such a configuration, but it's worth a try if there are no better options.

My position (as I've written about recently) is that it should be up to site owners to make browser support decision, rather than JavaScript library authors. I fully acknowledge your specific desire to support ES5 browsers, but this is not something that all site owners need
Of course there are trade offs here, but we believe it's in the best interest of the web ecosystem to keep pushing forward, and we don't think we're pushing too early.

I would agree in principle if we had a differential loading mechanism to match this, but the unfortunate reality is that we don't.
Even in a same-origin scenario, module / nomodule is only useful to decide between two sides of an immutable, arbitrary line in the sand that only grows more distant and irrelevant as time goes by. So while the argument can be made for module / nomodule being sufficient for ES5 vs ES2015, that reasoning cannot be extended to any later thresholds, particularly moving ones.
"Baseline Widely Available" is a build-time concept that to my knowledge has no feasible runtime differential loading mechanism other than "try loading the modern script and if it fails, load the other one" 😕

we do not want to impose additional, unnecessary code on users who do not need it.

Supporting easy transpilation to ES5 does not mean having additional, unnecessary code; just a different coding approach in the library. The only reason why the v5 RC requires additional transpilation helpers when compared to v4 is that existing, working code was replaced with newer syntax (such as for ... of) that essentially does the same thing.
It should be possible to keep building web-vitals in a similar way as before, i.e., in a way that would result in minimal helpers being needed when transpiling — ES5 is valid ES2015+, after all!
Believe me, I do understand the desire to adopt simpler, terser, and in many ways clearer syntax, and not being stuck to a minimum common denominator forever! However, using newer syntax is not an inevitability, and in some cases it makes sense to put in the effort so that transpilation is minimal (e.g. const or let), rather than verbose (for ... of), or incredibly verbose (async / await).
In our RUM script, that choice seems obvious for all of the aforementioned reasons. We imagine we're not alone in this, and that it would be beneficial to web-vitals to easily enable these use-cases without differential loading workarounds, but perhaps we're extrapolating our needs too much? 🙂

Follow-up: as an experiment, I pulled web-vitals v5 into our source tree, and modified it to avoid needing large transpilation helpers. At least in our case (we don't use all of web-vitals, e.g. attribution), and at least for now, the only changes that were required were moving from for ... of back to .forEach, and from object spreads back to Object.assign.
With those changes in place, the bundle size is effectively identical to using v4, at only 40 bytes difference.

Glad to hear you found have a workable solution!
For some additional context, the switch to using Baseline Widely Available is part of a larger change that we're standardizing on for all open source projects within Chrome, so we're unlikely to make an exception here just for web-vitals.
While I totally understand the arguments you're making in your reply (and why it would be easier for you if web-vitals continued to support ES5), ultimately we think the question of browser support should be a decision that individual sites make, as they're the ones who have the most information about their user base.

It's unfortunate we'll have to maintain a fork just to replace the usage of some transpilation-heavy syntactic sugar, but I understand the reasoning behind your approach. Thank you for considering the request!

Thank you for your testing, @tunetheweb, that's really useful info!

Hi @sgomes , Just to let you know I did some more testing on this that might be of interest to you.
For a start for for...of seems to be very well supported. The latest browsers to support this to seem to be Edge 12 ands Samsung Internet in 2015. So maybe it's not as important to polyfill that?

Yes, support is indeed very good, with IE and 10-year-old versions of modern browsers as the only things left without support. According to caniuse, this means that nearly 98% of tracked users use browsers that support this.
That said, in order to collect this sort of data (which we would like to, for each site we host), we need to be very conservative. A script that fails when parsing won't beacon, which means we're not aware of that visit, and so users of older browsers would become invisible.
Granted, we need to draw the line somewhere — we won't be supporting ES3, after all! So for..of support could potentially be the line in the sand, yes, assuming no other blockers.

The most recent syntax we have used that is maybe less well supported is Array.prototype.at which only gained Safari support in 2022, however testing it on older Safari browsers this is not an issue, as they also don't support the metrics that use that syntax (FCP, LCP, CLS, and INP) and testing proves it doesn't stop importing and compiling the bundle for those browsers so this is a non-issue for Safari browsers.
Chrome 60-92 (released July 2021) does support FCP, but not Array.prototype.at which will cause a runtime error when that callback is fired for those browsers, but the rest of the module will continue to run fine, so yes you will miss out on those metrics for those browsers, and you will see errors in console (and any monitoring that collects those errors) but, all in all, I expect those browsers to be rarely used nowadays.

Right, we're not as concerned with things like Array.prototype.at, because as you mention it's easy to polyfill without large helpers. And since it's not new syntax, but rather new methods, it won't break when parsing anyway. Which means that we wouldn't have to account for it in web-vitals, if we don't expect the library to ever reach those codepaths in older browsers anyway.

This leaves optional chaining and nullish coalescing as the main changes that may cause problems on older browsers (< March 2020) but those are less expensive to transpile if support is really needed for them. It is our opinion that support by default is not needed for those, but we're sure some developers will have use cases that diffs from that.

Yes, optional chaining and nullish coalescing are generally not a problem at all. I don't think I've ever seen a helper for any of them; they just generate a little bit of extra inline syntax.
However, object spreads ({ ... foo }) also need some largeish helpers, and a few were added in v5 to replace usage of Object.assign.

So the situation may not be as bad as first assumed, and why we are comfortable making this decision. That is not to say we won't use any of this new syntax on metrics that may be supported by older browsers in the future (like TTFB)—and I take your point that the only way to be certain here is to transpile syntax just in case any unsupported syntax used—but I thought you might find these findings interesting.

They are, yes, thank you!
I guess my concern is partly current and partly forward-looking, since Baseline Widely Available will keep moving forward, and already includes syntax that requires some substantially larger helpers if it ever lands in web-vitals, such as async / await.
So, effectively, the only way to guarantee we wouldn't end up with large transpilation helpers without maintaining a fork of web-vitals would be to adopt Baseline Widely Available ourselves, which is a much smaller set of users than we'd like when considering e.g. users stuck on Chrome 109 due to dropped OS support.

Oh good point about spread operators, but again this looks to have very good support.
I totally get your concerns, but as you say a line should be drawn somewhere and good to know there is agreement on that, even if there is not exact agreement on where that line should be drawn! And yes the aim is to have this line continually move forward as usage does too which will certainly mean losing support of older browsers on a continual basis (though for our use case, it's questionable whether the metrics collected from them are that useful since they lack bug fixes and improvements to those metrics).
For your fully use case (outside of just these specific web performance metrics), I wonder if this needs some sort if different thinking here to support the (small) subset of older browsers to still allow knowing about them, but without holding back the newer browsers. For example:

A lighter script for very basic beaconing (which then maybe loads the fully script and allows that to fail in some browsers)? - Or server side logging of an image pixel, for that?

Anyway, will let you ponder that. Good discussion.

Anyway, will let you ponder that. Good discussion.

Indeed, thank you for continuing the discussion!
Ultimately, for us, I think it comes down to whether it's easier to keep a single-script architecture while maintaining a fork of web-vitals; or whether it's better instead to create a two-tier reporting architecture, either with two scripts, or a script + a pixel, as you mention.
There's also the fact that this is a script we're adding to client sites, so we'd rather avoid it failing in the first place. We'd prefer it not to not appear as a potential source of problems, and accidentally mislead anyone debugging a legitimate issue. That again comes down to usage numbers.
For now, at least, it seems that maintaining an internal fork is easier, by staying on top of new web-vitals releases and porting changes over. Perhaps one day we'll be forced to reconsider 🙂


Improve targeted tests

It'd be nice to be able to say <<scala.Int>> instead of scala.<<Int>> and then navigating to the parent.
Currently, this is blocked by the fact that the second parameter of targeted (the lambda expression) takes parameters of type Name. We can probably work around that by judicious use of whitebox macros.

Recently, we decided to limit the surface of our work to actionable items only - either bugs in existing code or feature requests that are warranted by the roadmap. This ticket is neither, so I'm going to close it.


Update hello-node example to use deployments

@johndmulhausen RE: using $ in preformatted console, Happy to remove it from all the commands here, but I'd like to come up with a consistent way of clearly delineating the command from the command output (outside the scope of this PR).  I have come across an example or 2 where it wasn't clear and I ended up trying to run the command output in the console.  The vagrant guide uses a couple different approaches to address this, which offers a side-by-side comparison.

I tend to agree with @pwittrock on the $s. There are several cases that it was unclear if it was a command I could run or not.

cc @janetkuo

+1 for using $s.

RE $: here is an example in the doc that I think may be confusing to the reader.  I find that it runs together a bit.  I would love to be able to shade command output differently with a shell-output directive or something.  Not necessary to solve as part of this PR.
gsutil ls # This is a command
gs://artifacts.<PROJECT_ID>.appspot.com/ # This is command output
gsutil rm -r gs://artifacts.<PROJECT_ID>.appspot.com/ # This is a command
Removing gs://artifacts.<PROJECT_ID>.appspot.com/... # This is command output

PTAL.  I believe I have addressed all comments.
Published at: http://pwittrock.github.io/docs/hellonode/

Realized http://pwittrock.github.io/docs/hellonode/ didn't have all of the updates, just pushed it.

Per an offline discussion, there are a few other changes that should be made either in this PR or as a follow up.

Add documentation explaining that this requires both client and server version of 1.2 with link to 1.1 branch documentation
Add documentation about how to get the old behavior (use generator)
Explain how to setup kubectl
Update the ui dashboard section to match what is shown in 1.2

The images also reference "Replication Controller" in the diagram  I am going to see if I can fix this.

Updated the image

RE: The ui
The old kubernetes-ui seems to be absent, and the new kubernetes-dashboard and unless I am missing something it looks like it still speaks replication controller.  This seems out of place given the example now just deals with replication controllers.  I am thinking we should simply omit it from this example.  Open to feedback on how we should generally reconcile the new dashboard with our deployment centric world.

PTAL

LGTM.
I still prefer using $. GKE docs and Docker docs and most of our docs use $. it's more clear and consistent to our users IMHO.

Open to feedback on how we should generally reconcile the new dashboard with our deployment centric world.

cc @bryk

I found a style guide that suggests using $ when the code section includes command output, and omitting it if there is no command output.  I am happy to change it in a follow up if we agree on a standard.

Open to feedback on how we should generally reconcile the new dashboard with our deployment centric world.

We'll be adding deployments, replica sets, and all the new stuff to the UI. We just didn't have time for this so far.
Until this happens, I'm for removing the UI part.
cc @kubernetes/dashboard-maintainers

SGTM, I will take care of that in an immediate follow up.

@bryk I can also add a dashboard section to hello-node once it has deployments + replicasets.

Thanks a ton for addressing the comments and chatting privately. :)


Revert "Merge pull request #101 from rdkcentral/development/async_net…

Reverting changes to Netlink, as it caused a deadlock when the network device was set up externally.
Synchronous flushing is done when the new network interface is set up, however, if blocks the ResourceMonitor thread, effectively blocking itself from getting a response. It needs to be rewritten in a fully asynchronous way before restoring changes.
As it is a critical problem on some platforms, revert is needed.

https://jenkins.code.rdkcentral.com/job/github-triggered/1330/ started


Error installing on OSX El Capitan

I am having issues installing tsne on El Capitan. I've tried using both the pypi source and the git version but get the same error:
pip install tsne
Collecting tsne
  Using cached tsne-0.1.1.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/private/var/folders/1j/l25m3sbs51gbfpynfwny1xvc0000gn/T/pip-build-LDFM7r/tsne/setup.py", line 15, in <module>
        v1, v2, v3 = [float(val) for val in v.split('.')]
    ValueError: need more than 2 values to unpack

any ideas how to fix this?

Thanks for the report.
Should be fixed on https://github.com/danielfrg/tsne/commit/b6188b49b202fe9c168d0434f12f34f3832f0150. New v0.1.2 is on pypi now: https://pypi.python.org/pypi/tsne
Let me know if you are able to test and if it worked or not.

Thanks for quickly looking at this @danielfrg. So now, it gets past the requirement checks and fails during the installation (build). The new error which pops up now when i install directly from the git repo:
running install
    running build
    running build_py
    creating build
    creating build/lib.macosx-10.5-x86_64-2.7
    creating build/lib.macosx-10.5-x86_64-2.7/tsne
    copying tsne/__init__.py -> build/lib.macosx-10.5-x86_64-2.7/tsne
    copying tsne/_version.py -> build/lib.macosx-10.5-x86_64-2.7/tsne
    UPDATING build/lib.macosx-10.5-x86_64-2.7/tsne/_version.py
    set build/lib.macosx-10.5-x86_64-2.7/tsne/_version.py to 'v0.1.2'
    running build_ext
    building 'bh_sne' extension
    error: unknown file type '.pyx' (from 'tsne/bh_sne.pyx')

i tried renaming the file bh_sne.pyx to bh_sne.py but that didn't work.

What python are you using? from homebrew? Do you have cython installed? I would recommend anaconda it just worked for me on a new env with this dependencies: https://github.com/danielfrg/tsne/blob/master/environment.yml

I created a new environment with the dependencies in your .yml and that works fine (when installed from the git repo). Thanks so much! I was probably missing some dependency.
I should mention though that the pypi version still throws an error about versioneer even though it's installed:
Collecting tsne
  Using cached tsne-0.1.2.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/private/var/folders/1j/l25m3sbs51gbfpynfwny1xvc0000gn/T/pip-build-_r263k/tsne/setup.py", line 9, in <module>
        import versioneer
    ImportError: No module named versioneer

I just fixed the versioneer bug and you should be able to pip install it.
Closing since the issue was fixed.
Thanks!


Download of suppression files with authorization header

Is your feature request related to a problem? Please describe.
We are keeping some of our suppression files in our company internal on-premise version control system, and so far have been using simple URLs for referencing and downloading them during the analysis. This is possible as long as the repository allows public access.
For security reasons we would like to disable all public access even to our internal repositories, though. At the moment it is possible to achieve a retrieval of a suppression file even in that case using username and password, but managing a complete user with credentials is cumbersome just for retrieval of a suppression file.
Our version control system offers the creation of access tokens for repositories, which can then be used in an authorization header to access repository content. This allows to create individual tokens per integration, which is also the recommended way.
Describe the solution you'd like
It would be nice if the utils for downloading suppression files (and the configuration they use) could support either an 'Authorization: Bearer' header or completely freely configurable extra-headers.
I may be able to implement this and create a pull-request if we can align on the functional solution.
Describe alternatives you've considered

using basic auth with username and password: possible already, but cumbersome in our case
encoding credentials into the URL somehow: unexpected and somewhat "hacky"

Additional context
(none)

I am okay with adding an option to use an authorization token. I wouldn't explicitly make it a bearer token - but allow the user to specify the value for the authorization header instead of only using the username/password. It would be great if you could create a PR or it might be a while before you see this implemented.

Thanks for the quick reply! I will try to make some time for it soon.

@jeremylong were you thinking of something like
<nvdAuthorizationHeader>Bearer eyJhbGciOiJIUzI1NiI...MDIySMeKKF2yJV_adQssw5c</nvdAuthorizationHeader>

or even <nvdAuthorizationHeader>Basic dGhlX3VzZXI6dGhlX3Bhc3N3b3Jk</nvdAuthorizationHeader> as an alternative to nvdUser and nvdPassword?
... and are you still interested by a PR to address this?


phone-number: Regenerate Tests

Update phone-number tests to: 1.6.0 a317aa4
Update generator to use the standard error indicator.
Update solution to pass updated tests.

@Insti changes are up for review 👍 Thank you for the discussion!

For reference the discussion is here: https://github.com/exercism/ruby/pull/870#pullrequestreview-162148552 you might need to "view outdated"

🎈


Reframe CLI, revise quickstart, and reorganize tutorials

This PR:

correctly frames the CLI's current state as a tutorial toy.
provides a friendlier quickstart that puts what it's doing into perspective and guides you to next steps.
provides a better sense of what each tutorial/quickstart doc is for.
removes outdated references to pycrypto in the installation steps.
makes the getting started page slightly more friendly.

The larger task this PR is part of is Issue #808.

Some more tasks:

[ ] CLI.md and CLI_EXAMPLES.md are really doing the same thing and should probably be merged into a single file: CLI_EXAMPLES.md.
[ ] adjust the mention of PyNaCl in TUTORIAL.md to refer to the replacement library

@awwad It's because cryptography manylinux1 wheel bundles its own copy of OpenSSL, unless you use something glib-c incompatible, like Alpine


Update how-to-move-regions.md (Typo "flexible server"→"Flexible Server")

https://github.com/MicrosoftDocs/azure-databases-docs/blob/main/articles/mysql/flexible-server/how-to-move-regions.md
#PingMSFTDocs

@VandhanaMehta - related #29


Mobile Account: Your Overview

Left:Build — Right:Design

[x] Make 'Total Account Value' and 'Profit and Loss (ETH)' 12px Bold Mono

[x] Check sizing and colour of type against design

[ ] centre Augur Logo

[x] check font size, weights and colour against design

[x] percentages for account value and P/L should be in brackets

[x] Spacing

@matt plz rvw

Closing and creating separate tickets for remaining issues


Refactor hipBLASLt documentation

Refactoring all libraries to adhere to the documentation standards that includes following home page format, index style, language improvements, link fixes, navigation, and overall content readability improvements.

@SwRaw  Please let me know once you would like to merge it.

installation.rst
This is messed up:

This seems wrong - two headings in a row without body text in between:

@lpaoletti Thanks for your review. The code blocks were not being rendered, that's why stacked headings. I should have noticed it earlier.  Fixed it and reviewed the doc again. Please take a quick look again and let me know if the PR is good to be merged.


Tag Cloud should display the tags which have the highest API count

Description:
The query which has been used to display dev portal tag cloud,  should be refactored by; first sorting the result by highest API count and then alphabetical order
Affected Product Version:
3.x.x

Close the issue as per the above commit


new module for node: auto-set PATH on prompt

This is sort of my first shell script.
Also, since this is small, I didn't bother reading the style guidelines, but I looked at an existing plugin's code.

After a few commits, this looks cleaner and works much faster. Fast enough for me on an old laptop.

This is very wrong. Use npm-run.


[TimePicker] allow set time to null

When i try to set time picker back to null it raises error getHours undefined in null so now i need to make custom hack:
  resetTime(){
    const emptyTime = new Date();
    emptyTime.setHours(0);
    emptyTime.setMinutes(0);
    emptyTime.setSeconds(0);
    emptyTime.setMilliseconds(0);

    this.refs.time.setState({
      time: emptyTime
    });
    this.refs.time.refs.input.setValue(null);
  }

I think that in the future, we should remove setTime for the API. I would rather add a controlled property: time (very similar to the uncontrolled one defaultTime) than pursuing changing this API.

props over methods any day, @oliviertassinari :+1:

@oliviertassinari Yeah, it'll be good. Alongside with respect of switches to null/undefined values in this prop :+1:

@oliviertassinari OK to merge?

:+1:

@qnub Thanks!


Update customer.py

Hello Jarvis Johnson I really liked you pizza order program!

This won't run.


Remove Azure as phase1 provider

Following the discussion in https://github.com/kubernetes/kubernetes-anywhere/issues/366. Removing Azure provider as it is already broken and is no longer used or maintained.
After this PR merged, it will be one step closer to move towards kubeadm based deployments and only vsphere will be using ignition phase2 provider.
/assign @pipejakob
/cc @luxas

/lgtm

Thanks!

Since https://github.com/kubernetes/kubernetes-anywhere/issues/366 has gone a week with no objections, merging.


Dart2JS Compiler Crash Error

D:\projectFolder\web>dart2js --out=main.dart.js main.dart
main.dart:
Internal Error: The compiler crashed when compiling this element.
The compiler is broken.
When compiling the above element, the compiler crashed. It is not
possible to tell if this is caused by a problem in your program or
not. Regardless, the compiler should not crash.
The Dart team would greatly appreciate if you would take a moment to
report this problem at http://dartbug.com/new.
Please include the following information:

the name and version of your operating system:  Windows 7 Enterprise, 64 Bit

the Dart SDK build number (1.11.1), and

the entire message you see here (including the full stack trace
below as well as the source location above).

The compiler crashed: Stack Overflow
#0      Compiler.run.<run_async_body> (file:///e:/b/build/slave/dart-sdk-windows
-stable/build/sdk/pkg/compiler/lib/src/apiimpl.dart)
#1      _asyncCatchHelper. (dart:core-patch/core_patch.dart:1
4)
#2      _RootZone.runBinary (dart:async/zone.dart:1171)
#3      _Future._propagateToListeners.handleError (dart:async/future_impl.dart:5
21)
#4      _Future._propagateToListeners (dart:async/future_impl.dart:580)
#5      _Future._completeWithValue (dart:async/future_impl.dart:368)
#6      _Future._asyncComplete. (dart:async/future_impl.dart:
422)
#7      _microtaskLoop (dart:async/schedule_microtask.dart:43)
#8      _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#9      _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#10     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dar
t:149)
#11     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#12     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dar
t:149)
#13     _Future._asyncComplete. (dart:async/future_impl.dart:
422)
#14     _microtaskLoop (dart:async/schedule_microtask.dart:43)
#15     _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#16     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#17     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dar
t:149)

Can you provide the dart file that cause the crash?

It's the main file for an entire project.  UIInteraction initializes a lot of different classes and objects for a web application.
But here's the main.dart file contents itself:
import 'UIInteraction.dart';
void main() {
UIInteraction init = new UIInteraction();
}

Is the project somewhere I can access?
On Wed, Aug 12, 2015, 11:54 AM curtis-robert<EMAIL_ADDRESS>wrote:

It's the main file for an entire project. UIInteraction initializes a lot
of different classes and objects for a web application.
But here's the main.dart file contents itself:
import 'UIInteraction.dart';
void main() {
UIInteraction init = new UIInteraction();
}
—
Reply to this email directly or view it on GitHub
https://github.com/dart-lang/sdk/issues/24057#issuecomment-130411036.

Alright, sorry about the delay.
I couldn't figure out how to upload the file here, so it's at this link, named "problemFile.DART":
https://sites.google.com/site/horizonmapdata/home
I've figured out that it is able to add a few of the <key, value> pairs to the Map, but at a certain point the Dart2JS conversion fails.  I say certain point because it's not the same point every time.  For example, the conversion works when I put a return statement at line 646, right before adding the key "Line31" to the the map, but then it doesn't if I remove the return statement (which makes it look like that key may be the problem).  However, if I comment out the adding of keys "Line16", "Line19", "Line22", "Line25", and "Line28", and then put the return statement after "Line31" it works.

You could try a couple of things:

Use a static initializer. This does less inlining, so it might be compiling a smaller function.

class MapOverlayDictionary {
	Map horizonCoordinates;

	MapOverlayDictionary() {
		initializeMap();
	}

	void initializeMap() {
		horizonCoordinates = _data;
    }

    static var _data = {
        "Bus1": [new LatLng(46.7545166, -122.865112),
			new LatLng(46.7545204, -122.864334),
			new LatLng(46.7536354, -122.864288),
			new LatLng(46.7534904, -122.864418),
			new LatLng(46.7534904, -122.864632),
			new LatLng(46.7536507, -122.864784),
			new LatLng(46.7541847, -122.864822),
			new LatLng(46.7542534, -122.864868),
			new LatLng(46.7544022, -122.865112),
			new LatLng(46.7545166, -122.865112)],
      "Bus2": [ ... ]
    };
}

Break it up into some local functions (which will not be inlined by the current compiler)

class MapOverlayDictionary {
	Map horizonCoordinates;

	MapOverlayDictionary() {
		initializeMap();
	}

    void initializeMap() {
      horizonCoordinates = new Map();
      part1() {
		horizonCoordinates["Bus1"] = [
			new LatLng(46.7545166, -122.865112),
			new LatLng(46.7545204, -122.864334),
			new LatLng(46.7536354, -122.864288),
			new LatLng(46.7534904, -122.864418),
			new LatLng(46.7534904, -122.864632),
			new LatLng(46.7536507, -122.864784),
			new LatLng(46.7541847, -122.864822),
			new LatLng(46.7542534, -122.864868),
			new LatLng(46.7544022, -122.865112),
			new LatLng(46.7545166, -122.865112)
		];
      }
      part2() { ... }
      ...

      part1();
      part2();
     ...
    }

I'm moving this to https://github.com/dart-lang/sdk/issues/24635 since I have added a test for this problem.


Inside Unity Editor, InputField moves when pressing the A,W,S, and D key

Describe the bug
MRTK3
In Scenes/InputFieldExamples pressing A,W,S,D moves the inputfield left,up,right,down inside Unity Editor.
To reproduce
Steps to reproduce the behavior:

In Unity Editor, Load InputFieldExamples Scene
Press Play
In the InputField press the keyboard key A, W, S , and D.

Expected behavior
Inside Unity Editor, When in Play mode, when you type the key A, W, S, D the input field should not move.
Screenshots
Video attached
Youtube
Your setup (please complete the following information)

Unity Version 2021.3.21f
MRTK 3 - updated to April 20, 2023 "Shayine 2021 Upgrade"

Target platform (please complete the following information)

HoloLens 2

Additional context
Issue appears to be related to Input Simulator prefab -> Camera Settings -> Simulation enabled. See video.

This does appear to be relate to MRTK3's camera/head simulation.  Thank you for the issue


Added ability to filter SQL query on property

This optimisation greatly decreases the query result returned from the database which the trove index reporter iterates through to come up with the final result.  This increases speed by four or five times.
@scoen @terenceingram @sjacob @yetti @shuangzhou @MingtaoSun

Looks good.


Allow follow log option (-f) in sparkctl

Currently we repeatedly run sparkctl log command to get the new log lines. It would be good to have -f option that shows the log as its updated.

This is now supported.


Downgrade to Bootstrap-3 & implement Settings

Issue: softbrew/phr-core#3

Downgrade because of lack of device support in Bootstrap-4 and in
Alpha version
Implement Settings with Bootstrap navbar

:+1:


Prevent per-node scheduling fallback during batch scheduling retry

Context
Currently, when a new job gets submitted, all the workers get scheduled in batch to have an all-or-nothing manner. However, the job actor heartbeat check will also try to re-schedule a worker if it's "stuck" in the allocation phase for too long (based on the worker-heartbeat-timeout config). Thus the batch scheduling gets invalidated after some timeout (which could be problematic for larger jobs when we need more time to get the requested resource allocated from the cluster auto scaler).
Behavior changes here:

Batch scheduling failure will retry without attempt limit. (We will rely on the cancel request message from its job actor to interrupt).
JobActor heartbeat routine will not act on unscheduled workers.
fixed the akka-tests and added these back to the CI build.

Checklist

[ ] ./gradlew build compiles code correctly
[ ] Added new tests where applicable
[ ] ./gradlew test passes all tests
[ ] Extended README or added javadocs where applicable

@fdc-ntflx ptal


scrapli_netconf_call fails when using QueueRunner

When trying to use scrapli_netconf_call while using the QueueRunner fails to work.
If i change my runner back to RetryRunner connections work as expected.
Below is the traceback when using QueueRunner;
get_config:
            Traceback (most recent call last):
              File "/opt/salt/venv/lib/python3.9/site-packages/nornir/core/task.py", line 99, in start
                r = self.task(self, **self.params)
              File "/opt/salt/venv/lib/python3.9/site-packages/nornir_salt/plugins/tasks/scrapli_netconf_call.py", line 232, in scrapli_netconf_call
                result = getattr(conn, call)(*args, **kwargs)
            TypeError: get_config() got an unexpected keyword argument 'connection_name'

This should be fixed starting with 0.10.1 release.


Verla -Missing company LOGO and the MESSAGE "Bucuresti, Cluj-Napoca, Iasi is not a city in Romania" is displayed instead of the job locations

ENVIRONMENT: production
URL: https://scrapers.peviitor.ro/
Browser: Chrome
Device: Laptop
OS: Windows 10
STEPS TO REPRODUCE:
1.Open the URL in the browser
2.Search for the company "Verla"
3.Check the logo.
4.Open "Run Scrapers" button
5.Check the job locations.
EXPECTED RESULTS:
The " Verla Company" logo is there and is functional.
Job locations should be the same on Scrapers-UI as on the company website.
ACTUAL RESULTS:
Error LOGO on the scrapers.peviitor.ro
The message "Bucuresti, Cluj-Napoca, Iasi is not a city in Romania" is displayed instead of the job locations
ATTACHMENTS:

Fixed job cities
Verla logo link not set in html in scrapers-ui, moving bug to scrapers-ui


Fix node name visibility

Fixes #7259
Node label (and output port in general) used to depend on view-mode logic, which is currently not fully functional. Since we have removed profiling mode from the application, It's best to remove some remaining parts of it to avoid them from interfering.
Labels now work as they used to, being shown on hover or when ctrl is held down.

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

Labels now work as they used to, being shown on hover or when ctrl is held down.

Are they displayed also when CB is opened? They should.

Are they displayed also when CB is opened? They should.
Yes. When editing an existing node, the label is visible. For new nodes, the name is not set yet so there is no label.

@mwu-tow Could you force-merge it? It's an important fix, and we're experiencing random CI failures.

@mwu-tow Could you force-merge it? It's an important fix, and we're experiencing random CI failures.

done


make run-renode fails with verilator error

When I try to use run-renode like this:
$ scripts/setup
$ . environment
$ cd proj/proj_template
$ make run-renode

It fails with the following message.
(monitor) s @digilent_arty.resc
There was an error executing command 'machine LoadPlatformDescription @/home/avg/src/CFU-Playground/proj/proj_template/build/renode/digilent_arty.repl'
Error E04: Could not resolve type: 'Verilated.CFUVerilatedPeripheral'.
At /home/avg/src/CFU-Playground/proj/proj_template/build/renode/digilent_arty.repl:24:7:
cfu0: Verilated.CFUVerilatedPeripheral @ cpu 0
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(digilent_arty)  uart_connect sysbus.uart
Peripheral sysbus.uart not found or not an IUART.
Command uart_connect failed, returning "1".
(digilent_arty)
(digilent_arty)

Is it possible that I have misconfigured something?

It might be worth deleting third_party/renode and rerunning ./scripts/setup to get the latest renode, just to eliminate that possibility.


Feature Request - PI Extraction Tracking

Hey Erik,
It would be incredible if PI was able to be tracked using this desktop app. Whether that's actively tracking the timer on an extraction via ESI, or if it can somehow see how long an extraction is set for and set some kind of internal clock/alarm.
I understand that it's unlikely there are any standard eve ESI notifications for PI, but have seen something like this done via the browser before. Not sure how that person managed it, but moving it from a browser based function into a desktop application that lives in the background would be awesome.

I took a quick look at ESI and it seams like it would not be possible to calculate any kind of timers from the provided data.
Can you maybe provide me more information about the website you mentions, so I can maybe find out more about how that works?
I still plan to add the list of owned colonies though, which is what you can get from the ESI.
See also #5

Hey Erik,
The website is https://planetsin.space/
Excellent!

I have implemented your feature request. Would very much appreciate your feedback if you get the change to check it out.


Pandora STM32L475: Vendor is not correct

Describe the bug
Pandora board was introduced in https://github.com/zephyrproject-rtos/zephyr/pull/55577
It has been documented with ST as vendor. This is not correct as vendor is Alientek. This should be updated

fixed via #59460. Thanks @supperthomas!


Add reboot caveat to wireshark-chmodbpf cask

A reboot is required before an admin user is able to access a BPF device.

I added it to make the output more readable.
So that we get:
This cask will install only the ChmodBPF package from the current Wireshark
stable install package.
An access_bpf group will be created and its members allowed access to BPF
devices at boot to allow unpriviledged packet captures.
This cask is not required if installing the Wireshark cask. It is meant to
support Wireshark installed from homebrew or other cases where unpriviledged
access to macOS packet capture devices is desired without installing the binary
distribution of Wireshark.

The user account used to install this cask will be added to the access_bpf
group automatically.

You must reboot for the installation of wireshark-chmodbpf to take effect.

Instead of:
This cask will install only the ChmodBPF package from the current Wireshark
stable install package.
An access_bpf group will be created and its members allowed access to BPF
devices at boot to allow unpriviledged packet captures.
This cask is not required if installing the Wireshark cask. It is meant to
support Wireshark installed from homebrew or other cases where unpriviledged
access to macOS packet capture devices is desired without installing the binary
distribution of Wireshark.

The user account used to install this cask will be added to the access_bpf
group automatically.
You must reboot for the installation of wireshark-chmodbpf to take effect.


Support linux/arm64/v8 Apple Silicon docker architecture

Currently, if you start ghcr.io/goccy/bigquery-emulator:0.4.3 docker will write a warning.
➜  ~  docker run --rm -i -t -d ghcr.io/goccy/bigquery-emulator:0.4.3 --project=test
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
b51e130c41d14c3ef4eb0f2864512f44edad39d847994cf2bd5421bba5758581

I have already written about how to deal with it here, have you already tried it?
https://github.com/goccy/bigquery-emulator#how-to-start-the-standalone-server

If you are using an M1 Mac ( and Docker Desktop ) you may get a warning. In that case please use --platform linux/x86_64 option.

Thank you.
But unfortunately, this warning also appears inside test-containers. It would be better if the docker image for Apple Silicon architecture will be published as well.

This flag (--platform) won't do anything if it's not multi-platform docker image. Image needs to be built for both platforms.

Thank you. But unfortunately, this warning also appears inside test-containers. It would be better if the docker image for Apple Silicon architecture will be published as well.

Actually, at least for me given my Docker Desktop installation on an Apple Silicon Mac and use of testcontainers-hs, it isn't just a warning: I get an exception specifically about the fact there's no arm64/v8 image.

@paul-snively I have the same problem. Did you manage to solve it?

Yes. The package is published on my fork.Sent from my iPhoneOn May 15, 2024, at 11:26 AM, MaiElshiashi @.***> wrote:
@paul-snively I have the same problem. Did you manage to solve it?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Stop after "Task exception"

System Health details
System Information

version
core-2024.1.3

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.11.6

os_name
Linux

os_version
6.1.71-haos

arch
x86_64

timezone
Europe/Berlin

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4996

Installed Version
1.33.0

Stage
running

Available Repositories
1458

Downloaded Repositories
65

HACS Data
ok

AccuWeather

can_reach_server
ok

remaining_requests
21

Home Assistant Cloud

logged_in
true

subscription_expiration
16. September 2024 um 02:00

relayer_connected
true

relayer_region
eu-central-1

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
false

remote_server
eu-central-1-10.ui.nabu.casa

certificate_status
ready

instance_id
a7fe12d5565c4109a7dc2704cdd5220b

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Discovergy

api_endpoint_reachable
ok

Home Assistant Supervisor

host_os
Home Assistant OS 11.4

update_channel
stable

supervisor_version
supervisor-2023.12.1

agent_version
1.6.0

docker_version
24.0.7

disk_total
48.5 GB

disk_used
32.7 GB

healthy
true

supported
true

board
ova

supervisor_api
ok

version_api
ok

installed_addons
Advanced SSH & Web Terminal (17.0.4), Samba share (12.2.0), Mosquitto broker (6.4.0), Node-RED (17.0.3), Samba Backup (5.2.0), File editor (5.7.0), ioBroker (0.8.0), ESPHome (2023.12.5), Signal Messenger (0.80.0), Matter Server (5.0.3), Music Assistant BETA (2.0.0b82), Speedtest (1.5.0), Piper (1.4.0), Whisper (1.0.2), Studio Code Server (5.15.0), PSA Car Controller (v3.3.2), MQTT Explorer (browser-1.0.3), openWakeWord (1.8.2), NGINX Home Assistant SSL proxy (3.7.0)

Dashboards

dashboards
9

resources
38

views
56

mode
storage

Recorder

oldest_recorder_run
9. Januar 2024 um 19:03

current_recorder_run
19. Januar 2024 um 09:15

estimated_db_size
5704.94 MiB

database_engine
mysql

database_version
10.11.3

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
I sometimes get the below mentioned error and then the integration is not useable anymore, no updates anymore. I need to reload the integration to receive data.
Reproduction steps

I don't know

Debug logs
Logger: homeassistant
Source: custom_components/gruenbeck_cloud/coordinator.py:66
Integration: Grünbeck Cloud (documentation, issues)
First occurred: 09:52:58 (1 occurrences)
Last logged: 09:52:58

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/config/custom_components/gruenbeck_cloud/coordinator.py", line 66, in listen
    await self.api.listen(callback=self.async_set_updated_data)
  File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 780, in listen
    await self.refresh_sd()
  File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 599, in refresh_sd
    await self._http_request(
  File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 680, in _http_request
    raise PyGruenbeckCloudResponseStatusError(error)
pygruenbeck_cloud.exceptions.PyGruenbeckCloudResponseStatusError: Response status code for https://prod-eu-gruenbeck-api.azurewebsites.net/api/devices/softliQ.D/BS40008472/realtime/refresh?api-version=2020-08-03 is 500, we expected 202.

Diagnostics dump
No response

Same
`Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht
Logger: homeassistant
Source: custom_components/gruenbeck_cloud/coordinator.py:66
Integration: Grünbeck Cloud (documentation, issues)
First occurred: 16:00:25 (1 occurrences)
Last logged: 16:00:25
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/gruenbeck_cloud/coordinator.py", line 66, in listen
await self.api.listen(callback=self.async_set_updated_data)
File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 780, in listen
await self.refresh_sd()
File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 599, in refresh_sd
await self._http_request(
File "/usr/local/lib/python3.11/site-packages/pygruenbeck_cloud/pygruenbeck_cloud.py", line 680, in _http_request
raise PyGruenbeckCloudResponseStatusError(error)
pygruenbeck_cloud.exceptions.PyGruenbeckCloudResponseStatusError: Response status code for https://prod-eu-gruenbeck-api.azurewebsites.net/api/devices/softliQ.D/BS50020597/realtime/refresh?api-version=2020-08-03 is 500, we expected 202.
`
`Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht
Logger: custom_components.gruenbeck_cloud.coordinator
Source: custom_components/gruenbeck_cloud/coordinator.py:66
Integration: Grünbeck Cloud (documentation, issues)
First occurred: 16:00:25 (1 occurrences)
Last logged: 16:00:25
Response status code for https://prod-eu-gruenbeck-api.azurewebsites.net/api/devices/softliQ.D/BS50020597/realtime/refresh?api-version=2020-08-03 is 500, we expected 202.`


Support to host on heroku directly

Checkout the following feature:
https://devcenter.heroku.com/articles/heroku-button

Closed via #49


TC Health Client uses TM's /api/cache-statuses API which does not participate in the health protocol

This Bug Report affects these Traffic Control components:

Traffic Control Health Client (t3c-health-client)

Current behavior:

The TC Health Client uses TM's /api/cache-statuses API for getting cache availability states in order to mark caches up/down. This is very dangerous because this API returns the TM's local cache states rather than the combined cache states of itself and its peers using the optimistic health protocol. Using this API, the TC health client will set caches down when only the single requested TM thinks they're down. However, if that singular TM is on a network partition and can't reach those caches because of it, it will mark those caches down even though they might be perfectly reachable by its peers (and the broader client base).
Expected behavior:

The TC Health Client should use TM's /publish/CrStates API for getting cache availability states. This API returns the combined cache states of itself and its peers participating in the optimistic health protocol, and this API is what Traffic Router actually uses for routing clients to available caches.
In addition to the dangers of using TM's local cache states, /api/cache-statuses includes a lot of unnecessary data that the tc-health-client doesn't really need, whereas /publish/CrStates is simply just cache availability. We also shouldn't have Traffic Router and the tc-health-client using different APIs for getting cache states from TM.
Steps to reproduce:

Disconnect a TM from the cache network or otherwise make it unable to reach one or more caches. Request /api/cache-statuses and /publish/CrStates and compare the results. As long as a cache is reachable and otherwise healthy, the other peers will consider it available, so the caches will be available in /publish/CrStates but not in /api/cache-statuses.

This is in progress but publish/CrStates does not give any context around unhealthy caches, see #6448.  For now will leave out the status logging information.


BackendTLSPolicy: Add CEL Tests

What would you like to be added:
Tests to ensure the CEL validation added in #2448 is working as expected.
Why this is needed:
All other CEL validations have corresponding go tests in https://github.com/kubernetes-sigs/gateway-api/tree/main/pkg/test/cel. Without it, it's awfully hard to ensure that the CEL we've written covers all the inputs we want to allow or prevent.

I'm going to look into it, as I believe iI have hit a problem with the rules


KQL syntax for auto applied retention label

Trying to come up with the best filter for auto retention to be set with.
What will be the best way to auto apply retention on a SharePoint site to not include non end user working data? files in site assets or style library etc.
I'm trying to just target documents, any files within working libraries and list items which may include attachments.
(ContentType:'Document' OR ContentType:'Item') AND -FileType:aspx
Above returns items like site icon, associated page design files etc.
Using IsDocument:1 clause does not return list items and also skips files stored in working libraries.
Can I restrict locations that are used in an sp site by default?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8a4716f6-31db-306c-2804-56591e3af7e6
Version Independent ID: 8dfc13ff-3b6a-ba25-2911-db7a3dcd2e8a
Content: Automatically apply a retention label to retain or delete content - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/apply-retention-labels-automatically.md
Service: o365-seccomp
GitHub Login: @cabailey
Microsoft Alias: cabailey

@cabailey Please help us in resolving this issue. Thanks.

@mishmishilicous  Checking, but by default, system files won't be retained so I don't think you need to worry about the query excluding these.  Is there a reason why you're using an auto-apply label here rather than a retention policy for the site, or apply the label as a default label if you want to apply the same retention settings to all documents in the site?

@cabailey, I'm using an auto applied label for newly added content to ensure initial retention is set.
Later on content is labeled by end users with other provisioned labels thru the UI later in the life cycle.
When I open the site assets library I can see the label shows up on system files which makes sense since the content type is a match ("Document"). I've created the label and associated it into a retention policy. In the policy I list the sites I'm interested in for this auto applied label. I'm not sure what you meant by "rather than a retention policy for the site".
Regarding the second part of your answer, "apply the label as a default label..", Do you mean in specific locations like libraries (via library settings) is so, this is not answering the requirement I have.
The requirement is to ensure an initial retention is set. Users later on work and collaborate with the data. At a certain point the user will choose an appropriate label to set an accurate retention is set.
With that being said, I need to find a way to ensure that initial retention is set documents (ContentType:'Document'), list items (ContentType:'Item') including attachments and miscellaneous files that are stored within a library (like zip or what not).

We took this offline so closing this GitHub Issue. But in summary, we determined the best workaround for your scenario was to exclude files you didn't want to retain in the Site Assets library and other default document libraries by using a KQL query such as NOT(DocumentLink:"")  You're going to follow up with your TAM to file a DCR for a neater solution and I'll look to clarify in the docs exactly what is and isn't retained/deleted by default.


Added Japanese translation

Thanks a lot! I'll merge it into the next release.

Merged into staging.


MM-37128 Detox/E2E Maintenance: Fix failing tests - iOS

Summary

These are maintenance fixes. Ran the suite and fixed failing tests found locally.
Moved detox/e2e/support/utils.js to detox/e2e/support/utils/index.js
Added email utils

detox/e2e/support/utils/email.js

Note: Will run the suite against android and will create a separate PR for that.
Ticket Link
JIRA tickets:

https://mattermost.atlassian.net/browse/MM-37128

Screenshots

Release Note
NONE

What are these email templates? And how does it affect the mobile app?

Those are use to verify correct email notifications. We have it on Webapp/Cypress as well.

And how does it affect the mobile app? Mobile has nothing to do with emails, so I need more information about this

See MM-T3256 for one example of test criteria where email notifications in Mobile app is being set to immediately and never. When set to immediately, we need to have a way to verify that the actual email is received and has expected content (since there could be other email message too). If set to never, then no email notification should have been sent. Without those email templates, the verification would not be complete if we'll only rely on mobile UI indication.

@saturninoabril that is exactly the context I needed!! Love it, thank you


Add unique frames for thought bubbles

Thought bubbles such as when you examine inanimate object should have a unique set of thought bubble frames, not the round speech bubble frames.

Closing due to removal of freeroam mode (#1257)


we can change the background color to more interesting

i have some thing special for this . hope you understand and assign me this issue i will happy to  work with you

sure @codewithnadeem14502 start working on this.

thank you


Parallel mavlink logging for LMC

Flight logging via Mavlink changes to transfer static definitions in parallel with topic data to avoid several seconds long blackout period in the beginning of the log.
This requires PARALLEL_LOGGING support also from receiver end (e.g. mavlink-router).

LGTM, only question I have is, if we truly need another linked list implementation embedded in here; I didn't deep dive into it just looks peculiar as there are plenty of implementations already all around px4....

That is a valid point. Need to check if there is any common impl available to use for that.

Re-used linked list implementation from src/include/containers/List.hpp. Looks smoother now.
Functionality verified with SingleSocSaluki HITL env


Potential difference in client and shotover load balancing behaviours with Redis cluster

There may be differences in the way that a client (with cluster awareness) handles load balancing vs. the way that shotover handles load balancing. For example, I've noticed that redis-bench with cluster mode enabled results in a set load on 2 master nodes, and 2 replica nodes (for a 3 master, 3 replica cluster). It's odd that it doesn't use all 3 master nodes.
Same client (without cluster mode) via shotover results in different behaviour, with sets, 1 master and 1 replica are used, with gets, 1 master is used. Can we make shotover cluster load balancing behaviour configurable (many clients support either master only, or master and replica load balancing), allow all master nodes to be used for better load distributed (for sets), and output confirmation about what nodes are being used (and how) for load balancing on shotover startup.

How to recreate this issue
Directly on the cluster

Run the Redis cluster example with docker-compose up -d in examples/redis-cluster
Use docker stats to monitor load.
Run redis benchmark directly on the cluster (in cluster mode) with redis-benchmark -h <IP_ADDRESS> -p 2225 -n 1000000 -c 20 -t set --cluster

On Shotover

Run the Redis cluster example with docker-compose up -d in examples/redis-cluster
Use docker stats to monitor load.
Run redis benchmark (not in cluster mode) with redis-benchmark -h <IP_ADDRESS> -p 6379 -n 1000000 -c 20 -t set

Closing as stale.

Did you find that your method of reproduction in https://github.com/shotover/shotover-proxy/issues/28#issuecomment-958577344 no longer reproduces the issue?


bat syntax support does not match vim

Problem
I set up page as my git pager:
:; git config core.pager 'page -O -t git'
:; git diff
[<PHONE_NUMBER> | WARN  | dump in page ]
cannot spawn bat, use stdout: Os { code: 2, kind: NotFound, message: "No such file or directory" }
diff --git ...

Though it worked, I was confused about the warning, not knowing what it was or that it was a dependency that needed to be installed.
After looking through the source, I tried installing it:
:; git diff
[bat error]: unknown syntax: 'git'

and now there's no output at all! One can't always assume that bat language names will match git filetypes.
Resolution
There appears to be no way to configure this behaviour. I could've set PAGE_LOG=error to silence all warnings, but there's no direct way to turn the bat fallback off. I also would be happy to run bat if the --language argument were omitted. I'd suggest:

Some sort of argument/syntax that configures vim's filetype (-t) and bat's language (--bat-language? -T?) separately
If -T defaults to -t's value, there should be a way to clear it with -T auto or something
When a file path is provided instead of stdin, prefer bat --file-name argument instead of bat --language - this code seems incorrect, the extension is not a language and the filename should be passed instead if it is available.
(bat uses the filename to auto-detect the language, but unlike --language, it will not panic if it does not recognize it)
There should probably be a flag to explicitly turn bat on/off, perhaps -T none for example.
So page -O -t pager -T auto would use bat, while page -O -t rust -T none would cat instead

Hello, thank you for this bug report and sorry that I was silent for so long. Currently life overwhelms me.

Honestly, I'd really like to get rid of bat dependency altogether.
As for now I like your suggestion, it really seems to be the best solution possible. Just no time/energy to implement it.
But I'll definitely return to this in the future!


Improve "istioctl authn tls-check " error message

Describe the bug
istioctl authn tls-check   results in "Error: nothing to output"
Expected behavior
behavior as seen in 1.0.6
Steps to reproduce the bug
run command: istioctl authn tls-check
Version
istio 1.1.1
kube 1.11
Installation
helm template
Environment
AWS
Cluster state
Can be provided if necessary

I need more information.  I have verified that the output of istioctl authn tls-check dummy is
Error: nothing to output

This is a poor error message.  I have no pod named "dummy" and the message should have said that.
I was able to get output doing istioctl authn tls-check productpage-v1-6df5fcc896-t2s2p and istioctl authn tls-check productpage-v1-6df5fcc896-t2s2p.default.  (I am running Bookinfo).
What argument did you supply?

istioctl authn tls-check sleep-88ddbcfdd-fgn45.default  httpbin.default.svc.cluster.local
Error: nothing to output
---
with debug on
---
2019-04-02T18:50:16.694061Z	debug	[Config loaded from file /home/rdyer/.kube/config]
2019-04-02T18:50:16.695446Z	debug	[Config loaded from file /home/rdyer/.kube/config]
2019-04-02T18:50:16.696302Z	info	curl -k -v -XGET  -H "Accept: application/json, */*" -H "Authorization: Basic FOOBAR" 'https://api.kube.domain/api/v1/namespaces/istio-system/pods?fieldSelector=status.phase%3DRunning&labelSelector=istio%3Dpilot'
2019-04-02T18:50:17.049084Z	info	GET https://api.kube.domain/api/v1/namespaces/istio-system/pods?fieldSelector=status.phase%3DRunning&labelSelector=istio%3Dpilot 200 OK in 352 milliseconds
2019-04-02T18:50:17.049167Z	info	Response Headers:
2019-04-02T18:50:17.049237Z	info	    Content-Type: application/json
2019-04-02T18:50:17.049314Z	info	    Date: Tue, 02 Apr 2019 18:50:21 GMT
2019-04-02T18:50:17.124839Z	info	Response Body: {"kind":"PodList","apiVersion":"v1","metadata":{"selfLink":"/api/v1/namespaces/istio-system/pods","resourceVersion":"8718457"},"items":[{"metadata":{"name":"istio-pilot-55d5f6464f-dcb8v","generateName":"istio-pilot-55d5f6464f-","namespace":"istio-system","selfLink":"/api/v1/namespaces/istio-system/pods/istio-pilot-55d5f6464f-dcb8v","uid":"af900585-5567-11e9-b7fc-1238749b0fea","resourceVersion":"8698794","creationTimestamp":"2019-04-02T16:52:22Z","labels":{"app":"pilot","chart":"pilot","heritage":"Tiller","istio":"pilot","pod-template-hash":"1181920209","release":"istio"},"annotations":{"scheduler.alpha.kubernetes.io/critical-pod":"","sidecar.istio.io/inject":"false"},"ownerReferences":[{"apiVersion":"apps/v1","kind":"ReplicaSet","name":"istio-pilot-55d5f6464f","uid":"5601957b-5541-11e9-b7fc-1238749b0fea","controller":true,"blockOwnerDeletion":true}]},"spec":{"volumes":[{"name":"config-volume","configMap":{"name":"istio","defaultMode":420}},{"name":"istio-certs","secret":{"secretName":"istio.istio-pilot-service-account","defaultMode":420,"optional":true}},{"name":"istio-pilot-service-account-token-qm7tz","secret":{"secretName":"istio-pilot-service-account-token-qm7tz","defaultMode":420}}],"containers":[{"name":"discovery","image":"docker.io/istio/pilot:1.1.1","args":["discovery","--monitoringAddr=:15014","--domain","cluster.local","--secureGrpcAddr","","--keepaliveMaxServerConnectionAge","30m"],"ports":[{"containerPort":8080,"protocol":"TCP"},{"containerPort":15010,"protocol":"TCP"}],"env":[{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}},{"name":"POD_NAMESPACE","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"}}},{"name":"GODEBUG","value":"gctrace=1"},{"name":"PILOT_PUSH_THROTTLE","value":"100"},{"name":"PILOT_TRACE_SAMPLING","value":"1"},{"name":"PILOT_DISABLE_XDS_MARSHALING_TO_ANY","value":"1"}],"resources":{"requests":{"cpu":"500m","memory":"2Gi"}},"volumeMounts":[{"name":"config-volume","mountPath":"/etc/istio/config"},{"name":"istio-certs","readOnly":true,"mountPath":"/etc/certs"},{"name":"istio-pilot-service-account-token-qm7tz","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"readinessProbe":{"httpGet":{"path":"/ready","port":8080,"scheme":"HTTP"},"initialDelaySeconds":5,"timeoutSeconds":5,"periodSeconds":30,"successThreshold":1,"failureThreshold":3},"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"IfNotPresent"},{"name":"istio-proxy","image":"docker.io/istio/proxyv2:1.1.1","args":["proxy","--domain","$(POD_NAMESPACE).svc.cluster.local","--serviceCluster","istio-pilot","--templateFile","/etc/istio/proxy/envoy_pilot.yaml.tmpl","--controlPlaneAuthPolicy","NONE"],"ports":[{"containerPort":15003,"protocol":"TCP"},{"containerPort":15005,"protocol":"TCP"},{"containerPort":15007,"protocol":"TCP"},{"containerPort":15011,"protocol":"TCP"}],"env":[{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}},{"name":"POD_NAMESPACE","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"}}},{"name":"INSTANCE_IP","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.podIP"}}}],"resources":{"limits":{"cpu":"2","memory":"128Mi"},"requests":{"cpu":"100m","memory":"128Mi"}},"volumeMounts":[{"name":"istio-certs","readOnly":true,"mountPath":"/etc/certs"},{"name":"istio-pilot-service-account-token-qm7tz","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"IfNotPresent"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","serviceAccountName":"istio-pilot-service-account","serviceAccount":"istio-pilot-service-account","nodeName":"ip-10-1-9-84.ec2.internal","securityContext":{},"affinity":{"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["amd64","ppc64le","s390x"]}]}]},"preferredDuringSchedulingIgnoredDuringExecution":[{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["amd64"]}]}},{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["ppc64le"]}]}},{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["s390x"]}]}}]}},"schedulerName":"default-scheduler","tolerations":[{"key":"node.kubernetes.io/not-ready","operator":"Exists","effect":"NoExecute","tolerationSeconds":300},{"key":"node.kubernetes.io/unreachable","operator":"Exists","effect":"NoExecute","tolerationSeconds":300}],"priority":0},"status":{"phase":"Running","conditions":[{"type":"Initialized","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:22Z"},{"type":"Ready","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:42Z"},{"type":"ContainersReady","status":"True","lastProbeTime":null,"lastTransitionTime":null},{"type":"PodScheduled","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:22Z"}],"hostIP":"<IP_ADDRESS>","podIP":"<IP_ADDRESS>","startTime":"2019-04-02T16:52:22Z","containerStatuses":[{"name":"discovery","state":{"running":{"startedAt":"2019-04-02T16:52:23Z"}},"lastState":{},"ready":true,"restartCount":0,"image":"istio/pilot:1.1.1","imageID":"docker-pullable://istio/pilot@sha256:573506316664cad19ed9d2640c52955294811163c4e3c849a305555fca22759c","containerID":"docker://231ace88f34919f9ff92a345ac286a22a5957e748eaf9c986528e5d055c0676d"},{"name":"istio-proxy","state":{"running":{"startedAt":"2019-04-02T16:52:23Z"}},"lastState":{},"ready":true,"restartCount":0,"image":"istio/proxyv2:1.1.1","imageID":"docker-pullable://istio/proxyv2@sha256:ca41c2c715db0bf2369f892451008a631de6af519ad0bebf3e657bcbb5afb9df","containerID":"docker://9657e40f02e5d6f8f27e7e39af6b78b81fe21b30e77179dec200070844746919"}],"qosClass":"Burstable"}},{"metadata":{"name":"istio-pilot-55d5f6464f-s87r7","generateName":"istio-pilot-55d5f6464f-","namespace":"istio-system","selfLink":"/api/v1/namespaces/istio-system/pods/istio-pilot-55d5f6464f-s87r7","uid":"af9d3807-5567-11e9-b7fc-1238749b0fea","resourceVersion":"8698849","creationTimestamp":"2019-04-02T16:52:22Z","labels":{"app":"pilot","chart":"pilot","heritage":"Tiller","istio":"pilot","pod-template-hash":"1181920209","release":"istio"},"annotations":{"scheduler.alpha.kubernetes.io/critical-pod":"","sidecar.istio.io/inject":"false"},"ownerReferences":[{"apiVersion":"apps/v1","kind":"ReplicaSet","name":"istio-pilot-55d5f6464f","uid":"5601957b-5541-11e9-b7fc-1238749b0fea","controller":true,"blockOwnerDeletion":true}]},"spec":{"volumes":[{"name":"config-volume","configMap":{"name":"istio","defaultMode":420}},{"name":"istio-certs","secret":{"secretName":"istio.istio-pilot-service-account","defaultMode":420,"optional":true}},{"name":"istio-pilot-service-account-token-qm7tz","secret":{"secretName":"istio-pilot-service-account-token-qm7tz","defaultMode":420}}],"containers":[{"name":"discovery","image":"docker.io/istio/pilot:1.1.1","args":["discovery","--monitoringAddr=:15014","--domain","cluster.local","--secureGrpcAddr","","--keepaliveMaxServerConnectionAge","30m"],"ports":[{"containerPort":8080,"protocol":"TCP"},{"containerPort":15010,"protocol":"TCP"}],"env":[{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}},{"name":"POD_NAMESPACE","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"}}},{"name":"GODEBUG","value":"gctrace=1"},{"name":"PILOT_PUSH_THROTTLE","value":"100"},{"name":"PILOT_TRACE_SAMPLING","value":"1"},{"name":"PILOT_DISABLE_XDS_MARSHALING_TO_ANY","value":"1"}],"resources":{"requests":{"cpu":"500m","memory":"2Gi"}},"volumeMounts":[{"name":"config-volume","mountPath":"/etc/istio/config"},{"name":"istio-certs","readOnly":true,"mountPath":"/etc/certs"},{"name":"istio-pilot-service-account-token-qm7tz","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"readinessProbe":{"httpGet":{"path":"/ready","port":8080,"scheme":"HTTP"},"initialDelaySeconds":5,"timeoutSeconds":5,"periodSeconds":30,"successThreshold":1,"failureThreshold":3},"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"IfNotPresent"},{"name":"istio-proxy","image":"docker.io/istio/proxyv2:1.1.1","args":["proxy","--domain","$(POD_NAMESPACE).svc.cluster.local","--serviceCluster","istio-pilot","--templateFile","/etc/istio/proxy/envoy_pilot.yaml.tmpl","--controlPlaneAuthPolicy","NONE"],"ports":[{"containerPort":15003,"protocol":"TCP"},{"containerPort":15005,"protocol":"TCP"},{"containerPort":15007,"protocol":"TCP"},{"containerPort":15011,"protocol":"TCP"}],"env":[{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}},{"name":"POD_NAMESPACE","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"}}},{"name":"INSTANCE_IP","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.podIP"}}}],"resources":{"limits":{"cpu":"2","memory":"128Mi"},"requests":{"cpu":"100m","memory":"128Mi"}},"volumeMounts":[{"name":"istio-certs","readOnly":true,"mountPath":"/etc/certs"},{"name":"istio-pilot-service-account-token-qm7tz","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"IfNotPresent"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","serviceAccountName":"istio-pilot-service-account","serviceAccount":"istio-pilot-service-account","nodeName":"ip-10-1-62-112.ec2.internal","securityContext":{},"affinity":{"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["amd64","ppc64le","s390x"]}]}]},"preferredDuringSchedulingIgnoredDuringExecution":[{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["amd64"]}]}},{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["ppc64le"]}]}},{"weight":2,"preference":{"matchExpressions":[{"key":"beta.kubernetes.io/arch","operator":"In","values":["s390x"]}]}}]}},"schedulerName":"default-scheduler","tolerations":[{"key":"node.kubernetes.io/not-ready","operator":"Exists","effect":"NoExecute","tolerationSeconds":300},{"key":"node.kubernetes.io/unreachable","operator":"Exists","effect":"NoExecute","tolerationSeconds":300}],"priority":0},"status":{"phase":"Running","conditions":[{"type":"Initialized","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:22Z"},{"type":"Ready","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:55Z"},{"type":"ContainersReady","status":"True","lastProbeTime":null,"lastTransitionTime":null},{"type":"PodScheduled","status":"True","lastProbeTime":null,"lastTransitionTime":"2019-04-02T16:52:22Z"}],"hostIP":"<IP_ADDRESS>","podIP":"<IP_ADDRESS>","startTime":"2019-04-02T16:52:22Z","containerStatuses":[{"name":"discovery","state":{"running":{"startedAt":"2019-04-02T16:52:42Z"}},"lastState":{},"ready":true,"restartCount":0,"image":"istio/pilot:1.1.1","imageID":"docker-pullable://istio/pilot@sha256:573506316664cad19ed9d2640c52955294811163c4e3c849a305555fca22759c","containerID":"docker://87cf1a12d81d77b6dac54bc5df7662299bb8304bf540adf5b5e1dd12293acae2"},{"name":"istio-proxy","state":{"running":{"startedAt":"2019-04-02T16:52:42Z"}},"lastState":{},"ready":true,"restartCount":0,"image":"istio/proxyv2:1.1.1","imageID":"docker-pullable://istio/proxyv2@sha256:ca41c2c715db0bf2369f892451008a631de6af519ad0bebf3e657bcbb5afb9df","containerID":"docker://6121ea39e6eb7aa94ef22692c4de1287e299a545f1c99f5dbf669dcaa318230f"}],"qosClass":"Burstable"}}]}
2019-04-02T18:50:17.149412Z	info	curl -k -v -XPOST  -H "X-Stream-Protocol-Version: v4.channel.k8s.io" -H "X-Stream-Protocol-Version: v3.channel.k8s.io" -H "X-Stream-Protocol-Version: v2.channel.k8s.io" -H "X-Stream-Protocol-Version: channel.k8s.io" -H "Authorization: Basic FOOBAR" 'https://api.kube.domain/api/v1/namespaces/istio-system/pods/istio-pilot-55d5f6464f-dcb8v/exec?command=sh&command=-c&command=GODEBUG%3D+%2Fusr%2Flocal%2Fbin%2Fpilot-discovery+request+GET+%2Fdebug%2Fauthenticationz%3FproxyID%3Dsleep-88ddbcfdd-fgn45.default+&container=discovery&container=discovery&stderr=true&stdout=true'
2019-04-02T18:50:17.537412Z	info	POST https://api.kube.domain/api/v1/namespaces/istio-system/pods/istio-pilot-55d5f6464f-dcb8v/exec?command=sh&command=-c&command=GODEBUG%3D+%2Fusr%2Flocal%2Fbin%2Fpilot-discovery+request+GET+%2Fdebug%2Fauthenticationz%3FproxyID%3Dsleep-88ddbcfdd-fgn45.default+&container=discovery&container=discovery&stderr=true&stdout=true 101 Switching Protocols in 387 milliseconds
2019-04-02T18:50:17.537498Z	info	Response Headers:
2019-04-02T18:50:17.537541Z	info	    Connection: Upgrade
2019-04-02T18:50:17.537592Z	info	    Upgrade: SPDY/3.1
2019-04-02T18:50:17.537629Z	info	    X-Stream-Protocol-Version: v4.channel.k8s.io
2019-04-02T18:50:17.537665Z	info	    Date: Tue, 02 Apr 2019 18:50:21 GMT
ERROR: nothing to output

Did some additional testing and its working now, though I tried this so many times this past week all with the same results.  Better error message would indeed be helpful.

The patch for this is blocked because of code coverage.  I have a PR for mocking that will allow the code coverage to be improved.

note, we are going to make some large refactor and improvements on istioctl authn.
/cc @diemtvu
See https://github.com/istio/istio/pull/12774

@esnible A better error is great, but I think there's an underlying problem here.
If I run multiple pilot replicas, only the one connected to a particular pod has the auth data (it seems).
When I scaled pilot down to 1 replica it immediately started working again. I also ran the authenticationz query on each pilot replica to confirm. Perhaps istioctl should pick the pilot pod to query based on the target pod instead of random?

I don't think it is possible to figure out which instance of Pilot is being used by a sidecar.  @dwradcliffe I think it would make sense to ask each Pilot instance and not fail until all running Pilots refused to acknowledge the pod.  Do you agree?

If we can't figure out which one to target, yes that makes sense. But how does istioctl ps report the connected pilot?
(Also, why does only one pilot have this data?)

@dwradcliffe istioctl ps literally calls AllPilotsDiscoveryDo() while istioctl authn tls-check only calls PilotDiscoveryDo().

@dwradcliffe @esnible
We're planning to change the istioctl auth in the following directions:

check the Envoy config to detect potential mTLS problems directly, so that we don't rely on Pilot at all, then multiple pilot instances won't be a problem,
get the policy from galley instead of pilot as galley is the central point for config processing since Istio 1.1, but we might still have the problem of multiple instances of galley

Any thoughts?

@yangminzhu That seems good to me. Each galley should have the same config, so in theory that's fine. (I'm still not sure why each pilot doesn't have the same config)
What's the timeline for this?

@dwradcliffe
I'm not sure about the pilot part either. For the new tool, I just checked in the first PoC PR (https://github.com/istio/istio/pull/12774) last week, will need to come up with a doc and discuss it in the user experience group. Generally, we're aiming for 1.2.

We have two issues.
istioctl doesn't check all the pilots and should https://github.com/istio/istio/pull/13724
istioctl error message confusing if the pod truly doesn't exist https://github.com/istio/istio/pull/13103
Both issues were fixed by PRs that went stale.  I will recreate.


fix: unit tests with versioned refs

Resolves #10880; Resolves #10528; Resolves #10623
Problem
The error raises due the method RefableLookup.find at  dbt-my/core/dbt/contracts/graph/manifest.py:
Tracking the storage object, without specifying a version in the model we will obtain something like that for the Unit Test Node running phase
{'upstream_model_versioned': {}, 'upstream_model_versioned.v<LATEST>': {'demo_dbt_py': 'model.demo_dbt_py.upstream_model_versioned'}}

Which it seems to me that is not right, because if I specified the latest_version for my model, I should get   a Storage like this
{
    'upstream_model_versioned': {'demo_dbt_py': 'model.demo_dbt_py.upstream_model_versioned'},
    'upstream_model_versioned.v <LATEST> ': {'demo_dbt_py': 'model.demo_dbt_py.upstream_model_versioned'}
}

I run some different cases and obtain the following table

Status
Model Ref
Model Latest
Test Ref
Test Latest
Expectation
v on find
Compilation Message

❌
true
true
true
false
fail
1
depends on a node named 'upstream_model_versioned' with version '1' which was not found

❌
true
false
false
None
fail
2
depends on a node named 'upstream_model_versioned' with version '2' which was not found

❌
false
None
false
false
success
None
depends on a node named 'upstream_model_versioned' which was not found

❌
false
None
true
true
success
None
depends on a node named 'upstream_model_versioned' which was not found

✅
true
true
false
None
success
1
model.demo_dbt_py.upstream_model_versioned

✅
true
true
true
true
success
1
model.demo_dbt_py.upstream_model_versioned

✅
true
false
true
false
success
2
model.demo_dbt_py.upstream_model_versioned

However, even in cases where the tests were successful, the storage objects it seems that not properly constructed. For example, when using ref('upstream_model_versioned', v=1) I got this:
{'upstream_model_versioned': {},
 'upstream_model_versioned.v1': {'demo_dbt_py': 'model.demo_dbt_py.upstream_model_versioned'}}

This worked not because the storage structure was correct, but because there was a key named upstream_model_versioned.v1.
Solution
The only problem that I found is that the Node object for the UnitTest was not copying the value from latest_version prop if it was available
Checklist

[x] I have read the contributing guide and understand what's expected of me.
[x] I have run this code in development, and it appears to resolve the stated issue.
[x] This PR includes tests, or tests are not required or relevant for this PR.
[x] This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
[x] This PR includes type annotations for new and modified functions.

Hello @dbeatty10. This is a PR with a very simple fix that closes 3 open issues. It's covered by functional tests, but I’m not sure why this class doesn’t have any unit tests, so I left that aside.

Thank you for the contribution @devmessias!
This is looking good overall, but it looks like this PR is failing on unrelated functional tests with the same 'strategy' error for tests related to snapshots. We've been doing a lot of work on snapshots recently so it may just be an intermittent issue that has since been resolved. Could you please merge main into this branch and re-run the tests?
Otherwise, just a refactoring suggestion for clarity, as well as some examples of testing for expected errors in logs.

Hi @MichelleArk , the branch is now updated


@export_enum does not export string values

Godot version
v4.0.beta1.official [20d667284]
System information
Windows 10
Issue description
When using the new @export_enum you cannot assign a value of String to the variable like you should be able to (according to the docs).
Steps to reproduce
Add a script to a node with the following code:
@export_enum("A", "B", "C") var my_string : String
You will get the error "@export_enum" annotation requires a variable of type "int" but type "String" was given instead.".
Minimal reproduction project
No response

Duplicate of #54828


Jazzy updates

Description
Several fixes & changes needed for Jazzy support:

renames ign and ignition related nodes to use gz or sim (per new nomenclature)
updates gazebo plugin & resource environment variables to use the new GZ_* nomenclature
adds GzSceneManager and InteractiveViewControl plugins to gui.config (needed for the visualization to render correctly & allow camera movement)
fixes a bug where dock & undock behaviours could be preempted by e.g. reflex, causing their associated ROS actions to cancel
updates diff_drive_controller interaction to use TwistStamped messages (per recent changes from ROS controllers)
replace NotEqualsSubstitution(...) with IfCondition(NotEqualsSubstitution(...)) (deprecation)
slight change to the maze world to ensure the robot's default spawn location doesn't clip into wall 12

How Has This Been Tested?
Tested on Ubuntu 24.04.  Able to successfully:

dock & undock the robot using the action servers
control the robot using on-screen teleop controls + keyboard controls
visualize the robot & dock in Rviz2
drive the robot into an obstacle to trigger reflex behaviours

# To start the simulation
ros2 launch irobot_create_gz_bringup create3_gz.launch.py

Wait for the simulation to load fully (may take several seconds, depending on the specs of the machine being used), then press the orange play button to start the simulation. The fan in the depot ceiling will spin when the simulation is running.  Rviz will show the robot & dock.
To undock the robot:
ros2 action send_goal /undock irobot_create_msgs/action/Undock {}

To dock the robot:
ros2 action send_goal /dock irobot_create_msgs/action/Dock {} --feedback

Overall looks good, thanks for the work!
I'll give it a try in the next days

No big rush. I imagine there may be a few additional updates as I continue testing with the Turtlebot4 packages. But this should give a good base for the remaining Jazzy work.

I did an additional review and, besides the small comments above, everything looks good.

@civerachb-cpr there's still a few CHANGELOG files that have been inadvertently modified.
Can you please revert these changes as well?

Great to see this update. Just wanted to drop https://gazebosim.org/docs/latest/ros2_gz_vendor_pkgs/ in case you haven't seen it. Also, since Gazebo is now available from packages.ros.org, there's no need for the instructions that add the packages.osrfoundation.org repo.


Change copyright year 2023 to 2024

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@thestarsahil please assign this issue to me under GSSOC’24

That's a minor change , I request you to focus on major problem as you can take references of merged PR !
Thanks


Install ps on the nginx container and fix docker-compose.yml when using letsencrypt

The file docker-compose.yml ends up with the port option defined twice when using letsencrypt. The arrangement of the if statements in the PR fixes that issue.
The file start.sh in the nginx compose folder has the command kill $(ps aux | grep 'nginx' | grep -v 'grep' | awk '{print $2}'). The problem is that the ps command is not installed in the nginx image. The command added in the PR installs the ps command so that start.sh runs without error.
This eliminates a problem that I was having where nginx was reporting that port 80 was already in use. The error in the logs was:
nginx_1         | /start.sh: 59: /start.sh: ps: not found
nginx_1         | /start.sh: 59: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
nginx_1         | kill -l [exitstatus]
nginx_1         | 2017/05/04 16:20:08 [emerg] 26#26: bind() to <IP_ADDRESS>:80 failed (98: Address already in use)
nginx_1         | nginx: [emerg] bind() to <IP_ADDRESS>:80 failed (98: Address already in use)

The RUN command addition works for me.

LGMT

@luzfcb can we get this merged?

Thanks! This is a needed fix. I don't know how long it will last, though: #1132

@jayfk I have never used Caddy, but so far every decision made by this community has been accurate. Looking forward to adopt it if the community goes that way. Thanks for the merge.