Make workflow "id", "key" parameters not required

What would you like to be added:
Make id , key params not required
Why is this needed:
if one is not provided, runtime can generate unique

I will take a look at this as well. This seems similar to #464

nice. yeah update the schema and the required field in table and then we can figure out the text in spec doc that needs updates. thanks

IMHO, turning all those properties into optionals might bring in some quality of life issues for users. As a matter of fact, if a user deploys a workflow and overlooks the returned ID or key, he's left with no ubiquitous way to find that workflow amongst potentially hundreds of definitions. I believe those properties should be mutually exclusive, leaving the user with a choice concerning identification. Plus, versioning, which's in my opinion absolutely critical, is left with no purpose in case of lack of explicit identification (or auto-generated one): if I upload one revision of a workflow, with auto-id and auto-version, then publish another revision of it, runtimes will have 2 choices: considering them both as separate, unique workflows (making version useless) or having some kind of parsing mechanism (shaky at best) to determine that they are 2 revisions of a single definition.

@cdavernas are we concerned finding workflow definitions or workflow instances?
As far as definitions goes, those are user-defined.
User would need some id which is almost always runtime-specific. This they should get from the runtime, on deployment/execution time.
Typically the id alone is not enough to identify a workflow instance/execution. You also need some instance id which in combination to the workflow identification is unique. In distributed systems sometimes you need even a third param like a "namespace" on where the workflow instance is actually running (as can run on multiple at times).
WDYT?

@cdavernas side-tracking this discussion, we should probably add a "namespace" param to our dsl.
Currently no matter the runtime, the DSL cannot specify that one workflow state should run on a different pod for example than another. It's assumed that either they all run on the same pod or its up to the magic of the runtime to figure that out.
There are however many use cases where you want certain work to be performed on specific pods. For example consider file uploading. Once a file for a specific customer has been uploaded to pod A, then all subsequent file uploads for that customer should be also done on the same pod. How can we define that currently in DSL? I don't think there is a way.

Currently no matter the runtime, the DSL cannot specify that one workflow state should run on a different pod for example than another. It's assumed that either they all run on the same pod or its up to the magic of the runtime to figure that out.

@tsurdilo, I think we shouldn't have this defined in the DSL. Again, it's a matter of infrastructure, which implementations should manage by themselves.
Kubernetes, for example, has the ability to control objects by labels and annotations. Implementations should expose such information relying on the platform it's running. If the SW would have a Kubernetes CRD representation, one can leverage these attributes from the platform. No need to duplicate here. We should stick with the domain model only, IMO.

@ricardozanini
I think thats fair, but it is from the point of view of a "closed system", meaning user does not control the deployment infra.
In those types of systems requirements like defining that workflow states A, B, C should all run in the same location and D, E on another (these are real business requirements btw) cannot even be considered and many people fall to not using workflows for those situations at all.
The main use case for this is file uploading/downloading. We cannot assure currently that user requirement of all associated file uploads/downloads happen on the same "instance".
Another use cases that is very important is for users to be able to have multiple clusters/pods/infras, each provisioned differently. They want then a workflow state that processes 1TB of data to run on cluster A which is provisioned for high IO operations, and rest of states on some other cluster.
I used the term "pod" in last message but this is not specific for kubernetes at all. It could as well be cluster or substitute any other word that is tied to a virtual machine.

@tsurdilo

@cdavernas are we concerned finding workflow definitions or workflow instances?
Well, in my use cases, I am indeed concerned with finding workflow definitions and their associated instances. This is for tracking, tracing, management, log aggregation and metrics.

Furthermore, as I said in my comment, I think it's important we think about the versioning aspect. If the id is auto-generated by the runtime, there is no need for versioning, as any definition added in the future will be considered a new one, instead of a revision, if the user has not manually retrieved it (how so, if it's just UUIDs? Creation timestamp? Doesn't feel nice to me) and input it in its revision? The way I'm using my runtime implementation allows me - because any kind of user-inputed identifier is required for now, should it be key, name, id - is to auto-increase the version of a definition that has the same name than an existing one, thus making sure the user does not inadvertently override an old, still running version of it, and all the data associated to it. With that system, this is gone. As are fancy dashboard (of the like of Camunda-Operate) allowing the user to track, manage, manually compensate, etc., workflows in a human-readable fashion (as opposed to just facing UUIDs).

As far as definitions goes, those are user-defined.
So far, they are required to be set by users. The change you suggest, however, is to make it optional, which WILL result in users inadvertently creating workflows without setting any expected identifier and facing the difficulty of finding it easily afterwards, even if only to delete. IMHO, we should enforce AT LEAST ONE user-defined property for identification purpose. IMHO, the name property was perfect to achieve that. I'm still fly with key or id though. As long as at least one is required. Even for things such as Custom Resource Definitions, K8s enforces setting at least the name (as well as a couple other properties). And that is for quality of use purpose only.

WDYT?

@tsurdilo Regarding your idea on pod-related config and such, though I find it interesting, I tend to agree with @ricardozanini, as often.
In my personal opinion, deployment related information is out of Serverless Workflow scope, as it is a runtime/infrastructure concern. It's purely related to the control plane, which lies way beyond the boundaries of the spec as I see it.
At best, we could cook up some kind of orchestration-related extension and its related documentation, and runtimes have the choice to support it or not (which Synapse will, if that's the case).
WDYT?

@tsurdilo I think the research/study @cdavernas and I are doing about representing the SW on "containers orchestration platforms" would answer many of these questions you brought in your previous comment.
They are super valid, and I think we need to bring them to the table. Perhaps opening a new doc about how the spec is supposed to be represented in such environments. Not written in stone, more like suggestions for implementations. Things we are learning with our own implementations and integration with serverless platforms.

@manick02 seems after these discussions we want to hold off on this issue for now, sorry.
We can work on the other open good first issues if you are up for it :) . Will try to open some more this week as well.
@cdavernas @ricardozanini the dsl does not have to contain some deployment related information as we always abstract that. The point I was trying to make  is that we cannot currently describe some user business requirements and was trying to bring that up for discussions.

@tsurdilo thanks, I will pick up other two :)


typeof s === "symbol" yields error 'unexpected predicate "symbol"'

And it can't be suppressed either.
It totally breaks things, not just a normal error.

Issue is here. This code isn't actually unreachable, because the string inside the IsP/NotP can be provided by the user in a typeof check. We should output a normal flow error instead of asserting.

But it shouldn't error. An es6 symbol has typeof "symbol"
On Mon, Aug 10, 2015 at 4:55 PM Sam Goldman<EMAIL_ADDRESS>wrote:

Issue is here
https://github.com/facebook/flow/blob/790d186350e90262731844c6399bfd9d9f2932ae/src/typing/flow_js.ml#L4209.
This code isn't actually unreachable, because the string inside the IsP/
NotP can be provided by the user in a typeof check. We should output a
normal flow error instead of asserting.
—
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/712#issuecomment-129649771.

You're right. There are two issues here: 1) we assume code is unreachable when it isn't and 2) we should properly refine symbols.

I fixed the exception in d45c099 and filed #1015 to make typeof x === "symbol" actually work. until then, you should be able to suppress the error now.
thanks, this was a bad one.


After autoclosing flyout in vertical grammar, flyout area still is detected as delete area

Expected Behavior
After flyout autocloses, the area under the flyout should be a workspace area, not a delete area. That is, dragging a block onto the area where the flyout used to be should not result in the block being deleted. The horizontal workspace scrollbar should stretch to the left all the way to the categories, at least when the flyout is closed.
Actual Behavior
After autoclosing the flyout, flyout area still is detected as delete area. In addition, before and after the flyout autocloses, the workspace horizontal scrollbar does not stretch to the left into the flyout area.
Steps to Reproduce

Set Blockly.VerticalFlyout.prototype.autoClose set to true in flyout_vertical.js
Open tests/vertical_playground.html
Drag a block out from the flyout
Drag the block from the workspace on to the area where the flyout used to be

Operating System and Browser
Mac OS 10.11.6 Chrome 59

@ericrosenbaum Does the new flyout still support auto-closing?  I saw that you set it to false by default.

Hi @rachel-fenichel , we also have found this issue when using the latest version of Scratch 3.0, any updates on fixing it?

It depends on whether we're supporting auto-closing flyouts in scratch blocks.  @ericrosenbaum do you know?

We use them for vertical grammar on the Cozmo project. I think there are a few bugs in scratch-blocks with the auto-closing flyout that I have worked around.

@rachel-fenichel we've now talked this over and decided to support auto-closing flyouts.
@msintov it would help us out if you're able to describe your bug workarounds, or even better submit a PR. Thanks!

Here are the changes I have made to support an autoclosing flyout (let me know if something seems to be missing):

In flyout_vertical.js, set autoClose to true:

Blockly.VerticalFlyout.prototype.autoClose = true;

Note that width of the scratchCategoryMenu in css.js is important in the calculations below (by default this is 52px).

In toolbox.js, I expose a way to set the width:

Blockly.Toolbox.prototype.setWidth = function(width) {
  this.width = width;
};

Note that the desired flyout width is stored in Blockly.VerticalFlyout.prototype.DEFAULT_WIDTH.

In Blockly.Toolbox.prototype.init, I calculate Blockly.Toolbox.prototype.width to be the sum of our desired flyout width and the toolbox (52px).

At the end of Blockly.hideChaff(), I hide the flyout and also update the delete areas:

        workspace.toolbox_.flyout_.hide();
        workspace.recordDeleteAreas();

In flyout_base.js, in Blockly.Flyout.prototype.setVisible, if flyout is set to visible, I set the width of parentToolbox_ to include both the toolbox and flyout width:

    this.parentToolbox_.setWidth(toolboxWidth + this.getWidth());

In Blockly.WorkspaceSvg.prototype.recordDeleteAreas , I only take flyout size into account when flyout is visible:

  if (this.getFlyout() && this.getFlyout().isVisible()) {
    this.deleteAreaToolbox_ = this.getFlyout().getClientRect();
  }

The biggest hack: in Blockly.WorkspaceSvg.getTopLevelWorkspaceMetrics_, I had to force the toolbox width recognized here to be only the width without the flyout. This enables the user to drag their program closer to the toolbox. Unfortunately I was not able to find a better place to put this fix that didn't cause other badness like scripts jumping on workspace pan after project load or a newly dragged out block jumping. Probably there is a redraw call that needs to be made after the workspace is loaded instead of hacking it in like this.

    toolboxDimensions.width = 52;


