Resolve css/js Media paths using static templatetag

When running Mezzanine with a CDN for CSS/JavaScript (or even just browser side caching) it's important to use some form of cache-busting names for static files like those generated by CachedStaticFileStorage.
Static files listed under class Media: do not automatically get these benefits, so it is required to manually convert them to their static file names. Django's admin does this in several places.
Otherwise caching (via CDN or browser) can wreak some havoc when these files change and old versions are used.

Makes sense, thanks.


Refactor folder structure, introduce developer debug option

Here is a screenshot from locally rendered site

I'm not against it but given the small number of files we are currently dealing with I have to ask whether this is really worth it.

I'm ok to close or keep a private fork of PR branch if this is not helpful. Either sounds fine to me.

Folder structure refactoring will allow one to group together a category of governance documents into one folder.
A developer debug option will allow one to render the page locally, verify any bugs priori.

I'm not against it but given the small number of files we are currently dealing with I have to ask whether this is really worth it.

I'm ok to close or keep a private fork of PR branch if this is not helpful. Either sounds fine to me.
1. Folder structure refactoring will allow one to group together a category of governance documents into one folder.

2. A developer debug option will allow one to render the page locally, verify any bugs priori.

I suggest you move the debug option to a different PR anyway. As for the folder refactoring I understand the rationale. I just think we have so few files anyway that this won't make much difference. But, again, I'm not against it so I'm happy to leave it to others to decide whether they think this is worth it.

I'm not against it but given the small number of files we are currently dealing with I have to ask whether this is really worth it.

I'm ok to close or keep a private fork of PR branch if this is not helpful. Either sounds fine to me.
1. Folder structure refactoring will allow one to group together a category of governance documents into one folder.

2. A developer debug option will allow one to render the page locally, verify any bugs priori.

I suggest you move the debug option to a different PR anyway. As for the folder refactoring I understand the rationale. I just think we have so few files anyway that this won't make much difference. But, again, I'm not against it so I'm happy to leave it to others to decide whether they think this is worth it.

Moved as per suggestion https://github.com/hyperledger/tsc/pull/12


not file:src.data_processor.chatglm2

this file don't updown

Thanks for your interest in our work. Actually, the chatglm2 is not adopted in our code. I deleted the code related to chatglm2 directly to eliminate the bug and you can pull the repo again.
Best regards


Use develop image in MTM helm values

Hi,
Shouldn't we use the latest development image inside the MTM helm chart? I tried using the one from answerdigital but I did not have permissions to do so.
See "discussion" in https://github.com/Project-MONAI/monai-deploy-workflow-manager/discussions/658
Description
This PR sets the image in the MTM helm chart values to the development image being built nightly from this repo. Right now, it points to an external image from answerdigital which is not accessible publicly.
Status
Ready
Types of changes

[ ] Non-breaking change (fix or new feature that would not break existing functionality).
[X] Breaking change (fix or new feature that would cause existing functionality to change).
[ ] New tests added to cover the changes.
[ ] All tests passed locally.
[ ] Documentation comments included/updated.
[ ] User guide updated.
[ ] I have updated the changelog

This has been "superseded" by https://github.com/Project-MONAI/monai-deploy-workflow-manager/pull/666 .


Multiple references from same note

When referencing on the same note multiple times appears also multiple times in "links to this note"
Is it possible to just once on the "links to this note"?
Best regards
ArchGalileu

This has been fixed. Thanks for letting me know.


doc: bluetooth: clarify where to find the btmgmt binary

Prepend the btmgmt call with the tools/ subdirectory to line up with
the other BlueZ tool calls in the examples.
Signed-off-by: Henrik Brix Andersen<EMAIL_ADDRESS>

Codecov Report

Merging #10810 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10810   +/-   ##
=======================================
  Coverage   53.24%   53.24%
=======================================
  Files         215      215
  Lines       25820    25820
  Branches     5692     5692
=======================================
  Hits        13748    13748
  Misses       9756     9756
  Partials     2316     2316

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 b6cd192...050f199. Read the comment docs.


Add an example of a differentiable model

An Implementation of the Fully Connected model described in this paper.
Description
It is not meant to reproduce the paper's results (because the implementation of the HRR in the paper is slightly different from torchhd's HRR). It is just a good starting point, for implementing other models described in the mentioned paper and "Multi-Label Classification With Hyperdimensional Representations".
Closes #143

Checklist

[ ] I added/updated documentation for the changes.
[ ] I have thoroughly tested the changes.

@mikeheddes I just fixed the points and pushed the changes.

@milad2073 thank you for another great contribution to Torchhd!


Can't connect Power BI to Azure DevOps even with "View analytics" permission.

I can't connect Power BI to Azure DevOps. I still get the error "We couldn't authenticate with the credentials provided. Please try again." even when I have "View analytics" permission.

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

ID: 1f04bf6a-1455-8770-0a2e-da22f644bced
Version Independent ID: d63dea23-3678-60c4-c028-c4b618fc3613
Content: Analytics permissions and security - Azure DevOps
Content Source: docs/report/powerbi/analytics-security.md
Product: devops
Technology: devops-analytics
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@qzxpqbp Thank you for the feedback, we're sorry for the issues you're experiencing.
Please go through the steps outlined in this post using an OData feed to find out which one is causing issues.
You can also try soliciting feedback from the Power BI product team here or try the Azure DevOps community.

Closing this issue now.


SCSS support: Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.

Importing this package in npm isn't as viable as it used to be since including .css files with @import became a non-standard behavioud in LibSass..

@coldtelling use systematize then 😈
It's basically normalize.css 8.0 translated to SCSS, and with some very localized additions, such as the system font-stack.

I'm not going to rename the npm package. Sounds like a problem with libsass that can be addressed somewhere in the tool chain

Dart Sass is also not allowing this behavior. It's possible to address this during a build, but it would be nice if a .scss version was also available. Because forks of this library never seem to last more than a couple of months, would you please reconsider adding this?

As announced on the Sass repo on 16th June, importing of .css files will be officially supported by Sass in future.
My understanding of the announcement and proposal is that @import 'normalize.css/normalize' (note; no file extension) should print the contents of normalize.css into your final compiled CSS file rather than introducing a CSS @import.

@robneu Dart Sass does now support importing CSS files

Right now I'm using Gulp 4 as bundler, I have a root app.scss file where I include everything I need, so adding normalize.css as an extra source file which will be called using @import is not good enough for me.
What I did is install normalize.css using npm and then, inside my main styles bundling pipeline, just add one previous step before bundling my main SCSS file:
// Bundle styles files
function styles() {
    // Rename NPM's "normalize.css" to "_normalize.scss"
    gulp.src("./node_modules/normalize.css/normalize.css")
      .pipe(rename(function (path) {
          path.basename = "_normalize";
        path.extname = ".scss";
      }))
      .pipe(gulp.dest("./node_modules/normalize.css/"));

    // And then bundle everything
    return gulp
        .src(paths.styles.src)
        // ...
        .pipe(gulp.dest(paths.dest))
        // ...
}

Please note I'm using gulp-sass and gulp-rename packages in this example.
Later on I just use @import in the root sass file, like so:
@import './my-path-to/node_modules/normalize.css/_normalize.scss';

This way normalize.css will be always up-to-date.
Hope this helps someone!


[Request] Silence Background music when enabling Video sound.

Currently, when using extra metadata (fullscreen loader) and the right theme, both the background and video audio will play if enabled.
It would be nice if the background music could pause when a video is playing with audio.

i have no control over other extensions so i can not detect if video is playing or not


Update gamedata for TF2 version 8835751 (2024-04-22)

Closes #19.
Untested; you'll probably want to verify the changes yourself (CC @NNinja1255 for testing).  Note the following:

On Linux, some function calls may have been optimized to use custom calling conventions.  The detours will not appear to work in those cases.  I have not identified which ones are still called.
On Windows, CObjectSentrygun::ValidTargetPlayer() has been inlined into ::FindTarget().  I've opted to remove the signature here.  The plugin seems to support missing signatures, so it'll just be missing functionality.
I haven't updated the annotations to match the signatures.

Notes on finding signatures:

CHeadlessHatmanAttack::IsPotentiallyChaseable via referenced ConVar tf_halloween_bot_quit_range
CMerasmusAttack::IsPotentiallyChaseable via referenced ConVar tf_merasmus_chase_range
CEyeballBoss::FindClosestVisibleVictim via referenced ConVar tf_eyeball_boss_debug_orientation
CObjectSentrygun::FoundTarget via unique string Building_Sentrygun.AlertTarget

Yea the plugin should definitely be able to handle missing sigs. Thank you again for updating my signatures 💙


Week error

Describe your bug here.
im new to this, but when i try to open my custom week i get this (look down) i dont know what it means so can someone tell me how to fix this error

Command Prompt/Terminal logs (if existing)
look at the error at the top bruh

Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
a whole week

Not a bug
Duplicate of #9507


Flatten EventHubOptions

Resolves https://github.com/Azure/azure-sdk-for-net/issues/17742 and https://github.com/Azure/azure-sdk-for-net/issues/18088

/azp run net - eventhub - tests

/azp run net - eventhub - tests


Please consider removing custom install script

Contact Details
No response
What do you need?
I previously filed issue  which is closed as “completed”, but the custom install script only seems to be removed from tsparticles, not react-tsparticles or tsparticles-engine.
(I would have commented on that issue, but it’s locked now.)
More information can be found in the linked ticket.
Thanks!
tsParticles Version
latest
Which library are you using?
Vanilla (tsparticles), React.js (react-particles, react-tsparticles, react-particles-js)
Code of Conduct

[X] I agree to follow this project's Code of Conduct

This is not a planned change in the near future. There are still many tutorials using react-particles-js for showing particles in a React environment.
Maybe in the future, these scripts will be removed, keeping this open is not necessary.


Add an endpoint to calculate Cost of Goods Sold

Note

Add an endpoint to calculate Free Cash Flow to Firm.
Create a function in ./helpers/functions.py file for the calculation.
Map it with an endpoint GET /cogs in the main.py file with properly.

@nikhil25803 Please assign this to me.

Go ahead and add the endpoint :)


missing header RestKit.h

cloned repo, it's no where to be found but bridging header is looking for it.

How did you integrate it @gaming-hacker ?

cloned it.
tried to compile the example by default
i search the cloned repo and there's no Restkit.h

Have you tried to get the git submodules @gaming-hacker ?

d'oh, let me look.

yes forgot to include.


Give Goombas' something unique

Make Goombas appear in game
Make Goombas move back and forth between two set locations
Make Goombas interact with player and kill them on touch
Make Goombas die when jumped on
Make unique Goombas (flying ones, invulnerable ones)
Make it so you can choose the spawn location of Goombas
Make walking Goombas on platforms
Make Goombas interact with eachother (bump off of eachother and such)


deps: bump capability to v1.0.1

Description

closes: #XXXX

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/).
[ ] Added relevant godoc comments.
[ ] Provide a conventional commit message to follow the repository standards.
[ ] Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
[ ] Re-reviewed Files changed in the GitHub PR explorer.
[ ] Review SonarCloud Report in the comment section below once CI passes.

Opening this for review, although yesterday I saw something strange: locally, VS Code indicates in the go.mod that instead of picking up cosmossdk.io/core v0.11.0 (which is the one specified in the go.mod), pick up v0.12.0, which gives build errors. If somebody else could try locally as well to check if they have the same behaviour, that would be nice.


Use the fully fledged struct for downloading

The hand-constructed NVD API 2.0 struct was naively done and appears to lead to nil pointer panics under certain conditions.

do you have more details on the actual panics?

I saw a crash yesterday that related to this and didn't investigate further, but assumed there must have been some malformed JSON:
ERROR 2023-11-30T06:04:40.502525813Z [resource.labels.containerName: nvd-mirror] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x983216] goroutine 1 [running]: main.downloadCVE2WithOffset({0x7fff84b72d58, 0x24}, 0x0) /src/cmd/download-cves/main.go:106 +0x6d6 main.downloadCVE2({0x7fff84b72d58, 0x24}, {0x7fff84b72d87, 0x8}) /src/cmd/download-cves/main.go:122 +0x1af main.main() /src/cmd/download-cves/main.go:42 +0xdd

I'd been meaning to excise this struct when I added the other one, but ran into some issues at the time that I was able to work through with fresh eyes on a second attempt.


Feature/quality pipeline GitHub

Adding the quality workflow for github

Draft for two reason:

Waiting for github pipeline generator PR to be merged
waiting for the quality for devon4node PR to be merged also


Allow 'match' operator

Closes #3359

@GAumala Do you need any help with this?

Yes, I'm not sure how should I write a test for this. It doesn't seem very simple because:

It would have to be SQLite only, I don't think other databases support MATCH.
It would require a new table created with fts.

Yes, I'm not sure how should I write a test for this. It doesn't seem very simple because:

It would have to be SQLite only, I don't think other databases support MATCH.
It would require a new table created with fts.

@GAumala Check test/integration2/schema/foreign-keys.spec.js for an example of how to do DB-specific tests. You can skip everything that !isSQLite(knex))

@GAumala Check test/integration2/schema/foreign-keys.spec.js for an example of how to do DB-specific tests. You can skip everything that !isSQLite(knex))

Thanks for the help! I added a test. Let me know if further changes are needed.

Thanks for the help! I added a test. Let me know if further changes are needed.

Thank you!

Thank you!


Hide slide number

Hi,
I know it is now possible to not increment the slide number, if we want. But is there a way to completely hide the slides number ?
Thanks

Ok sorry, found it:
var slideshow = remark.create(
{
slideNumberFormat: ''"
});


add workflow for publihsing gpu images and zarf-packages

We now have access to larger runners so we can finally be better about how we publish artifacts.
This PR adds a workflow for building the Dockerfile.gpu image, publishing the created image, and then using the newly published image to build a zarf package and then, finally, publishing the newly created zarf package.

Change PR name to match conventional commits v1.0.0, and fix typo on "publishing". Just to start using proper practice for future release-please automation.


Channel inversion during conversion from opencv::core::Mat -> image::DynamicImage

