Appimage error safe browser

Prerequisites

[ ] Using Appimage
[ ] Using Ubuntu ~19
[ ] safe browser version 0.15.3

Expected Behavior
Should run
Current Behavior
[main 16:54:36.518] › >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[main 16:54:36.524] › whoops! there was an uncaught error:
[main 16:54:36.524] › In the main process
[main 16:54:36.524] › {"message":"libssl.so.1.0.0: cannot open shared object file: No such file or directory","name":"Error"}
[main 16:54:36.524] › >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

can you check if this is still an issue for you w/ latest alpha @hamiltino 🙇
https://github.com/maidsafe/safe_browser/releases/tag/v0.16.0-alpha.2

Closing legacy issues - this should now be resolved


Does scheduler.cron de-duplicate jobs with the same id?

If I run scheduler.cron() twice with the same id argument, the job is only scheduled once.
This is great, but it's not documented anywhere. This old issue also seems to contradict what I'm seeing.
Can someone confirm that the scheduler actually de-duplicates cron jobs with the same id?

This also works for scheduler.schedule()
Would be nice if this was documented anywhere :-)


Build process

Each function is it's own file and automatically gets added to the lib on build.

This will(should) cut down on the number of merge conflicts

This is a good idea.

D U N

YES. FINALLY. WE DID IT GUYS. THANK YOU.
I would like to thank my mother for all the spaghetti she made me.

Hello? Spaghetti? Who said spaghetti? I'm up for some.

It's ready.
You better never let it go!
You only get one spaghetti.
Do not miss your chance to blow;
'coz spaghetti comes once in a lifetime, yo!
:musical_note: :musical_note:

BARNEY IS A DINOSAUR FROM OUR IMMAGINATION


projects built with Lor

this is a list about projects or libraries that are built with Lor framework.

Orange - A Gateway based on OpenResty(Nginx+lua) for API Monitoring and Management.

OpenResty-China - 一个运行在OpenResty上的基于lor编写的社区软件

Mio - API statistics/summary and health datas in NGINX based on OpenResty/ngx_lua, just like NGINX Plus


python3Packages.langchain: 0.0.170 -> 0.0.172

Diff: https://github.com/hwchase17/langchain/compare/refs/tags/v0.0.170...v0.0.172
Changelog: https://github.com/hwchase17/langchain/releases/tag/v0.0.172
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 232542 run on x86_64-linux 1

2 packages built:

python310Packages.langchain
python310Packages.langchain.dist

@ofborg build python3Packages.langchain python3Packages.langchain.passthru.tests


TOC - Group tutorials by days

My stab at grouping the tutorials by days.
Also added table of contents for each day and section.

thanks so much @jomey The one added convenience I can think of are links on the schedule page, but overall this is much easier to follow.

Will add that.
Also note that I am thinking of merging PR #100 first and then update this PR. There are some outstanding improvement ideas to the content of the ML tutorial and it would cause less conflict merging first merging the open PRs and then do a follow up with a new one


'template' won't be navigated for route added by javascript

Describe the bug
'template' won't be navigated for route added by javascript (4.2.0)
To Reproduce
Steps to reproduce the behavior:

window.PineconeRouter.add('/', {handlers: [], template: '/home.html'})
click the link '/' won't load '/home.html' page.

Expected behavior
link should work
Desktop (please complete the following information):

OS: MacOS
Browser: Chrome
Version: 4.2.0

I can confirm this was not considered, I'm wondering how you expect this to behave?
Since there is no x-route element it cannot be rendered in it.
Only way this work is to add a "target" option, and show the template in that element. However the template logic is inside the x-template directive, I'll see if I can extract it.

I can confirm this was not considered, I'm wondering how you expect this to behave? Since there is no x-route element it cannot be rendered in it.
Only way this work is to add a "target" option, and show the template in that element. However the template logic is inside the x-template directive, I'll see if I can extract it.

For some reason, I want to manage routes in js, and this worked fine for 3.x, using 'views' middleware.
Home

document.addEventListener('alpine:initialized', () => {
    PineconeRouter.add('/', {handlers: [], view: ['/home.html']});
});

Recently, I upgraded to 4.x and saw changelog said: "x-template directive replacing the views middleware".  So I try to change options to {handlers: [], template: '/home.html'} according to the document and expected the same behavior.

Sorry for the inconvenience, I will try to make it load the template and show it in the window.PineconeRouter.settings.templateTargetId element.
Note: This will mean that if the route with template is added programmatically, it will show when the route is matched, however, it will not clear automatically, this is to keep compatibility with x-template. so you must have a route and template for notfound route and every other route or otherwise when the route is changed to another that doesn't have a template, the previous template will keep showing. Is that okay?

Fixed in 4.3.0.
Let me know if you find further issues and thanks for submitting this one!

Note: This will mean that if the route with template is added programmatically, it will show when the route is matched, however, it will not clear automatically, this is to keep compatibility with x-template. so you must have a route and template for notfound route and every other route or otherwise when the route is changed to another that doesn't have a template, the previous template will keep showing. Is that okay?

4.3.0 fixed! It okay for my case, actually, I handle almost all 'wildcard' routes in notfound handler except some hardcode ones such as  '/'.
Thank you for the fixed and the whole extension, pinecone-router is very useful and handy, and with good interface design :)

Glad to hear it working! thanks for using it:)


[Enhancement] add column prune after mv rewrite

Signed-off-by: ABingHuang<EMAIL_ADDRESS>What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #17051
Problem Summary(Required) ：

[Enhancement] add column prune after mv rewrite
Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_fe_unittest


Button doesn't set aria-disabled attribute when it is disabled

🐛 Bug Report
Many Nimble components (for example the switch and toggle-button) automatically set aria-disabled=true whenever you apply the disabled attribute. The nimble-button doesn't do this.
💻 Repro or Code Sample
https://nimble.ni.dev/storybook/?path=/story/components-button--outline-button&args=disabled:!true
🤔 Expected Behavior
If a client sets disabled then aria-disabled will be true.
😯 Current Behavior
aria-disabled is never set automatically
💁 Possible Solution
Other components have code in their template to sync the attributes. Unfortunately the button is currently using a FAST template so we'd either have to make a change in FAST (requiring a release from their legacy branch) or fork the template as we've done for other components.
Even if we fork the template we should still file an upstream issue to FAST.
🔦 Context
This is a problem for this SLE PR making changes to Playwright tests. The Playwright toBeDisabled() assertion will only succeed if native form elements have the disabled attribute or non-native custom elements have aria-disabled=true. This means a nimble-button with the disabled attribute is currently failing that assertion.
🌍 Your Environment

I've submitted an issue to FAST: https://github.com/microsoft/fast/issues/6783. We should see if they are willing to fix this quickly, and if so, if they are willing to cherry-pick the fix into our legacy branch. If not, I guess we fork the template. 😒

Chris Holt very quickly pushed back on the request, pointing out that the element that is of interest from an accessibility standpoint is the native button in the shadow DOM. It is the one with the "button" role, not the host element. This is different from our switch and toggle-button, where the host element has the a11y role.
We may just need to modify the way our tests are being written.

I guess that leaves us with options like:

change the test to use expect(control).toHaveBooleanAttribute('disabled')
create higher level matchers that conditionally call toBeDisabled() or toHaveBooleanAttribute() depending on the type of the control
file a bug to Playwright saying that toBeDisabled() is wrong for custom elements
decide we disagree with FAST and we really want aria-disabled and disabled to be synced, which means either making our case to FAST or forking their template

@rajsite you advocated for calling this a bug initially, do you have an opinion here? I'm inclined to trust FAST and try for a combo of 1-3.

I think 1-2 are essentially advocating for a high-level page objects for our components right? Maybe we need to put the effort into playwright page objects.
I'm on the fence about 3-4. Think it might take some research. My questions:

Right now the approach largely used by us / FAST is that the host custom-element itself is not the accessibility presenting element. Some child element is and we hide the host custom element / treat it as generic and forward properties to some child. I'm wondering if that is the right long-term vision.
The ElementInternals apis have been adding a bunch of stuff to make the host custom element the accessibility tree presenting element. Maybe we / FAST should actually be targeting the host custom element for the accessibility tree.

In the upcoming Accessibility Object Model APIs there will be a concept of computed accessibility node values. This is pure conjecture but I wonder if thoughts of shadow dom will participate in that. I could see the "computed accessibility" of a custom element with a shadow root being flattened to the custom element. Again pure conjecture, would need to find those discussions

Given the above I think playwright is not 100% correct but I'm not sure if fixes help us. The playwright disabled check algorithm checks against a hard coded list of tag names and then checks for aria attributes. They should probably also check the ElementInternals state based on what exists today or check the Computed Accessibility Tree for what exists tomorrow. I think it's probably unreasonable for them to try and search our shadow root to figure out what is presenting externally, but maybe that's not unreasonable! I'm not completely sure.