stack overflow caused by nixpkgs/.git/ directory

Issue description
My nixpkgs is in the ~/nixpkgs/ local git directory. When I execute "nixos-rebuild build", I get a

"error: stack overflow (possible infinite recursion)"

If I delete the ~/nixpkgs/.git/ directory (i.e., only the .git/ internal subdirectory), "nixos-rebuild build" works fine. I worked around the problem by cloning again from github.
Technical details

System: channels/nixos-unstable

I can do this with .git:
~/Documents/nixpkgs $ git checkout 453086a
~/Documents/nixpkgs $ sudo nixos-rebuild dry-build -I nixpkgs=$HOME/Documents/nixpkgs
building the system configuration...
these derivations will be built:
  /nix/store/75aq7svzrrwv2y0by0xw9dmkzlz41jvv-manual-olinkdb.drv

Maybe it is something in your config?

Thanks for answering. I don't see the relationship between your answer and my question though. My question is related to the nixpkgs/.git subdirectory (the git internal directory), not nixpkgs/ itself. Additionally, I said that cloning again from github was a workaround.

My answer was that I am able to build with the .git directory in the clone I have. I could have written "I can do this with the .git directory in my clone".
Are you able to reproduce the behavior from a fresh clone?

Are you able to reproduce the behavior from a fresh clone?

a fresh clone doesn't show the problem. This is indeed the workaround I found. Still,

why is nixos-rebuild impacted by the .git internal subdirectory?
how can I debug what's wrong in my .git directory?

I have encountered this issue, too. It comes and goes away as it pleases, seemingly related to various Git states. For example, I fixed it once with commiting staged changes.
...and no idea what happens!

The culprit seems to be commitIdFromGitRepo -- if I fill this binding with garbage the problem goes away!

cc @obadz as the function's author.

@DamienCassou: could you show the output of the following commands?
$ cat .git/HEAD
ref: refs/heads/obadz

$ grep "$(cat .git/HEAD | cut -f 2- -d \  )" .git/packed-refs
4774831f80f877d70dc18c63762341a7d93ce15d refs/heads/obadz

@obadz sorry, I changed laptops in between and didn't backup the faulty .git/ directory. Maybe @abbradar can help.

@obadz sadly I don't have a faulty directory backup, too. However I've reverted my local workaround, so when the bug presents itself again I'll do the job.

I hit this just now.
@obadz: My output:
$ cat .git/HEAD
ref: refs/heads/tmp-unstable     # this is just a temp branch as a snapshot on master, points at 6f893694401fa3048eed94c865ed3f0038deac44

$ grep "$(cat .git/HEAD | cut -f 2- -d \  )" .git/packed-refs
6f893694401fa3048eed94c865ed3f0038deac44 refs/heads/tmp-unstable

Let me know if there is some more I can dig out from my git clone. I have preserved copy of it.

I tried switching branches, pulling doing git gc. Nothing seems to "unbreak" the state of the git clone.

@bjornfor,
Would really appreciate if you kept a copy of this the git repo in that state until we've sorted that out :-)
Could you post the error with --show-trace ?

Also do you have the file .git/refs/heads/tmp-unstable and if so what is its contents?

@obadz:

Would really appreciate if you kept a copy of this the git repo in that state until we've sorted that out :-)

Yes, I have a copy :-)

Could you post the error with --show-trace ?

$ nixos-rebuild -I nixpkgs=. build --show-trace
building Nix...
building the system configuration...
trace: warning: The option `nix.useChroot' defined in `/etc/nixos/modules/base-small.nix' has been renamed to `nix.useSandbox'.
error: stack overflow (possible infinite recursion)

Is that line the very last line of packed-refs by any chance? Is there a trailing \n ?

Nope, it's somewhere in the middle:
$ grep -C2 tmp-unstable .git/packed-refs
b9fa0cf83c3aaa8a2d251412c80e8dba66f2f563 refs/heads/release-16.03
92099db6f7471e32b4054dc19cf215d5f77072f1 refs/heads/release16.03
6f893694401fa3048eed94c865ed3f0038deac44 refs/heads/tmp-unstable
8e06768779c868f64d92e641320a326c11d09a30 refs/remotes/bjornfor/add-opencv-examples
ef9db6a50a823ecf988358a3c57d5a990b4c5b86 refs/remotes/bjornfor/avr-stuff

Yes, .git/packed-refs ends with a newline / linefeed / \n / 0x0a:
$ tail -3 .git/packed-refs
197f6c6c4ce0c284afa437130f096d4ab7f755f1 refs/tags/last-glibc-2.13
b62961af30e235654c6972aa89f57fbbb32d91da refs/tags/release-16.03-start
^1f89aa6c7f2f16c8c0834cfa65b8484fecd72af3

$ tail -3 .git/packed-refs | hexdump -C
[...snipped...]
00000070  2f 74 61 67 73 2f 72 65  6c 65 61 73 65 2d 31 36  |/tags/release-16|
00000080  2e 30 33 2d 73 74 61 72  74 0a 5e 31 66 38 39 61  |.03-start.^1f89a|
00000090  61 36 63 37 66 32 66 31  36 63 38 63 30 38 33 34  |a6c7f2f16c8c0834|
000000a0  63 66 61 36 35 62 38 34  38 34 66 65 63 64 37 32  |cfa65b8484fecd72|
000000b0  61 66 33 0a                                       |af3.|
000000b4

Also do you have the file .git/refs/heads/tmp-unstable and if so what is its contents?

$ cat .git/refs/heads/tmp-unstable
cat: .git/refs/heads/tmp-unstable: No such file or directory

I know you didn't ask for this, but just in case it's useful:
$ find .git/ -name "tmp-unstable"
.git/logs/refs/heads/tmp-unstable

$ cat .git/logs/refs/heads/tmp-unstable
0000000000000000000000000000000000000000 6f893694401fa3048eed94c865ed3f0038deac44 Bjørn Forsman<EMAIL_ADDRESS>1468936904 +0200	branch: Created from 6f89369
6f893694401fa3048eed94c865ed3f0038deac44 6f893694401fa3048eed94c865ed3f0038deac44 Bjørn Forsman<EMAIL_ADDRESS>1468961987 +0200	Branch: renamed refs/heads/tmp to refs/heads/tmp-unstable

Ok, so far everything look fine. Could you get me tarball of the .git subfolder so that I can poke further? Maybe put it up on a drive and/or ping me on IRC and we will find a way?

@obadz: Here: http://bforsman.name/~bfo/nixpkgs2.nixos-rebuild-infinite-recursion.tar.gz (380 MiB)

I've narrowed down the problem: your packed-ref file is just very big (900KB whereas mine is more like 13KB) so the stringSplit operations craps out:
$ nix-instantiate --eval --expr 'with import <nixpkgs> {}; with builtins; with lib; splitString "\n" (readFile ./packed-refs)'
error: stack overflow (possible infinite recursion)