Hello,
I'm new to Rust so thank you for your crate, you saved my life!
However, I noticed an issue that is quite blocking for me. I'm using the methods ty_into_cv and try_from_cv to convert a Mat from a .png to a DynamicImage. The issue is that the channels seem to be mixed up during the process because my resulting image is blue.
Here is the sample code:
fn load_image(&mut self, img_path: &str) -> Result<ColorImage> {
        let cv_img = imgcodecs::imread(img_path, imgcodecs::IMREAD_ANYCOLOR)?;
        let dyn_img: DynamicImage = cv_img.try_into_cv().unwrap();
        dyn_img.save("test.png");

The code does other things with the image afterwards but i tracked down the issue to this step.
Here is the original image and the one I save:

Thanks for your help!

Hello,
Yesterday I found the solution which was user error I suppose.Te issue was that opencv::imgcodecs::imread opens the image as a Bgr image instead of Rgb. The solution was therefore:
 fn load_image(&mut self, img_path: &str) -> Result<ColorImage> {
        let bgr_cv_img = imgcodecs::imread(img_path, imgcodecs::IMREAD_ANYCOLOR)?;
        let mut rgb_cv_img = core::Mat::default();
        imgcodecs::cvt_colot(&bgr_cv_img, &mut rgb_cv_img, COLOR_BGR2RGB, 0);
        let dyn_img: DynamicImage = rgb_cv_img.try_into_cv().unwrap();
        dyn_img.save("test.png");


Proposed api interface changes

I want to propose interface changes, Firstly to follow go interface naming, api creates Client interface.
All methods have args with native types, so for adding port to logical switch we can provide
*LogicalSwitch struct to function, that have needed name. Also in this struct we can pass ExternalIDs, so LSPAdd can find needed ls by name, uuid, or external_ids. This is already handled with getRowUUIDs.
as in example of LSPAdd second arg is *LogicalSwitchPort with filled needed data. So function can receive only 2 args. We can easy handle optional params and default values.
Inside function we can use https://godoc.org/github.com/mitchellh/mapstructure to convert from struct to map[string]interface{}.
I think that this is more universal that current approach, and easy deduplicate many identical pieces of our code.

we can use https://godoc.org/github.com/mitchellh/mapstructure to convert from map[string]interface

@hzhou8 any suggestions?

@softwarejl what do you think about interface changes? another thing not pass struct is use option like feature.
So for each ovn table we have item Option, and passing it to Delete, Create, Update methods, slice of such options set struct row items.
Drawback for this - for each uniq item in struct we need to have different option. So this is many options.

@hzhou8 @softwarejl i need you approve and suggestions. This is not small task, but it don't need too much time to provide WIP for this.

@vtolstov I support this idea! @softwarejl and I had discussed about having more generic API interface many times, just didn't get bandwidth to work on it. Maybe you could have a POC first. @softwarejl what do you think?

Yes, we need to improve on that part, beside the interface, we need a way to define the data structure which aligns  with ovn table structure. we need a poc firstly.

first change in this series #42

@hzhou8 this is first part of storing in cache needed struct https://github.com/eBay/go-ovn/pull/44/files#diff-48d527baa1a7dc53e558c5548785cf1bR277

i think that if we store needed type inside cache all thing can be very simple.
next sep is write helper to check if some struct holds in another (so we can pass LogicalSwitch with only uuid setted and get back full row from cache if it exists)

if somebody want helps me , i'l be happy =)

@vtolstov Thanks for the effort. Could you complete the POC with just one end-to-end example, e.g. LogicalSwitchPort create/read/update/delete with the new approach? That would be very helpful for me to understand, since I am not sure yet if I understand what the helper function means exactly.

@hzhou8 check ovnnbimp.go and acl.go
main thing - i'm parse map[string]interface{} and convert it to needed struct and store it in cache,
when i need to find needed row i'm check via reflection all fields in passed row and check such row in cache.
now this is POC so not all fine, but main parts ready.

@hzhou8 what can you say?

@vtolstov this looks awesome! It simplifies a lot for the conversions. I think most of the code is generic for ovsdb, so it can actually be in libovsdb. For OVN part, it would be even better if we can generate the data types from schema, instead of manually write it (but it is totally ok now as the first step).

i think that if we store needed type inside cache all thing can be very simple.
next sep is write helper to check if some struct holds in another (so we can pass LogicalSwitch with only uuid setted and get back full row from cache if it exists)

I think we should have two sets of "get" methods. One is get by uuid, another is "find" by any combination of column values.

Ok, so for now may be i can complete rewrite via ovn repo? And after that when all works fine we can move needed parts of code to libovsdb and change some parts of go-ovn?
Generation types from /usr/share/openvswitch/ovn-nb.ovsschema is fine for me, this is error prone and cam be used via go generate step.
About two get method -thanks,  this is good.

last question, does we need to support nested values in ExternalIDs?
As i know for neutron case this is needed, so i also need to create some recursive function to check nested values... (but for POC now needed now).

last question, does we need to support nested values in ExternalIDs?
As i know for neutron case this is needed, so i also need to create some recursive function to check nested values... (but for POC now needed now).

Do you have an example? I think we should support whatever column types can appear in OVSDB schema. (Of course it doesn't have to be complete in the first version)

I can't find example now, but as i see in libovsdb map represented as map[string]interface{} , but ovn-nb says:
external_ids: map of string-string pairs
                     Key-value pairs for use by the CMS.  The  CMS  might  use
                     certain  pairs,  for example, to identify entities in its
                     own configuration that correspond to those in this  data‐
                     base.

so may be recursion is not needed

Yes, the schema defines as:
"external_ids": {
"type": {"key": "string", "value": "string",
"min": 0, "max": "unlimited"}}},
So the value must be string.
In fact, checking OVSDB RFC7047, it is not possible to have nested values:

The type of a database column.  Either an  or a JSON
object that describes the type of a database column, with the
following members:
"key":                  required
"value":                optional
"min":                    optional
"max":  or "unlimited"    optional
The "value" has to be base-type, i.e. string, integer, etc.

So happy to see this issue after write some code like this 🤣
func MapInterfaceToMapString(m map[interface{}]interface{}) map[string]string{
	mapString := make(map[string]string)
	for i, v := range m {
		strKey := fmt.Sprintf("%v", i)
		strValue := fmt.Sprintf("%v", v)
		mapString[strKey] = strValue
	}
	return mapString
}

@vtolstov , @hzhou8 What is the status of this enhancement?
I think I'd be able to allocate some cycles to help on this effort if needed.

i don't have time to finish it. may be the best - generate needed struct from schema and replace own handmade stuff
after that rewrite api interfaces

I have coded a small PoC based on @vtolstov's and some old code I had. The result is here:
https://github.com/amorenoz/go-ovn/commits/poc/crud-api
(used a new table: Datapath_Binding from SouthBound)
Since there is no proposal for an API (let's discuss this!), I've implemented an API that resembles a ORM:
https://github.com/amorenoz/go-ovn/blob/be88c59e1074b54956d632c38165123ee6644c36/datapath_binding_test.go
Taking @vtolstov's idea, the encoding/decoding is done based on struct tags:
https://github.com/amorenoz/go-ovn/blob/be88c59e1074b54956d632c38165123ee6644c36/datapath_binding.go
It's still very early, but it could serve as a discussion trigger. @hzhou8 WDYT?
Some issues that I would like feedback on:

Is there a proposal of how the API should look like? I think that would be a good start.
Should we keep expose a "clean"  Add() function that performs the operation instead of returning it?
Should this be exposed in the same Client or in another interface?
Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

sorry i need more time to dig.
Firstly i don't like
var datas []DataPathBinding
err = ovndbapi.List(&datas)

usually List, returns slice and err like datas, err := ovndbapi.List()
Same thing for Get...

sorry i need more time to dig.
Thanks for taking some time to look into it!

Firstly i don't like
var datas []DataPathBinding
err = ovndbapi.List(&datas)

I took inspiration from a well-known, widely-used Golang ORM
It also resembles the widely used json {un,}marshal functions where the information of how to translate from json to struct is encoded in the stuct's 'tags' (credit's are yours @vtolstov for this)
This also allows the API to be expanded without requiring library recompilation. If a new user-specific table is created, the user could create a new struct specifying "ovn" tags and the library would be able to read / write from that Table without recompiling the library.

usually List, returns slice and err like datas, err := ovndbapi.List()

If ovndbapi.List() is used, how will List() know what Table to list? (the current PoC uses reflect to inspect the type of the given argument). We would en up having ListLogicalRouter(), ListLogicalSwitch, etc... and this should be automatically generated. Is that what you prefer?
@hzhou8 WDYT?

sorry i need more time to dig.
Thanks for taking some time to look into it!

Firstly i don't like
var datas []DataPathBinding
err = ovndbapi.List(&datas)

I took inspiration from a well-known, widely-used Golang ORM
It also resembles the widely used json {un,}marshal functions where the information of how to translate from json to struct is encoded in the stuct's 'tags' (credit's are yours @vtolstov for this)
This also allows the API to be expanded without requiring library recompilation. If a new user-specific table is created, the user could create a new struct specifying "ovn" tags and the library would be able to read / write from that Table without recompiling the library.

usually List, returns slice and err like datas, err := ovndbapi.List()

If ovndbapi.List() is used, how will List() know what Table to list? (the current PoC uses reflect to inspect the type of the given argument). We would en up having ListLogicalRouter(), ListLogicalSwitch, etc... and this should be automatically generated. Is that what you prefer?
@hzhou8 WDYT?

i'm prefer this style:
type Client struct {
  LogicalRouter
  LogicalSwitch
  ...
}

type LogicalSwitch interface {
  List() ([]schema.LogicalSwitch, error)
}

so list of switches looks like
cli, err := NewClient(xxx)

sws, err := cli.LogicalSwitch.List()

i'm prefer this style:
type Client struct {
  LogicalRouter
  LogicalSwitch
  ...
}

type LogicalSwitch interface {
  List() ([]schema.LogicalSwitch, error)
}

so list of switches looks like
cli, err := NewClient(xxx)

sws, err := cli.LogicalSwitch.List()

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)
My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)
My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?
So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?
Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?
So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?
Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