For 1 or 2 I had been naively thinking they'd be changes to the tests or test utilities, but you're right that a page object is a better long term place for that. I left a comment on our testing APIs issue linking to this one.
Great research on the future direction. I'll need to take some time to digest to form an opinion.

We ended up using toHaveAttribute('disabled') to work around this issue in the SystemsManagement Playwright tests. We should replace that if we fix this some other way.

Closing as low ROI. If this becomes an issue in the future, please reopen.

For more context / future direction:

The ElementInternals apis for configuring aria are now available in all browsers. So we are longer term more likely to stop doing aria attribute configuration on the elements directly.

As we adopt that api we can behave "more normal", i.e. aria attributes on the elements are for users to configure and override our aria (for example when creating molecules out of nimble components). The aria attributes on our elements are not for the element itself to configure aria (which was needed prior to ElementInternals aria api availability)

We should continue expanding the page objects we create to encapsulate details like this
We should file issues to libraries that are failing to detect aria correctly


Adds loader to the infowindow

@xavijam: I'm not sure if you like the approach to work with the loader. Can you have a look, please?

In the image load, bad thing is there is no tick until image is loaded. Any way, @piensaenpixel is your man to take test and check.

ping: @piensaenpixel

@viddo, @piensaenpixel: can you have a look to the PR, please?

@javierarce for me it's ok

ping @viddo.

:+1: added some comments for some minor doubts


RTF fix

Fixes #686
I had a greedy regex where a non-greedy one was wanted, and I didn't have a test case to cover this situation. When I committed the initial code, I verified visually that the only changes in dist were that RTFNotes got added -- but I didn't look closely enough to see that the field contained more than it should have. All better now.

My regex experience is limited to using the ones ChatGPT tells me to. If you're satisfied that it works, let's merge it.

You're familiar with the old chestnut?

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

This change passes the eye test and also passes the test case I added to the suite. And the RTF for beam_selected_region.lua looks correct. Merging.


[WIP] Switch to std futures

Open issues:

For some reason the poll() implementation cannot be found in a few places?
mio doesn't seem to have a std-future branch yet

For some reason the poll() implementation cannot be found in a few places?

Pin::new(&mut foo).poll(cx)

mio doesn't seem to have a std-future branch yet

What does tokio std-futures use?

I actually already wrote much of this, only stopping at the tests (with the lib compiling) when I realized I wasn't sure if futures 0.3 would be released at the same time as std futures, since it has lots of non-'static futures that seem awkward to use before async/await, e.g. its ReadToEnd variant. I've pushed a std-futures branch (which I now realize is a very similar name, oops) for comparison. My apologies for the poor communication.

Ahh, I was wondering if you'd done the work already. I figured I'd open a WIP PR proactively to let you know about the work. So I think it's good if you own this topic for now (maybe open a PR with your take, or take over this branch?), and I'll focus on some of the other stuff?

I'm not sure I like having our inherent poll_read/write methods renamed to read/write; the poll_ names are more correct, UFCS should be sufficient to disambiguate when necessary, and the normal behavior, preferring inherent impls, is desired here.

Yeah, I think I agree.

So I think it's good if you own this topic for now (maybe open a PR with your take, or take over this branch?), and I'll focus on some of the other stuff?

Works for me, closing in favor of #372.


Add external access and JNLP port

@albertoarias, FYI

Hi @kmala, is there anything required to merge this?

nope! All is done. Just verifying that specific version of jenkins exposes the JNLP port on 50000 on my end, then we should be good to merge.

LGTM after viewing the history of this image:
9a950ac7d681        3 months ago        /bin/sh -c #(nop) EXPOSE 50000/tcp
2e7b98150a55        3 months ago        /bin/sh -c #(nop) EXPOSE 8080/tcp


Update dependencies (including libdparse)

Needed for dlang.org CI to stop spewing thousands of lines of error messages: https://github.com/dlang/dlang.org/pull/2758#issuecomment-649181685

Updated with the latest eventcore / vibe-core, the later being a requirement for https://github.com/dlang/phobos/pull/7545

Tagged as https://github.com/rejectedsoftware/ddox/releases/tag/v0.16.15


About the calculation of AUC

Hi, could you give an explanation for the reason of  substracting the halves of the head and tail elements in an array when calculating the AUC?

@shinkyo0513 Hi, the reason for that is that we are computing a sum of the areas of trapezoids. The area of one is (h1+h2)/2*x, where h1 and h2 are the values in the array, and x is a width that we can set to 1. Then, the whole area is (h1+h2)/2 + (h2+h3)/2 + ... + (h[n-1] + hn) / 2 = S - h1/2 - hn/2

Got it! Thank you for the response.


Need more information about install:

Hi,
Thank you for bringing this plugin!
It's quite embarrassing to ask, but where should I run composer require mindkomm/timber-integration-woocommerce  command? If I want to install as a plugin, do I have to compile by myself?
I tried to run in the root folder of my timber theme and inside the timber plugin folder, but this seems not working to both path.
It would be really nice if you can deliberate more about how to install 🙏Thank you!

If you want to install it as a plugin you can simply download the github repository, and then run composer install the /timber-integration-woocommerce/ plugin folder

Hi @gchtr @chrislind,
I have successfully installed and activated the integration as a plugin. Thank you for helping this out!
Tried almost every method from here to add WooCommerce to my Timber theme, this might be the fastest way to do it.
Thank you again!


Auto scale when set ratio 9:16

When i set config like this:
config.presetFixedRatioType = .alwaysUsingOnePresetFixedRatio(ratio: 9.0 / 16.0)
image auto scale. How to not scale this?
https://user-images.githubusercontent.com/75512024/112818216-7c0e8380-90ad-11eb-8f8b-e9091d80722a.MP4

@nthnhung23 Which version are you using? I think it was solved in the latest version 1.5.1

@nthnhung23 Which version are you using? I think it was solved in the latest version 1.5.1

yes, thank you. But i have new issue.
I try crop like video, ratio frame will change error.
And How do I keep ratio frame and only change image?
https://user-images.githubusercontent.com/75512024/112930915-5df46200-9145-11eb-89b1-c179f0f74d04.MOV

@nthnhung23 Mantis does not support video crop. Do you mean animation GIFs?

@nthnhung23 Mantis does not support video crop. Do you mean animation GIFs?

@nthnhung23 Mantis does not support video crop. Do you mean animation GIFs?

No, video is demo bug. I crop only image

@nthnhung23 Can you provie more information about your iOS device? Does it happen to any photos you are using? Thank you!

@nthnhung23 Can you provie more information about your iOS device? Does it happen to any photos you are using? Thank you!

this problem any device and photos i used.

@nthnhung23 Does it also happen when you use the Example App?

@nthnhung23 I reproduced this issue. I will check it later when I have enough time.


Request to Support Schrödinger State Evaluation in Java SDK

Currently, it appears that the SDK does not support the evaluation of the Schrödinger state. This is a very important feature for many users, particularly those working in quantum computing or similar fields. The ability to evaluate the Schrödinger state is crucial to accurately model and understand quantum systems.
I understand that implementing this feature might require substantial work, but I believe it would be a valuable contribution to the SDK. It would not only extend the current capabilities of the SDK but also make it more appealing to a wider audience.
I hope you will consider this request. I am looking forward to any feedback or thoughts you might have on this.

Hello @ashenp!
From my point of view if we add the evaluation of the Schrödinger state, we will be obligated to add the same to all others SDKs (Kotlin, Swift, Dart etc.)
First of all the method of the evaluation of the Schrödinger state should appear in docs and then the developers of the SDKs will implement this feature.
It seems like to add @Auz and @jdorn to the discussion is appropriate here.


typo: InteropServicxes.MarshalAs -> InteropServices.MarshalAsAttribute

Summary
OpenBuild was failing from the typo. This change also isn't in master

Thanks for submitting this fix, @nschonni. However, your PR targets Live rather than Master. Changing the target creates a merge conflict that is difficult to resolve. I'm going to close this PR. Would you mind submitting a new PR that targets Master?

@rpetrusha the problem only exists in live because there was another PR that landed on live only.
Please reopen.

Thanks for pointing this out, @nschonni I didn't realize that there was a divergence between live and master, which was caused, I'm sad to say, by my merging a PR that I didn't realize targeted live.
What we're going to do is bring the current content of live to master for this topic, since this entire paragraph diverges on live and master. We'll preserve the typo. After that, if you'd like, you can open a PR against master (or possibly reopen this PR and retarget it to master).

@rpetrusha can I suggest you re-open this and change the target to master when you backport the fix.