To be fair there's a warning in the comment above splitString:
  /* Cut a string with a separator and produces a list of strings which
     were separated by this separator.

     NOTE: this function is not performant and should never be used.

Thank you very much

No problem. I'm glad we were able to resolve this!

Yay! Thank you @obadz!


disable goerr113

No integration is defining errors, and this linter make the pr fail.
Refactoring all errors of integrations is quite time consuming and just defining new ones is not consistent with the existing code.

Closing since we decided to manage this case-by-case, disabling this check for very old integrations.


Fix #27: allow  to quit highlight mode. Document in README.md

If you use https://github.com/Shougo/neobundle.vim, you can test with:
NeoBundle 'tony/vim-multiple-cursors', { 'rev': 'quit-multiple-cursors' }

Map quitting:
let g:multi_cursor_quit_key='<C-c>'
nnoremap <C-c> :call multiple_cursors#quit()<CR>

Originally was named "allow s:quit for multiple-cursors to be called publicly". Apparently, this will get <C-c> to work only if <C-c> is mapped, but there seems to be more interconnections inside that get in the way.

Happy to see someone has resurrected this issue

Sorry, this dropped off the radar


[fix][license] Exclude java-version-trim-agent.jar from presto license check

Motivation
We don't need to check the java-version-trim-agent.jar when checking presto license files.
Modifications
Exclude java-version-trim-agent.jar from presto license check.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] no-need-doc
(Please explain why)

[ ] doc
(Your PR contains doc changes)

[ ] doc-added
(Docs have been already added)

/pulsarbot rerun-failure-checks


Support other domain types than KVM.

Other machine types than KVM like LXC, Xen and others should be available to create. Right now KVM type is hardcoded.

With no activity for 2.5 years I'm closing this.  As discussed, if hypervisor drivers other than QEMU/KVM are to be supported, separate issues should be made or PRs should be submitted per driver type.
It would however be a significant amount of work and would require an expansion of the box metadata definition, since each hypervisor driver may need very different image formats, boot devices, bootloaders or even kernels.  It's not clear to me whether if libvirt hypervisor driver subtypes can even be specified in the metadata for boxes of the same Vagrant provider.
Additionally, there is the issue of fragmentation in available boxes; all existing boxes assume QEMU/KVM and they may not even work for different hypervisor driver, which would cause confusion for users.  So adding this feature requires some serious thought as to not cause backwards compatibility issues with current and new boxes.

@infernix :+1:  no one need it :)


add Swedish translation

First cut at Swedish translation. Review by another Sweden would be most useful.

First cut at Swedish translation. Review by another Sweden would be most useful.

Swedish is already translated, see Issue https://github.com/Ixam97/CarStatsViewer/issues/69
Also, please do not create pull requests to master as this branch is meant to only contain release-ready code. Forks meant to supply additional internal test tracks use this to build the bundles for the Play Store. Insterad, use active_developement. That's the branch new additions are made too and it always contains up to date strings. Strings in master would be outdated in the next release.

Thanks, I'll review the current translation!
You might want to set the default branch to active_developement as well? (and rename it due to the speling eror).


monaco editor wordWrap problem

<div style="width: 100%; height: 100%">
  <monaco-editor></monaco-editor>
</div>

My editor options:
{
  // 布局自适应
  automaticLayout: true,
  // 自动换行
  wordWrap: true,
  // 折叠
  folding: false,
  // 小地图
  minimap: {
    enabled: false
  },
  // 底部滚动超出
  scrollBeyondLastLine: false,
  // 行号
  lineNumbers: false,
  // 只读
  readOnly: false,
  // 字体
  fontFamily: '微软雅黑',
  fontSize: 20
}

Does anyone know why? please help me~
==============================
I tried again. If the font is Microsoft Yahei, just enter a long "======" and it will appear. If it is the default font, it will also appear in many Chinese cases. It seems that both font and character type have an effect.

@hellobugme With the upcoming editor release (0.20.x), there will be a new editor option, wrappingStrategy. You can then set that to advanced and your use-case will work correctly.

@hellobugme With the upcoming editor release (0.20.x), there will be a new editor option, wrappingStrategy. You can then set that to advanced and your use-case will work correctly.

Hi alexdima, thanks for the reply.
But when I upgraded to 0.20.0, I got an error, this is the error message:

And 0.19.3 is working well.

@hellobugme Perhaps you have a caching issue or some other kind of problem? getMassagedFontFamily is defined on the class BareFontInfo and everything works fine for me.

@hellobugme Perhaps you have a caching issue or some other kind of problem? getMassagedFontFamily is defined on the class BareFontInfo and everything works fine for me.
Should be caused by caching. I removed monaco-editor package and added it again, and it worked.
Thank you very much!


[FLINK-30802] Add details on SplitReader#fetch() interruption/resume

After a discussion in https://github.com/apache/flink-connector-cassandra/pull/3#discussion_r1087830169
R: @zentol

Forgot @zentol is off, @MartijnVisser can you take a look at this tiny PR ?


Change avatar problem

After update Admin Panel plugin Admin Addon User Manager not work normal.
Try change avatar - result error "Data type 'user-manager/test' doesn't exist!"

Getting the same issue here.

Thanks for reporting, I will take care of it this week.
On Mon, 18 Dec 2017, 17:53 Seth Geib<EMAIL_ADDRESS>wrote:

Getting the same issue here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/david-szabo97/grav-plugin-admin-addon-user-manager/issues/25#issuecomment-352486513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACJs6HpIF-KPhmKSmKfxAWobomABwQtHks5tBpibgaJpZM4Q-lFH
.

Fixed in v2.0.0

Cannot modify avatar.

@iqvision
Could you give more information please? Maybe a screenshot or video recording about the issue? Console errors? Server log? Anything that would help me?


Package structure for statsd should follow current accessM paradigms

My expectation when looking at zio.metrics.statsd was to find only the accessM proxy methods to whatever underlying layer is eventually supplied, the Has[???] type, and the layer constructors (clients, objects, etc).
I expect that moving everything around to what I think would be common idioms, set out by things like zio-logging and zio's built-in layers, should be coordinated with a ABI-breaking release, but I'm raising this issue just to start the discussion.

Hi @blast-hardcheese,
Thanks for your input and sorry for the late reply. There is a lot of work related to statsd reporting on zio-zmx, in particular this PR: https://github.com/zio/zio-zmx/pull/155
I suggest you can have a look and possibly add to the discussion there, then we can decide whether to bring the changes to zio-metrics or if zio-zmx cover your needs better.


Adding Elastic search

Implement elastic search on the backend which would later be extended to fit the product search & filter functionality.
While at it keep in mind the workflow

user searches on browser
search sent to backend as query
elastic search gives back search results as a response
the response is rendered in the browser

Backend code is complete.
Frontend needs to be done.

Basic search functionality is implemented in the frontend.
Still needs to be done:

handle the corner cases
improve the architecture
add filtering


Coverage Report Script does not work

Error message:
Traceback (most recent call last):
  File "./fc4sc/tools/coverage_report/report.py", line 66, in <module>
    d = parser.get_report_data(args.xml_report)
AttributeError: UCIS_DB_Parser instance has no attribute 'get_report_data'

As far as I can see, the type UCIS_DB_Parser from merge.py actually has no such method.

Hi nrother,
Thank you for the issue. You are correct.
The report script is not documented or tested yet. The missing functions were removed from the merge.py python module in a previous commit.
I have fixed the problem: https://github.com/amiq-consulting/fc4sc/commit/1b4ddef0b41b468ccad2d2e830cf9a4ed659e425.
Best Regard.


ZodOpenAPI errors after 3.10.5 and 0.9x

What version of Hono are you using?
3.11.x
What runtime/platform is your app running on?
workers
What steps can reproduce the bug?
Mixing zValidator and ZodOpenAPI has errors after 3.10.5 RPC changes
const baseRoutesSchema = z.enum(['*', '/']);

app.get(baseRoutesSchema.enum['/'], async (c) => {
	// c.text('Hello Hono!');
	await sleep(1000);
	return c.text('Hello Hono!');
});

/**
 * This binding allows us to access the cloudflare bindings from inngest
 */
app.use(baseRoutesSchema.enum['*'], async (c, next) => {
	try {
		// temporary to create cloudflare bindings
		globalThis.cfBindings = c.env;
		await next();
	} catch (e) {
		console.log(e);
	}
});

// app.doc31(appRoutesSchema.enum['/openapi'], {
// 	openapi: '3.1.0',
// 	info: {
// 		version: '0.0.1',
// 		title: 'AskLuna Worker API',
// 	},
// });

app.route(appRoutesSchema.Enum['/api'], apiRoute);
app.route(appRoutesSchema.Enum['/examples'], examplesRoute);
app.route(appRoutesSchema.Enum['/lease'], leaseRoute);

example route:
import { sleep } from '~core/helpers/functions/sleep';

import { type DistributedLeaseHonoController } from '~~/controllers/lease/services/DistributedLease';
import { createClientForDO } from '~~/helpers/createClientForDO';
import { honoFactory } from '~~/helpers/honoFactory';
const route = honoFactory();

route.get('/do-client', async (c) => {
	// c.text('Hello Hono!');
	await sleep(1000);
	// return c.text('Hello Hono after sleep!');

	const leaseRouteClient = createClientForDO<DistributedLeaseHonoController>({
		dObj: c.env.JobDistributedLease,
		idString: 'default',
		origin: new URL(c.req.url).origin,
	});

	const result = await leaseRouteClient.acquire.$get({
		query: { entityUid: 'd843c5af-9e97-4fc5-9a06-a1062430283c' },
	});
	const data = await result.json();
	return c.text(JSON.stringify(data));
});

export const examplesRoute = route;

When example route is used without hono open api it works, but does not with it.
What is the expected behavior?
I'm getting zod validator errors when i enable zod open api for endpoints.  For example open api.
What do you see instead?
No response
Additional information
No response

Hi @ShravanSunder
Please give us a code that can work with a minimum of that.

No response, I'll close this.


Bitcoin bridge direct send succeeds but is never debited to the sending ripple account

2.225 BTC was received at 1MUJropxdq9txyRJDJ5XJBsjQg7TU9BCFD via
https://blockchain.info/tx/5c4f98b335db018ee53e92f1cd8189277ce3bc7a5b789d45dcccd415a91f5f5f
from rw3Ms86G9Dmm23Z5TM6yAsxiA5v24UZKf7 using a send through a Bitcoin bridge
However the sending account was never debited 2.225 BTC
https://ripple.com/tools/info/#rw3Ms86G9Dmm23Z5TM6yAsxiA5v24UZKf7

Obsolete and not specific to rippled


Cannot install via go get

Trying to install dobi via go get, I run into the error:
$ go get github.com/dnephin/dobi
# github.com/dnephin/dobi/cmd
/srv/go/src/github.com/dnephin/dobi/cmd/dobi.go:44: unknown cobra.Command field 'TraverseChildCommands' in struct literal
/srv/go/src/github.com/dnephin/dobi/cmd/dobi.go:45: unknown cobra.Command field 'Args' in struct literal

I'm using go 1.6:
$ go version
go version go1.6.2 linux/amd64

I am running Ubuntu16.04.

Ah, I guess it is not go gettable at this time because my PRs on cobra haven't been merged yet.
I need to update the readme to say to use git clone instead.
The dependency versions are in the glide.lock:  https://github.com/dnephin/dobi/blob/master/glide.lock
Thanks for letting me know!

This should be fixed e4ec29bfe5a8789770bb63df7c5f6cafeb277a65 , now in master, and docs are published.
Let me know if you have any problems with the new instructions.


[rcamera] Matrix definition missing in rcamera.h

WARNING: Please, read this note carefully before submitting a new issue:
It is important to realise that this is NOT A SUPPORT FORUM, this is for reproducible BUGS with raylib ONLY.
There are lots of generous and helpful people ready to help you out on raylib Discord forum or raylib reddit.
Remember that asking for support questions here actively takes developer time away from improving raylib.

Please, before submitting a new issue verify and check:

[x] I tested it on latest raylib version from master branch
[x] I checked there is no similar issue already reported
[x] My code has no errors or misuse of raylib

Issue description
These two functions uses Matrix but it is not defined in rcamera.h
RLAPI Matrix GetCameraViewMatrix(Camera *camera);
RLAPI Matrix GetCameraProjectionMatrix(Camera* camera, float aspect);

I see Vector2, Vector3, Camera3D etc defined but not Matrix in #if defined(CAMERA_STANDALONE) section.
Missing Matrix definition makes rcamera.h cannot be used as standalone module.

@9tin9tin9 Good catch! rcamera.h was rewriten from scratch recently and it was probably removed by error.


SPA caching is incorrectly applied to index.html

Per #209: in SPA mode, serve should be serving up assets with the specified cache value, but ./index.html is special-cased to have no cache. Instead, serve appears to be serving up all files with the specified --cache value.
$ ./node_modules/.bin/serve --version
6.0.6
$ ./node_modules/.bin/serve --single --cache<PHONE_NUMBER>0

$ curl -I localhost:5000/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Accept-Ranges: bytes
Cache-Control: public, max-age=12345678
Last-Modified: Tue, 22 Aug 2017 17:33:37 GMT
ETag: W/"c-15e0b01bd68"
Content-Length: 12
Vary: Accept-Encoding
Date: Tue, 22 Aug 2017 17:57:09 GMT
Connection: keep-alive
$ curl -I localhost:5000/index.js
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=12345678
Last-Modified: Tue, 22 Aug 2017 17:33:50 GMT
ETag: W/"13-15e0b01f030"
Content-Type: application/javascript
Content-Length: 19
Vary: Accept-Encoding
Date: Tue, 22 Aug 2017 17:57:23 GMT
Connection: keep-alive

