[SIP-110] Proposal for Alert & Report Modal with Dashboard Filters and Tabs

[SIP-110] Proposal for Alert & Report Modal with Dashboard Filters and Tabs
Motivation
We've identified a recurring request for enhanced capabilities in alert and report configurations specifically, the inclusion of more granular filters and tab details. To address this, we are considering updates to the user interface for creating alerts and reports. These updates are aimed at incorporating additional filter and tab options, and reorganizing field groupings to heighten modal clarity and simplify the setup process for users.
Proposed Change
For an overview of the proposed enhancements to Alert and Report Modal, please refer to the design mock-ups in this Superset discussion. Additionally, the proof of concept (POC) can be viewed in this pull request.

Refined User Interface: We're addressing concerns of clutter in the current modal by introducing a design that emphasizes simplicity and order. The new layout will dispense with superfluous elements to reduce user confusion and streamline interaction.
Intuitive Configuration Sequence: The setup process will be restructured into a clear, step-by-step sequence. By guiding users through each phase methodically, we aim to simplify the creation of alerts and reports, thereby minimizing potential errors.
Enhancements and New Functionalities:

Dashboard-Imported Filters/Tabs for Customization: The latest system update introduces a variety of filters and tabs, all imported from the dashboard. This new functionality allows users to effectively customize their alerts and reports to meet specific requirements, enhancing the adaptability and precision of data handling and reporting.
Provision for Test Report Deployment: This new feature enables the dispatch of test reports, a crucial tool for validating report configurations. It ensures reliable and accurate delivery of these reports, operating independently of the standard report scheduling process.

New or Changed Public Interfaces

Dashboard State Management: Upon user interaction with the dashboard dropdown, the useDashboard hook will be utilized to access the selected dashboard. New methods will be implemented to update the dataMask and nativeFilters states in the Redux store. This enhancement is aimed at facilitating the integration of dashboard-specific native filters and tab selections using established hooks like useNativeFiltersDataMask and useFilters. This strategy is designed to ensure a seamless and efficient integration within the existing system's framework.
Native Filter Dropdown Integration: Implement a searchable dropdown within this modal, exclusively listing the names of native filters imported from the dashboard. This design is crafted to ensure users have access to and can utilize only the pre-established native filters specific to the dashboard, thereby simplifying filter selection and maintaining a streamlined user experience. Additionally, the dropdown will remain hidden in cases where the dashboard does not possess any native filters, ensuring a clean and uncluttered interface.
Enhanced Tab Selector: Improve the tab selection interface by analyzing position_data to list all tab titles. We will develop a utility function:
https://github.com/apache/superset/blob/9476ec14671f13045998d1b3a291387574f2634b/superset-frontend/src/features/alerts/components/DashboardFiltersAndTabs.tsx#L115-L131
It is designed to facilitate effortless navigation through the dashboard's tree-structured layout This function will provide users with a straightforward and intuitive way to select tabs, as exemplified in the given structure:

{
  ...
  ROOT_ID: {
    children: ['TABS-ALL'],
    id: 'ROOT_ID',
    type: 'ROOT',
  },
  'TAB-A': {
    children: ['ROW-03', 'ROW-04'],
    id: 'TAB-A',
    meta: {
      text: 'Overview',
    },
    parents: ['ROOT_ID', 'TABS-ALL'],
    type: 'TAB',
  },
  'TAB-B': {
    children: ['ROW-01', 'ROW-02'],
    id: 'TAB-B',
    meta: {
      text: 'Exploratory',
    },
    parents: ['ROOT_ID', 'TABS-ALL'],
    type: 'TAB',
  },
  'TABS-ALL': {
    children: ['TAB-A', 'TAB-B'],
    id: 'TABS-ALL',
    meta: {},
    parents: ['ROOT_ID'],
    type: 'TABS',
  },
  ...
};

Dynamic Permalink Generation: Utilizing existing functionalities in report/execute.py https://github.com/apache/superset/blob/4f004048054776c3074dfa5b4d5fd684cced47f1/superset/commands/report/execute.py#L175-L180 to dynamically generate permalinks. By saving the dataMask and activeTabs in the extra JSON field of the reportSchedule model, the system can create a permalink that encapsulates the current state of the dashboard, including selected filters and selected tabs.
Editing Modal Permalink Handling: In the editing modal, extra JSON field will be employed to access the saved filters and tabs associated with the permalinks. In scenarios involving pre-existing alerts and reports, the system will default to no selected filter, and in instances where the dashboard includes tabs, it will automatically select the first tab(s). Importantly, if the dashboard does not feature any tabs, the tab dropdown will be hidden. This design is intended to pre-populate fields with existing configurations, thereby enhancing and simplifying the user's editing experience.

Questions You Might Have
Q: How do we handle a large number of filters?
A: To manage a large number of filters effectively, the interface includes a searchable dropdown for the filters that are present on the dashboard. This allows users to quickly find and apply the filters they need. Additionally, if users have numerous filters, they have the option to apply them individually to tailor their search or view more precisely.
Q: Some filters are only applicable to some tabs, which can make the setup complex. Do we show only the filter applicable to the default tab, or how do we handle this alongside the tab selector feature?
A: We can add an informative message to the user if their filter(s) are not applicable to the tab they have selected for the report. Any selected filters that aren’t applicable to the tab would not have any impact on the report.
Q: How should we handle filters that are dependent on the selection of another filter? What would be the best approach to reflect this interdependent behavior in our system?
A: If filters values are dependent on another filter, if that filter is selected in reports, we can filter the dependent filter values accordingly.
Rejected Alternatives

Adding the Filters and Tabs to the Existing UI:

Pros:

Direct integration with the current interface could make the feature more accessible and visible to users who are already familiar with the UI.
It could provide a more seamless user experience since users wouldn't have to navigate away from the main interface to use the new feature.

Cons:

If the existing UI is already cluttered, adding more elements could overwhelm the users and make the interface less intuitive.

Creating a Permalink on the Dashboard and Copy/Pasting into the Report Modal:

Pros:

This approach avoids further cluttering the existing UI, keeping it more streamlined.
It could be easier to implement from a technical standpoint, as it doesn't require major changes to the existing UI layout.

Cons:

This method might be less intuitive for users, as it requires multiple steps and navigation between different parts of the software.
Users may find it cumbersome to switch back and forth between creating a permalink and pasting it into a report.

Thanks for authoring the SIP @lilykuang. Regarding the "Enhancements and New Functionalities"—specifically the "Native Filter Dropdown Integration" and "Enhanced Tab Selector" features—is there a more detailed mock-up of what this will be beyond the screenshots provided in https://github.com/apache/superset/discussions/25729?
The reason I ask is I gather the new functionalities are the main impetus of the SIP yet it isn't overly apparent how these will materialize. For example "Enhanced Tab Selector" feature allows the user to select a single tab (per the Select tab option) whereas in reality tabs can be i) nested, and ii) have siblings, hence in actuality a tree like UI element (similar to filter scopes) is likely more appropriate. The same holds true for the filter pre-selection.
These questions seem rather pertinent  given that they may not work within the current confines of the proposed UI. Additionally I think there is merit in flushing out the UI/UX first as this may dictate how solution is engineered—via the proposed new/changed public interface.

@lilykuang Thanks for writing this SIP and for providing a POC to visualize the idea ❤
My main concern with this approach is that we end up re-implementing many of the complex logic that exists in the dashboard inside the alerts/reports modal. Let me give you some examples about the complexity:

Tabs can be global or nested and they are more closely related to a hierarchical model as @john-bodley mentioned above.
Filter scopes influence on how the charts will be affected by the filters. The dashboard provides mechanisms to indicate to users which charts are being affected by which filters.
Filter dependencies are very important in the context of large datasets or in helping users navigate filter hierarchies. Some filters contain millions of rows and the dependency is very important.
Filters contain validation that should be respected. For example, if a required filter is cleared, we need to show a validation message and block the report generation.
Some dashboards won't render if a filter is not present. This happens when a filter is configured to select the first database value by default.
Cross filters are a great way to explore data and many times you want to generate an alert/report as the result of the interaction with this feature.

When @villebro proposed generating alerts/reports from permalinks  the intention was to provide all these features by reusing existing logic. @vivek-kandhvar correctly pointed that the solution would be very handy but not really user intuitive.
I believe we can tackle this problem from a different angle and configure the alerts/reports feature using the What You See Is What You Get concept. Users would be able to interact with a dashboard and all its features and generate an alert/report based on the dashboard state. That's exactly what @villebro proposed, but instead of copying and pasting a permalink, this would be handled by the application behind the scenes. In the alerts/reports modal we would have a screenshot of the alert/report so that users can easily identify its contents and an edit option that would lead to the dashboard again where users could make changes and save.
By using the dashboard as the source of truth, we can use all its current features, reuse existing logic and also be prepared for future improvements given that if a new feature is added, it can be supported by an internal permalink.

@michael-s-molina if we're able to extend the permalink logic to include all UI state—including filters and all selected/visible tabs—wouldn't @villebro's solution be suffice—at least for the next iteration? Copying and pasting a permalink into the Alerts + Reports modal isn't that much overhead and it would mean we wouldn't need to build out a new workflows/modals for both charts and dashboards.

@michael-s-molina if we're able to extend the permalink logic to include all UI state—including filters and all selected/visible tabs

@john-bodley Permalinks already include filters and selected tabs. We may have to make some improvements such as cross filters or really specific use cases that are not currently covered but we do that anyway as part of the permalink feature.

we wouldn't need to build out a new workflows/modals for both charts and dashboards.

I'm not sure what you mean by new modals.  I'm assuming that the redesign proposed here is a separate effort that will be made independently of this feature. Considering the above, I think including a screenshot of the dashboard and a button to edit it is not much work and it's a better user experience than copying/pasting permalinks as users will be able to visualize what's being sent by alerts/reports.