The problem is that live has a bunch of PRs that are not part of master so changing the base brings all of those. Might be better to create a new PR.

@mairaw if you re-open this I can rebase and force push. If I force-push a closed PR it can't be re-opened

I have created PR #9594 to fix this but I'll reopen and you can decide what to do.

OK, I was just trying to avoid a second PR, but if you've already submitted it I'll close this. Thanks for re-opening though


[4.x] Undo/Redo does not work in the UV editor

Tested versions
This problem occurs in all versions starting from 4.0+, but is not observed in 3.5+
System information
Windows 10, Radeon RX 560 Series
Issue description
When editing UVs in the Polygon2D editor, you cannot undo any action when pressing Ctrl+Z
Steps to reproduce
Open the UV editor, move the points and try to return them to their original place
Minimal reproduction project (MRP)
Too easy to check, not required

AcceptDialog blocks input from the main window; if you create an UndoRedo and an AcceptDialog in the editor itself you will be able to test this.
I tried to make the UV Editor exclusive as it helps lock the AcceptDialog input focus in the editor, but uv_edit->set_exclusive(false) in polygon_2d_editor_plugin.cpp doesn't solve the problem


Handling s3n:// and s3a:// protocols

I have perused the open/closed issues as well as the source code and notice the only S3 prefix coded into the handlers is s3://
From my experience these 2 additional protocols are utilized by some people explicitly and this potentially affects those users.

Hello @tylerjharden can you be more specific whtat s3n and s3a should do in particular ?

This StackOverflow Question and the top Answer gives a solid technical explanation of the differences:
http://stackoverflow.com/questions/33356041/technically-what-is-the-difference-between-s3n-s3a-and-s3
For posterity, there is a native file system (s3n) accessor, an alternative without a 5GB limit (s3a) and the standard S3 block storage accessor (s3).
Each of the 3 have some pretty significant differences.

I should also note this applies specifically to Hadoop on S3, sorry that I didn't mention that earlier and was unclear.


Support Generated Interfaces