However, if you hit a path that isn't the physical index.html file or an asset file, the index.html contents do get returned with a max-age of 0:
$ curl -I localhost:5000/no-physical-file-at-this-path
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Tue, 22 Aug 2017 17:33:37 GMT
ETag: W/"c-15e0b01bd68"
Content-Type: text/html; charset=UTF-8
Content-Length: 12
Vary: Accept-Encoding
Date: Tue, 22 Aug 2017 18:01:57 GMT
Connection: keep-alive

Have you read this?

Yes, I have. And I've read the commit diffs for #209. Unfortunately, there's a bug.
$ curl -I localhost:5000/
Cache-Control: public, max-age=12345678

For clarity, here are the three cases side-by-side:
$ curl -I localhost:5000/index.js
Cache-Control: public, max-age=12345678                 // correct
$ curl -I localhost:5000/no-physical-file-at-this-path
Cache-Control: public, max-age=0                        // correct (though probably should be no-cache?)
$ curl -I localhost:5000/
Cache-Control: public, max-age=12345678                 // incorrect

Oh. Are you using the -s flag?

Yup, running with -s.

I'm curious if there's any update on this issue?

Seems like we need to fix it! We're not correctly applying the right caching values.

Fixed in https://github.com/zeit/serve/pull/269 - will go out once https://github.com/zeit/serve/pull/274 is merged!


Parser doesn't find modules folder if the jai compiler root is a directory not ending in "jai"

I was seeing a lot of "Could not open file" messages when running the parser on my project. This turned out to be the case, because I renamed the compiler root directory from "jai" to "jai_compiler", which causes the parser to not find any modules directory.

Fixed in https://github.com/SogoCZE/jai_parser/pull/5.


Draft: Support for Data Transfer Feedback via Backchannels

Overview
Explain the topic in 2 sentences
Dataspace consumers should be able to send feedback about consumed data to the respective data provider, via a proper back channel. This back channel is the counter part for the forward channel and should be contained within the same transfer process context (same contract agreement and transfer process).
What's the benefit?
Providers won't need to create specific offers just to allow consumers to send feedback.
What are the Risks/Dependencies ?
Some changes are required in the upstream EDC, but they are already aligned with the respective commiter group.
Detailed explanation
"Bidirectional data transfers involve transmissions that can be sent by either the provider or consumer during the transfer's lifetime. The provider sends data over a forward channel, while the client uses a response channel (back channel) to send data related to the forward transmission. For example, a provider sends parts data over the forward channel, while the consumer sends data related to errors in the forward transmission via the response channel."
Current implementation
No current implementation. Workarounds are in place.
Proposed improvements
The concept for bidirectional transfers was already presented in a previous CatenaX release. The goal of this task is to provide an implementation of the concept.
Feature Team
Contributor

@rafaelmag110
@bmg13

Committer

@paullatzelsperger
@jimmarino

User Stories

Issue 1, linked to specific repository
Issue 2, linked to another specific repository

Acceptance Criteria

[ ] Dataset consumers can send feedback messages - over a back channel - to the dataset provider under the same transfer process context.

Test Cases

Test Case 1

Feedback can be sent over a back channel.
Steps
Given a Provider has created an offer and specified a data address for the back channel
Then a consumer:

Find and Negotiate the Offer
Obtain a valid contract agreement
Start a transfer process using the obtained contract agreement
Search and obtain the required information to send feedback over the transfer process back channel

Expected Result
From 4.
4.1. The required information can be located
4.2. The information can be used to relay feedback to the data provider over the back channel

Expectation

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

[ ] This feature aligns with our current architectural guidelines

Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)

[ ] CX-0010 Business Partner Number
[ ] CX-0013 Identity of Member Companies
[ ] CX-0018 Data Space Connectivity (EDC)
[ ] CX-0049 DID Document Schema
[ ] CX-0050 Framework Agreement Credential
[ ] CX-0149 Verified Company Identity

Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)

[ ] CX-0001 EDC Discovery API
[ ] CX-0002 Digital Twins in Catena-X
[ ] CX-0018 Data Space Connectivity (EDC)

Data Format:

[ ] The data model is based on a published Semantic Model

[ ] The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
[ ] Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information

[x] I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

A few notes:

Most of this work is upstream in EDC
This will require standardization of a distribution dct:format type in Catena-X.

@paullatzelsperger  how much is there to do really in Tractus-X EDC? We could be a bit more specific in this issue to make clear that most of the work has been done upstream already.

Contributor @rafaelmag110  is currently unavailable and thus can't check the architecture criteria, but we guarantee that they are fulfilled.


gstreamer pipeline with nvcamerasrc causing nvcamera demon to stop working. ( segmentation fault )

Hi everyone.
I'm trying to grab frames from the TX1/2 using  gstCamera::capture(). I have been able to do the same using USB cameras, and they work just fine.
But when I try to use the same code to grab frames from TX1/2 on-board camera,  the nvcamera demon starts to throw errors when the function gstCamera::Open() is called.
More precisely on:
const GstStateChangeReturn result = gst_element_set_state(mPipeline, GST_STATE_PLAYING);
Within open() function.Eventually nvcamera demon stops working with segmentation fault. The errors are the following:

(NvOdmDevice) Error IoctlFailed: error setting format (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function setActiveMode(), line 1189)
(NvOdmDevice) Error IoctlFailed:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function enableStreamingConfiguration(), line 1797)
(NvOdmDevice) Error BadParameter: enableStreamingConfiguration FAILED (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorBase.cpp, function writeMode(), line 293)
(NvOdmDevice) Error BadParameter:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function apply(), line 160)
(NvOdmDevice) Error BadParameter: Sensor mode has not been configured! (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function apply(), line 194)
(NvOdmDevice) Error InvalidState: Invalid active Mode Size (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function streamControl(), line 1300)
(NvOdmDevice) Error InvalidState:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function apply(), line 196)
PowerServiceCore:handleRequests: timePassed = 11099
(NvOdmDevice) Error InvalidState: Invalid active Mode Size (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function streamControl(), line 1300)
(NvOdmDevice) Error InvalidState:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function apply(), line 196)
(NvOdmDevice) Error InvalidState: Invalid active Mode Size (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function streamControl(), line 1300)
(NvOdmDevice) Error InvalidState:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function apply(), line 196)
SCF: Error Timeout: ISP port 0 timed out! (in src/services/capture/CaptureServiceDeviceIsp.cpp, function waitIspFrameEnd(), line 702)
SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceEvent.cpp, function wait(), line 59)
Error: Camera HwEvents wait, this may indicate a hardware timeout occured,abort current/incoming cc
launchCC abort cc 104 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 105 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 106 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 107 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 108 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 109 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 110 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
launchCC abort cc 111 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
Error: waitCsiFrameStart timeout guid 0
VI Stream Id = 2 Virtual Channel = 0
**VI Debug Registers
VI_CSIMUX_STAT_FRAME_8	 = 0x00000774
VI_CSIMUX_FRAME_STATUS_0	 = 0x00000000
VI_CFG_INTERRUPT_STATUS_0	 = 0x3f000000
VI_ISPBUFA_ERROR_0	 = 0x00000000
VI_FMLITE_ERROR_0	 = 0x00000000
VI_NOTIFY_ERROR_0	 = 0x00000000

CSI Stream Id = 2 Brick Id = 1
**CSI Debug Registers
CILA_INTR_STATUS_CILA[0x20400]	 = 0x00000000
CILB_INTR_STATUS_CILB[0x20c00]	 = 0x00000000
INTR_STATUS[0x200a4]	 = 0x00000000
INTR_STATUS[0x200a4]	 = 0x00000000
ERR_INTR_STATUS[0x200ac]	 = 0x00000000
ERROR_STATUS2VI_VC0[0x20094]	 = 0x00000000
ERROR_STATUS2VI_VC1[0x20098]	 = 0x00000000
ERROR_STATUS2VI_VC2[0x2009c]	 = 0x00000000
ERROR_STATUS2VI_VC3[0x200a0]	 = 0x00000000

VI Stream Id = 2 Virtual Channel = 0
**VI Debug Registers
VI_CSIMUX_STAT_FRAME_8	 = 0x00000774
VI_CSIMUX_FRAME_STATUS_0	 = 0x00000000
VI_CFG_INTERRUPT_STATUS_0	 = 0x3f000000
VI_ISPBUFA_ERROR_0	 = 0x00000000
VI_FMLITE_ERROR_0	 = 0x00000000
VI_NOTIFY_ERROR_0	 = 0x00000000

CSI Stream Id = 2 Brick Id = 1
**CSI Debug Registers
CILA_INTR_STATUS_CILA[0x20400]	 = 0x00000000
CILB_INTR_STATUS_CILB[0x20c00]	 = 0x00000000
INTR_STATUS[0x200a4]	 = 0x00000000
INTR_STATUS[0x200a4]	 = 0x00000000
ERR_INTR_STATUS[0x200ac]	 = 0x00000000
ERROR_STATUS2VI_VC0[0x20094]	 = 0x00000000
ERROR_STATUS2VI_VC1[0x20098]	 = 0x00000000
ERROR_STATUS2VI_VC2[0x2009c]	 = 0x00000000
ERROR_STATUS2VI_VC3[0x200a0]	 = 0x00000000

SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceDeviceIsp.cpp, function waitCompletion(), line 676)
SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function pause(), line 884)
SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function handleCancelSourceRequests(), line 955)
SCF: Error Timeout:  (propagating from src/services/capture/CaptureServiceDevice.cpp, function issueCaptures(), line 983)
SCF: Error Timeout:  (propagating from src/common/Utils.cpp, function workerThread(), line 114)
SCF: Error Timeout: Worker thread CaptureScheduler frameStart failed (in src/common/Utils.cpp, function workerThread(), line 131)
launchCC abort cc 249 session 0
SCF: Error Timeout:  (propagating from src/api/Session.cpp, function capture(), line 830)
SCF: Error Timeout: NvRmSyncWait failed (in src/api/Buffer.cpp, function cpuWaitFences(), line 489)
SCF: Error Timeout:  (propagating from src/api/Buffer.cpp, function unassignFromCapture(), line 256)
SCF: Error Timeout:  (propagating from src/components/CaptureContainerImpl.cpp, function returnBuffer(), line 373)
SCF: Error Timeout:  (propagating from src/components/CaptureContainerImpl.cpp, function returnApiBuffers(), line 505)
Segmentation fault (core dumped)
Also, if I try the same pipeline of this project with gst -launch-1.0 in a stand alone fashion, it also works fine.
I have done this procedures with both TX1 and TX2 with same results.
Any thoughts ?
Thanks,
Nicolas.