Thanks @john-bodley and @michael-s-molina, this is all really great feedback. @lilykuang and @yousoph and I spoke yesterday and were talking about the expected user flow, and I think this could help us understand how people will be using this feature. Right now, people are creating a dashboard and then saving it and then setting up a report. From what we're hearing from users, what they'd like to do after they set up the dashboard and report is to add some small extra filters on top. I expect that the flow will look something like this:

create dashboard with all the base filters needed
set up a report
create a new report with a subset of the filters (like sales department data only) and send to the sales department
set up another report for someone else with different filters (like marketing department data) and send to marketing

So we don't expect or encourage people to set up all the filters in the report, just the ones that they need for their specific use case. We're talking about some other improvements or ways to bring your feedback into some revisions, if that sounds like a plan.

Thanks for all the feedback!
To address some of the points that have come up:

Here's a mockup of what the tab selection could look like - we can highlight the name of the tab and give info about the nested structure, while still showing them in a dropdown list

As for setting up filters, there are currently 2 paths to set up reports:

From the Reports page. Like @eschutho mentioned, there are cases where an admin wants to set up multiple reports to different groups of users, while changing some simple filters (email, department, region, etc). In the case of setting up a few reports, it's easier to make changes in one place in the Reports tab rather than jumping between dashboards.
We're thinking it could help to add a Preview link on the reports modal that opens up the dashboard in a new tab with the tab + filters applied so the user can confirm their choices if needed.

From the dashboard view. Here, we can use the filters/tabs that are already set up on the dashboard to pre-fill the reports modal so that the user's current selection is set up by default. We can consider expanding this to a full size modal as well in the future and provide a way to link from Reports page -> dashboard view to set up if users prefer to set up reports in the dashboard context.

We feel that the addition of filters & tabs (along with the easier to navigate modal design) are a step towards continued improvement in the reports flow. We'll continue to monitor for user feedback and suggestions to continue to iterate on this process!

Hi everyone, just to keep this moving, and simplify as much as possible, we have moved the redesign out of this sip, and are working on that effort now. We're also thinking of splitting out the tab work from the filters work. It seems that the tabs from reports is a simpler solution than the filters and the only open question was about how to handle nested tabs.
If there are no objections, we're going to put up a PR for the tabs, and create an ephemeral and we can test out and discuss the edge cases there, and then vote on this SIP for the filters. Thanks!

@yousoph thanks for sharing the mockups for the tab selection. A few questions/comments:

Does the dropdown support multi select?
If so, how does one ensure that you're not selecting conflicting tabs, i.e., sibling tabs within the same tab bar?
I not, how does one select the relevant tabs when there are multiple sibling (as opposed to nested) tab bars?
My sense is that the selector UX will be problematic for complex dashboards containing multiple tabs once enumerated, i.e., the number of items will grow exponentially when tabs are nested.

Users can build rather complex dashboards with tabs—be that nested or sibling in a recursive manner—and thus it feels (from a UX perspective) the easier way to choose all the selected tabs is actually from within the dashboard* as opposed to selecting via the proposed selector. I know permalinks have been discussed previously and I wonder if that route is preferred?
* Users may struggle to connect the UI layout of a dashboard with the tabs enumerated in the selector (which lack context)—especially if they have the same (or similar) names. My sense is the current proposal will work (from a usability perspective) for toy examples but will breakdown for more complex real world examples.

@eschutho regarding your previous comment,

Hi everyone, just to keep this moving, and simplify as much as possible, we have moved the redesign out of this sip, and are working on that effort now. We're also thinking of splitting out the tab work from the filters work.

If this is the case, would it be possible to clarify what the intention of this SIP is now as it's not overly clear to me? It might be easier to set up a meeting to discuss this (as opposed to via GitHub comments) for us (and others) to better understand the overall approach and desired outcomes so there's clarity when it comes time to vote on SIPs, review PRs, etc.

Hi @john-bodley I think setting up a meeting is good idea. I can update the SIP to focus on just report filters and either create a separate SIP for tabs or we can treat it as a smaller improvement rather than a feature. The goal is just to scope everything down into smaller pieces to make the discussions easier.

Any thoughts on expanding the Alert Condition to something easier than SQL for a novice user?
More specifically: use Datasets as the source of the Alert Condition and have it filterable using the Charts feature of Query Filters as the point-and-click definition of the data. Finally, have the user select either a SUM/COUNT/MAX/MIN of some specific dataset Column to be the scalar to Trigger against.

Hi @ulfsa, thanks for the suggestion. Yes, we've discussed that there are likely some ways that we can make the alert condition simpler to use, especially since there is no way to test the alert in the modal. Making an alert query more point-and-click definitely sounds like an improvement. It would be great if someone wants to take this idea and develop it more.

Hi @john-bodley and @michael-s-molina and other community folks on this thread. I have updated the description of this PR to mention that this work will go behind a feature flag until we can find a solution that works for simple use-cases and more complicated ones, and also removed mention of the redesign which has already been done and the test email which will be pushed out to a later SIP. Thanks again for all the feedback so far. I'll leave this SIP open for a bit longer for any further discussion with these changes, and then put it up for vote.

@lilykuang @eschutho @yousoph do you know the current state of implementation here? Not sure if we can move this along on the kanban yet :)

We finished up the tabs feature, but haven't yet started on the filters. So, probably still in development. :)

@eschutho Very nice, is there an MR that we can collaborate?

HI, the PR for tabs is https://github.com/apache/superset/pull/27962


checkpath directive

Hi BTBurke,
we found ourselves in a quite similar situation as described in https://github.com/BTBurke/caddy-jwt/issues/41.
 Hope you like it! ;-)

Thanks for the contribution.  I like the idea but I think I might implement this a little bit differently.  This method is limited in that you can only have one path and it doesn't take into account what some people want to do, which is allow access to a whole set of resources under a particular path.
What I'm thinking about doing instead is to introduce some reserved keywords using the existing allow and deny directives.  If done right, people should be able to mix and match allow and deny to reach any kind of dynamic path protection.
For example, adding two new reserved keywords match:exact and match:prefix:
allow path match:prefix

And with a JWT with a path:
{
    "path":  "/protected/resource"
}

A prefix match would allow someone to access  /protected/resource/1.  Setting it to match:exact would only allow you access to /protected/resource but not /protected/resource/1.  Likewise, a deny rule could be used on a path to deny access to particular paths.
What do you think?