We are actually generating our interfaces (we're actually using multiple generators together).
[AutoInterface]
[AutoConstruct]
public partial class ItemsService : IItemsService
{
   // removed for brevity
}

However, AutoRegisterInject isn't finding our generated interfaces.
Both:
[AutoInterface]
[AutoConstruct]
[RegisterTransient]
public partial class ItemsService : IItemsService
{
   // removed for brevity
}

And:
[AutoInterface]
[AutoConstruct]
[RegisterTransient(typeof(IItemsService))]
public partial class ItemsService : IItemsService
{
   // removed for brevity
}

Produce:
// <auto-generated>
//     Automatically generated by AutoRegisterInject.
//     Changes made to this file may be lost and may cause undesirable behaviour.
// </auto-generated>
using Microsoft.Extensions.DependencyInjection;
public static class AutoRegisterInjectServiceCollectionExtension
{
    public static Microsoft.Extensions.DependencyInjection.IServiceCollection AutoRegisterFromServices(this Microsoft.Extensions.DependencyInjection.IServiceCollection serviceCollection)
    {
        return AutoRegister(serviceCollection);
    }

    internal static Microsoft.Extensions.DependencyInjection.IServiceCollection AutoRegister(this Microsoft.Extensions.DependencyInjection.IServiceCollection serviceCollection)
    {
        serviceCollection.AddTransient<Services.ItemsService>();
        return serviceCollection;
    }
}

Not sure whether it will be possible to address this due to the use of multiple generators. Was hoping to not have to chose one generator in favor of another when they do not compete in equivalent features.

I'm afraid this is not possible given Source Generators are not aware of one another.


can't move /run/k3s/containerd to different dir (disk partition space issue)

K3s Version:  1.25.9
OS: Linux (Centos, Rocky)
Our servers (not cloud) have partitions we can't change. We can add a big one (like /app or /usr/local/) to put all the working data, etc. in it. We need to be able to specify paths for all k3s things on startup so we don't fill up /var/lib/ and /run/.
I use --data-dir /app/rancher/k3s
and possibly kubelet-arg: --data-dir=/usr/local/kubelet might work
but how can I move /run/k3s/ ?
It fills up to 429MB for a mostly empty deploy (after adding to rancher) and I'm sure would get large when
Almost nothing else in /run is over 4kb, it probably isn't the appropriate place for gigs of containerd "rootfs"'s
(Path example: /run/k3s/containerd/io.containerd.runtime.v2.task/k8s.io/8705.../rootfs
Expected behavior:
Can specify where k3s/containerd lives
Actual behavior:
Can't specify where k3s/containerd lives
Workaround like setting up a symlink at /run/k3s to point to a dir on the big partition seems to get overwritten at k3s/k3s-agent service startup
PS.
k3s-killall.sh and k3s-killall-agent.sh will rm -rf /run/k3s so a symlink will also be lost if created there

/run/k3s should just contain ephemeral runtime data, which is why the killall script deletes it. On most distros there is tmpfs mounted there, so it shouldn't consume any actual storage off your root partition. Are you sure that it is consuming actual space on your nodes?


Remove puts _params in Push Notification

Removes output when calling as_json method.
Why? Output gets printed in test suite:
> rspec spec/models/push_notification_spec.rb

Randomized with seed 26855

PushNotification
  #send_notification
    calls SendPushNotifications
  #to_expo
{:title=>"Title", :body=>"Message", :sound=>"bam"}
    gets converted to Expo push notification

Ah haha. That's not intended :)
Do you need a release on rubygems or will you reference this?

Ah haha. That's not intended :)
Do you need a release on rubygems or will you reference this?

A batch release would be preferred if there's no other planned anytime soon 🙏🏻

Ping me if you don't have it by next week please!

@SleeplessByte ping!

https://rubygems.org/gems/expo-server-sdk/versions/0.1.5


Using enum with type scalar

Running into an error where I'd like to use type: scalar and enum: [true, false, recursive].  Using version 1.6.1.
Schema:
type: scalar
enum: [true, false, recursive]

Example data:
create: recursive

Output:
pykwalify -d test.yaml -s test-schema.yaml -vvvvv
 DEBUG - Setting verbose level: 5
 DEBUG - Arguments from CLI: {'--allow-assertions': False,
 '--data-file': 'test.yaml',
 '--extension': [],
 '--fix-ruby-style-regex': False,
 '--quiet': False,
 '--schema-file': ['test-schema.yaml'],
 '--strict-rule-validation': False,
 '--verbose': 5}
 DEBUG - Using yaml library: /usr/local/lib/python3.6/site-packages/yaml/__init__.py
 DEBUG - source_file: test.yaml
 DEBUG - schema_file: ['test-schema.yaml']
 DEBUG - source_data: None
 DEBUG - schema_data: None
 DEBUG - extension files: []
 DEBUG - loading all extensions : []
 DEBUG - []
 DEBUG - []
 DEBUG - starting core
 DEBUG - Building root rule object
 DEBUG - Init schema: {'type': 'scalar', 'enum': [True, False, 'recursive']}
 DEBUG - Init type value :
 DEBUG - Type: scalar Rule: {'type': 'scalar', 'enum': [True, False, 'recursive']}
 DEBUG - Init enum value :
Traceback (most recent call last):
  File "/usr/local/bin/pykwalify", line 11, in <module>
    sys.exit(cli_entrypoint())
  File "/usr/local/lib/python3.6/site-packages/pykwalify/cli.py", line 95, in cli_entrypoint
    run(parse_cli())
  File "/usr/local/lib/python3.6/site-packages/pykwalify/cli.py", line 82, in run
    c.validate()
  File "/usr/local/lib/python3.6/site-packages/pykwalify/core.py", line 155, in validate
    self._start_validate(self.source)
  File "/usr/local/lib/python3.6/site-packages/pykwalify/core.py", line 197, in _start_validate
    root_rule = Rule(schema=self.schema)
  File "/usr/local/lib/python3.6/site-packages/pykwalify/rule.py", line 66, in __init__
    self.init(schema, "")
  File "/usr/local/lib/python3.6/site-packages/pykwalify/rule.py", line 443, in init
    func_mapping[k](v, rule, path)
  File "/usr/local/lib/python3.6/site-packages/pykwalify/rule.py", line 847, in init_enum_value
    if not isinstance(item, self.type_class):
TypeError: isinstance() arg 2 must be a type or tuple of types

Just commenting out lines 847-852 in pykwalify/rule.py works around the issue.  Can't say I know of a better solution to the problem, would like input there.

First off, this is a interesting bug that you found out and that might require some additional checks to avoid it.
But you are still using the rules wrong. In your example, your data section is basically the following json data {"create": "recursive"} and that schema you have will not validate against that. What you basically say with your schema is that you should have one top level item of some kind like only a string or boolean value. But the problem is that you really can't have that kind of data structure becuase you need to have a list or a dict as data on the top level.
So basically you need to alter your schema to something like the following
mapping:
  create:
    type: scalar
    enum: [True, False, Recursvie]

(Did not test the schema but it should work i think)


Add 3rd person to the Features list

As the title suggests, we don't have 3rd person linked to the read me.

Also updated the VR sample cover image

This VR image looks nice!


NameError: name 'QtCore' is not defined

Hello. I followed your install instructions exactly and I can get the AE Python window to open. I tried a few of your demo codes and I keep getting NameError: name 'QtCore' is not defined and NameError: name 'importlib' is not defined. Also I am getting NameError: name 'scriptName' is not defined
Do you know why this is happening?
Thank you!

Nevermind, you need to execute the sample scripts by File > Execute Python Script. You can't just copy and past the code into the editor. Thanks!


Thread pool induced deadlocks and starvation

Dear all,
I was running into issues when running Kytos in a medium-size environment [1] where the Kytos controller suddenly gets stuck and stops answering OpenFlow messages, switches get disconnected and never connect again, Napps stop handling events, etc. After adding a few extra log messages to the code [2], I could notice the following behavior which is very likely to be a deadlock/starvation induced by the thread pool way of managing the threads.
Quoting an explanation from the web:

(...) Thread pool induced deadlocks may differ on the difficulty of finding their cause, but they most often follow the same schema. The simplest reason of deadlock is depending in one task (T1) on the results of another task (T2). If a thread pool is full and the second task (T2) gets queued, the first task (T1) might block and wait infinitely. Classic deadlock appears then: thread in a pool is occupied by the first task (T1) which waits for the second task (T2) that cannot be executed because all threads in a pool are busy. (...)

The first thing I noticed was the ThreadPoolExecutor queue size growing uncontrolled (output was summarized by minute to avoid very long output):
grep 'thread pool queue size' /var/log/kytos/kytos.log | uniq -w 16
2022-04-24 17:52:33,173 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:53:00,001 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:54:00,002 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:55:00,023 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:56:00,367 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:57:00,456 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:58:00,559 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 17:59:00,003 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 18:00:00,013 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 0
2022-04-24 18:01:00,849 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 419
2022-04-24 18:02:00,498 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1118
2022-04-24 18:03:00,060 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 2196
2022-04-24 18:04:00,136 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 3276
2022-04-24 18:05:00,206 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 4356
2022-04-24 18:06:00,277 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 5427
2022-04-24 18:07:00,352 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 6507
2022-04-24 18:08:00,424 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 7585
2022-04-24 18:09:00,005 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 8644
2022-04-24 18:10:00,065 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 9722
2022-04-24 18:11:00,139 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 10802
2022-04-24 18:12:00,209 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 11882
2022-04-24 18:13:00,285 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 12962
...
2022-04-25 12:51:00,099 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1116846
2022-04-25 12:52:00,172 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1117926
2022-04-25 12:53:00,239 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1119006
2022-04-25 12:54:00,312 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1120086
2022-04-25 12:55:00,387 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1121166
2022-04-25 12:56:00,459 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 1122246

Then, trying to understand what happened at the time thread pool queue size started growing, I've looked at events triggers right before that moment. After a few investigation, it come to my attention that most of them were related to Locks (threading Locks and Filelocks) and they looked just like a deadlock and starvation scenario:
One of the very previous messages logged before thread pool queue size start growing was this:
2022-04-24 19:34:14,553 - DEBUG [kytos.napps.kytos/flow_manager] (ThreadPoolExecutor-0_244) Lock trying to acquire lineno 265 uuid 05ecb018fed743a2aceba708826b129d

The log above was related to the Lock at Flow Manager _publish_installed_flow() with self._storehouse_lock: line. Then the question become: who was holding that Lock and what happened to that thread? The answer comes a few milliseconds before in the log:
2022-04-24 19:34:14,321 - DEBUG [kytos.napps.kytos/flow_manager] (ThreadPoolExecutor-0_147) Lock acquired lineno 267 uuid b24337dd58004cdfbcb99fe07a5612c8

Looking at the other part of the question (what happened to that thread?), this particular thread was also blocked into a Lock (but this time the flow_manager.storehouse._lock Lock) a few milliseconds after it acquires the flow_manager._storehouse_lock Lock:
2022-04-24 19:34:14,343 - DEBUG [kytos.napps.kytos/flow_manager] (ThreadPoolExecutor-0_147) save_flow (wait lock) namespace kytos.flow.persistence box_id c354ebb9bbea4638b720ce5906e66f56 uuid 19d9d648d5c8426ab1e50e5f896be003

The question then becomes: who was holding the flow_manager.storehouse._lock  Lock and what happened to that thread? The answer once again was a few milliseconds before at the log:
2022-04-24 19:34:14,225 - DEBUG [kytos.napps.kytos/flow_manager] (Thread-884) Lock <locked _thread.lock object at 0x7fe34e4e66c0> acquired.

Looking into the log messages, the Lock was never released:
root@d5d19a072126:/# awk '/^2022-04-24 19:34:14,225/,0' /var/log/kytos/kytos.log | grep '_thread.lock object at 0x7fe34e4e66c0'
2022-04-24 19:34:14,225 - DEBUG [kytos.napps.kytos/flow_manager] (Thread-884) Lock <locked _thread.lock object at 0x7fe34e4e66c0> acquired.
root@d5d19a072126:/#

What happened to this thread can be answered by looking at the sequence of log messages below (log entries below were manually organized to facilitate comprehension):
2022-04-24 19:34:14,225 - DEBUG [kytos.napps.kytos/flow_manager] (Thread-884) Lock <locked _thread.lock object at 0x7fe34e4e66c0> acquired.
2022-04-24 19:34:14,282 - DEBUG [kytos.napps.kytos/flow_manager] (Thread-884) storehouse.update namespace kytos.flow.persistence box_id c354ebb9bbea4638b720ce5906e66f56 uuid<PHONE_NUMBER>674af3a7e7b87b52aa82ce
2022-04-24 19:34:14,289 - DEBUG [kytos.core.buffers] (Thread-884) [buffer: app_event] Added: kytos.storehouse.update
2022-04-24 19:34:14,380 - DEBUG [kytos.core.buffers] (MainThread) [buffer: app_event] Removed: kytos.storehouse.update
2022-04-24 19:34:14,385 - DEBUG [kytos.core.controller] (MainThread) looking for listeners for kytos.storehouse.update

The first line is the lock acquired from flow_manager.storehouse component. The second message is the debug message I've added just before calling self.controller.buffers.app.put(event). The third is the Kytos core component informing that the message was added to KytosBuffer app_event queue. Then, the fourth and fifth messages are the Kytos core asyncio tasks that should create a thread and process the event in that thread. Indeed, I've added a log message right in the beginning of storehouse's handler for kytos.storehouse.update , however that log message was never seen after looking for listeners for kytos.storehouse.update :
root@d5d19a072126:/# awk '/^2022-04-24 19:34:14,385/,0' /var/log/kytos/kytos.log | grep storehouse.backend.update
root@d5d19a072126:/#

Why is that? I believe that is because the thread pool size (defaults to 256) is already full of requests in the waiting room and never gets the opportunity to create a thread to handle this request (which could unblock other threads that are actually blocking this one.. and there is where we have a deadlock/starvation). At that moment, all thread pool workers were allocated and the backlog/waiting-queue was already growing:
root@d5d19a072126:/# awk '/^2022-04-24 19:34:14,385/,0' /var/log/kytos/kytos.log | grep 'thread pool queue size'  | uniq -w 21 | head -n 20
2022-04-24 19:34:14,388 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 46
2022-04-24 19:34:14,402 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 47
2022-04-24 19:34:14,500 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 56
2022-04-24 19:34:15,385 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 56
2022-04-24 19:34:16,385 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 59
2022-04-24 19:34:17,388 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 65
2022-04-24 19:34:17,509 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 68
2022-04-24 19:34:17,602 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 76
2022-04-24 19:34:17,700 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 81
2022-04-24 19:34:18,389 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 84
2022-04-24 19:34:19,390 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 90
2022-04-24 19:34:20,391 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 93
2022-04-24 19:34:20,733 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 99
2022-04-24 19:34:20,803 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 106
2022-04-24 19:34:20,900 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 110
2022-04-24 19:34:21,393 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 115
2022-04-24 19:34:22,393 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 118
2022-04-24 19:34:23,394 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 124
2022-04-24 19:34:23,401 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 125
2022-04-24 19:34:23,961 - DEBUG [kytos.core.controller] (MainThread) thread pool queue size 127

[1] Description of the scenario
Kytos running into a docker container, using amlight/kytos:latest. Mininet topology was based on AmlightTopo (tmux new-sess -d -s mn mn --custom /e2e-tests/tests/helpers.py --topo amlight --controller=remote,ip=<IP_ADDRESS>). There were 50 EVCs created between UNIs 00:00:00:00:00:00:00:16:55 and 00:00:00:00:00:00:00:21:60 (dynamic-path). Finally, to stress the system I've disabled one of the links in the path for the 50 EVCs (and mef_eline was running a modified version to process all EVC's link_down event in parallel).
The physical environment running the tests was a server with processor Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz, 12 vcpus, 24GB of RAM memory.
[2] Extra log messages added to kytos (core and napps):
root@d5d19a072126:/src/kytos# git diff
diff --git a/kytos/core/controller.py b/kytos/core/controller.py
index c12a167..0e0da56 100644
--- a/kytos/core/controller.py
+++ b/kytos/core/controller.py
@@ -493,6 +493,8 @@ class Controller:
             event (~kytos.core.KytosEvent): An instance of a KytosEvent.
         """
         self.log.debug("looking for listeners for %s", event)
+        if executor_pool:
+            self.log.debug("thread pool queue size %d", executor_pool._work_queue.qsize())
         for event_regex, listeners in dict(self.events_listeners).items():
             # self.log.debug("listeners found for %s: %r => %s", event,
             #                event_regex, [l.__qualname__ for l in listeners])
root@d5d19a072126:/src/kytos-flow-manager# git diff
diff --git a/main.py b/main.py
index 911fbd1..d5fb498 100644
--- a/main.py
+++ b/main.py
@@ -7,6 +7,8 @@ from collections import OrderedDict, defaultdict
 from copy import deepcopy
 from enum import Enum
 from threading import Lock
+import inspect
+import uuid

 from flask import jsonify, request
 from napps.kytos.flow_manager.match import match_flow, match_strict_flow
@@ -154,8 +156,12 @@ class Main(KytosNApp):
         switch = event.content["source"].switch
         if not switch:
             return
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._check_consistency_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self.reset_check_consistency_exec(switch.id)
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

     def reset_check_consistency_exec(self, dpid):
         """Reset _check_consistency_exec_at for a dpid."""
@@ -214,20 +220,28 @@ class Main(KytosNApp):
         switch = event.source.switch
         message = event.message
         xid = int(message.header.xid)
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._pending_barrier_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             flow_xid = self._pending_barrier_reply[switch.id].pop(xid, None)
             if not flow_xid:
                 log.error(
                     f"Failed to pop barrier reply xid: {xid}, flow xid: {flow_xid}"
                 )
                 return
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._flow_mods_sent_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             if flow_xid not in self._flow_mods_sent:
                 log.error(
                     f"Flow xid: {flow_xid} not in flow mods sent. Inconsistent state"
                 )
                 return
             flow, _ = self._flow_mods_sent[flow_xid]
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

         """
         It should only publish installed flow if it the original FlowMod xid hasn't
@@ -235,18 +249,26 @@ class Main(KytosNApp):
         hasn't been sent out or processed yet this can happen if the network latency
         is super low.
         """
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._flow_mods_sent_error_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             error_kwargs = self._flow_mods_sent_error.get(flow_xid)
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         if not error_kwargs:
             self._publish_installed_flow(switch, flow)

     def _publish_installed_flow(self, switch, flow):
         """Publish installed flow when it's confirmed."""
         self._send_napp_event(switch, flow, "add")
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._storehouse_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self._update_flow_state_store(
                 switch.id, set([flow.id]), FlowEntryState.INSTALLED.value
             )
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

     @listen_to("kytos/of_core.flow_stats.received")
     def on_flow_stats_publish_installed_flows(self, event):
@@ -272,10 +294,14 @@ class Main(KytosNApp):
             flow_ids_to_update.add(_id)
             self._send_napp_event(switch, installed_flow, "add")

+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._storehouse_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self._update_flow_state_store(
                 switch.id, flow_ids_to_update, FlowEntryState.INSTALLED.value
             )
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

     def _retry_on_openflow_connection_error(
         self,
@@ -309,7 +335,10 @@ class Main(KytosNApp):
             )
         switch = event.content["destination"].switch

+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._flow_mods_retry_count_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             if xid not in self._flow_mods_retry_count:
                 self._flow_mods_retry_count[xid] = (0, now(), min_wait)
             (count, sent_at, wait_acc) = self._flow_mods_retry_count[xid]
@@ -327,6 +356,7 @@ class Main(KytosNApp):
                 datetime_t2,
                 wait_acc * multiplier,
             )
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         try:
             wait_diff = get_min_wait_diff(datetime_t2, sent_at, wait_acc)
             if wait_diff:
@@ -350,7 +380,10 @@ class Main(KytosNApp):
         """Check consistency of stored and installed flows given a switch."""
         if not ENABLE_CONSISTENCY_CHECK or not switch.is_enabled():
             return
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._check_consistency_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             exec_at = self._check_consistency_exec_at.get(
                 switch.id, "0001-01-01T00:00:00"
             )
@@ -365,6 +398,7 @@ class Main(KytosNApp):
             self._check_consistency_exec_at[switch.id] = now().strftime(
                 "%Y-%m-%dT%H:%M:%S"
             )
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         log.debug(f"check_consistency on switch {switch.id} has started")
         self.check_storehouse_consistency(switch)
         if switch.dpid in self.stored_flows:
@@ -615,7 +649,10 @@ class Main(KytosNApp):
         """Add archived flows in memory (will be stored in the DB in the future)."""
         if not archived_flows:
             return
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._archived_flows_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             if dpid not in self.archived_flows:
                 self.archived_flows[dpid] = OrderedDict()
             for archived_flow in archived_flows:
@@ -623,6 +660,7 @@ class Main(KytosNApp):

             while len(self.archived_flows[dpid]) > max_len:
                 self.archived_flows[dpid].popitem(last=False)
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

     def _update_flow_state_store(self, dpid, flow_ids, state):
         """Try to bulk update the state of some flow ids given a dpid."""
@@ -866,14 +904,22 @@ class Main(KytosNApp):
                 except SwitchNotConnectedError:
                     if reraise_conn:
                         raise
+                my_uuid = uuid.uuid4().hex
+                log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                 with self._flow_mods_sent_lock:
+                    log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                     self._add_flow_mod_sent(flow_mod.header.xid, flow, command)
+                log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                 self._send_napp_event(switch, flow, "pending")

                 if not save:
                     continue
+                my_uuid = uuid.uuid4().hex
+                log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                 with self._storehouse_lock:
+                    log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                     self._store_changed_flows(command, flow_dict, flow.id, switch)
+                log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

     def _add_flow_mod_sent(self, xid, flow, command):
         """Add the flow mod to the list of flow mods sent."""
@@ -896,8 +942,12 @@ class Main(KytosNApp):

         barrier_request = new_barrier_request(switch.connection.protocol.version)
         barrier_xid = barrier_request.header.xid
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._pending_barrier_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self._add_barrier_request(switch.id, barrier_xid, flow_mod.header.xid)
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))

         content = {"destination": switch.connection, "message": barrier_request}
         event = KytosEvent(name=event_name, content=content)
@@ -953,8 +1003,12 @@ class Main(KytosNApp):
             "error_command": error_command,
             "error_exception": event.content.get("exception"),
         }
+        my_uuid = uuid.uuid4().hex
+        log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         with self._flow_mods_sent_error_lock:
+            log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self._flow_mods_sent_error[int(event.message.header.xid)] = error_kwargs
+        log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
         self._send_napp_event(
             switch,
             flow,
@@ -1013,12 +1067,20 @@ class Main(KytosNApp):
                 "error_type": error_type,
                 "error_code": error_code,
             }
+            my_uuid = uuid.uuid4().hex
+            log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             with self._flow_mods_sent_error_lock:
+                log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                 self._flow_mods_sent_error[int(event.message.header.xid)] = error_kwargs
+            log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             log.warning(
                 f"Deleting flow: {flow.as_dict()}, xid: {xid}, cookie: {flow.cookie}, "
                 f"error: {error_kwargs}"
             )