Hi Nicolas, are you able to repetitively launch the nvgstcapture-1.0 application ok without seeing the problem?


Determine collection and table versioning strategy

The collection name is currently hard-coded as a constant. This means a code change is required whenever there is a new data version release, which is perhaps good if we want to wipe the previous data and replace it with new data in the existing table.  The API would always point to the latest data. There are alternate patterns we may want to consider:

Create a new db table for new data and keep older versions in their own table for a period of time
Would we then want to/be able to support multiple versions of the API, so a user could point to a different base URL if they want to use a previous collection version?
What time period would we want to keep older versions of the data for? Need to check with DPub to see what the retirement policy is for SWOT. Once the data in a previous version is no longer available through the archive it shouldn't be available in hydrocron.

Allow loading new data alongside old data in same table
This would involve allowing the operator to specify the collection name/version as an input to the lambda function, which would intentionally result in multiple data versions in the same table. The version/collection name would be returned in the API response, but is not a field than can be queried on. New versions of data that have the same reachid/timestamp as existing data will be overwritten by the new version (eg in a reprocessing campaign), but it would be much harder to manually clear out older versions of data if there is ever a need to remove it (eg if there is a collection retired without a new version to replace it). Not sure if that's expected to ever occur.

@cassienickles @frankinspace @nikki-t would appreciate your thoughts

My take would be to match as close as we can the plan for data curation. If I recall correctly for swot reprocessing the understanding is that podaac will only have a single collection version available at any given time. I think hydrocron should match that... whatever collection version is available is the version of the data served by hydrocron.
That said, I think we should also try to minimize downtime of the api itself. So I think we should think of it as more of a blue/green style of update where blue = data connected to collection version that is being sunsetted and green = data connected to the new collection version.
The API would be connected to blue tables by default. When a new collection version is being planned; we should create an empty green copy of the tables and connect the green tables to ingest events of the new collection version. So as reprocessed data is delivered to the green collection, it would flow into the green db tables. We could also implement a strategy for manually controlling which tables the api queries agains (easiest thing that comes to mind would simply be a request parameter... maybe undocumented so as not to add confusion?). Once the new collection is in operations and public, we make the green tables the new blue and drop the old blue tables.

Along the same line of thought... we could also say that new collection versions always result in an increment to the hydrocron api version (other changes could also increment the api version, not just new collection; but new collection would always increment api version)
That way there could be an overlap period where both data is available via API
/hydrocron/v1/timeseries -> blue data
/hydrocron/v2/timeseries -> green data
This could be considered too burdensome for our users though as the URL would change. But depending on the nature of the data change it might actually be warranted?
However, that could still be mitigated further by having an additional endpoint that simply points to the 'latest' api version
/hydrocron/LATEST/timeseries -> blue data

I agree with having it match as close as we can the plan for data curation! And also minimizing downtime of the API!
Adding additional versions of hydrocron and changing the URL makes me feel like that could get really complicated and mistakes could be made... people thinking they're getting the latest and then they aren't. Links and workflows are shared quickly among scientists and whoever made the initial decision on which version to use would be making that decision for everyone they share their link with. I'd prefer to keep it simple and just have one deployed version but could be convinced otherwise :)

NASD ticket requesting the ability to serve multiple stages simultaneously from cloudfront: https://bugs.earthdata.nasa.gov/browse/NASD-4190

Adding in some info picked up at the SWOT STM this week:

forward stream ingest for the new collection version will begin in October in 24.4, prior to reprocessing prior data starting in 25.1. I think if that rushes us too much, or we're still waiting on the NASD capability, we can wait and backfill again in the same way we did for the v1 release.

consensus among scientists/users of hydrocron that I've spoken with so far prefer exactly the incremented API version with a period where both the both versions are available as @frankinspace described above:
That way there could be an overlap period where both data is available via API/hydrocron/v1/timeseries -> blue data/hydrocron/v2/timeseries -> green data

This way they can still get a full time series by making calls to both tables. Since reprocessing is expected to take months, we don't want to remove the previous version too early. However, when the SWORD version increments, the reach and node ids often change, and could be recycled, so the same reach_id in v1 and v2 could actually be pointing to different features. This table/url design forces users to think about that and handle it in their applications.

Thanks for the update @torimcd
Will the forward stream be made public immediately or will there be a delay?
It sounds like the consensus is that we need to provide for some period of overlap where users can query both versions of the data. This makes the back-end decision pretty straightforward (IMO), we should maintain tables-per-collection. Theoretically we could add another global secondary index on the 'collection_shortname' / 'collection_version' columns in the existing tables but I don't think that would provide any benefit over tables-per-collection at this point (@torimcd do you agree?)
I do want to explore the new endpoint vs request parameter thought a little more. We don't necessarily need new endpoints to achieve the goal of serving multiple collection versions.
The multiple endpoint solution would look something like:
/hydrocron/v1/timeseries -> SWOT_L2_HR_RiverSP_2.0 data
/hydrocron/v2/timeseries -> SWOT_L2_HR_RiverSP_TBD data
/hydrocron/LATEST/timeseries -> 2.0 or TBD data, controlled by podaac operations
However, same functionality could be achieved by introducing a new request parameter (e.g. 'collection', could be 'short_name' or 'data_version' or something else)
/hydrocron/v1/timeseries?collection=C2799438299-POCLOUD -> SWOT_L2_HR_RiverSP_2.0 data
/hydrocron/v1/timeseries?collection=CTBD-POCLOUD -> SWOT_L2_HR_RiverSP_TBD data
/hydrocron/v1/timeseries?collection=latest -> 2.0 or TBD data, controlled by podaac operations
Here's just a few thoughts on the pros/cons of each approach
Solution 1 (new data = new endpoint):

Pro: Obvious that data is changing, forces clients to be cognizant of that fact
Pro: Simple to track usage metrics, podaac would know which endpoint is receiving traffic
Pro: More flexibility with how retirement of 'old' endpoint is managed. Could setup a redirect from v1 to v2, or could return 501 Not Implemented with a message that v1 is not supported and link to v2 docs
Con: Need to manage multiple stages(?), going to take some research to see how this is achieved in terraform/API Gateway though I believe it is possible
Con: Must deploy new API version when data changes, even if there is no change to API specification

Solution 2 (add request parameter to specify collection used):

Pro: Minimal impact to clients, URL does not change, just a query parameter
Pro: Can support multiple data versions with no change to API specification
Pro: Collections supported could be managed via UMM-S/UMM-C association
Pro: Breaking API changes can be decoupled from data management. Meaning /hydrocron/v2/timeseries would be reserved for if/when we have API specification changes that are not backward-compatible
Con: More difficult to track metrics, would require parsing request params (which we are planning on doing anyway but is blocked for other reasons).
Con: Air is a great movie

Thinking through this I'm leaning towards managing the data via request parameter instead of new endpoints but welcome other contributions too.

Thanks @frankinspace:
There's always the chance of a delay, but I think we should plan assuming that the new data version will be public ~immediately (within Oct, but perhaps not the same day data starts ingesting).
I agree we should go with tables-per-collection. I think using another GSI to work around this only adds complexity, and effectively duplicates the data anyways, so doesn't save on storage.
In general using a query parameter vs a different endpoint has the same impact on the end user for having to deal with versioning, in that they have to make different API requests to get different versions of the data in both cases, so from that sense I'm fine with either approach. I like decoupling the API versioning from the data versioning, so am onboard with going forward with the request parameter. I don't love using shortname or concept ID as the parameter though, since that starts needing a bit more technical knowledge. Also need to think a little about backward compatibility here, multiple endpoints is already backward compatible as it's already deployed as v1, but I don't know how we could implement this through request parameters without it being a required parameter (otherwise at what point do we switch the 'default'?), so introducing this will be a breaking change.

Jack's opinion: the blue/green idea described in this comment gets my vote, if we can pull it off: https://github.com/podaac/hydrocron/issues/103#issuecomment-2181817817 If blue is version C and green is version D, then in October blue stops growing and green starts growing from zero, and green will not have the complete data record until mid-2025 optimistically

Steps needed to implement table versioning based on request parameter:

create new dynamodb tables for each feature type (reach, node, prior_lake), table name contains data version (ie hydrocron-swot-reach-table-d or hydrocron-swot-reach-table-version-d)
create new API request parameter for user to specify data version (data_version=d?, confirm with dpub/app sci what this should be), query correct table based on parameter requested. Should this parameter be required?
update documentation
deploy new hydrocron version to UAT, test, deploy to OPS
Dependency on OPS: back-load any data in new table if new version forward stream data release date is missed - do we know what date this is yet?
Dependency on I&A: connect forward stream to send CNM to hydrocron on ingest
Potential feature analysis for removing tables/validating query parameters on collection version retirement

I know that we don't need our API gateway to support multiple stages for this work but I followed up on the tickets listed in this comment and it looks like NGAP will be able to support this work in 24.4.3 starting in the SIT environment.
Tickets:

https://bugs.earthdata.nasa.gov/browse/NASD-4190
https://bugs.earthdata.nasa.gov/browse/NASD-4491


TrailingCommaMultiLineRule Issue with Empty Arrays

Rule(s) related to or rule(s) missing
TrailingCommaMultiLineRule
Expected behavior
{% set allowed = [
] %}

Actual behavior
{% set allowed = [,
] %}

Yesterday the rule TrailingCommaMultiLineRule was activated again by default, but causes the php runtime error Unexpected token "punctuation" of value "," as soon there are empty arrays in the code. See #320.

@VincentLanglet Looks good - It works now for my codebase! Thanks for the fix.


"string indices must be integers" when adding dependency to meta

When adding a dependency ansibe-mdgen crashes. Without dependency, e.g. just [], it's working
meta/main.yml
---
galaxy_info:
  author: Peter Murphy
  description: Role to install and configure Minio in distributed mode
  company: My Company
  license: None
  min_ansible_version: 2.9
  platforms:
    - name: RedHat
      versions:
        - 7.8

  galaxy_tags: []

dependencies:
  - geerlingguy.java