I agree fully. That would be elegant indeed.
I was dreaming about something similar for a few moments but then the Real life knocked and I had to whip out something functional to replace Nginx's secure_link feature. :-) My itch is pretty much scratched. :-D
My proposal is to have such a functionality now and replace it later. It's an minor patch and it won't be a problem to rip it off when the time comes.
I also cannot promise to invest too much time into this.  :-(
Implemented as discussed would make allowroot obsolete too, am I right?

I needed something like what @BTBurke suggested, so I went ahead and started working on it. I hope I'm not stepping on any toes.  I think icb-/caddy-jwt@d0f8d4bd92b84c4e99d7b8582fe49fbf011e7337 is mostly complete, except for rounding out tests. I went with new config directives rather than reserved keywords in the existing allow and deny directives, but I'm happy to make whatever changes others think are appropriate.


[FLINK-2323] [api-breaking] Rename OperatorState interface methods to value() and update(..)

Refactor OperatorState interface for clearer method names

+2 Looks good, this is a simple rename :ski:


Remove the libraries we don't use anymore from the readme

Libraries we use
We use the following libraries, and we're not closed to changes where relevant :-)
If you spot any libraries we added or we don't use anymore, feel free to update this list using a Pull Request.

Dagger 2 - A fast dependency injector for Android and Java
Retrofit - Retrofit turns your REST API into a Java interface
OkHttp - An HTTP+SPDY client for Android and Java applications
Mockito - Most popular Mocking framework for unit tests written in Java
Apache - The Apache Commons IO library contains utility classes, stream implementations, file filters, file comparators, endian transformation classes, and much more.
RxJava - Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
android-async-http - A Callback-Based Http Client Library for Android
Jackson - Core part of Jackson that defines Streaming API as well as basic shared abstractions
code-mc/loadtoast - Pretty material design toasts with feedback animations
journeyapps/zxing-android-embedded - Barcode scanner library for Android, based on the ZXing decoder
koush/ion - Android Asynchronous Networking and Image Loading
jsoup - jsoup is a Java library for working with real-world HTML
satyan/sugar - Insanely easy way to work with Android Database.
afollestad/material-dialogs - A beautiful, fluid, and extensible dialogs API for Kotlin & Android.
jjhesk/LoyalNativeSlider - Possible a dynamic viewpager ever you can find.
mikepenz/MaterialDrawer - The flexible, easy to use, all in one drawer library for your Android project.

I believe we can use dependency analysis plugin to remove the unused dependencies. I have found 6 unused dependencies, 5 app dependencies and 1 Test dependency that are not used.  App passes all Unit Test after removing these dependencies.

Is this issue still open ?


Create RelationalModelBuilder

As discussed in the design meeting, create a relational-specific model builder that will pull up relational methods onto the main model builder APIs and thus not require the use of ForRelational() calls.

Don't think we are going to do this now. What we have seems pretty good.


Implement Provisioning API

See doc for information on how it's set up.

Seems like git doesn't want to play ball at all. I'll work through this review and then clean it up.

I couldn't leave a comment, but on line 182 of Twitter.js, there's an if statement that uses url. There's a potential race here because prior to the if, there's a then chain that includes the setting of url. This could occur after the if statement.

Also, in general, === is best unless you absolutely need the whole convoluted coercion process that occurs with ==.

Good shout. I added it as a rule and there are 85 violations of it soooo that's gonna be fun :laughing:


Add support for 1.21.1

1.21 and 1.21.1 are protocol compatible as there were very few changes, so this by itself should just work, tested basic npc creation and everything seems to function, but feel free to let me know if there's anything i missed.

This has been completed in this dev build, thank you for your contribution nonetheless!


Minor: Remove the unreached simplification rule for 0 / 0

Which issue does this PR close?
Closes #3849
Closes #4669
Now both 0 / 0 and 10 / 0 will result in the same DivideByZero error.
DataFusion CLI v30.0.0
❯ select 0/0;
Optimizer rule 'simplify_expressions' failed
caused by
Arrow error: Divide by zero error
❯ select 10/0;
Optimizer rule 'simplify_expressions' failed
caused by
Arrow error: Divide by zero error

Rationale for this change
The const evaluator will first eliminate the expression 0 / 0 and raise a DivideByZero error.
https://github.com/apache/arrow-datafusion/blob/ea9144e6597593c09a4ef0b71a4da1cdfaca8249/datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs#L129-L130
Then this rule will never have a match.
https://github.com/apache/arrow-datafusion/blob/ea9144e6597593c09a4ef0b71a4da1cdfaca8249/datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs#L709-L715
Furthermore, the behavior of this rule is inconsistent with the results of the following test case.
https://github.com/apache/arrow-datafusion/blob/ea9144e6597593c09a4ef0b71a4da1cdfaca8249/datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs#L1666-L1675
What changes are included in this PR?
Remove an unreached simplification rule.
Are these changes tested?
N/A
Are there any user-facing changes?
No

I believe CI will pass after merging up from main to get the change in  https://github.com/apache/arrow-datafusion/pull/7416

I believe CI will pass after merging up from main to get the change in  https://github.com/apache/arrow-datafusion/pull/7416

I took the liberty of merging up from main to get a fix for CI failure

Thanks @jonahgao  and @Weijun-H


minio/ ability to set cluster domain name

Signed-off-by: Arvind Gupta<EMAIL_ADDRESS>
What this PR does / why we need it:
added support to specify the custom kubernetes cluster domain.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md

/assign @unguiculus

cc @acaleph @minio

/lgtm


Autodetect Tectonic licenses in Tectonic Installer

Feature Request
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
bare-metal
Desired Feature
It would be nice if the Tectonic Installer would automatically know which Tectonic licenses I own and offer me those to select from, instead of having to paste lots of stuff from the website. You could automatically log into the user's account on account.tectonic.com (using OAUTH2 or similar) and offer him/her all the licenses s/he owns.

Hey @urzds - thanks for filing this issue. Autodetection of licenses is definitely on our roadmap - will let you know when we add that. In the meantime, we're making it easier to download your licenses at the beginning of the signup flow so they're a bit more handy.


Palette shows colour values in RGBA

This is probably an enhancement, rather than a bug.
The palette shows the colour in 32bit RGBA, rather than 12bit X16 colours. Showing colour number would be handy as well.

Absolutely

Yeah, I'd categorize this as an enhancement. Imgui's color widget doesn't support 12bit color. Box16 should be rounding it appropriately, but I'll need to write a bespoke color widget, or modify Imgui's widget.

In terms of priority, I'm currently looking at adding read/write data breakpoints, so far this would come after that.

So I've been looking into this. Fixing UIs and whatnot to only show 4-bit color components is easy enough. Fixing the color wheel and triangle in the color picker to only show VERA-legal colors is probably impossible.
The issue is that OpenGL is drawing the UI elements in 32-bit color, and it's blending the color on the triangles making up those widgets with 32-bit precision. There's no good way that I'm seeing to fix that in ImGui, because ImGui is queuing up all the geometry (and texture UVs and color data) to draw before issuing its draw calls. Even if I clamp the colors of the vertices to VERA-legal colors, the blending between different verts with different colors is still a problem.
It may still be possible to fix the color wheel specifically, but the problem is finding the thresholds where the color changes so I can slice it up into a bunch of tiny, monochrome arcs. I don't have any ideas right now that would fix the triangle to only show VERA-legal colors.
The "right" way would probably be to change the fragment shader in use by ImGui, maybe adding a parameter to various verts to indicate when their associated fragments should be clamped to VERA-legal colors. But that will require some deep digging to find the shader and make changes, and propagate the data structure changes through ImGui. That's quite a large amount of work and likely means never being able to pick up fixes or updates to ImGui ever again... so I'm not a super big fan of that.
At the very least, I'm inclined to commit the changes I have at present that don't address the colors represented on the color wheel or the triangle, and leave those specific widgets for another day.

So unless/until I dig into the rendering pipeline to create a specialized 4-bit color case for this widget, 3d434511b08a61e679e47a08fc11fa2238af21f7 is about as good as this can get: 4-bit color palette in the various text fields and inputs, but the color gradients themselves are still 32-bit and shall remain 32-bit for the foreseeable future.
If folks want, we can still leave this open, but at the moment I have no plans to dig that far into Imgui.


Return after handling a CancelRequestNotification

We were dispatching the notification to messageHandlingQueue, which then didn’t do anything with it. That’s not necessary.

@swift-ci Please test Windows


RustPython panics with a debug std library

To reproduce:
rustup override set nightly
cargo run -Zbuild-std --target=x86_64-unknown-linux-gnu -- -m unittest -v test.test_array.DoubleTest.test_pickle_for_empty_array

Result is:
     Running `target/x86_64-unknown-linux-gnu/debug/rustpython -m unittest -v test.test_array.DoubleTest.test_pickle_for_empty_array`
test_pickle_for_empty_array (test.test_array.DoubleTest) ... thread 'main' panicked at 'unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`', /home/abell/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:123:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.
Aborted

Blocks #4 .

Fixed and pushed to parent with PR 4579.


check me out

Hey can i contribute in your project? I have seen your project and i think i can improve many things


[bug]: DEVELOPER INSTALL ERROR

Is there an existing issue for this?

[X] I have searched the existing issues

OS
Linux
GPU
cuda
VRAM
10GB
What version did you experience this issue on?
3.0.0
What happened?
It does not work in cli 'invokeai' and 'invokeai-configure'
Screenshots
No response
Additional context
No response
Contact Details
<EMAIL_ADDRESS>

i will give screenshots


Azure CosmosDB ChangeFeeds never exhaust and the feed continues to repeat last value when using fetchNext

Package Name: @azure/cosmos
Package Version: 3.15.1
Operating system: Windows 10 Version 21H2 (Build 19044.1586)
[x] nodejs

version: 16

[x] browser

name/version: Chrome 100.0.4896.75 (Official Build) (64-bit) (cohort: Stable)

[ ] typescript

version:

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
Azure Cosmos ChangeFeeds never exhaust and continue providing the last item. E.g. iterator.hasMoreResults never returns false and iterator.fetchNext() continues providing repeat values.
Reproduction Case
Have a look at my reproduction on: https://observablehq.com/@selenecodes/cosmosdb-user-agent-header-issues
Expected behavior
If your azure cosmos container has 3 items (with the same partitionkey, for simplification) and you have the following setup:
const iterator = container.items.changeFeed(partitionKey, {
    startFromBeginning: true,
    maxItemCount: 1
});

We would expect the following behaviour:
iterator.fetchNext()
// first item, iterator.hasMoreResults == true
iterator.fetchNext()
// second item, iterator.hasMoreResults == true
iterator.fetchNext()
// third item, iterator.hasMoreResults == false
iterator.fetchNext()
// empty, iterator.hasMoreResults == false

Actual behavior
Assuming the exact same setup as above the actual behaviour is as follows:
iterator.fetchNext()
// first item, iterator.hasMoreResults == true
iterator.fetchNext()
// second item, iterator.hasMoreResults == true
iterator.fetchNext()
// third item, iterator.hasMoreResults == true
iterator.fetchNext()
// third item, iterator.hasMoreResults == true
// iterator.hasMoreResults will NEVER be false

I was wondering if there was any update on the status of this issue and if the specified behavior/reproduction case shed light on the issue (if not I can update it accordingly)

This was entirely due to me not setting up CORS in Azure Portal.
If you're running into this issue be sure to:

Disable any CORS bypass extensions on your web browser
You should now not be able to request any data.

To solve this follow this documentation page


Install NDK 25.1.8937393 in the Docker image

What does this PR do?
Build script is using NDK 25.1.8937393 while Docker contains the older one, so we were wasting some time to download the necessary NDK version during the build process.
This PR update NDK version to the necessary one in the Docker image.
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #248 (e1f04f3) into develop (924006b) will decrease coverage by 0.08%.
The diff coverage is n/a.

Additional details and impacted files
@@              Coverage Diff              @@
##             develop     #248      +/-   ##
=============================================
- Coverage      81.50%   81.42%   -0.08%
- Complexity       203      204       +1
=============================================
  Files             26       26
  Lines            800      802       +2
  Branches         103      104       +1
=============================================
+ Hits             652      653       +1
  Misses           112      112
- Partials          36       37       +1

see 1 file with indirect coverage changes


Skip connection implementation issue

I want to implement the skip connection.

model1 = Sequential()
model1.add(Embedding(input_dim=vocab_size, output_dim=embedding_dim, mask_zero=True, init='normal'))
model2 = Sequential()
model2.add(model1)
model2.add(LSTM(hidden_layer_size, go_backwards=is_reverse, return_sequences=True))

model3 = Sequential()
model3.add(Merge([model1,model2], mode='concat'))
model3.add(LSTM(hidden_layer_size, return_sequences=False))
model3.add(Dropout(dropout_rate))

model3.add(Dense(output_dim=entity_size, init="normal"))
model3.add(Activation("softmax"))

model3.compile(loss='categorical_crossentropy', optimizer=SGD(lr=init_learning_rate, momentum=0.9, decay=0.95, nesterov=True))

And an error occurs.(Note that embedding_dim=1000,hidden_layer_size=256)

ValueError: dimension mismatch in args to gemm (128,1000)x(1256,256)->(128,256)

How can I solve this problem?

Now I use the Graph class, and the problem still exists.

model = Graph()
model.add_input(name='input', input_shape=(None,), dtype='int')

model.add_node(Embedding(input_dim=vocab_size, output_dim=embedding_dim, mask_zero=True, init='normal'), name='embedding', input='input')

model.add_node(LSTM(hidden_layer_size, go_backwards=is_reverse, return_sequences=True), name='lstm0', input='embedding')

model.add_node(LSTM(hidden_layer_size, return_sequences=False), name='lstm1', inputs=['embedding', 'lstm0'], merge_mode='concat')

model.add_node(Dropout(dropout_rate), name='dropout', input='lstm1')

model.add_node(Dense(output_dim=entity_size, init="normal"), name='dense', input='dropout')

model.add_node(Activation("softmax"), name='prob', input='dense')

model.add_output(name='output', input='prob')

Is there something wrong with my code?

No problems here running the code you provided.
I think you are using theano, right? Have you updated keras/theano lately?

well embedding is of size embedding_dim while LSTM is of size hidden_layer_size. If you're gonna do concat you must at least agree on one axis. By default it's -1 http://keras.io/layers/core/#merge so the last one. But you want to concat them over the time dimension which is 1.
Or something similar.
also I set the input shape to input_shape=[1] when working with embedding layers.

@lemuriandezapada I don't want to correct you if I'm missing something, so can you expand on why you think @zzjin13 wants to concat on axis = 1 (or why -1 won't work)?
I'll reiterate and clarify. No problems here running the code provided, including fitting the model (to some randomly generated data). embedding_dim doesn't need to match hidden_layer_size. Default concat executes fine (in fact, setting concat_axis to 1 won't work). Unspecified input shape is no problem, though I also generally set it to (sequence_length,)
I also decided to check to see if i could get the original sequential model based approach to also compile and fit, again, no problems, no modifications.


fix: vertically align to do list checkboxes

Hi @tslaton, can you provide a before/after screenshot?
Thanks for contributing.

Sorry it's taken me so long to get back to you. I wanted to get some screenshots outside of macOS. Now that I have, the results are not quite the same on Windows—looks like the checkboxes are a little higher relative to the item text either way. That said, I can see the issue I was attempting to address in the leading screenshot for the theme at the root of the repo, as well. I'm guessing you were using macOS?
On macOS, I think the change improves the checkboxes appearing below the text by aligning them to the text. On Windows, they were too low before to a lesser degree and they end up looking a little too high for the text after the change, but that could still be preferable.
Example text
# (Platform)

## This is a checklist *before/after* the change

- [ ] this is one checklist item
- [x] this is a second checklist item
- [ ] this is a third checklist item

macOS

Windows

Thank you!


[BUG] Registration closed even if setting is on

Describe the bug
Even with "USER_ACCOUNTS=true" in the .env you can't register on the website.
To Reproduce
Steps to reproduce the behavior:

Setup chibisafe with user_accounts false
edit .env
restart service
See error

Expected behavior
Registrations being turned on.
Screenshots

Feel free to open this issue again if you are still having problems


feat: added a new shape #423

fixes #2772

Created a shapes screen with filename shapes,#423_Sanidhya.html

Followed the provided format

Heartfelt Thanks for Your Contribution to Our Open Source Project!
Dear @S4N1DHY4 (None),
I trust this message finds you in good health and high spirits. I am reaching out with a heart full of gratitude for your recent contribution to our open source project. Your dedication has not only elevated the functionality of our project but has also exemplified the collaborative spirit that lies at the core of thriving open source communities.
A heartfelt congratulations are in order for your exceptional work! Your commitment and expertise have played a pivotal role in the success of our project, and we consider ourselves truly fortunate to count you among our community members.
I must extend my sincere apologies for the delay in responding to your pull request. Your patience and understanding during this time are immensely appreciated. As our project continues to grow, we acknowledge the imperative need to enhance the quality and response time for contributions. To address this, we've kickstarted a call for maintainers and reviewers who can help us uphold the high standards of our project and ensure swift responses to pull requests.
Your involvement and insights would be invaluable in this initiative. If you, or someone you know, is interested in taking on a more active role in the project, please don't hesitate to reach out. We firmly believe that with a robust team of maintainers and reviewers, we can elevate both the quality of the project and the speed of our responses.
On an exciting note, I am thrilled to share that we have activated the sponsorship button for our project. This development allows supporters like yourself to contribute to the sustainability and growth of the project. Your ongoing support, whether through code contributions or sponsorship, is genuinely appreciated.
Once again, congratulations on your outstanding contribution, and thank you for being an indispensable part of our open source community. We eagerly anticipate your continued collaboration and shared success.
Best regards,
Ntem Kenyor K.
Lead
Kwickerhub


Support for KHR_mesh_quantization & EXT_meshopt_compression

Hi Cesium,
I'm in the process of testing cesium with gltf datasets, for 3d-tiles-next.
My gltf files are compressed with EXT_meshopt_compression and KHR_mesh_quantization, using gltf-pack
I noticed support for these glTF extensions, is in progress...
https://github.com/CesiumGS/cesium/issues/9520
I'm wondering, is there a preview of this, in a feature branch somewhere ?
Greatly appreciated.

Try setting Cesium.ExperimentalFeatures.enableModelExperimental = true before creating an tilesets.
We're in the process of refactoring the glTF loader and some new functionality like meshopt is behind this experimental flag.

That did it - thanks!

I'll add it to here

@wallabyway great!


[zh] Update patch-releases.md

Signed-off-by: Gao Qian<EMAIL_ADDRESS>

This can be closed.
Please search the PR list and check if any conflict exists before opening a PR.
In general, the PR opened early may take precedence.


[proposal] Platform Filter for Service Scheduling

This is a proposal PR to discuss the idea of automatically scheduling service tasks based on platform constraints. It's part of a larger change, where platform constraints would be passed as part of the service spec, and used during scheduling to avoid running tasks on nodes that don't support them.
What this PR does

Adds a SupportedPlatforms field to ContainerSpec. This is a list of all platforms that the container can be scheduled on.
Adds a PlatformFilter struct, that gets activated if SupportedPlatforms is non-empty, and picks a node for a container if node.Description.Platform is in SupportedPlatforms.

Where does the platform information come from?
Some images have fat manifests, that include references to platform-specific manifests (an example of such an image is friism/golang). The Docker daemon already pins service images by digest, and can in addition retrieve platform information from the fat manifest (if it exists) and populate the SupportedPlatforms field in ContainerSpec. If the field remains empty, then the platform filter is not enabled.
Comments invited. If we can broadly agree that this is the right direction, then I can work on integrating this change inside of Docker.
cc @aaronlehmann @aluzzardi @dongluochen @friism

Codecov Report

Merging #1981 into master will decrease coverage by -0.15%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master    #1981      +/-   ##
==========================================
- Coverage   53.63%   53.49%   -0.15%
==========================================
  Files         109      109
  Lines       18919    18939      +20
==========================================
- Hits        10147    10131      -16
- Misses       7538     7569      +31
- Partials     1234     1239       +5

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d29a857...75abfc8. Read the comment docs.

Adds a SupportedPlatforms field to ContainerSpec. This is a list of all platforms that the container can be scheduled on.
Adds a PlatformFilter struct, that gets activated if SupportedPlatforms is non-empty, and picks a node for a container if node.Description.Platform is in SupportedPlatforms.

The general approach seems sound. I don't think SupportedPlatforms should be inside ContainerSpec, though. We generally don't modify any specs inside the daemon. We made an exception for digest pinning, sort of as a hack, because reusing the existing Image field was simpler than the alternatives, and the behavior on updates was well-defined and well-behaved. But since SupportedPlatforms is a new addition, I don't think putting it in the spec buys us anything. I guess we'd have to manually copy this information to tasks, but I think that's worth it.
One thing that needs to be thought through before we move forward with this is how updates are handled. Basically, we need to define when the manager will retrieve the manifest and update this platform information. I think doing this on every update is a non-starter, because often updates are changing something totally unrelated to the image (i.e. --update-parallelism), and don't need to incur this round-trip.
With digest pinning, the logic is relatively simple: if there's no digest, we add one, but if there's already a digest, nothing needs to be done.
I think that for platform support, we need to define a mechanism that avoids unnecessary round trips to the registry when we update an image but keep the image/digest the same. My thought was that SupportedPlatforms could contain a Source field that indicates where the information came from. If the value of Source matches the current Image field in ContainerSpec, that means the platform information is up to date and it's not necessary to download the manifest. If Source does not match Image, then it needs to be updated.

Isn't SupportPlatforms part of image spec? If image hasn't changed, no need to inspect this info.

The general approach seems sound. I don't think SupportedPlatforms should be inside ContainerSpec, though. We generally don't modify any specs inside the daemon. We made an exception for digest pinning, sort of as a hack, because reusing the existing Image field was simpler than the alternatives, and the behavior on updates was well-defined and well-behaved. But since SupportedPlatforms is a new addition, I don't think putting it in the spec buys us anything. I guess we'd have to manually copy this information to tasks, but I think that's worth it.

I agree with this reasoning, but didn't know a better way. The reason I put it in ContainerSpec was that it's a container-specific field, assuming that tasks are more generic workloads that don't necessarily have platform information the way Docker specifies it. I don't understand "manually copy this information to tasks", can you clarify?

One thing that needs to be thought through before we move forward with this is how updates are handled. Basically, we need to define when the manager will retrieve the manifest and update this platform information. I think doing this on every update is a non-starter, because often updates are changing something totally unrelated to the image (i.e. --update-parallelism), and don't need to incur this round-trip.

Good point. Can we agree that whenever we're contacting the registry to retrieve digest, we don't mind pulling platform information also?
In cases where the --image is not supplied with service update, we don't need to do anything, because we just assume that the image and all its platform-related requirements stay the same.
The interesting case is when the digest is provided (say by the user). In this case, we do know at the manager level whether the digest of the new service spec is different from the existing one. If it isn't different, we don't need to do anything (this is probably the same case as above). If there is a change, then we want to contact the registry to get platform information. The only difference is that before, the user could update the service by providing a new digest, and skip the registry lookup, whereas now it would entail the registry lookup.
To summarize, I don't see why we cannot avoid registry lookup when the service is updated but the image is not.

I don't understand "manually copy this information to tasks", can you clarify?

I assume we want tasks to contain a list of supported platforms, so the scheduler can easily check against nodes. The TaskSpec (including ContainerSpec) gets automatically copied to tasks associated with the service, but something outside the spec would have to be copied separately by the orchestrator.

In this case, we do know at the manager level whether the digest of the new service spec is different from the existing one. If it isn't different, we don't need to do anything (this is probably the same case as above). If there is a change, then we want to contact the registry to get platform information.

This seems reasonable.

@aaronlehmann I've moved the SupportedPlatforms field to the Task object, taking it out of ContainerSpec. I still need to change add code for copying the field in the orchestrator.
In principle (assuming SwarmKit would support other workloads beyond containers in the future), do you think it's reasonable to attach platform restrictions to tasks?

@aaronlehmann To have that in the Task rather than the TaskSpec is weird though.
Task contains more like runtime status data while the spec contains configuration and here I think this is configuration
For instance, changing the supported list of platforms should trigger a rolling update IMO

To have that in the Task rather than the TaskSpec is weird though.

Hmm, I disagree. TaskSpec is declarative and SupportedPlatforms is something derived from other information.

For instance, changing the supported list of platforms should trigger a rolling update IMO

Since SupportedPlatforms is derived information, it will never be changed directly. A change in the information that SupportedPlatforms is derived from (such as the image digest) can trigger a rolling update.

SupportedPlatforms is not derived by SwarmKit. Either SwarmKit derives something internally and puts it into an attribute, or someone else does some computation and instructs SwarmKit to do stuff using the Spec.
Like - if we do put this into Task rather than TaskSpec, how's the engine going to pass it to us since all they can interact with is the spec?

I guess I'm uncomfortable with the "engine manipulates the spec" model. It means the REST API is not really declarative, even if the gRPC API is. I think these differences will be confusing and become a maintenance burden.
For example, what happens if the client decides to include a SupportedPlatforms field in the spec? How would we prevent the engine from overwriting it? One possibility is to hide this field from the REST API, but again, introducing differences between the APIs really seems like the wrong direction.
I don't have any great suggestions here. I think in my ideal world, the client would be doing these derivations, not the engine. I hoped to do it that way for digest pinning, but a different approach got chosen, and now I fear it's becoming precedent to continue adding similar hacks.

This doesn't look right. We are coupling ourselves way too tightly to the image format (why are we even assuming that tasks have images or even a platform?). It seems like we should only be supporting a constraint that would dispatch a service to a particular platform. Making a platform determination when full context isn't available will make the system limiting when we try to schedule other kinds of workloads.
Again, I hope we can step cautiously when adding multi-platform support. For this to work smoothly, sometimes it is more about what you don't do, than what you do do. In this case, this approach seems limiting.

@stevvooe SupportedPlatforms is a constraint. Ideally it should be in TaskSpec.Placement.Platforms, similar to TaskSpec.Placement.Constraints.
The engine has a convenience of filling out those fields based on the manifest

@stevvooe SupportedPlatforms is a constraint. Ideally it should be in TaskSpec.Placement.Platforms, similar to TaskSpec.Placement.Constraints.

That sounds more right.

Personally, I agree more with @aaronlehmann that the TaskSpec shouldn't have this information, especially if it results in coupling too tightly with the image format. But the problem as @aluzzardi pointed out is that the Engine only interacts with the spec, so there's a problem wrt passing the information to the manager.
Given this, isn't TaskSpec.Placement.Platforms still (somewhat) coupled with the image format, given that the information we put in Platforms will look like what the manifest contains?
There are also a couple of important questions to answer, based on https://github.com/docker/docker/issues/31348#issuecomment-282774434:

How much control should we give the user wrt setting platform constraints? If we put platform information in the spec, then the expectation would be that the user should be able to set it.
We are implicitly assuming that cross-platform services are okay. The platform filter as in this PR will not restrict all tasks to run on only a single platform if multiple platforms are supported. Are there images that will be affected by this? In particular, how does this change when we want to have persistent distributed data? cc @friism

Changed to TaskSpec.Placement.Platforms. PTAL.

Design LGTM

LGTM on protobufs

Added a unit test.

From a brief conversation with @friism, I've learned that having cross-platform services may not be the best idea after all. Particularly when we're using volumes and such. For instance, if you have a redis service running on Linux, you perhaps don't want it to run on Windows after some rescheduling. If this is a particularly important requirement, then protos need to change.
@friism what do you say?

@nishanttotla this is just me speculating, but as an example, for Docker Official images, work is being done to make stuff like redis multi-arch. That's great because you can simply docker pull redis and get the right image whether you're on Linux or Windows or on i686 or AMD64.
However, I don't think anyone running an heterogenous swarm, with both windows and linux, nodes would want  docker service create redis to cause tasks to be scheduled alternatingly on both windows and linux nodes. Even with a linux-only swarm with mixed ARM/x86 I suspect that could be a problem because redis running on different architectures might behave differently.
To me, the simplest use case to get right first is something like this: I'm running a mixed-node swarm with Linux and Windows nodes, and I want to create a service based on an image that's Windows-only (no multi-arch). Ideally Swarm would be able to figure out how to constrain tasks to windows-nodes in the swarm without the user having to specify additional constraints or parameters on docker service create example/windows-image.

In SwarmKit, we have
message Platform {
	// Architecture (e.g. x86_64)
	string architecture = 1;

	// Operating System (e.g. linux)
	string os = 2 [(gogoproto.customname) = "OS"];
}

In docker/distribution though, the manifestlist.PlatformSpec struct has more details.
// PlatformSpec specifies a platform where a particular image manifest is
// applicable.
type PlatformSpec struct {
	// Architecture field specifies the CPU architecture, for example
	// `amd64` or `ppc64`.
	Architecture string `json:"architecture"`

	// OS specifies the operating system, for example `linux` or `windows`.
	OS string `json:"os"`

	// OSVersion is an optional field specifying the operating system
	// version, for example `10.0.10586`.
	OSVersion string `json:"os.version,omitempty"`

	// OSFeatures is an optional field specifying an array of strings,
	// each listing a required OS feature (for example on Windows `win32k`).
	OSFeatures []string `json:"os.features,omitempty"`

	// Variant is an optional field specifying a variant of the CPU, for
	// example `ppc64le` to specify a little-endian version of a PowerPC CPU.
	Variant string `json:"variant,omitempty"`

	// Features is an optional field specifying an array of strings, each
	// listing a required CPU feature (for example `sse4` or `aes`).
	Features []string `json:"features,omitempty"`
}

Should we consider extending the Platform field in SwarmKit? It doesn't have to be part of this PR necessarily.

Let's add a test case for a missing architecture.
Otherwise, LGTM

@aaronlehmann done, thanks!
The tests seem flaky for some reason, do they need more time to run?

No, it's a problem with your test. watchAssignmentFailure silently consumes successes. You can't make assumptions about the order in which tasks are scheduled. It may be easier to create one task at a time, and watch for success or failure.

@aaronlehmann fixed it.

Requested changed, but you do not HAVE to make these changes, as long as you can give me a quick explanation as to why it's done the way it's done.

@dperny: These methods satisfy an interface.  Explain returns a string explaining why that filter prevented the task from being scheduled. It isn't useful to return an error because this gets exposed through TaskStatus protobuf message. It's not bubbled up internally.

@aaronlehmann thanks, sorry about that then. is the interface documented with that information?

@dperny: https://github.com/docker/swarmkit/blob/56bcb2fcb5a698201efb0491dbb6ad1671d5f6bf/manager/scheduler/filter.go#L11-L27

Thanks. LGTM 👍 👍 👍

It seems we are not very sure of the use cases, should we make this an experimental feature so we can change it when we get user feedbacks?

@dongluochen the use case is straightforward (and uncommon IMO). When you have a mixed cluster, you don't want images that are not supported by a platform to run on a node with that platform.

@nishanttotla My concern is mis-uses. For example, users may not realize an image can run on 2 platforms. It accidentally gets scheduled to a random platform.

My concern is mis-uses. For example, users may not realize an image can run on 2 platforms. It accidentally gets scheduled to a random platform.

This is what happens right now. Images are scheduled to any node whether or not it can run there. This PR just provides an extra filter to allow for preventing that.

please, see https://github.com/docker/swarmkit/issues/2294

@erikbgithub regarding the problem you're facing with 3 raspberries, can you open a new issue providing more details about individual nodes as well as the service you're running?
We can discuss possible solutions there, as well as ways to make the error report better.


Multi quickfix client for different users

Hi @esanchezros,
Could you tell me how can I configure for multi quickfix clients in the same app?
For example, I have a app that need to connect to multi quickfix servers
Quickfix server 1: IP1, port1, user1
Quickfix server 2: IP2, port 2, user2
Many thanks,

Hi @duongvansang,
You can create multiple sessions pointing to different hosts in the quickfix config:
`# default settings for sessions
[default]
ConnectionType=initiator
ReconnectInterval=60
SenderCompID=TW
session definition
[session]
inherit ConnectionType, ReconnectInterval and SenderCompID from default
BeginString=FIX.4.1
TargetCompID=ARCA
StartTime=12:30:00
EndTime=23:30:00
HeartBtInt=20
SocketConnectPort=9823
SocketConnectHost=<IP_ADDRESS>
DataDictionary=somewhere/FIX41.xml
[session]
BeginString=FIX.4.0
TargetCompID=ISLD
StartTime=12:00:00
EndTime=23:00:00
HeartBtInt=30
SocketConnectPort=8323
SocketConnectHost=<IP_ADDRESS>
DataDictionary=somewhere/FIX40.xml
[session]
BeginString=FIX.4.2
TargetCompID=INCA
StartTime=12:30:00
EndTime=21:30:00
overide default setting for RecconnectInterval
ReconnectInterval=30
HeartBtInt=30
SocketConnectPort=6523
SocketConnectHost=<IP_ADDRESS>
(optional) alternate connection ports and hosts to cycle through on failover
SocketConnectPort1=8392
SocketConnectHost1=<IP_ADDRESS>
SocketConnectPort2=2932
SocketConnectHost2=<IP_ADDRESS>
DataDictionary=somewhere/FIX42.xml`

Example taken from http://www.quickfixengine.org/quickfix/doc/html/configuration.html

Hi @esanchezros,
yes, I tried, it's good now thank you very much
I am trying to run both FIX server and FIX client in the same app, but I got error could not do it
Is there any way to config to run both FIX Server and FIX client in the same app?

Yes it's possible. What error are you getting?
Sent from Yahoo Mail on Android
On Wed, 19 Feb 2020 at 8:41<EMAIL_ADDRESS>wrote:
Hi @esanchezros,
yes, I tried, it's good now thank you very much
I am trying to run both FIX server and FIX client in the same app, but I got error could not do it
Is there any way to config to run both FIX Server and FIX client in the same app?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I got this error when enable both Server and client in the same app
Error creating bean with name 'clientInitiator' defined in class path resource [config/FIXInitiatorConfig.class]: Unsatisfied dependency expressed through method 'clientInitiator' parameter 3; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'clientLogFactory' defined in class path resource [io/allune/quickfixj/spring/boot/starter/autoconfigure/client/QuickFixJClientAutoConfiguration.class]: Unsatisfied dependency expressed through method 'clientLogFactory' parameter 0; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'quickfix.SessionSettings' available: expected single matching bean but found 2: clientSessionSettings,serverSessionSettings
It seems there is two beans of quickfix.SessionSettings type are available.

What version are you using? I think I fixed this issue on the latest one (2.5.0)
Sent from Yahoo Mail on Android
On Wed, 19 Feb 2020 at 8:58<EMAIL_ADDRESS>wrote:
I got this error when enable both Server and client in the same app
Error creating bean with name 'clientInitiator' defined in class path resource [config/FIXInitiatorConfig.class]: Unsatisfied dependency expressed through method 'clientInitiator' parameter 3; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'clientLogFactory' defined in class path resource [io/allune/quickfixj/spring/boot/starter/autoconfigure/client/QuickFixJClientAutoConfiguration.class]: Unsatisfied dependency expressed through method 'clientLogFactory' parameter 0; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'quickfix.SessionSettings' available: expected single matching bean but found 2: clientSessionSettings,serverSessionSettings
It seems there is two beans of quickfix.SessionSettings type are available.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

oh I am using 2.4.1, let me try 2.5.0

I tried, it works now, great
Thank you

That's great. From now on I will publish release notes with new changes/bug fixes.
Sent from Yahoo Mail on Android
On Wed, 19 Feb 2020 at 9:05<EMAIL_ADDRESS>wrote:
I tried, it works now, great
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


多任务学习的训练代码在哪呢没找到呀~

@Torres9999 Hi,
The multitask learning code is under construction. You may refer to #22 for details if you wanna implement it yourself.


Native notebooks: Changing the kernel of a notebook does not mark it as dirty

Change the kernel of a notebook
Reload VS code
Kernel will not be picked as the preferred kernel

I don't see the need for this.
The user hasn't run the cell, hence i don't see why we need to persist this.
This is deliberate.
If a user opens a notebook, a kernel is picked, we can't make it dirty, else every notebook that's opened can be marked as dirty just because the user opened a notebook.
I.e. we cannot differentiate between vscode opening & selecting a kernel vs user selecting a kernel & don't think we need to either. We haven't had users file issues against this.

I changed the kernel. That should be different metadata. Maybe I only opened it, changed the kernel, but then forgot to run it. It just looks inconsistent.

Works as expected today


Contributor dead links

On the README’s contributors section, a few contributos have dead links:

Brad Davies
Hugo Torzuoli
Bruno C. Couto

@hugomd @varbrad @imbrn can you all submit PRs to update these links if you would like? Otherwise I will close (:

@mfix22 I think you meant to tag @HZooly 😉

Hey guys, indeed, this is me 😄
https://github.com/dawnlabs/carbon/pull/442


Add supported for fish and sql

Added support for fish shell
Added support for SQL scripts

Thank you!


v8 DEPS update.

Revision f2e4deb40b678a06f953154f348d6f847b08690c.
For RUN-2477 (https://linear.app/replay/issue/RUN-2447/disallow-events-in-futexemulationwaitsync-interrupt-loop)
Bucket issue RUN-2378.

This has long been fixed.


Signing with Keychain doesn't work on Firefox Android

I am able to install steem-keychain on Android mobile phone on Firefox browser. I can view and make transfers with the extension but signing in to apps doesn't work.
It could be related to external pop up since keychain opens a new window for signing a txn.

Hi! We dont provide support for Firefox for Android.
You can check @roelandp 's SteemWallet on Android that wraps keychain to be used with many websites.

@nirvanaitsolutions thats https://steemwallet.app :)


[Cosmos] Build pipeline fix

Our build pipeline keeps running into errors with our Windows config due to not being able to import certain core packages due to them not being listed in _ _ all _ _. This PR removes those and adds them to the file in question directly.
Link to failing pipeline: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2952315&view=results

/azp run python - cosmos - tests


Add support for generating non-abi3 python import libraries for Windows targets

Continuing from https://github.com/PyO3/python3-dll-a/issues/12

error[E0432]: unresolved import `python3_dll_a::ImportLibraryGenerator`
 --> /home/runner/work/pyo3/pyo3/pyo3-build-config/src/import_lib.rs:6:5
  |
6 | use python3_dll_a::ImportLibraryGenerator;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ImportLibraryGenerator` in the root

This is odd, I've already patched it to git dependency.
@ravenexp Could you release a new version of python3-dll-a so we can just test with crates.io version? Thanks!

@ravenexp Could you release a new version of python3-dll-a so we can just test with crates.io version? Thanks!

Created https://github.com/PyO3/python3-dll-a/pull/16

Needs https://github.com/PyO3/python3-dll-a/pull/17

Needs PyO3/python3-dll-a#17

Mirroring my concerns here because they also affect PyO3 https://github.com/PyO3/python3-dll-a/pull/17#issuecomment-1122607225


Fix mirroring aggregates for with same IDs

Previously, the ID of a Mirror projection consisted only of the ID of the mirrored aggregated, wrapped into Any. This caused a bug: if two aggregate instances had the same ID (e.g. parts belonging to one aggregate root), the Mirrors of those aggregates would override each other.
This PR adds the entity type URL field to the MirrorId. This way, there is no valid scenario in which two aggregates would have the same Mirror.
Fixes #996.
Also, this PR performs several test improvements:

test model for Aggregate part is cleaned up;
test entity state definitions are now marked with the (entity) option;
most of the tests now ensure that entities have IDs set.

@armiol, PTAL.


Improve "get involved" page

[Issue created based on the suggestion document that Naoe created]
Become a helper

Contents of “Workshop
helpers”
could come here as it is.
Potentially link to “Helper’s
guide”

Become an instructor

Explanation that there are two options, being an instructor of
either

a self-organized workshop (by their own), and/or
upcoming workshops by CodeRefinery

And how to sign-up (potentially a link to “Stay
connected”)
Link to pages explaining about instructor trainings to be
Carpentries instructor and CodeRefinery
instructor
Link to “For instructors”

Contribute to lesson materials

Very short description of the possibility and link to the
corresponding section for more
details.

Become a partner institution (or “hub”?)

I am unsure what the definition of a “hub”, but is it different from
“partner institution” that could be a reciprocal partner (at least
ideally, in the end)? Or is it a sponsor institution??
Depending on the definition of a partner institution/hub, edit
contents under “Become a
partner”

Host workshops

Short description and a link to “Request
workshops”
Could be merged to “Become a partner institution”? Depending on the
definition of a partner institution, or a hub.

Stay connected

Each of the following with a link and a short description, if
necessary

News letter (subscription and archives)
Twitter
Zulip chat
Workshop notifications
GitHub?

Preferably with each logo

How shall we do with the paragraph "Become a partner"? Are we going to keep it as "become a training hub" and/or "become a funding partner"?

I would go for "Become a training hub".

"Become a training hub" only? Then the current description does not fit at all. Should I just remove all the current text and write to direct the visitor to https://coderefinery.org/about/hubs/#become-a-hub (i.e., to put a link there)?

I would not say no to a partner institution who only wants to give us money and does not want to become a training hub :-)
But seriously: Link is a good idea but the entry should be there. The person visiting "how to get involved" may not know about the about/hubs.

Well, So shall we keep the text under the current "Become a partner" as it is, but change the heading? Or shall we merge it under "Become a training hub", which I personally think a bit strange...

How about changing the header to "Become an institutional partner as a training hub", keeping the following part of the current text "Coderefinery started as a sponsored and funded project, but we are encouraging more partnerships to stay sustainable long-term. In general, we image a reciprocal relationship for academic institutions: you help us run workshops, we give workshops at your institution." and "Please take a look at training hubs page for more information"?

Sounds great.

Is this issue done? No rush if not, just checking whether this is still ongoing.

Well, I think content wise it is done. But for some reason, the current layout is very much changed and I feel it is a bit too noisy.

You mean font size and spacing?

Yes. Ref. law of proximity.

I agree it looks rough now but work in progress.
There is this: https://github.com/coderefinery/coderefinery.org/pull/398
But also please open issues or tell me everything that looks strange or not good. I have changed the underlying code a lot so styling got a bit shaken up.

Closing issue because it has been addressed (noisy form is independent problem).


fix(merge): return Observable when called with single lowerCaseO

Description:
Currently when merge is used with lower case observable, it returns lower case observable itself, instead of adapting it to RxJS Observable.
Observable.merge(lowerCaseO).map(...); // throws, since 'map' is not on lower case observable

Coverage increased (+0.0003%) to 97.689% when pulling 85752ebc22561c62aa98b004fd259347cea4742c on Podlas29:static-merge-with-one-observable-input into 31dfc7324bf51b98df6678f072b7a3bd4c0b5888 on ReactiveX:master.


nixos/privacyidea: use envsubst to avoid leaking secrets to the store

Motivation for this change
Otherwise, you'd have to specify a few values I'd consider rather secret in the Nix store.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@lheckemann thanks, fixed!


parameterization for multiple runs from one config

User Story
As a user I want parameterization for multiple runs.
Description
As a user, I want the ability to parameterize my simulations for multiple runs with a single configuration file.
Acceptance criteria

[ ] results of parameters match input from configuration file specified by the user
[ ] for every run suitable results are equal to the amount of outputfiles
[ ] all not parametrized remain the same in all runs
[ ] ...

To be able to do this task, we need to change almost all of our values, that are defined as uint, int or float.
In golang it is not possible to change a type dynamically. We would need to change every single value to slice or an array.


Make basic-build-test.sh more deterministic

Description
This PR makes the invocations of ssl-opt.sh in basic-build-test.sh more deterministic by fixing the seed used by the proxy. The motivations for this include:

avoid random failures in CI runs due to unlucky seeds that cause the proxy to drop too aggressively, resulting in timeouts
avoid random variations in coverage stats

I think that was the only part of basic-build-test.sh that was non-deterministic in ways that could cause such variations. (Of course SSL tests all use entropy, but neither the result of the tests nor the coverage data should depend on the random values used here.)
Status
READY
Requires Backporting
Yes

[x] 2.16 - #3442
[x] 2.7 - #3443

The CI failure on Mbed OS is unrelated to this PR — this PR only changes files that aren't used on Mbed OS. So the useful part of the CI has passed.


Fix locale files

Some files in the locale folder were not correct. Fixed to have the right syntax.

Some files like locale/en_BORK.js still contain const blaver = new Blavercale() – should be const blaver = new Blavercale()

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.171%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4996

Relevant Lines:
5034

💛  - Coveralls

Some files like locale/en_BORK.js still contain const blaver = new Blavercale() – should be const blaver = new Blaver()
My bad, changed where it was wrong

Thank you very much @dangus21


WoW DF - issue

1x [ADDON_ACTION_FORBIDDEN] AddOn 'Dejunk' tried to call the protected function 'SpellStopCasting()'.
...  Just ..  It is causing issues in combat for some absurd reason.

I get the same error when exiting the keybinds window in the game options, happens in the most recent build.
4x [ADDON_ACTION_FORBIDDEN] AddOn 'Dejunk' tried to call the protected function 'SpellStopCasting()'.
[string "@Interface/AddOns/!BugGrabber/BugGrabber.lua"]:480: in function <Interface/AddOns/!BugGrabber/BugGrabber.lua:480>
[string "=[C]"]: in function `SpellStopCasting'
[string "@Interface/FrameXML/UIParent.lua"]:4006: in function `ToggleGameMenu'
[string "@Interface/SharedXML/Settings/Blizzard_SettingsPanel.lua"]:292: in function `TransitionBackOpeningPanel'
[string "@Interface/SharedXML/Settings/Blizzard_SettingsPanel.lua"]:281: in function `ExitWithCommit'
[string "@Interface/SharedXML/Settings/Blizzard_SettingsPanel.lua"]:257: in function `Close'
[string "@Interface/SharedXML/Settings/Blizzard_SettingsPanel.lua"]:44: in function `onCloseCallback'
[string "@Interface/SharedXML/SharedUIPanelTemplates.lua"]:127: in function <Interface/SharedXML/SharedUIPanelTemplates.lua:122>


Can W041 be reinstated as a new option?

In v2.9.5 (which I realise was 11 months ago now) there was a change to remove W041 (#3115). So, after what would normally be considered a very minor version bump (2.9.4 to 2.9.5), jshint is no longer warning of an issue that it did previously. This I consider to be a backwards incompatible change. There doesn't appear to be a way to reinstate this behaviour.
I for one liked the previous behaviour but I can see it would be unnecessarily strict for many. But I am a bit unhappy that it was changed without any way to get it back. However, I'd be happy to look at re adding this as a new option if the maintainers would accept a PR for such a change?

As noted in the original bug report, we removed that warning because it was inconsistently-implemented and therefor a potential source of confusion. We don't classify relaxation of linting behavior to be backwards incompatible because consumers do not tely on the presence of warnings--only on their absence.
That said, we further rationalized the removal of the warning because it served the same purpose as warning W116 ("Expected '===' and instead saw '=='.") which users can opt in to received via the eqeqeq linting option. Can you try enabling that option in your project?

Thanks for responding.

because consumers do not tely on the presence of warnings--only on their absence

I sort of understand that logic, but by the same token, you could remove literally every warning issued by jshint and it would be backwards compatible. If you did that I don't think you could argue that consumers only rely on the absence of warnings.
In any case, I'm not really arguing for the changes done last year to be reversed, I'm more interested in whether you'd accept a PR for the addition of an option that allowed me to turn on W041 independently of eqeqeq. If you wouldn't that's fair enough. I'll move on.
It's not a big deal but it is a change in behaviour that I picked up because we run jshint on our codebase on two different systems (local dev and CI test plans). They are configured to run the same config file but run independent jshint source. One of those had been upgraded but seemingly only by a very minor version change. (I say it's not a big deal, but it would be a big deal if you'd removed a warning I really care about. This one I only slightly care about.)
In answer to your question - turning on eqeqeq produces a large bunch of warnings I'm not interested in. Particularly sometimes I want to take advantage of the loosely typed nature of javascript and compare "123" against 123 and have it succeed. W041 was a much more specific check for comparison against falsey which picks up possible code errors in a particular case. e.g. did you really mean compare to null or are you checking for "is falsey":  if (foo === null) vs if (!foo).
In short W041 doesn't serve the same purpose as W116, it is a subset. W116 is very broad. If I was starting a new project I probably would have W116 turned on but then I'd also probably go the whole hog and use Typescript.

I agree with @fivegreenapples , make sense the removing warning logic , but in reallity not work like that. In my case, the warning is useful and in version 2.9.5 it's gone.
Maybe that behaviour, remove warnings, should be consider to be a backwards incompatible change.
What do you think @jugglinmike ? It's worse to that project if we get that way?

Any news about that case @jugglinmike ?

Any news about that case @jugglinmike ?


bitlpm: Add Return Value to Upsert Method

It would be helpful to know when the Upsert method adds or replaces a new key. This updates
the Upsert method to do that.

/test

/test

/test


chore: create a dir for docs and add a RFC template

Signed-off-by: arkbriar<EMAIL_ADDRESS>What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Make a directory for docs and add a template for RFCs

Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


How to get application version in pubspec.yaml at runtime?

I want to show my application version at runtime.

You have to use https://github.com/go-flutter-desktop/plugins/blob/master/package_info/README.md

Thank you


Bump packages

Codecov Report

Merging #37 (15e05b6) into main (a7b35f2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #37   +/-   ##
=======================================
  Coverage   84.55%   84.55%
=======================================
  Files          28       28
  Lines         602      602
  Branches        2        2
=======================================
  Hits          509      509
  Misses         92       92
  Partials        1        1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7b35f2...15e05b6. Read the comment docs.


Bullet points

I've been trying to edit my Wiki documents, so that they display nicely in markdown or asciidoc, and I can't figure out why bullet points as asterix aren't displaying well under asciidoc.
Example
https://wikistr.com/nkbip-01*dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319

Turns out you need a blank line between the list bullet points and the previous and next paragraphs. I should add a preview thing on https://wikistr.com/

Deployed.

Next I have to fix quill-asciidoc to account for these shenanigans.

Looks good now, thanks.


Pod to Pod access is blocked with STRICT mtls

Bug Description
There is a user case that we need pod to pod direct access inside mesh. Before we enable the STRICT PeerAuthentication, it's working as expected however after enable the STRICT mtls, the access is broken. Here is the flow;

And here is the error msg got from pod1 to curl pod2 IP:
curl  http://<IP_ADDRESS>:8082 -v
*   Trying <IP_ADDRESS>:8082...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8082 (#0)
> GET / HTTP/1.1
> Host: <IP_ADDRESS>:8082
> User-Agent: curl/7.68.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host <IP_ADDRESS> left intact
curl: (52) Empty reply from server

Checked the sidecar log in client side(pod 1), here is the error:
2022-02-18T09:53:52.338146Z debug   envoy pool  [C1649] connecting
2022-02-18T09:53:52.338153Z debug   envoy connection    [C1649] connecting to <IP_ADDRESS>:8082
2022-02-18T09:53:52.338194Z debug   envoy connection    [C1649] connection in progress
2022-02-18T09:53:52.338210Z debug   envoy pool  queueing request due to no available connections
2022-02-18T09:53:52.338215Z debug   envoy conn_handler  [C1648] new connection
2022-02-18T09:53:52.339039Z debug   envoy connection    [C1649] connected
2022-02-18T09:53:52.339056Z debug   envoy pool  [C1649] assigning connection
2022-02-18T09:53:52.339070Z debug   envoy filter    [C1648] TCP:onUpstreamEvent(), requestedServerName:
2022-02-18T09:53:52.339988Z debug   envoy misc  Unknown error code 104 details Connection reset by peer
2022-02-18T09:53:52.340001Z debug   envoy connection    [C1649] remote close
2022-02-18T09:53:52.340004Z debug   envoy connection    [C1649] closing socket: 0
2022-02-18T09:53:52.340017Z debug   envoy pool  [C1649] client disconnected

Also checked the sidecar log in server side(pod 2), fond some log like:
2022-02-18T10:18:07.114417Z	debug	envoy connection	[C49805] closing data_to_write=143 type=2
2022-02-18T10:18:07.114429Z	debug	envoy connection	[C49805] setting delayed close timer with timeout 1000 ms
2022-02-18T10:18:07.114438Z	debug	envoy pool	[C6] response complete
2022-02-18T10:18:07.114443Z	debug	envoy pool	[C6] destroying stream: 0 remaining
2022-02-18T10:18:07.114488Z	debug	envoy connection	[C49805] write flush complete
2022-02-18T10:18:07.114633Z	debug	envoy connection	[C49805] remote early close
2022-02-18T10:18:07.114643Z	debug	envoy connection	[C49805] closing socket: 0
2022-02-18T10:18:07.114669Z	debug	envoy conn_handler	[C49805] adding to cleanup list
2022-02-18T10:18:07.520497Z	debug	envoy main	flushing stats
2022-02-18T10:18:08.051608Z	debug	envoy filter	original_dst: New connection accepted
2022-02-18T10:18:08.051676Z	debug	envoy filter	tls inspector: new connection accepted
2022-02-18T10:18:08.051720Z	debug	envoy conn_handler	closing connection: no matching filter chain found
2022-02-18T10:18:08.315775Z	debug	envoy connection	[C49800] remote close
2022-02-18T10:18:08.315816Z	debug	envoy connection	[C49800] closing socket: 0
2022-02-18T10:18:08.315885Z	debug	envoy conn_handler	[C49800] adding to cleanup list
2022-02-18T10:18:09.113576Z	debug	envoy conn_handler	[C49806] new connection
2022-02-18T10:18:09.113872Z	debug	envoy http	[C49806] new stream
2022-02-18T10:18:09.113989Z	debug	envoy http	[C49806][S9254331503083015686] request headers complete (end_stream=true):
':authorit

Expected behavior:
Suppose the pod to pod access should always work no matter if it's PERMISSIVE or STRICT. For STRICT mode,  the client sidecar should intercept the request and do tls origination and the server sidecar should do tls termination and mtls between both sidecars.
Version
istio version: 1.10
kubectl version: 1.18.8

Additional Information
No response

This is a known limitation of the current architecture. I am working on a design doc to make it work.
You can actually make it work only for HTTO if you set the host header to service name and configure DestinationRule lb policy to ORIGINAL_DST

This is a known limitation of the current architecture. I am working on a design doc to make it work.
You can actually make it work only for HTTO if you set the host header to service name and configure DestinationRule lb policy to ORIGINAL_DST

Thanks @howardjohn , would you share the plan/ETA to fix this issue, is there some WIP doc? In the DestinationRule lb policy only PASSTHROUGH supports ORIGINAL_DST and I guess the workaround is:

Create a service foo for the destination pod
Create the DR with PASSTHROUGH for above service
In the client pod do something like curl http://<IP_ADDRESS>:8080  -H "Host: foo"

Another workaround in my mind is to introduce port level PeerAuthentication for example change port 8080 to PERMISSIVE. But considering we want to build an end 2 end TLS environment, we would still need a long term fix to support pod to pod access within mesh and STRICT mtls.

@howardjohn  I found the related upstream issues
https://discuss.istio.io/t/503-between-pod-to-pod-communication-1-5-1/6121/21
and https://github.com/istio/istio/issues/23024
May I know what is the proposed solution in upstream to address this issue?

I think the gap here is that by default if the client pod access server pod ip directly, the request will be handled by the PASSTHROUGH cluster however the PASSTHROUGH cluster doesn't support mtls. A workaround is to create service per pod and access service name instead of pod but that's not a scalable solution.

Currently the workaround is to create a ClusterIP service per pod and the client pod access the server pod with service name, for example:
curl http://service-select-one-pod:8080

The http request will be changed to mtls between sidecars. This is not a scalable solution but works for us for now. Still need a generic solution for it.

@howardjohn  Would you kindly help share the long term solution for this?

https://docs.google.com/document/d/1NAccj8WyjBXOUsMdOHW9sWW6PeCnrIWpc3muBHd4Cs8/edit#heading=h.xw1gqgyqs5b
On Mon, Feb 28, 2022 at 6:38 AM Chen Youxiong @.***>
wrote:

@howardjohn https://github.com/howardjohn Would you kindly help share
the long term solution for this?
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/37431#issuecomment-1054323077, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXMLQ4ZIPLQ54RE4L33U5OCHNANCNFSM5OXOM22Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@howardjohn
I am also facing this issue. My use case is for prometheus scraping where I have configured a job with kubernetes_sd_config as role:pod.
i can scrape by using the service_name and port but not by pod IP. The reason I am using pod IP and not the service name is because I need to scrape metrics from all the pods of the service.

We are also experiencing this issue with a few workloads that advertise their services via IP. The solutions proposed in the design document look suitable for the current problem, what time-frame will it take to see these implemented in Istio? Also we would be more than happy to provide assistance if we can in any way.

@Champ-Goblem if its just a few Services I would make them headless Services where this does work, even today. That of course doesn't work for something like prometheus where it needs to hit every pod, but if its just a couple like Zookeeper or whatever, should be fine. Best case that doc is implemented in 1.14 so released in ~2mo, but realistically it won't land until 1.15+. In order to implement it we will likely need substantial changes both to Istio and Envoy

@howardjohn
Hello, I was following up on an issue that we are experiencing which led me to this discussion. We are experiencing the same issue and the same result as the OP. Direct communication from podIP to podIP is causing us to receive the following response:
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

I'm on the deployment side of our operations team and I do not have access to manipulate the application headers.
I read through the proposal google doc you posted in this comment https://github.com/istio/istio/issues/37431#issuecomment-1054450785 and feel as though this would address our case. Specifically line numbers 5 or 8 in the proposal table.
Are there any updates to this proposal? I know that this post is closed but would I would really appreciate an update or any progress around this issue.
Thanks in advance!

We are still interested but its very very hard to implement due to backwards compatibility; https://istio.io/latest/blog/2022/introducing-ambient-mesh/ will support direct to pod


accessing YAML arrays

Hi guys,
I've been trying to access some data in the Front matter array using the percent syntax. I.e.:
social:
 - link<EMAIL_ADDRESS>   icon: email.svg
 - link: http://www.instagram.com/myname
   icon: instagram.svg
 - link: http://www.linkedin.com/in/myname
   icon: linkedin.svg

How do I get the instagram link for example? I tried %meta.social[1].link%
Thank you in advance.

I'm afraid this isn't possible. The %meta.*% syntax is meant to be a simple and convenient way of including (or rather replacing) static contents like a description or title, not for things like arrays what would require a pretty complex parser. Depending on what you're trying to achieve a Twig-based solution is probably the best way to go.

I'm using the front matter social in the template to display the icons in the header (much like the default content-sample). I'd like to also inline those links on the page. Since it's a small site and I only need this on one page I'm fine just using markdown link references and editing two places in the future. But I could imagine that, for a bigger site, inlining meta links could prove useful.
Thanks for letting me know I'm not crazy. I was trying so many things!
Issue resolved.


Monthly "Celo (d)App and Wallet Council"

Closing this epic because it's not in use anymore (and too broad).


Allow icons to align to the "opposite" side of the menu

Broken out of https://github.com/dermotduffy/frigate-hass-card/issues/378 . Suggested by @felipecrs .

Will be in the v4.0.0 release.


Checking if worker image exists

Until now, we assumed the worker image existed if the kmod image existed, which caused a bug when using different worker images but the same kmod image in two scenarios on the same cluster. Now, we ensure that the existence of the worker image is also checked locally.
/cc @ybettan @yevgeny-shnaidman

/lgtm

/retest

/cherry-pick release-2.2

/cherry-pick release-2.2


Make language specific stuffs configurable

We should move language specific configuration into separated folder to support for new languages.

Dataset standard
Metric configuration
Language specific configuration

Prior to task 2

#14 #15 Due to some problems of metric programs (hard code from previous guy), I should reconstruct all the pipeline and propose in PR #16

@ledong0110 Dataset for Korean:

https://huggingface.co/datasets/HAERAE-HUB/KMMLU
https://huggingface.co/datasets/EunsuKim/CLIcK


While using Angular the History module cannot be used

Swiper Version: ~6.4.5
Platform/Target and Browser Versions: Ionic 5

What You Did
By activating the history module through the SwiperCore.use method, you should be able to provide the data-history attribute to the template tag that has the swiperSlide directive. Unfortunately, to my understanding, the current implementation of Swiper doesn't allow binding [attr.data-history] and by forcefully binding the parameter through the underlying swiperRef instance using the following code:
this.swiper.swiperRef.slides.forEach((element, index) => element.setAttribute('data-history', this.items[index]))

The History.slugify method throws the following error:
Cannot read property 'toString' of null

Expected Behavior
The users should be able to bind the attribute or an alternative solution should be provided.
Actual Behavior
To my understanding, the current implementation doesn't allow binding the data-history attribute on the slides.

Can you prepare a demo on stackblitz, please?
You can fork this: https://stackblitz.com/edit/swiper-angular-example?file=src/app/app.component.ts

Closing due to inactivity and/or no responses from issue author and missing stackblitz demo