+            my_uuid = uuid.uuid4().hex
+            log.debug("Lock trying to acquire lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             with self._storehouse_lock:
+                log.debug("Lock acquired lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
                 self._del_stored_flow_by_id(switch.id, flow.cookie, flow.id)
+            log.debug("Lock done lineno %d uuid %s" % (inspect.stack()[0].lineno, my_uuid))
             self._send_napp_event(flow.switch, flow, "error", **error_kwargs)
diff --git a/storehouse.py b/storehouse.py
index 81d32c7..8e33c0f 100644
--- a/storehouse.py
+++ b/storehouse.py
@@ -1,6 +1,7 @@
 """Module to handle the storehouse."""
 import threading
 import time
+import uuid

 from napps.kytos.flow_manager import settings

@@ -91,16 +92,20 @@ class StoreHouse:
     # pylint: disable=consider-using-with
     def get_stored_box(self, box_id):
         """Get persistence box from storehouse."""
+        my_uuid = uuid.uuid4().hex
         content = {
             "namespace": self.namespace,
             "callback": self._get_box_callback,
             "box_id": box_id,
+            'my_uuid': my_uuid,
             "data": {},
         }
         name = "kytos.storehouse.retrieve"
         event = KytosEvent(name=name, content=content)
+        log.debug("get_stored_box (wait lock) namespace %s box_id %s uuid %s" % (self.namespace, box_id, my_uuid))
         self._lock.acquire()  # Lock to avoid race condition
         log.debug(f"Lock {self._lock} acquired.")
+        log.debug("storehouse.retrieve namespace %s box_id %s uuid %s" % (self.namespace, box_id, my_uuid))
         self.controller.buffers.app.put(event)

     def _get_box_callback(self, _event, data, error):
@@ -115,6 +120,8 @@ class StoreHouse:
     # pylint: disable=consider-using-with
     def save_flow(self, flows):
         """Save flows in storehouse."""
+        my_uuid = uuid.uuid4().hex
+        log.debug("save_flow (wait lock) namespace %s box_id %s uuid %s" % (self.namespace, self.box.box_id, my_uuid))
         self._lock.acquire()  # Lock to avoid race condition
         log.debug(f"Lock {self._lock} acquired.")
         self.box.data[flows["id"]] = flows
@@ -122,10 +129,12 @@ class StoreHouse:
             "namespace": self.namespace,
             "box_id": self.box.box_id,
             "data": self.box.data,
+            'my_uuid': my_uuid,
             "callback": self._save_flow_callback,
         }

         event = KytosEvent(name="kytos.storehouse.update", content=content)
+        log.debug("storehouse.update namespace %s box_id %s uuid %s" % (self.namespace, self.box.box_id, my_uuid))
         self.controller.buffers.app.put(event)

     def _save_flow_callback(self, _event, data, error):
root@d5d19a072126:/src/kytos-storehouse# git diff
diff --git a/main.py b/main.py
index 42cbd87..cba06b7 100644
--- a/main.py
+++ b/main.py
@@ -291,7 +291,9 @@ class Main(KytosNApp):
     def event_retrieve(self, event):
         """Retrieve a box from a namespace based on an event."""
         error = None
+        my_uuid = event.content.get('my_uuid', uuid4().hex)

+        log.debug("storehouse.backend.retrieve namespace %s box_id %s uuid %s" % (event.content['namespace'], event.content['box_id'], my_uuid))
         try:
             box = self.backend.retrieve(event.content['namespace'],
                                         event.content['box_id'])
@@ -299,6 +301,7 @@ class Main(KytosNApp):
             box = None
             error = exc

+        log.debug("storehouse.backend.retrieve done (exec callback) namespace %s box_id %s uuid %s" % (event.content['namespace'], event.content['box_id'], my_uuid))
         self._execute_callback(event, box, error)

     @listen_to('kytos.storehouse.update')
@@ -313,7 +316,9 @@ class Main(KytosNApp):
         data: a python dict with the data
         """
         error = False
+        my_uuid = event.content.get('my_uuid', uuid4().hex)

+        log.debug("storehouse.backend.update namespace %s box_id %s uuid %s" % (event.content['namespace'], event.content['box_id'], my_uuid))
         try:
             namespace = event.content['namespace']
             box_id = event.content['box_id']
@@ -335,6 +340,7 @@ class Main(KytosNApp):

             self.backend.update(namespace, box)

+        log.debug("storehouse.backend.update done (exec callback) namespace %s box_id %s uuid %s" % (event.content['namespace'], event.content['box_id'], my_uuid))
         self._execute_callback(event, box, error)

     @listen_to('kytos.storehouse.delete')

Running Kytos in the standard Thread (non thread pool) strategy seems to workaround for this issue:
tmux new-session -d -s kytosserver "kytosd -E -f -t 0"

@italovalcy thanks for reporting this and this helpful debug analysis, very interesting and I'm glad this was caught at this stage.
I believe storehouse async lock acquire/release on different thread is the only situation that is vulnerable to reach to this major starvation issue since on other listen_to decorators the lock is held with a context manager. I think the solution will be multifold and it might have some overlap with priority queues (I mean we'll probably want to have a solution aligned to that too).
1 - We could have multiple ThreadPoolExecutors where each should be used accordingly depending on the priority or how critical the category of the event is, for instance we could seggregate into:

control: for control plane related stuff, but aren't primarily IO-bound
io: for handlers that are IO-bound
napps: for anything else (default)

That way we could parametrize accordingly in the decorator the category of that handler with a pool parameter or something similar, for instance:
@listen_to("kytos/of_core.v0x0[14].messages.in.ofpt_barrier_reply", pool="io")
It's probably worth mentioning that as we migrate to Mongo, the number of locks will also tend to reduce (including that async aquire/release), however, we probably want to make sure that IO/control bound handlers still have higher priority.
2 - We might also need to reassess the default number of workers in the default thread pool depending if we have additional ones.
Out of curiosity, is it reproducing deterministically with this topology? Let me know also what you think about these initial ideas.

@viniarck I've tried to modify flow_manager's storehouse to use context based locks but so far no good outcomes. Here are more details:
First of all, below is the modification I made in mef_eline to process multiple EVCs in parallel (as events) upon link down message:
root@7434f28148ff:/src/kytos-mef-eline# git diff
diff --git a/main.py b/main.py
index 3a59a6b..4569a58 100644
--- a/main.py
+++ b/main.py
@@ -639,23 +639,45 @@ class Main(KytosNApp):

     def handle_link_down(self, event):
         """Change circuit when link is down or under_mantenance."""
-        log.debug("Event handle_link_down %s", event)
+        log.info("Event handle_link_down %s", event)
         for evc in self.circuits.values():
-            with evc.lock:
-                if evc.is_affected_by_link(event.content["link"]):
-                    log.debug(f"Handling evc {evc.id} on link down")
-                    if evc.handle_link_down():
-                        emit_event(
-                            self.controller,
-                            "redeployed_link_down",
-                            evc_id=evc.id,
-                        )
-                    else:
-                        emit_event(
-                            self.controller,
-                            "error_redeploy_link_down",
-                            evc_id=evc.id,
-                        )
+            if evc.is_affected_by_link(event.content["link"]):
+                emit_event(
+                    self.controller,
+                    "evc_affected_by_link_down",
+                    evc_id=evc.id,
+                    link=event.content["link"],
+                )
+
+    @listen_to("kytos/mef_eline.evc_affected_by_link_down")
+    def on_evc_affected_by_link_down(self, event):
+        """Change circuit when link is down or under_mantenance."""
+        self.handle_evc_affected_by_link_down(event)
+
+    def handle_evc_affected_by_link_down(self, event):
+        try:
+            evc = self.circuits[event.content["evc_id"]]
+        except KeyError:
+            result = f"circuit_id {circuit_id} not found"
+            log.error("handle evc affected by link down - invalid circuit_id"
+                      f" {circuit_id}")
+
+        log.info(f"Handling evc {evc.id} on link down")
+        # TODO: if link is already up here, can we just ignore this event?
+        with evc.lock:
+            if evc.handle_link_down():
+                emit_event(
+                    self.controller,
+                    "redeployed_link_down",
+                    evc_id=evc.id,
+                )
+                log.info(f"EVC {evc.id} redeployed due to link down")
+            else:
+                emit_event(
+                    self.controller,
+                    "error_redeploy_link_down",
+                    evc_id=evc.id,
+                )

     def load_all_evcs(self):
         """Try to load all EVCs on startup."""

Change I've made to flow_manager's storehouse to use context based locks:
diff --git a/settings.py b/settings.py
index 6b904c3..b48c1ad 100644
--- a/settings.py
+++ b/settings.py
@@ -20,3 +20,10 @@ ARCHIVED_FLOWS_MAX_SIZE = 5000
 CONN_ERR_MAX_RETRIES = 3
 CONN_ERR_MIN_WAIT = 1  # minimum wait between iterations in seconds
 CONN_ERR_MULTIPLIER = 2  # multiplier for the accumulated wait on each iteration
+
+# Time (in seconds) to wait for a confirmation from storehouse
+# when retrieving or updating a box
+STOREHOUSE_TIMEOUT = 5.0
+
+# Time (in seconds) to sleep while waiting from storehouse (busy wait)
+STOREHOUSE_WAIT_INTERVAL = 0.05
diff --git a/storehouse.py b/storehouse.py
index 81d32c7..d248385 100644
--- a/storehouse.py
+++ b/storehouse.py
@@ -36,15 +36,17 @@ class StoreHouse:
             self.box = None
         if "_lock" not in self.__dict__:
             self._lock = threading.Lock()
+        self.storehouse_done = False
+        self.storehouse_error = None
         self.list_stored_boxes()

     def get_data(self):
         """Return the persistence box data."""
         # Wait retrieve or create box in storehouse
         i = 0
-        while not self.box and i < BOX_RESTORE_ATTEMPTS:
-            time.sleep(self.box_restore_timer)
-            i += 1
+        while not self.box and i < settings.STOREHOUSE_TIMEOUT:
+            time.sleep(settings.STOREHOUSE_WAIT_INTERVAL)
+            i += settings.STOREHOUSE_WAIT_INTERVAL
         if not self.box:
             error = "Error retrieving persistence box from storehouse."
             log.error(error)
@@ -91,48 +93,69 @@ class StoreHouse:
     # pylint: disable=consider-using-with
     def get_stored_box(self, box_id):
         """Get persistence box from storehouse."""
-        content = {
-            "namespace": self.namespace,
-            "callback": self._get_box_callback,
-            "box_id": box_id,
-            "data": {},
-        }
-        name = "kytos.storehouse.retrieve"
-        event = KytosEvent(name=name, content=content)
-        self._lock.acquire()  # Lock to avoid race condition
-        log.debug(f"Lock {self._lock} acquired.")
-        self.controller.buffers.app.put(event)
-
-    def _get_box_callback(self, _event, data, error):
+        with self._lock:
+            self.storehouse_done = False
+            self.storehouse_error = None
+            content = {
+                "namespace": self.namespace,
+                "callback": self._storehouse_callback,
+                "box_id": box_id,
+                "data": {},
+            }
+            name = "kytos.storehouse.retrieve"
+            event = KytosEvent(name=name, content=content)
+            self.controller.buffers.app.put(event)
+
+            i = 0
+            while not self.storehouse_done and i < settings.STOREHOUSE_TIMEOUT:
+                time.sleep(settings.STOREHOUSE_WAIT_INTERVAL)
+                i += settings.STOREHOUSE_WAIT_INTERVAL
+
+            if not self.storehouse_done:
+                self.storehouse_error = 'Timeout while waiting for storehouse'
+
+            if self.storehouse_error:
+                log.error('Fail to update persistence box in '
+                          f'{self.namespace}.{self.box.box_id}. '
+                          f'Error: {self.storehouse_error}')
+                return
+
+        log.debug(f"get_stored_box done {self.namespace}.{self.box.box_id}")
+
+    def _storehouse_callback(self, _event, data, error):
         """Handle get_box method saving the box or logging with the error."""
-        if error:
-            log.error("Persistence box not found.")
-
-        self.box = data
-        self._lock.release()
-        log.debug(f"Lock {self._lock} released.")
+        self.storehouse_done = True
+        self.storehouse_error = error

     # pylint: disable=consider-using-with
     def save_flow(self, flows):
         """Save flows in storehouse."""
-        self._lock.acquire()  # Lock to avoid race condition
-        log.debug(f"Lock {self._lock} acquired.")
-        self.box.data[flows["id"]] = flows
-        content = {
-            "namespace": self.namespace,
-            "box_id": self.box.box_id,
-            "data": self.box.data,
-            "callback": self._save_flow_callback,
-        }
-
-        event = KytosEvent(name="kytos.storehouse.update", content=content)
-        self.controller.buffers.app.put(event)
-
-    def _save_flow_callback(self, _event, data, error):
-        """Display stored flow."""
-        self._lock.release()
-        log.debug(f"Lock {self._lock} released.")
-        if error:
-            log.error(f"Can't update persistence box {data.box_id}.")
-
-        log.info(f"Flow saved in {self.namespace}.{data.box_id}")
+        with self._lock:
+            self.storehouse_done = False
+            self.storehouse_error = None
+            self.box.data[flows["id"]] = flows
+            content = {
+                "namespace": self.namespace,
+                "box_id": self.box.box_id,
+                "data": self.box.data,
+                "callback": self._storehouse_callback,
+            }
+
+            event = KytosEvent(name="kytos.storehouse.update", content=content)
+            self.controller.buffers.app.put(event)
+
+            i = 0
+            while not self.storehouse_done and i < settings.STOREHOUSE_TIMEOUT:
+                time.sleep(settings.STOREHOUSE_WAIT_INTERVAL)
+                i += settings.STOREHOUSE_WAIT_INTERVAL
+
+            if not self.storehouse_done:
+                self.storehouse_error = 'Timeout while waiting for storehouse'
+
+            if self.storehouse_error:
+                log.error('Fail to update persistence box in '
+                          f'{self.namespace}.{self.box.box_id}. '
+                          f'Error: {self.storehouse_error}')
+                return
+
+        log.info(f"Flow saved in {self.namespace}.{self.box.box_id}")

Steps to reproduce are basically:

Run Kytos docker imagem from docker hub: docker run -d --name k2 --privileged -v $(pwd)/kytos-end-to-end-tests:/e2e-tests -w /e2e-tests amlight/kytos
Run mininet with Amlight's topology: tmux new-sess -d -s mn mn --custom /e2e-tests/tests/helpers.py --topo amlight --controller=remote,ip=<IP_ADDRESS>
Create a few EVCs with dynamic path from certain UNIs:

root@7434f28148ff:/e2e-tests# cat create-evc-dyn.sh
#!/bin/bash

IFACEID_A=00:00:00:00:00:00:00:16:55
IFACEID_Z=00:00:00:00:00:00:00:21:60

VLAN_A=$1
VLAN_Z=$2
test -z "$VLAN_Z" && VLAN_Z=$VLAN_A

for VLAN in $(seq $VLAN_A $VLAN_Z); do
	curl --max-time 120 -H 'Content-type: application/json' -X POST http://<IP_ADDRESS>:8181/api/kytos/mef_eline/v2/evc -d '{"name": "my evc '$VLAN'", "dynamic_backup_path": true, "enabled": true, "uni_a": {"tag": {"value": '$VLAN', "tag_type": 1}, "interface_id": "'$IFACEID_A'"}, "uni_z": {"tag": {"value": '$VLAN', "tag_type": 1}, "interface_id": "'$IFACEID_Z'"}}'
done
root@7434f28148ff:/e2e-tests# ./create-evc-dyn.sh 400 449
...

Access Mininet and simulate a link down event: tmux send-keys -t mn "sh ip link set up AL2-eth6" ENTER

@italovalcy appreciated your help and investigation, thanks also for the topology you shared, it facilitated to reproduce the issue, the fix is under review on PR #213.


make clean init build docker fails on a Mac

Bug description
make clean init build docker` fails on a Mac
make clean init build docker docker.push
Building with your local toolchain.
=> cleaning...
rm -rf  /Users/ericvn/work/go/out/darwin_amd64/release /Users/ericvn/work/go/out/linux_amd64/release
rm -f  install/consul/istio.yaml install/kubernetes/istio-auth.yaml install/kubernetes/istio-citadel-plugin-certs.yaml install/kubernetes/istio-citadel-with-health-check.yaml install/kubernetes/istio-one-namespace-auth.yaml install/kubernetes/istio-one-namespace-trust-domain.yaml install/kubernetes/istio-one-namespace.yaml install/kubernetes/istio.yaml samples/bookinfo/platform/consul/bookinfo.sidecars.yaml
ISTIO_OUT=/Users/ericvn/work/go/out/darwin_amd64/release bin/init.sh
Skipping envoy debug. Set DEBUG_IMAGE to download.
~/work/go/out/linux_amd64/release ~/work/go/src/istio.io/istio
Downloading Envoy: curl -fLSs https://storage.googleapis.com/istio-build/proxy/envoy-alpha-c85d04a044f4245a3c6dd335b012a6d8e6430d74.tar.gz to /Users/ericvn/work/go/out/linux_amd64/release/envoy-c85d04a044f4245a3c6dd335b012a6d8e6430d74

real	0m1.837s
user	0m0.302s
sys	0m0.114s
Copying /Users/ericvn/work/go/out/linux_amd64/release/envoy-c85d04a044f4245a3c6dd335b012a6d8e6430d74 to /Users/ericvn/work/go/out/linux_amd64/release/envoy
~/work/go/src/istio.io/istio
~/work/go/out/darwin_amd64/release ~/work/go/src/istio.io/istio
Downloading Envoy: curl -fLSs https://github.com/istio/proxy/releases/download/1.0.2/istio-proxy-1.0.2-macos.tar.gz to /Users/ericvn/work/go/out/darwin_amd64/release/envoy-1.0.2

real	0m2.764s
user	0m0.158s
sys	0m0.083s
Copying /Users/ericvn/work/go/out/darwin_amd64/release/envoy-1.0.2 to /Users/ericvn/work/go/out/darwin_amd64/release/envoy
~/work/go/src/istio.io/istio
Copying /Users/ericvn/work/go/out/darwin_amd64/release/envoy-1.0.2 to /Users/ericvn/work/go/out/darwin_amd64/release/envoy
Copying /Users/ericvn/work/go/out/darwin_amd64/release/envoy to /Users/ericvn/work/go/bin/envoy
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 9520k  100 9520k    0     0  8806k      0  0:00:01  0:00:01 --:--:-- 8806k
touch /Users/ericvn/work/go/out/darwin_amd64/release/istio_is_init
mkdir -p /Users/ericvn/work/go/out/logs
STATIC=0 GOOS=darwin GOARCH=amd64 LDFLAGS='-extldflags -static -s -w' common/scripts/gobuild.sh /Users/ericvn/work/go/out/darwin_amd64/release/ ./istioctl/cmd/istioctl ./pilot/cmd/pilot-discovery ./pilot/cmd/pilot-agent ./sidecar-injector/cmd/sidecar-injector ./mixer/cmd/mixs ./mixer/cmd/mixc ./mixer/tools/mixgen ./galley/cmd/galley ./security/cmd/node_agent ./security/cmd/node_agent_k8s ./security/cmd/istio_ca ./security/tools/sdsclient ./pkg/test/echo/cmd/client ./pkg/test/echo/cmd/server ./mixer/test/policybackend ./cmd/istiod ./tools/hyperistio ./tools/istio-iptables ./tools/istio-clean-iptables

real	0m26.406s
user	1m31.870s
sys	0m31.665s
make: *** No rule to make target `/Users/ericvn/work/go/out/linux_amd64/release/pilot-discovery', needed by `docker.pilot'.  Stop.

Expected behavior
Command should build Docker images
Steps to reproduce the bug
Get latest source from master branch and run make clean init build docker
Environment where bug was observed (cloud vendor, OS, etc)
Mac OS used for development

A make build-linux is the work-around to make things work, (i.e. make clean init build build-linux docker works).
Just need to add the dependency.


Merge beta into alpha

:tada: This PR is included in version 4.0.0-alpha.3 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-alpha.3 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-beta.2 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Path Based Routing is not working Properly

Describe the bug
When i use pathType: ImplementationSpecific, it is being routed to one of the path I mentioned there(provided I don't give any paths explicitly), no matter what path i give to the host & when i use the pathtype: Prefix, it is always redirecting to alerta and not routing to grafana, even though i gave correct path
To Reproduce*
Steps to reproduce the behavior:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-path-prefix: /
  namespace: monitoring
  name: guidebook
spec:
  defaultBackend:
    service:
      name: alerta-alerta-web
      port:
        number: 80
  rules:
    - host: genix-health-hub.westeurope.cloudapp.azure.com
      http:
        paths:
        - backend:
            service:
              name: alerta-alerta-web
              port:
                number: 80
          path: /alerta*
          pathType: Prefix
        - backend:
            service:
              name: prometheus-monitoring-grafana
              port:
                number: 80
          path: /grafana*
          pathType: Prefix

Ingress Controller details

Output of kubectl describe pod <ingress controller> . The  pod name can be obtained by running helm list.
Name:             ingress-azure-b9f9fc67b-k7hkb
Namespace:        default
Priority:         0
Service Account:  ingress-azure
Node:             aks-userpool-41561070-vmss000001/<IP_ADDRESS>
Start Time:       Mon, 17 Apr 2023 17:36:42 +0000
Labels:           aadpodidbinding=ingress-azure
app=ingress-azure
pod-template-hash=b9f9fc67b
release=ingress-azure
Annotations:      checksum/config: 6b6b9585b05c2aae16e4e95d99442b7cb2f004bd3c7e4f7cc1f59298e7a89f9b
prometheus.io/port: 8123
prometheus.io/scrape: true
Status:           Running
IP:               <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/ingress-azure-b9f9fc67b
Containers:
ingress-azure:
Container ID:   containerd://803c8066a8181cbf74435b2b2e708e80f6265c84ce3a0aee3b1b18d60df6bd2b
Image:          mcr.microsoft.com/azure-application-gateway/kubernetes-ingress:1.6.0
Image ID:       mcr.microsoft.com/azure-application-gateway/kubernetes-ingress@sha256:bccaa701e2dfeaaab978035e16f384d02824191489c95181865a94a38adde407
Port:
Host Port:
State:          Running
Started:      Mon, 17 Apr 2023 17:36:46 +0000
Ready:          True
Restart Count:  0
Liveness:       http-get http://:8123/health/alive delay=15s timeout=1s period=20s #success=1 #failure=3
Readiness:      http-get http://:8123/health/ready delay=5s timeout=1s period=10s #success=1 #failure=3
Environment Variables from:
ingress-azure  ConfigMap  Optional: false
Environment:
AZURE_CLOUD_PROVIDER_LOCATION:  /etc/appgw/azure.json
AGIC_POD_NAME:                  ingress-azure-b9f9fc67b-k7hkb (v1:metadata.name)
AGIC_POD_NAMESPACE:             default (v1:metadata.namespace)
Mounts:
/etc/appgw/ from azure (ro)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-b2vww (ro)
Conditions:
Type              Status
Initialized       True
Ready             True
ContainersReady   True
PodScheduled      True
Volumes:
azure:
Type:          HostPath (bare host directory volume)
Path:          /etc/kubernetes/
HostPathType:  Directory
kube-api-access-b2vww:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  3607
ConfigMapName:           kube-root-ca.crt
ConfigMapOptional:
DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:

were you able to fix this? I am also facing this issue.


[core] Upgrade tshy to ^1.13.0

Packages impacted by this PR

Core packages using ESM migration

Issues associated with this PR

#28940
#28918

Describe the problem that is addressed by this PR
Upgrade to new version of tshy which does not force target to ES2022 (see PR). This should resolve some issues for people whose environments do not support newer syntax (e.g. Node 14 and the Webpack 4 bundler).

API change check
API changes are not detected in this pull request.


setFilter - Multiple value on the same field

Hello, I would like to know if there's a way to use the setFilter function and passing different values for the same field ?
I tried this way, but it doesn't seems to work (did I missed someting):
this.source.setFilter( [
{ field: 'user', search: 'admin' },
{ field: 'user', search: 'user' },
{ field: 'user', search: 'toto' }
]);

You search three value in the same field, so it can't be done

True.
To solve this issue, I simply reload the table on a filtered data array with "user" I wanted to display.


Slider activeColor should support coloring the thumb of the slider at min position

Create a slider that has 3 segments with a unique color for each value. Select segment 1:
new Slider(
  value: 1.0,
  max: 3.0,
  divisions: 3,
  activeColor: Colors.deepOrange[300],
)

results in:

However selecting segment 0 with a color:
new Slider(
  value: 0.0,
  max: 3.0,
  divisions: 3,
  activeColor: Colors.orangeAccent[100],
)

results in:

I understand material design suggests the min value to always be gray but I presume that should be left to the app's discretion since sliders can be used in a variety of contexts and min does not necessarily mean "inactive".
I propose that activeColor to be renamed "color" and apply to min position as well.

The slide actually looks a bit different when inactive.  (The head is smaller is filled in with grey.)
This boils down to how much we want to support people building off-spec.  /cc @Hixie for thoughts.

People want to build off-spec, and will do it whether we make it easy or not. We should probably just get guidance from the material team about what is ok to offer and what isn't.

I would not have made this request if I believed ours was a niche case. Material design is often limiting in terms of real-world functionality and thus should be extended where applicable. For instance, I want a volume slider where the minimum value is 10. 10 isn't "off" so it should not be grayed out. I can think of a whole slew of use cases along similar lines.
I would be happy to make this case to the material team if you include me in the communication.

We want to allow folks to build UIs that are off-spec or not-spec, as there are many degrees of freedom in app UIs. This is especially important as we look for external teams to start using Flutter, as many teams will want to create brand-driven or customized designs. This is an area that Flutter can excel at :)

Ok, sounds like we want to do this.  Will do.

The designers have also concluded that this should be an option.


音檔傳孤聲道就好

Coverage increased (+1.6%) to 64.11% when pulling bc0e090846b7aadcb44cebf8199a0536178e86e8 on 音檔傳孤聲道就好 into bec8020646b2a22ac9184908554b98d6abac5caf on master.