ansible-mdgen
Traceback (most recent call last):
  File "/home/mne-adm/.local/bin/ansible-mdgen", line 6, in <module>
    md = AnsibleMdgen()
  File "/home/mne-adm/.local/lib/python3.9/site-packages/ansiblemdgen/AnsibleMdgenClient.py", line 24, in __init__
    writer.render()
  File "/home/mne-adm/.local/lib/python3.9/site-packages/ansiblemdgen/AutoDocumenter.py", line 38, in render
    indexWriter.render()
  File "/home/mne-adm/.local/lib/python3.9/site-packages/ansiblemdgen/AutoDocumenterIndex.py", line 20, in render
    self.createIndexMDFile()
  File "/home/mne-adm/.local/lib/python3.9/site-packages/ansiblemdgen/AutoDocumenterIndex.py", line 31, in createIndexMDFile
    self.createMDFileContent(mdFile)
  File "/home/mne-adm/.local/lib/python3.9/site-packages/ansiblemdgen/AutoDocumenterIndex.py", line 84, in createMDFileContent
    mdFile.new_line("> "+dep_part+": "+dependency[dep_part])
TypeError: string indices must be integers

Hi Madic - I have put in a fix for this issue. Please download the latest version and retry, thanks.

Thank you!


Some version control badges dont show up

Addressed in https://github.com/inttter/md-buttons/commit/0acdc09606a613c95f3db73ee6add4cc5fc5f619.


STM32 pinout xml files are public available from STM on github

Hi,
FYI: it seems that the STM32 pinout xml files now are public available from STM on github- without the need to install CubeMX
https://github.com/STMicroelectronics/STM32_open_pin_data
It seems that the "families.xml" file is not included...
/Uffe

Oh, cool! Thanks for letting us know.


Use one BackOffPolicy instance per operation

Codecov Report

:exclamation: No coverage uploaded for pull request base (reliable_table_copy@3875ad1). Click here to learn what that means.
The diff coverage is 87.5%.

@@                  Coverage Diff                   @@
##             reliable_table_copy    #5563   +/-   ##
======================================================
  Coverage                       ?   82.64%
  Complexity                     ?    11384
======================================================
  Files                          ?     1357
  Lines                          ?    44170
  Branches                       ?     5515
======================================================
  Hits                           ?    36503
  Misses                         ?     5098
  Partials                       ?     2569

Impacted Files
Coverage Δ
Complexity Δ

...a/io/crate/operation/projectors/RetryListener.java
73.33% <100%> (ø)
3 <1> (?)

.../operation/projectors/ShardRequestAccumulator.java
81.81% <100%> (ø)
14 <0> (?)

.../crate/executor/transport/task/UpsertByIdTask.java
88.88% <100%> (ø)
40 <0> (?)

...e/operation/projectors/ShardingUpsertExecutor.java
74.88% <75%> (ø)
34 <0> (?)

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 3875ad1...e04c8f7. Read the comment docs.


Remove link to project templates from the README

Project templates were moved to the compiler repository, so the link to the project templates folder doesn't work anymore.

Thanks, I forgot about that.


mAP

I noticed that the projet didn't plot the mAP ,how can i revise the code?

Can you tell me how to solve this problem?Thank you!

Can you tell me how to solve this problem?Thank you!
给你个CSDN博客链接：
https://blog.csdn.net/beyond_xnsx/article/details/79910900

I added it here https://github.com/morpheusthewhite/Faster-RCNN-TensorFlow-Python3.5/commit/8c5307c4c92916e12fef436b19872eec7bede030 in my fork


Unit test cases for Validator Registry TP

Signed-off-by: S m, Aruna<EMAIL_ADDRESS>

This repo is not used, deleting the PR.


Cannot read property 'mode' of undefined

/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/index.js:289
  return Boolean(4 & parseInt((stats.mode & 0x1ff).toString(8)[0], 10));
                                    ^
TypeError: Cannot read property 'mode' of undefined
    at EventEmitter.FSWatcher._hasReadPermissions (/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/index.js:289:37)
    at EventEmitter.<anonymous> (/project/node_modules/webpack/node_modules/watchpack/node_modules/chokidar/lib/fsevents-handler.js:296:13)
    at FSReqWrap.oncomplete (fs.js:99:15)

chokidar 1.0.0-rc4
watchpack 0.2.3
webpack 1.7.3
OS X Yosemite 10.10.2
any thoughts?

It's fixed in master branch. I'm trying to tie up some loose ends and release rc5 today.
In the meantime, if you're setting ignorePermissionErrors: true take that off and it will probably work

The use of ignorePermissionErrors: true did not help. But problem solved by
$ cd node_modules/webpack/node_modules/watchpack/node_modules/
$ npm i git+https://github.com/paulmillr/chokidar.git

@es128 thanks!


fix(android): wrong coordinates on pressing polyline

Fix for wrong coordinates on pressing polyline

Does any other open PR do the same thing?

No
What issue is this PR fixing?
This change will fix the wrong coordinates sent while pressing the polyline on Android platform
How did you test this PR?

I have tested it on Android platform with the real device. The change is specific to Android, so haven't tested it on iOS

@Simon-TechForm Hi, can you check and approve this PR if possible?

@Simon-TechForm Please review and approve the changes. Thanks

LGTM, seems like it should have been fixed alongside #3966.


Support primary key error in the test runner

Make every table name match the table identity. Had to remove a conflict on
two tables both named "user", by naming one table "user1". Updates all
Semantic.User references to point to Semantic.User1

Replace several assert(!err) calls with assert.ifError(err), which
actually prints the error message.

Removes nested updates, which don't work anymore, because we don't let you
update the primary key.

sails-postgresql and waterline-adapter-tests depend on each other, unfortunately, so one side has to go first, then the other change can get merged and then we can repoint these tests at master.

I should have merged this a month ago.


Support for grammar "GAS/AT&T x86/x64" and extension "s"

Probably not the most popular language, but people still use it.

Would you mind pointing us to a reference or specification?

@prettydiff It is the assembler use in GNU CC for the Intel x86 instruction set.  The instruction set itself is available from Intel here:
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Note that GNU AS uses the "AT&T" style for assembler, whereas Intel uses a different style.  The instructions are the same (I believe) but the order for the operands are different, for example.  GNU AS syntax specifics below.
If you want to see output, you can run gcc -S on any source file and it should produce the .s assembly output.
There is a Wikibook here:
https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax
Online manuals are here:
https://sourceware.org/binutils/docs-2.26/as/index.html
Let me know if this helps.  Generally, I believe the structure should go something like this.  Labels are in column 1.  Directives and instructions go in column 9.  Operands go on column 17, separated by comma space.  One-line comments (#) start in column 40, as some operands can be long.  There are some directives that would not allow the "operands" for them to start on column 17.  If so, they should be in the next 8-character tab position.


Implement default values for at on array/dict

Implements #946

You should also edit the error message when the key doesn't exist and that no default value is given, hinting that you can set a default value.

You should also edit the error message when the key doesn't exist and that no default value is given, hinting that you can set a default value.

Good point, will implement.
Should I also implement the default value for String.at()?

Should I also implement the default value for String.at() and Content.at()? Not sure if that makes sense, but would be consistent to implement it for all .at functions

Go ahead, it makes sense.

Should be ready for review then :)

Was about to push the same thing :D You are fast! Thanks for finishing this up!


Azure VAT ID for the UK is not being accepted

Hi,
I noticed an old thread around this which seemed to get no resolution but to be fair, the person didnt seem very helpful.
https://github.com/MicrosoftDocs/azure-docs/issues/57356
Steps to replicate:-

Login to the Azure portal "portal.azure.com"
Navigate to "Cost Management + Billing"
Select my Billing Scope
Click on "Properties" on the left hand side
Under "Tax ID management", Click the "Manage Tax IDs"
Enter the VAT ID for the United Kingdom

upon doing this, the validation failures with or without the spaces and basically states its not a valid VAT number, despite it being the correct one used and generated by HMRC. My feeling is that its the validation itself that is broken rather than the "Save" button functionality as i don't think its even triggering it at that point. As soon as i type the VAT number in and click out of the field its at that point the validation kicks in and seems to be wrong.

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

ID: 6e36144b-06e5-b200-a3d5-acd6f8e21ce6
Version Independent ID: 9730a09a-9448-4994-0de2-473e5bbdaf9a
Content: Create a SaaS offer in the commercial marketplace.
Content Source: articles/marketplace/create-new-saas-offer.md
Service: marketplace
Sub-service: partnercenter-marketplace-publisher
GitHub Login: @mingshen-ms
Microsoft Alias: mingshen

@wc-whiteheadd
Thanks for your feedback! We will investigate and update as appropriate.

@wc-whiteheadd - Thank you for providing the document details. It looks like you have an issue with the product itself and this feedback is not related to the docs improvement. In this forum, we focus on improving the docs and feedback related to docs only.
Do you mind posting your question on Microsoft QnA as our engineers and community are actively working on answering questions related to the product on the forum.
At this moment, Since there is no doc update required, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Add controls ov5640

This PR adds to the ov5640 camera driver

some controls (hue, saturation, etc.)
support for changing frame rate which depends on this PR which add frame rate changing APIs

@ngphibang can you resolve the CI errors?

@ngphibang can you address the CI failures

@dleach02 CI failures are due to the dependency on this PR which is not merged yet

@dleach02 CI failures are due to the dependency on this PR which is not merged yet

Okay, looks like you have a comment 10 hrs ago then in the other PR from the assignee. Please work with the assignee to get their approval.

Rebase because the PR https://github.com/zephyrproject-rtos/zephyr/pull/76393 is merged

@josuah : https://github.com/zephyrproject-rtos/zephyr/blob/84f22d8a2dcce38a71eec029818fe8113b876161/drivers/video/ov5640.c#L604 ?

@loicpoulain @josuah : Yes, the ctrl value should be checked. The bigger problem is control value in the API is defined as *(void ) which cause some difficulties for drivers and applications. I am working on defining control types for each CID, will try to find time to finalize and push the PR soon.

Hi @loicpoulain , could you revisit this ?
Thanks


Selecting addon from dropdown with mouse leaves partial text

This is looking really great guys! Thanks for all the work you've put into this.
I noticed a bug with the dropdown list for addons. If you start typing an addon, say "ofxG" and then click on something from the filtered list (like ofxGui), the initial few characters remain in the field. Maybe it's a "feature" so you can speed-add things (ofxGui! ofxGrabCam!) but I'm assuming it should clear out :smile:

thanks will take a look at this...