"reading" functions should directly return the results. In addition, for efficiency, we should provide an interface to iterate the local cache instead of duplicate the whole result list by a List() function.

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?

Yes.

So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?

Yes. Do you think this is reasonable?

Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

I didn't thought about this. Too generic API may be harder to use, but I didn't think deeply on this option.

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

"reading" functions should directly return the results. In addition, for efficiency, we should provide an interface to iterate the local cache instead of duplicate the whole result list by a List() function.

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?

Yes.

So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?

Yes. Do you think this is reasonable?

Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

I didn't thought about this. Too generic API may be harder to use, but I didn't think deeply on this option.

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

"reading" functions should directly return the results. In addition, for efficiency, we should provide an interface to iterate the local cache instead of duplicate the whole result list by a List() function.

Good idea!

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?

Yes.

So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?

Yes. Do you think this is reasonable?

It might be complicated. Layered projects might want to stick with an old version of go-ovn feature-wise while supporting newer ovn schemas. That would put some pressure into go-ovn for being very conservative in the changes it introduces. The alternative would be to clone the entire repository per supported ovn version.
Plus, you have the problem of guaranteeing what version of ovn you work with. Projects that work with a pre-defined version of go-ovn (such as ovn-kubernetes) might be able to cope with it, but others like skydive might not have it that easy.
CC'ing some of the relevant contributors for feedback: @lebauce @abhat

Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

I didn't thought about this. Too generic API may be harder to use, but I didn't think deeply on this option.

The API in my last PoC is generic. The columns to read are determined by the tags of object the client passes to the function, e.g:
type DataPathBinding struct {
	UUID        string            `ovn:",uuid"`
	TunnelKey   int               `ovn:"tunnel_key"`
	ExternalIDs map[string]string `ovn:"external_ids"`
}
var datas []DataPathBinding
err = ovndbapi.List(&datas)

This would allow for us to provide a set of pre-defined structures per ovn version, place them in different directories and allow users to use the same version of go-ovn with multiple versions of ovn.
Even more, it would allow developers to define their own structs (e.g: only partial readings, or out-of-tree / unmerged ovn schemas).

@amorenoz Sorry for the slow response. The POC looks promising. I need more time to study the Golang ORM example. Feel free to send a PR to the repo. (In fact I think ebay/libovsdb is where the major part of change should go)

Thanks @hzhou8, once there is consensus on the high level API, I'll send a PR.

My answers to some of your questions:

Should we keep expose a "clean" Add() function that performs the operation instead of returning it?

I think it is important to return a command, so that it can be combined and executed together with other commands as a single transaction.

Should "reading" functions (such as List(), Get()) be the same?

"reading" functions should directly return the results. In addition, for efficiency, we should provide an interface to iterate the local cache instead of duplicate the whole result list by a List() function.

Good idea!

Should we auto-generate the definition of the structs and their tags based on the ovn schema? if so, how schema changes should be handled? should we keep updating the source code or keep compatibility with older schemas?

Yes we should auto-generate. I don't think we need to maitain the compatibility in the Go library. It is OVN's responsibility to keep the DB schema compatibility. We can follow the approach of the C IDL.

Right, but the IDL generation is at compile time, right?

Yes.

So go-ovn should use a specific version of the schema to generate it's code and it's the user's responsibility to use a version of go-ovn compatible with it's ovn DB schema?

Yes. Do you think this is reasonable?

It might be complicated. Layered projects might want to stick with an old version of go-ovn feature-wise while supporting newer ovn schemas. That would put some pressure into go-ovn for being very conservative in the changes it introduces. The alternative would be to clone the entire repository per supported ovn version.
Plus, you have the problem of guaranteeing what version of ovn you work with. Projects that work with a pre-defined version of go-ovn (such as ovn-kubernetes) might be able to cope with it, but others like skydive might not have it that easy.
CC'ing some of the relevant contributors for feedback: @lebauce @abhat

Or, alternatively, is the schema going to be provided dynamically? in which case, the API has to be 100% generic

I didn't thought about this. Too generic API may be harder to use, but I didn't think deeply on this option.

The API in my last PoC is generic. The columns to read are determined by the tags of object the client passes to the function, e.g:
type DataPathBinding struct {
	UUID        string            `ovn:",uuid"`
	TunnelKey   int               `ovn:"tunnel_key"`
	ExternalIDs map[string]string `ovn:"external_ids"`
}
var datas []DataPathBinding
err = ovndbapi.List(&datas)

This would allow for us to provide a set of pre-defined structures per ovn version, place them in different directories and allow users to use the same version of go-ovn with multiple versions of ovn.
Even more, it would allow developers to define their own structs (e.g: only partial readings, or out-of-tree / unmerged ovn schemas).

we can generate structs for all needed ovn versions in different dirs. libovsdb may check ovn version on connect and return needed structs to go-ovn. and go-ovn may return needed data depending on ovn version i think

we can generate structs for all needed ovn versions in different dirs. libovsdb may check ovn version on connect and return needed structs to go-ovn. and go-ovn may return needed data depending on ovn version i think

we can generate structs for all needed ovn versions in different dirs. libovsdb may check ovn version on connect and return needed structs to go-ovn. and go-ovn may return needed data depending on ovn version i think

OK, sounds good. How about the following for the API:
import api github.com/ebay/go-ovn/apis/nb/20.14.0

nbdb := api.newClient(cfg)

# list
var logical_routers []api.LogicalRouter
logical_routers, err = nbdb.LogicalRouter.List()

# get by UUID
var logical_router api.LogicalRouter
logical_router, err = nbdb.LogicalRouter.Get(uuid)

# get by index
var logical_router api.LogicalRouter
logical_router, err = nbdb.LogicalRouter.GetByIndex("name", name)

# add/update
logical_router := api.LogicalRouter {
...
}
cmd, err = nbdb.LogicalRouter.Add(logical_router)
cmd, err = nbdb.LogicalRouter.Update(logical_router)

How does that look to you?
Some questions:

In order to implement a zero-copy iterator, the internal cache should be changed to store interface{} (already decoded according to the ovndb schema). Right?
Technically, the dependency is not with the version of OVN but with the version of the ovn-nb.ovsschema and ovn-sb.ovsschema, which have different versions. So we will have separate sb and nb api paths, objects and SignalCB interfaces. Does it sound reasonable?
As it is a non-written policy from the ovn team not to delete fields in the schema, a specific set of api objects might work with more than one version. We could specify the range of known compatible schema versions per api and, if the installed version is not within the range, print a warning and try (best effort) to decode the data. The client must know that fields might be empty or missing.
A tool could be written to automatically generate the api objects based on a given schema file, that way we will be able to track future changes without too much work

we can generate structs for all needed ovn versions in different dirs. libovsdb may check ovn version on connect and return needed structs to go-ovn. and go-ovn may return needed data depending on ovn version i think

OK, sounds good. How about the following for the API:
import api github.com/ebay/go-ovn/apis/nb/20.14.0