Adding support to capture groups with custom types

At the moment filePattern2 has support for parsing directories (if specified using digits or characters) and fails when it contains both, whitespaces and metacharacter. So It would be better to add a support to capture groups with custom types as the folder names may be defined in various ways. Following below is an example of folder names of one of the dataset
├── 190725-3-36-HSV-1A_Plate_13965
├── 190725-3-36-HSV-1B_Plate_13966
├── 190725-3-36-HSV-1C_Plate_13967
├── 190725-3-36-HSV-1D_Plate_13969
├── 190801-3-37-HSV-2A_Plate_13992
├── 190801-3-37-HSV-2B_Plate_13993
├── 190801-3-37-HSV-2C_Plate_13994
├── 190801-3-37-HSV-2D_Plate_13995
├── 190808-3-38-HSV-3A_Plate_14024
├── 190808-3-38-HSV-3B_Plate_14025
├── 190808-3-38-HSV-3C_Plate_14026
└── 190808-3-38-HSV-3D_Plate_14027

Fixed in v2.0.3


Fix typos

Issue Number
Link to issue this PR addresses.  If no issue exists, please provide reasoning for PR.
Overview of PR
Provide an overview of the changes in this PR.
Don't forget to update the CHANGELOG.md file with any changes that are in this PR

thank you


Taking 'done' into consideration while calculating returns

Hello, thank you for making this repo,
I think while calculating the returns you should take done into consideration as,

    def calculate_returns(self, rewards, dones, normalize = True):

        returns = []
        R = 0
        for r, d in zip(reversed(rewards), reversed(dones)):
            if d:
                R = 0
            R = r + R * self.gamma
            returns.insert(0, R)

        returns = torch.tensor(returns).to(device)

        if normalize:
            returns = (returns - returns.mean()) / returns.std()

        return returns

Also can you please briefly describe the Generalized Advantage Estimation (GAE) while calculating the advantages.

Notebooks 1-7 all use Monte Carlo methods. That is each environment is run for a single episode, i.e. until the environment returns done = True, after which we then calculate the returns/advantages and update the policy parameters.
There is no need to check for done in the calculation of the returns/advantages as only the last state will have done = True, which is why R is initialized to zero.
I'll add the explanation to GAE when I get around to adding more detail to the notebooks - for now I'd recommend these two links:

https://datascience.stackexchange.com/questions/32480/how-does-generalised-advantage-estimation-work
https://lilianweng.github.io/lil-log/2018/02/19/a-long-peek-into-reinforcement-learning.html


Fails to update dired-git-info package when running doom upgrade

What did you expect to happen?
Running doom update finishes without an error related to updating dired-git-info package.
What actually happened?
When running doom update, the following error occurs.
      > (72/208) Re-cloning dired-git-info...
        > Cloning dired-git-info...
            I think that causes an error.
Steps to reproduce
Running doom update always causes that error.
System Information
https://pastebin.com/jpanAH83

There's an explanation and a solution for a similar problem here: https://github.com/hlissner/doom-emacs/issues/4984#issuecomment-832842879

The current remote for dired-git-info is https://github.com/emacs-straight/dired-git-info.git, but the requested commit id is in https://github.com/clemera/dired-git-info

@annagrram Thanks for the info, but I don't think that solve the problem because, as @zhelezov explains, the current commit hash looks point to different repository's branch.

I also hit the problem and came here to report it. Good to know that it was not me breaking something.

There's an explanation and a solution for a similar problem here: #4984 (comment)

I tried this but the doom upgrade command continues to throw the error.

My bad.
For me, it solved the issue in the sense that it let doom upgrade continue running properly.
When I checked the actual folder, it seems to indeed point to https://github.com/emacs-straight/dired-git-info.git and the branch is master rather than the pinned commit.

My bad.

Not at all. It gave me something to try. :)

For me, it solved the issue in the sense that it let doom upgrade continue running properly. When I checked the actual folder, it seems to indeed point to https://github.com/emacs-straight/dired-git-info.git and the branch is master rather than the pinned commit.

The current remote for dired-git-info is https://github.com/emacs-straight/dired-git-info.git, but the requested commit id is in https://github.com/clemera/dired-git-info. A revert of 80bdd27 should fix this.

I just tried to follow the initial suggestion, removed the directory and cloned the clemera repo manually. Then rerun doom upgrade and it worked like a charm.
I imagine that you may already know this should work, but I am very new to Doom Emacs so just wanted to leave this written in case someone else found the problem and wanted a quick solution before a proper one is implemented.

Do a git revert 80bdd2774 or git checkout 80bdd2774~ -- modules/emacs/dired/packages.el if this is bothering you.

Do a git revert 80bdd2774 or git checkout 80bdd2774~ -- modules/emacs/dired/packages.el if this is bothering you.

When I try this, and then doom upgrade, I get
!   Refusing to upgrade because "~/doom-emacs/" has been modified.

  Either stash/undo your changes or run ’doom upgrade -f’ to discard local changes.

   M  modules/emacs/dired/packages.el

How can do the revert or checkout and have doom upgrade be happy with it?

@gcoladon I did the following and it helped avoid that error. I'm not sure if this is the best/right approach though.
packages.el
(package! dired-git-info
  :pin "9461476a28a5fec0784260f6e318237c662c3430")

doom sync -u


clock.py: constrain hour to 0 to 24

Use a modulo to constrain the displayed hour to 0 - 24 after applying the UTC offset.
Very small change to the Galactic Unicorn, Cosmic Unicorn, and Interstate75 clock.py examples.

Looks good, thank you!
I think this may help fix #578 ?


Added timeline table

feel free to adjust the timeline - but I think this already looks clearer than several lists of meeting type ;)

Sure does look much clearer!
Two things:

Maybe put a note on top, that Tuesday/Thursday and the times are examples; the actual timeslots to be agreed-upon
Link in handbook.md?

Maybe add week_id as first column?

I accidentally added the link on master 🤦♀. So let's merge this if it's ok by you.


Put dataset data in list on main window

listed data from QList<QList<QString>> list to offers list in main window.


Client Source IP from cilium_host interface

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
I have k8s cluster with installed MetalLb with layer2 protocol:
  address-pools:
    - name: nginx-pool
      protocol: layer2
      addresses:
      - <IP_ADDRESS>/32
      auto-assign: false

In deployment i install nginx with Service:
kind: Service
metadata:
  name: nginx-proxy
  annotations:
    metallb.universe.tf/address-pool:  nginx-pool
spec:
  loadBalancerIP: <IP_ADDRESS>
  selector:
    app: nginx-proxy
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  type: LoadBalancer
  externalTrafficPolicy: Cluster

I would like to have the real client IP in the logs, but I have the IP address from the cilium_host interface from the node on which the ARP for the address <IP_ADDRESS> is propagated through MetalLB. When I set externalTrafficPolicy: Local I have the real client IP in the logs, but I don't have traffic spread over multiple pods - the traffic always goes to the node that is propagating ARP for the MetalLb address.
My cilium configuration:
kubeProxyReplacement: strict
      tunnel: disabled
      autoDirectNodeRoutes: true
      loadBalancer:
        mode: hybrid
        acceleration: native
      ipam:
        operator:
          clusterPoolIPv4PodCIDR: <IP_ADDRESS>/16
          clusterPoolIPv4PodCIDRList:
            - <IP_ADDRESS>/16
      ipv4NativeRoutingCIDR: <IP_ADDRESS>/24
      nativeRoutingCIDR: <IP_ADDRESS>/24
      k8sServiceHost: <IP_ADDRESS>
      k8sServicePort: 6443
      operator:
        replicas: 2
      encryption:
        enabled: false
        type: wireguard
      l7Proxy: false

Cilium Version
1.10.4
Kernel Version
5.4.0-104-generic #118-Ubuntu
Kubernetes Version
1.22 (v1.22.7+rke2r1)
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

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

Yes,  i trying to use DSR, following with: https://docs.cilium.io/en/v1.10/gettingstarted/kubeproxy-free/#dsr-mode . I trying settings:
kubeProxyReplacement: strict
tunnel: disabled
autoDirectNodeRoutes: true
loadBalancer:
   mode: dsr

and
kubeProxyReplacement: strict
tunnel: disabled
autoDirectNodeRoutes: true
loadBalancer:
   mode: hybrid

Now i trying with externalIPs field in service, but without any change, i still see IP from cilium_host.

DSR didn't work? What was the issue?

The issue is that i havent really client source IP but i have IP from cilium_host interface.
Cilium config:
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-cilium
  namespace: kube-system
spec:
  valuesContent: |-
    cilium:
      kubeProxyReplacement: strict
      tunnel: disabled
      autoDirectNodeRoutes: true
      loadBalancer:
        mode: dsr
      ipam:
        operator:
          clusterPoolIPv4PodCIDR: <IP_ADDRESS>/16
          clusterPoolIPv4PodCIDRList:
            - <IP_ADDRESS>/16
      ipv4NativeRoutingCIDR: <IP_ADDRESS>/24
      nativeRoutingCIDR: <IP_ADDRESS>/24
      k8sServiceHost: <IP_ADDRESS>
      k8sServicePort: 6443
      operator:
        replicas: 2
      encryption:
        enabled: false
        type: wireguard
      l7Proxy: false
      hubble:
        metrics:
          enabled:
          - dns:query;ignoreAAAA
          - drop
          - tcp
          - flow
          - icmp
          - http
        relay:
          enabled: true
        ui:
          enabled: true
          replicas: 1
          ingress:
            enabled: true
            className: nginx
            hosts:
              - hubble.CUT-HERE
            annotations:
              cert-manager.io/cluster-issuer: acme.CUT-HERE
              kubernetes.io/ingress.class: nginx
            tls:
            - secretName: ingress-hubble-ui-tls
              hosts:
              - hubble.CUT-HERE
      prometheus:
        enabled: true
        # Default port value (9090) needs to be changed since the RHEL cockpit also listens on this port.
        port: 19090
        # Configure this serviceMonitor section AFTER Rancher Monitoring is enabled!
        #serviceMonitor:
        #  enabled: true

Cilium status:
KVStore:                Ok   Disabled
Kubernetes:             Ok   1.22 (v1.22.7+rke2r1) [linux/amd64]
Kubernetes APIs:        ["cilium/v2::CiliumClusterwideNetworkPolicy", "cilium/v2::CiliumEndpoint", "cilium/v2::CiliumNetworkPolicy", "cilium/v2::CiliumNode", "core/v1::Namespace", "core/v1::Node", "core/v1::Pods", "core/v1::Service", "discovery/v1::EndpointSlice", "networking.k8s.io/v1::NetworkPolicy"]
KubeProxyReplacement:   Strict   [br100 <IP_ADDRESS>, br705 <IP_ADDRESS> (Direct Routing)]
Cilium:                 Ok   1.10.4 (v1.10.4-2a46fd6)
NodeMonitor:            Listening for events on 56 CPUs with 64x4096 of shared memory
Cilium health daemon:   Ok
IPAM:                   IPv4: 6/254 allocated from <IP_ADDRESS>/24,
Allocated addresses:
  <IP_ADDRESS> (router)
  <IP_ADDRESS> (kube-logging/fluentd-b2gx6)
  <IP_ADDRESS> (kube-system/csi-secrets-store-secrets-store-csi-driver-7tv46)
  <IP_ADDRESS> (health)
  <IP_ADDRESS> (ceph-csi-rbd/ceph-csi-rbd-provisioner-f875545b-mzvml)
  <IP_ADDRESS> (dc-debug/debian9-qj4vd)
BandwidthManager:       Disabled
Host Routing:           Legacy
Masquerading:           BPF   [br100, br705]   <IP_ADDRESS>/24 [IPv4: Enabled, IPv6: Disabled]
Clock Source for BPF:   ktime
Controller Status:      35/35 healthy
  Name                                  Last success    Last error   Count   Message
  cilium-health-ep                      13s ago         never        0       no error
  dns-garbage-collector-job             29s ago         never        0       no error
  endpoint-1211-regeneration-recovery   never           never        0       no error
  endpoint-1445-regeneration-recovery   never           never        0       no error
  endpoint-179-regeneration-recovery    never           never        0       no error
  endpoint-2476-regeneration-recovery   never           never        0       no error
  endpoint-2710-regeneration-recovery   never           never        0       no error
  endpoint-48-regeneration-recovery     never           never        0       no error
  endpoint-gc                           2m30s ago       never        0       no error
  k8s-heartbeat                         22s ago         never        0       no error
  mark-k8s-node-as-available            22h52m16s ago   never        0       no error
  metricsmap-bpf-prom-sync              6s ago          never        0       no error
  neighbor-table-refresh                2m16s ago       never        0       no error
  resolve-identity-1211                 2m15s ago       never        0       no error
  resolve-identity-1445                 2m15s ago       never        0       no error
  resolve-identity-179                  2m16s ago       never        0       no error
  resolve-identity-2476                 2m16s ago       never        0       no error
  resolve-identity-2710                 2m16s ago       never        0       no error
  resolve-identity-48                   2m15s ago       never        0       no error
  sync-endpoints-and-host-ips           14s ago         never        0       no error
  sync-lb-maps-with-k8s-services        22h52m16s ago   never        0       no error
  sync-policymap-1211                   7s ago          never        0       no error
  sync-policymap-1445                   7s ago          never        0       no error
  sync-policymap-179                    7s ago          never        0       no error
  sync-policymap-2476                   5s ago          never        0       no error
  sync-policymap-2710                   7s ago          never        0       no error
  sync-policymap-48                     7s ago          never        0       no error
  sync-to-k8s-ciliumendpoint (1211)     10s ago         never        0       no error
  sync-to-k8s-ciliumendpoint (1445)     10s ago         never        0       no error
  sync-to-k8s-ciliumendpoint (179)      10s ago         never        0       no error
  sync-to-k8s-ciliumendpoint (2476)     11s ago         never        0       no error
  sync-to-k8s-ciliumendpoint (2710)     10s ago         never        0       no error
  sync-to-k8s-ciliumendpoint (48)       9s ago          never        0       no error
  template-dir-watcher                  never           never        0       no error
  update-k8s-node-annotations           22h52m29s ago   never        0       no error
Proxy Status:   No managed proxy redirect
Hubble:         Ok   Current/Max Flows: 4095/4095 (100.00%), Flows/s: 7.21   Metrics: Ok
KubeProxyReplacement Details:
  Status:                Strict
  Socket LB Protocols:   TCP, UDP
  Devices:               br100 <IP_ADDRESS>, br705 <IP_ADDRESS> (Direct Routing)
  Mode:                  SNAT
  Backend Selection:     Random
  Session Affinity:      Enabled
  XDP Acceleration:      Disabled
  Services:
  - ClusterIP:      Enabled
  - NodePort:       Enabled (Range: 30000-32767)
  - LoadBalancer:   Enabled
  - externalIPs:    Enabled
  - HostPort:       Enabled
BPF Maps:   dynamic sizing: on (ratio: 0.002500)
  Name                          Size
  Non-TCP connection tracking   592286
  TCP connection tracking       1184572
  Endpoint policy               65535
  Events                        56
  IP cache                      512000
  IP masquerading agent         16384
  IPv4 fragmentation            8192
  IPv4 service                  65536
  IPv6 service                  65536
  IPv4 service backend          65536
  IPv6 service backend          65536
  IPv4 service reverse NAT      65536
  IPv6 service reverse NAT      65536
  Metrics                       1024
  NAT                           1184572
  Neighbor table                1184572
  Global policy                 16384
  Per endpoint policy           65536
  Session affinity              65536
  Signal                        56
  Sockmap                       65535
  Sock reverse NAT              592286
  Tunnel                        65536
Encryption:              Disabled
Cluster health:          3/3 reachable   (2022-04-07T09:22:39Z)
  Name                   IP              Node        Endpoints
  kub05n01 (localhost)   <IP_ADDRESS>      reachable   reachable
  kub05n02               <IP_ADDRESS>      reachable   reachable
  kub05n03               <IP_ADDRESS>      reachable   reachable

cilium bpf lb list for LoadBalancer IP :
<IP_ADDRESS>:80        <IP_ADDRESS>:0 (7) [ExternalIPs]
                     <IP_ADDRESS>:80 (7)
                     <IP_ADDRESS>:80 (7)
                     <IP_ADDRESS>:80 (7)
<IP_ADDRESS>:443       <IP_ADDRESS>:0 (8) [ExternalIPs]
                     <IP_ADDRESS>:443 (8)
                     <IP_ADDRESS>:443 (8)
                     <IP_ADDRESS>:443 (8)

kubectl get pod -o wide:
NAME                                      READY   STATUS    RESTARTS      AGE   IP            NODE       NOMINATED NODE   READINESS GATES
nginx-proxy-deployment-7f9554bfbf-c7dt9   2/2     Running   2 (22h ago)   23h   <IP_ADDRESS>   kub05n03   <none>           <none>
nginx-proxy-deployment-7f9554bfbf-gvv7p   2/2     Running   2 (22h ago)   25h   <IP_ADDRESS>   kub05n03   <none>           <none>
nginx-proxy-deployment-7f9554bfbf-gz5sc   2/2     Running   2 (23h ago)   44h   <IP_ADDRESS>    kub05n02   <none>           <none>

kubectl describe service:
Name:                     nginx-proxy
Namespace:                wildcard-test
Labels:                   app.kubernetes.io/managed-by=Helm
Annotations:              field.cattle.io/publicEndpoints:
                            [{"addresses":["<IP_ADDRESS>"],"port":80,"protocol":"TCP","serviceName":"wildcard-test:nginx-proxy","allNodes":false},{"addresses":["172.17....
                          meta.helm.sh/release-name: wildcard-test
                          meta.helm.sh/release-namespace: wildcard-test
                          metallb.universe.tf/address-pool: wildcard-vlan100
Selector:                 app=nginx-proxy
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       <IP_ADDRESS>
IPs:                      <IP_ADDRESS>
External IPs:             <IP_ADDRESS>
LoadBalancer Ingress:     <IP_ADDRESS>
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  30372/TCP
Endpoints:                <IP_ADDRESS>:80,<IP_ADDRESS>:80,<IP_ADDRESS>:80
Port:                     https  443/TCP
TargetPort:               443/TCP
NodePort:                 https  30325/TCP
Endpoints:                <IP_ADDRESS>:443,<IP_ADDRESS>:443,<IP_ADDRESS>:443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

MetalLb configuration:
NAME                                      READY   STATUS    RESTARTS      AGE
pod/metallb-controller-69bbb4669c-mmw5z   1/1     Running   1 (23h ago)   23h
pod/metallb-speaker-kmppg                 1/1     Running   3 (22h ago)   21d
pod/metallb-speaker-r6dnq                 1/1     Running   2 (22h ago)   21d
pod/metallb-speaker-xhcsr                 1/1     Running   2 (23h ago)   21d

NAME                             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/metallb-speaker   3         3         3       3            3           kubernetes.io/os=linux   21d

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/metallb-controller   1/1     1            1           21d

NAME                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/metallb-controller-69bbb4669c   1         1         1       21d

metallb configmap:
kubectl describe cm metallb
Name:         metallb
Namespace:    metallb-system
Labels:       app.kubernetes.io/instance=metallb
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=metallb
              app.kubernetes.io/version=v0.12.1
              helm.sh/chart=metallb-0.12.1
Annotations:  meta.helm.sh/release-name: metallb
              meta.helm.sh/release-namespace: metallb-system

Data
====
config:
----
address-pools:
- addresses:
  - <IP_ADDRESS>/32
  auto-assign: false
  name: ingress-internal
  protocol: layer2
- addresses:
  - <IP_ADDRESS>/32
  auto-assign: false
  name: wildcard-vlan100
  protocol: layer2

And issue - Nginx logs has  Allocated addresses: <IP_ADDRESS> (router) expected  as my real IP:
nginx-proxy-deployment-7f9554bfbf-gvv7p nginx-proxy <IP_ADDRESS> - - [07/Apr/2022:11:30:23 +0200] "GET / HTTP/2.0" 200 181731 "-" "curl/7.68.0"

If i change service to External Traffic Policy: Local i have my real IP.

KubeProxyReplacement Details:
Status:                Strict
Socket LB Protocols:   TCP, UDP
Devices:               br100 <IP_ADDRESS>, br705 <IP_ADDRESS> (Direct Routing)
Mode:                  SNAT

You are not using DSR according to your cilium status output. It should state Mode: DSR. Did you restart the Cilium pods after enabling DSR?

Thanks! All works! How you thinks,  RKE2 after deploy new HelmChartConfig should restart pods?