nbdb := api.newClient(cfg)

# list
var logical_routers []api.LogicalRouter
logical_routers, err = nbdb.LogicalRouter.List()

# get by UUID
var logical_router api.LogicalRouter
logical_router, err = nbdb.LogicalRouter.Get(uuid)

# get by index
var logical_router api.LogicalRouter
logical_router, err = nbdb.LogicalRouter.GetByIndex("name", name)

# add/update
logical_router := api.LogicalRouter {
...
}
cmd, err = nbdb.LogicalRouter.Add(logical_router)
cmd, err = nbdb.LogicalRouter.Update(logical_router)

How does that look to you?
Some questions:

In order to implement a zero-copy iterator, the internal cache should be changed to store interface{} (already decoded according to the ovndb schema). Right?
Technically, the dependency is not with the version of OVN but with the version of the ovn-nb.ovsschema and ovn-sb.ovsschema, which have different versions. So we will have separate sb and nb api paths, objects and SignalCB interfaces. Does it sound reasonable?
As it is a non-written policy from the ovn team not to delete fields in the schema, a specific set of api objects might work with more than one version. We could specify the range of known compatible schema versions per api and, if the installed version is not within the range, print a warning and try (best effort) to decode the data. The client must know that fields might be empty or missing.
A tool could be written to automatically generate the api objects based on a given schema file, that way we will be able to track future changes without too much work

Another question:
This API is more generic than the existing one, meaning: we would be replacing the existing "concrete" API that has functions such as LSPGetDHCPv4Options() or LinkSwithToRouter with this one. Right?
If we wanted to still have these concrete functions we would have to, either generate them per schema version (and that's quite a lot of generated code) or have it do some reflex magic. What do you think?

Another question:
This API is more generic than the existing one, meaning: we would be replacing the existing "concrete" API that has functions such as LSPGetDHCPv4Options() or LinkSwithToRouter with this one. Right?
If we wanted to still have these concrete functions we would have to, either generate them per schema version (and that's quite a lot of generated code) or have it do some reflex magic. What do you think?

I have updated my PoC to expose the API @vtolstov suggests:
The API is exposed in a new struct
The client using the API can be seen here
We would need to create a tool that generates the types and API structs per Table in the schema and combine them all into a DatabaseAPI object

I have updated my PoC to expose the API @vtolstov suggests:
The API is exposed in a new struct
The client using the API can be seen here
We would need to create a tool that generates the types and API structs per Table in the schema and combine them all into a DatabaseAPI object

client using the api looks good to me.
@hzhou8 what you think?

client using the api looks good to me.
@hzhou8 what you think?

@hzhou8, @vtolstov Any chance you could give your opinion on the questions above? I'd like to start implementing, but I would need to know there is an agreement on the general approach and API first.
Thanks

@hzhou8, @vtolstov Any chance you could give your opinion on the questions above? I'd like to start implementing, but I would need to know there is an agreement on the general approach and API first.
Thanks

@vtolstov @hzhou8 Any updates? I'm waiting for some feedback from you to proceed.
I opened an issue in libovsdb to start exposing a somewhat native API there (https://github.com/eBay/libovsdb/issues/29) as well as a PR to support schema parsing (https://github.com/eBay/libovsdb/pull/28).
Are we OK with the approach?


Feature/35712 redesign of members list

Details

In this PR the list of members displayed on the Workspace Members Page is re-designed to match the new design.
The new design for reference:

Fixed Issues

$ https://github.com/Expensify/App/issues/35712
PROPOSAL: https://docs.google.com/document/d/1gk3xqOs7epMbUrSSiX8K7YcqfPLVgqEos0sf-D-GMDA/edit#heading=h.qjcht79r25s1
Tests

LogIn to the App
Open any Workspace
Open Members page
Check if the members list looks the same as on the design.

[x] Verify that no errors appear in the JS console

Offline tests

Same as above.
QA Steps

Same as above.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

cc: @Expensify/design

@shawnborton i wonder if we should also use the new Badge design here?

Looking pretty good!
Totally agree that we should use the new badge component. Has that been merged into main yet?
For this area here:

I would think that the "Role" heading would be right-aligned since it's the last column. It also feels like each row has too much padding-right - I would expect the badge to be further over to the right. How much right-padding is currently being applied?

Ah okay, you can ignore me then. cc @trjExpensify @JmillsExpensify @Expensify/design for confirmation.
Can you show me how much right padding is being used though?

@shawnborton Alright, fixed the badge - thanks. It looks like below now:

Lovely! How much vertical padding does each row have? I think we want to be consistent and give these rows 16 vPadding and 16 hPadding. It seems like maybe there isn't quite as much vertical padding from the screenshot you showed.

Lovely! How much vertical padding does each row have? I think we want to be consistent and give these rows 16 vPadding and 16 hPadding. It seems like maybe there isn't quite as much vertical padding from the screenshot you showed.

It has 12px of vertical padding - taken from Figma. I can change it to 16px

BUG: removing a member offline leaves blank component.
https://github.com/Expensify/App/assets/75031127/a4aca654-08a3-4174-9d23-703f1c075ebf

BUG: removing a member offline leaves blank component.
Screen.Recording.2024-02-22.at.4.23.41.PM.mov

@getusha Thanks for pointing this out - I didn't touch the removal functionality yet. I'll be working on it in the next issue so I think I'll address this there (it's not a breaking issue I guess). What do you think?

Ah, got it. Maybe that is intended then, @Expensify/design thoughts on 12px vs 16px for vertical padding? Maybe @burczu can show us a comparison

Ah, got it. Maybe that is intended then, @Expensify/design thoughts on 12px vs 16px for vertical padding? Maybe @burczu can show us a comparison

@shawnborton This is how it looks with 16px vertical padding (very minor distinction for me tbh):

Okay personally I lean towards wanting 16px for both v and h. Let's see if Danny and Jon have any thoughts there too though.

@burczu lets also update the Storybook & we've got a merge conflict.

@shawnborton I'm down to standardize the padding for "tables" everywhere (here, money page, tags, categories, etc.). Your most recent "tightened spacing" for the money page had the padding at 12px—do we want to standardize on 12px or 16px? I'm good either way, I kinda just want them to be the same for all of these types of rows.
Also, this "Role" column label still looks misaligned to me (I realize it is technically properly aligned left, but I think it looks weird). I think we need to center align the column header like we're doing for the "Action" column on the money page designs.

@getusha Thanks for pointing this out - I didn't touch the removal functionality yet. I'll be working on it in the next issue so I think I'll address this there (it's not a breaking issue I guess). What do you think?

Yes, it is minor, can be handled later.

@dannymcclain I think I am team 16px right now, will tag ya in Figma where I'm using that currently.

Thanks for the reviews so far! @burczu would you mind addressing the latest comments and fixing the conflict so we can get this merged today?

@getusha your comments addressed + storybook updated
@shawnborton 16px vertical padding applied
@dannymcclain the Role column label center aligned as requested
@luacmartins conflicts solved and all the comments and requests addressed, I believe

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.4.44-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.44-13 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Ore-Mining

Jira-Issue: GER-14 and GER-34

[x] Implement a resource storage in the player
[x] Mine diamonds.
[ ] Show amount of diamonds mined.

Forgot to mention once again (I swear I'm trying):
9745d5e


Unable To Sideload Via AltStore

Steps to reproduce

Expected behavior
n/a
Actual behavior
n/a
Mangayomi version
n/a
Device
iPhone 15 Pro Max, 17.1.2
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated all installed extensions.

how to fix this?


Fix broken 'run-tests' target

This is followup to (#102) which renamed the executable
files.  It propagated the rename the tools and test
runner.
It also fixes the 'run-tests' target which was passing
the wrong argument name to the run_tests.py script.

Seems broken on Travis: scripts/travis-test.sh: line 56: SEXPR2WASM: unbound variable

Good to go now.  Can you take one more look since I made a few more changed to make the bots happy.

lgtm!


rope: rewrite Extend<> to use .collect()

Closes issue #46

Looks good to me! Once the CI build is complete, this should be good to merge.


WIP: Initial docs for multi-user isolation. unfinished

fixes #379
work in progress
/hold

This change is

/cc @jlewi @sarahmaddox feel free to comment

@abhi-g: GitHub didn't allow me to request PR reviews from the following users: feel, free, to, comment.

LOL a bot with a sense of humour.

/assign

Preview: https://deploy-preview-903--competent-brattain-de2d6d.netlify.com/docs/multi-user-overview/

/hold cancel

Preview https://deploy-preview-903--competent-brattain-de2d6d.netlify.com/docs/other-guides/multi-user-overview/

Thanks @abhi-g this is a very useful doc.
/lgtm
/approve


Transaction search

During the ODN4 hackathon, we've added an API endpoint and the corresponding page to list all the ballot blockchain transactions for a specific vote.
The goal of this page if to provide an easy way for anyone to explorer the content of the "digital ballot box" that is our smart contract.
First, we should add a "search by address" field. By entering (part of) its address (/public key), the user should be able to filter the transaction list to get only the matching one. The existing /vote/transactions/:voteId API endpoint should be updated to support an optional "address" POST parameter and filter the transaction list to return only the one with an address that starts with the specified one.
Then, because typing an address is cumbersome and it is supposed to be embedded in the downloadable SVG vote card, we should provide a way for the user to provide his vote card instead of filling up the address form manually.

[ ] search transaction by address
[ ] search transaction by vote card

ATTENTION! For privacy reasons, the vote card must NOT be sent to the server at any time. We already have existing Web app code to ask the user to provide his vote card without sending anything to the server and this code should be re-used.

@franklinovitch you have some existing stuff for the API endpoint, could you please share in a a feature/transaction-search branch ?

Done in d7638079f9f90595662920fdfbc79f709e324c66


watch command should have a log style output option

Do you want to request a feature or report a bug?
Feature.
What is the current behaviour?
The watch command output is destructive. i.e. it clears the screen. This does not play nice when coming from inside processes managers, for instance, when inside a docker container being ran in a cluster, because it remove output from other commands as well.
If the current behaviour is a bug, please provide the steps to reproduce.
N/A

What is the expected behaviour?
The watch command should have an option (e.g. --log) that prints its output in a cumulative manner (appending at the bottom) instead of clearing the screen. I understand that I'd lose the progress indicator with this change but that would be okay. Simply indicating that the files are being rebuilt and showing a confirmation when it's done and how long it took is just fine.
If this is a feature request, what is motivation or use case for changing the behaviour?
For when running watch inside a process manager like foreman, docker-compose, etc.
Please mention other relevant information.
N/A
I tried my best to explain everything but my English skills are kinda rusty today, so excuse me if something doesn't sound clear or makes no sense.

Thanks for opening this! Was just about to do the same. On my project, I have multiple different pieces going on (Core Wasm module, a lib compiled with rollup, and then the actual debugger), and the debugger (written in react), destroys the other output by the other two watch commands.

Definitely open to a PR for this.


feat: adds ability to list principals of Lambdas allowed to access ECR

what

This change allows listing IDs of the accounts allowed to consume ECR.

why

This is supported by terraform-aws-ecr, but not the component.

references

N/A

@Gowiem thanks a ton for the review! Could I ask you to merge this, please? I don't have write access to the cloudposse repo.


QJS-Patch Error

i tried to fllow the step to install fuzzilli for fuzzing QuickJs.

but i get stucked in there.Could you tell me where's the problem ? thanks a lot

Hi! Seems the patch was slightly broken, it should work now after https://github.com/googleprojectzero/fuzzilli/commit/70be6aafaf827bf4bb4e0497749205ea66a34d27
Note that the specified QuickJS revision is fairly old (mid 2020), so you might want to rebase the patch to a newer version. If you do so, please feel free to send a PR.


Blockcomments are not highlighted

Blockcomments are not highlighted like:
/*
That syntax highlighting is pretty nice. Good work.
*/

They do not get a color expected for comments.
While line comments (between !! and \n) work like expected.
Screenshot:

Tested with v0.1.3

Included in v0.1.4


Setup strict phinx mode, fixed all phinx warnings

Description
This patch fixes the warnings generated by sphinx python docstring tool when run in strict mode. It fixes the automatically generated documentation in a couple of places, removing obsolete anchors to samples and fixing links and dedent for linked samples for sync and sync version of communication client.
It also introduces the default sphinx = true option as requested in the original issue.
closes #33567
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

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

Trying to identify a reason for failing a single unit test on ubuntu where it throws in timer which doesn't seem related with my changes at all.

/reopen
The issue is not fixed yet

This issue was resolved by https://github.com/Azure/azure-sdk-for-python/pull/36111


Responsiveness in Dashboard site homepage

Issue
The landing page of the dashboard site is not responsive.
Description
It brakes for the mobile view. at around 547 X 620 (less than that the page has responsiveness flaws)

Hi, I would like to work on this issue.

Width 574x620 and less than that.
@RitikJaiswal75 is this fine or should there needs to be made some more corrections?


Investigate replacing HUBO template with vector of InstructionParameters

From @amccaskey on October 9, 2017 19:35
This will make us polymorphic in HUBO's, then we can make a general D-Wave application.
Copied from original issue: ORNL-QCI/xacc#63

This would make HUBO an IRGenerator


[CLOSED] Blacklist and whitelist seems to be broken

 Issue by Aniketh01
Friday Apr 10, 2020 at 14:23 GMT
Originally opened as https://github.com/Aniketh01/NaWaB/issues/5

The blacklist feature included (atleast the logic on how it works) seems to be not perfect and is buggy.

 Comment by iammarco11
Friday May 15, 2020 at 16:49 GMT

@Aniketh01 is this the same issue as relevant tweets being scraped?


[message] create new messages with priority

Free low priority messages when there is no enough memory for the high priority message.

@jwhui @abtink  Could you gave me some comments about this PR?


Improved support for gtid_mode

orchestrator to be more aware of Oracle MySQL gtid_mode:

recognize the different values (off, off_permissive, on_permissive, on) as opposed to "supprted"/"unsupported"
structure warning on different GTID mode values for a topology

Works well. I'll merge this and will continue iterations on improved GTID support in future PRs.


[Backport to 1.x] Update dependency opensearch-ml-client group name

Signed-off-by: jackieyanghan<EMAIL_ADDRESS>Description
Update dependency ml-client group name based on this change - https://github.com/opensearch-project/ml-commons/commit/e89540516a3f92e0e016f079f63e6bd3452eb08f
Issues Resolved
[List any issues this PR will resolve]
Check List

[x] New functionality includes testing.

[x] All tests pass, including unit test, integration test and doctest

[x] New functionality has been documented.

[x] New functionality has javadoc added
[x] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #480 (385d2f5) into 1.x (eb1ede4) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##                1.x     #480   +/-   ##
=========================================
  Coverage     95.25%   95.25%
  Complexity     2746     2746
=========================================
  Files           276      276
  Lines          7414     7414
  Branches        538      538
=========================================
  Hits           7062     7062
  Misses          298      298
  Partials         54       54

Flag
Coverage Δ

query-workbench
62.91% <ø> (ø)

sql-engine
98.40% <ø> (ø)

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

Continue to review full report at Codecov.

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


Make progress bar total instead of time left and total.

Hey! Cool program! This solved a problem that I was having with regular progressbars in tkinter. I am curious if you could make the "Time Left" option a keyword argument to turn it off so that the text could just be a percent?

Thanks for the issue. Created a new attribute display_time_left. It's default to True but you can set it to False, so that the time remaining can be turned off. To use the new feature, please update the package (>=0.1.2) by running pip install progresspanel --upgrade and set display_time_left=False when creating an instance.


CDN GA prep: changing List to Set as return/input param type

The goal is to eliminate the unintentionally implied compat promises about ordering and non-uniqueness of strings within collections, where neither the ordering nor duplication of those strings is meaningful. This should help prevent users from relying on some coincidental ordering in which strings might be returned by Azure, while also implying that only unique strings are meaningful.  This should deter user code whose back compat could be broken in the future.
Also making the affected APIs "GA" by removing @Beta.
Compat breaks in Beta functionality (no breaks in GA'd API) from 1.0.0:
The following now return and/or accept Set<String> instead of List<String>:

CdnEndpoint

.contentTypesToCompress() / .withContentTypesToCompress()
.customDomains()
.purgeContent() / .purgeContentAsync()
.loadContent() / .loadContentAsync()

CdnProfile

.purgeEndpointContent() / .purgeEndpointContentAsync()
.loadEndpointContent() / .loadEndpointContentAsync()

Can one of the admins verify this patch?

@hovsepm if you're able to take a quick look that'd be great, thanks

need to move forward with this one, we can take a look later if needed


[SMALLFIX] Fix "Allocation after freeing space" log message

dirView has no toString implementation. So it is certainly not what you want.

+ say '\033[0;31m-->\033[0m No coverage report found.'
+ echo -e '\033[0;31m-->\033[0m No coverage report found.'
--> No coverage report found.
+ say '    Please visit \033[0;36mhttp://docs.codecov.io/docs/supported-languages\033[0m'
+ echo -e '    Please visit \033[0;36mhttp://docs.codecov.io/docs/supported-languages\033[0m'
+ exit 1
    Please visit http://docs.codecov.io/docs/supported-languages
Error: Codecov failed with the following error: The process '/bin/bash' failed with exit code 1

generate code coverage flaked. Code Coverage generation has been flaky. Upload code coverage failed because generating it failed.

done.

Codecov Report

Merging #12801 (23cb25a) into master (2fb220b) will decrease coverage by 33.87%.
The diff coverage is 0.00%.

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

alluxio-bot, merge this please.


"Error occurred while loading images" for no apparent reason

"Error occurred while loading images" for no apparent reason
Fixes #2410
What changes did you make and why?
Checked in handler error.
Tests performed (required)
Tested on {Asus Zenfone Max M1 pro} with API level {27}.

Codecov Report

Merging #2413 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #2413      +/-   ##
=========================================
- Coverage    6.03%   6.03%   -0.01%
=========================================
  Files         242     242
  Lines       11872   11873       +1
  Branches     1072    1073       +1
=========================================
  Hits          716     716
- Misses      11100   11101       +1
  Partials       56      56

Impacted Files
Coverage Δ

...rw/commons/explore/images/SearchImageFragment.java
0% <0%> (ø)
:arrow_up:

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 bd9e629...785f283. Read the comment docs.


github: add citation

Add a citation so people can easily cite our software and use a
unified format.
See the documentation for details

This is cool. Will we need to continuously update that version number? We should think about adding to other repos as well.

This is cool. Will we need to continuously update that version number? We should think about adding to other repos as well.

I'll write a bot as soon as I find the time. And yes, I'll open PRs at the other repos, too. :)

@stevenhorsman Added a line to release process documentation.


Knowledge - Able to chat with deleted knowledge files in existing threads.

Electron build - d27f9f
Steps to reproduce the problem:

Create an assistant
Add multiple (at least 2) knowledge file say file1 and file2 using "Add Local Files"
Chat with the assistant about one of  knowledge file say file1.
Edit the assistant and remove file1.
Start a new chat with the assistant about the delete knowledge file -file1. This will not be able to fetch any information as expected
Continue to chat in existing thread (from step3) about delete knowledge file .

User will continue to get information about the deleted knowledge file.
Expected Behavior:
User should not get any information about the deleted knowledge file even in existing threads.

Is the information coming from queries to the knowlege api or from the context that had been built up? If it's from the context that's been built-up, then thats expected

When I tested the same scenario again, I was not getting the information from the deleted knowledge files when tool call was made to knowledgeRetrieval tool.
When I see the behavior mentioned in the issue , it was from the Knowledge Retrieval Context


Waydroid does not start due to binder not being present

Describe the bug
When trying to execute waydroid init I get
> # waydroid init
[21:00:45] Failed to load binder driver
[21:00:45] modprobe: FATAL: Module binder_linux not found in directory /run/current-system/kernel-modules/lib/modules/5.10.81
[21:00:45] ERROR: Binder node "binder" for waydroid not found
[21:00:45] See also: <https://github.com/waydroid>
Run 'waydroid log' for details.

waydroid log yields:
(004488) [21:00:45] % modprobe binder_linux devices="anbox-binder,anbox-vndbinder,anbox-hwbinder"
modprobe: FATAL: Module binder_linux not found in directory /run/current-system/kernel-modules/lib/modules/5.10.81
(004488) [21:00:45] Failed to load binder driver
(004488) [21:00:45] modprobe: FATAL: Module binder_linux not found in directory /run/current-system/kernel-modules/lib/modules/5.10.81
(004488) [21:00:45] ERROR: Binder node "binder" for waydroid not found
(004488) [21:00:45] See also: <https://github.com/waydroid>
(004488) [21:00:45] Traceback (most recent call last):
  File "/nix/store/wzc8a0y2kznbgvr69kciymypa89iiim3-waydroid-1.2.0/lib/python3.9/site-packages/tools/__init__.py", line 54, in main
    actions.init(args)
  File "/nix/store/wzc8a0y2kznbgvr69kciymypa89iiim3-waydroid-1.2.0/lib/python3.9/site-packages/tools/actions/initializer.py", line 85, in init
    setup_config(args)
  File "/nix/store/wzc8a0y2kznbgvr69kciymypa89iiim3-waydroid-1.2.0/lib/python3.9/site-packages/tools/actions/initializer.py", line 77, in setup_config
    helpers.drivers.setupBinderNodes(args)
  File "/nix/store/wzc8a0y2kznbgvr69kciymypa89iiim3-waydroid-1.2.0/lib/python3.9/site-packages/tools/helpers/drivers.py", line 137, in setupBinderNodes
    raise OSError('Binder node "binder" for waydroid not found')
OSError: Binder node "binder" for waydroid not found

Steps To Reproduce
Steps to reproduce the behavior:

Install waydroid ( I added it in my configuration.nix)
Run waydroid init

Expected behavior
I would expect waydroid to initialise its environment
Notify maintainers

@FlorianFranzen
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.81, NixOS, 21.11 (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(madonius): `"home-manager-21.11, nixos-21.11.334139.1bd4bbd49be, nixpkgs-21.11.334139.1bd4bbd49be, nixpkgs-unstable-22.05pre337603.47f45c8440e, sops-nix"`
 - channels(root): `"nixos-20.09.4125.7974217f94c, sops-nix, unstable-21.05pre281538.9e377a6ce42"`
 - nixpkgs: `/home/madonius/.nix-defexpr/channels/nixpkgs`

Fixed by https://github.com/NixOS/nixpkgs/pull/148442
Status can be tracked at https://nixpk.gs/pr-tracker.html?pr=148442


Solr search core initialization is fragile

Describe the bug
If discovery.search.server is incorrect, org.dspace.discovery.SolrSearchCore#initSolr just logs an error but leaves the class uninitialized, causing obscure errors later.  At time of writing, it causes the server Context to fail to start.  This is because the SolrClient reference held by the class is still null.
To Reproduce
Steps to reproduce the behavior:

Set discovery.search.server to a valid URL that won't connect to Solr.
Try to start webapps/server.

Expected behavior
There's no good way to recover, but perhaps initSolr could throw a more informative exception instead of silently failing.

@mwoodiupui : I agree that maybe we just need a better exception here... perhaps simply logging that discovery.search.server seems to be invalid? (or something similar).
I'll pull this over to the 7.4 board, as it seems like a small, quick fix is all we may need.


Karpenter support for prioritizing AWS Capacity Reservations

Tell us about your request
As a EKS platform engineer, I would like to reduce my platform cost and increase resiliency to capacity outages by provisioning AWS EC2 instances through the EC2 Fleet API by prioritizing Capacity Reservations. Capacity reservations are a mechanism for us to reserve capacity of particular instance types in particular AZs. This is done to reduce cost and increase resiliency to issues in acquiring capacity at large scale.
I would like to be able to specify in the, e.g. AWSTemplate.spec.on-demand-options.CapacityReservations and specify use-capacity-reservations-first in order to make sure the instances that launch are placed in targeted capacity reservations in that account. Without this support, we could end up paying for reserved capacity and On-Demand instances through EC2 Fleet.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
The problem is this workload is critical, and has a set SLA that we need to meet. Capacity reservations help us achieve tremendous vCPU counts without worrying about capacity, and currently we cannot use Karpenter's scalability and advantages at all.
Reserved instances and open capacity reservations help, but this puts the responsibility of the EKS platform engineer to always have to monitor and provide the AZs and empty reservation slots to the provisioner, which makes the application team less autonomous and adds complexity in managing the reservations. In addition, with targeted reservations opening the door for specific components of an application to take advantage of different reservation amounts in a single account, there is no current way in the provisioner to specify the reservation ID either.
Are you currently working around this issue?
There is no workaround; we don't have a mechanism to use Karpenter because it does not support specifying Capacity Reservations. Cluster Autoscaler also does not do this, so we have no way of guarranteeing the use of CRs with EKS currently on AWS unless we own the Ec2 fleet calls.
Additional Context
No response
Attachments
No response
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

We have something very similar explained here: https://karpenter.sh/preview/concepts/scheduling/#savings-plans-and-reserved-instances

Ryan,
While I appreciate this reserved instance approach, this won’t work with “targeted” capacity reservations because those need to be “pointed to” by the EC2 Fleet API. The current approach you mentioned also won’t factor in availability of capacity reservations by AZ even if the reservation is of type “open”.
If I reserve 20 instances of c4.large each in 5 AZs, with a total of 100, those 100 instances can be launched by Karpenter in any AZ without regard for placing them evenly across each AZ. Similarly, if I had 10 reservations available across 4 AZs, there’s no mechanism for Karpenter to place them in those AZs accordingly.
Let me know if I'm missing something.
Thanks,
David

if I had 10 reservations available across 4 AZs, there’s no mechanism for Karpenter to place them in those AZs accordingly.

your provisioner can specify which AZs to deploy to. Worst case, you could have a provisioner per AZ

I understand that, but how do I know I have 10 reservations across 4 AZs? There's no way the provisioner would know those exist, you as the infrastructure engineer would have to know how many are in each AZ, and the number could fluctuate due to other workloads or components taking up those reserved slots. Why not let EC2 Fleet figure it out, instead of putting onus on the infrastructure engineers?
And this still does not address targeted Capacity Reservations. If you have multiple workloads or components of a workload in the same account and have different reservations for each via reservation IDs, you are SOL.

I also need the ability to reference targeted on demand capacity requests.  We use ODCRs for instance types that are capacity constrained where we need a guarantee of being able to launch those instances.

I think it make sense to support capacity reservation but I am not sure it make sense to go down a priority within the same Node Pool. I think Karpenter has a solve for this already with weights. So you would have your ODCR NodePool at a higher weight and if that fails you would fall into the next node pool (maybe spot) and so on. Putting this priority logic within a single node pool seems problematic.

Fwiw, we maintain many launch templates under the hood per node pool. It's required for things like labels and architectures.
That said, we model "preferential fallback" using the weight feature, so I don't think it's crazy to reuse that here. However, LT combinatorics don't seem like they'll be a design constraint on this question.

Fwiw, we maintain many launch templates under the hood per node pool. It's required for things like labels and architectures.

Ya I realize I don't actually know that code that well I was suspecting I was wrong after writing this. But I think I agree that it's likely better to push that logic to weights instead. I am trying to write up a brief design on implementing adding capacity reservation to EC2NodeClasses so I wanted to make sure that we want to keep LT combos clean/ minimal for the sake for just launching the right node and not for prioriziation


[ACR] Add OCI manifest and blob upload/download samples

Resolves https://github.com/Azure/azure-sdk-for-python/issues/27428

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


Using get_last_request_id

I am bit confused as how to get this Id.
I tried getting the value in demo-flash-index.py. I am see a None value
Each time I tried getting with sso and logout a new request 'auth' object is created.  Perhaps that is why the ID value is None ?
Also looking at your implementation the ID value is stored in  auth.login() call.
But auth.login() we never return to in the client
So how the client should get the ID ?
Thanks
Asif

The login method returns the IdP SSO URL + SAMLRequest (+ RelayState)
If you check the flask demo, in the SP-initiaited SSO section instead
return redirect(auth.login())

you can execute:
target = auth.login()
request_id = auth.get_last_request_id()
# do whatever you want with the id (store in session, store in database)
return redirect(target)

thanks it worked.
I see we have 'is_valid()' for the Auth Response class which the takes the ID to validate. But is it possible to also get this ID out from Authentication Response ?
What I am trying to solve:
I want to send a number(identifier) in the request and get it back from IDP in the response message. I am using this number for downstream processing after user is authenticated.

https://github.com/onelogin/python-saml/commit/e70d0cd8f3c772ebd0b4606fd7ce02b5d3cce97d


Fix False Colors not being applied to all tiles

This PR addresses the same issue as https://github.com/appleseedhq/appleseed/pull/2880, namely, False Colors aren't correctly applied to all tiles in a final render when the frame has some post-processing stage.
For a further explanation of the problem, see: https://discord.com/channels/430063582777049089/707230180233707591/729948630668148766

92df33e is an alternative solution to the bug "False Colors not being applied to all tiles".
The problem is the following:

We emit a signal for the end of the render before applying post-process.
The signal is emitted using renderer_controller.on_rendering_success() in MasterRenderer::do_render().
Because of that, appleseed.studio apply False Colors before post-process.
False Colors gets applied on a copy of the frame, to keep the original render.
So if there is a post-process + False Colors, False Colors get replaced by the post-process.

One solution is to call on_rendering_success after applying post-process, which order-correctly the effects:

Post-process is applied first
Then False Colors is applied on the post-processed frame
It works !

The problem with that solution, is that we don't call on_rendering_success and on_rendering_abort from do_render anymore, but on_rendering_begin() still is. Triggering the signals from different places in the code make it less easy to maintain and understand.
I think we should keep the structure in do_render() to make sure interactive rendering + final rendering always work the same way.
Another solution, the one in this commit, is to apply the post-process right after render. Then, no matter when you emit the signal, the frame will always be ready and will never get modified after the signal is being emitted.
@laurelkeys What do you think about this approach ? If you agree, can you try to break it while testing it ?

@laurelkeys What do you think about this approach ? If you agree, can you try to break it while testing it ?
LGTM! Just tested it and it's working as expected 🙂


[💄] Added window resizing

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


The Twig extension should not depend on the Templating helper

This dependency means it forces a dependency on the Templating component. but Symfony 2.8+ makes it possible to use Symfony without the Templating component (using the Twig_Environment directly).

@stof Thanks for pointing it. I will fix it this week in a BC way.

@stof I would like to unregister the twig/php renderer in a compiler pass according to the user conf. Relying on the container parameter templating.engines is the way to go?

no. If you disabled the templating component entirely, this won't exist, while TwigBundle might still be there.
For the PHP engine, you can rely on it, but for the Twig extension, you should detect the availability of the twig service

Thanks for the clarification!