Fix props and debug methods for SFCs

to: @ljharb
cc: @ryanalane
This is essentially a copy of #220 . (There's a line or two different and that PR currently has conflicts).
Apologies to @ryanalane for stealing his git thunder :/
Fixes #134
Closes #220

LGTM

@lelandrichardson No problem! Just glad the work was helpful. :)


MariaDB support

Is MariaDB supported? Any reason not to add a mention of it to the README?

Hi.
We fully support MySQL protocol, so I believe we support MariaDB, as well as TiDB or any other DB using MySQL protocol. Indeed I referred to MariaDB's documentation for many protocol details. I would like to add to README about this feature.

Thanks, I suggested now to add "MySQL protocol supports MariaDB, MySQL, TiDB and others" to README with this PR: https://github.com/sogou/workflow/pull/1633


Fix capability support

Three vendor prefixed capabilities were marked as N/A when they should have been marked as supported.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/webdriver.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


How can we get nvidia hook to work with CRI-O.

@flx42 We would like to work with you to get your runc hook to work with CRI-O.
CRI-O reads a configuration file for each hook in
/usr/share/containers/oci/hooks.d
Here is a couple of examples of hooks.  The first one only runs if the container has bind mounts and only runs during the prestart phase.
# cat /usr/share/containers/oci/hooks.d/oci-umount.json
{
    "hasbindmounts": true,
    "hook": "/usr/libexec/oci/hooks.d/oci-umount",
    "stages": [ "prestart" ]
}

oci-register-machine only runs if the cmd matches the regex, and runs in the prestart and poststop section.
#: cat /usr/share/containers/oci/hooks.d/oci-register-machine.json
{
    "cmd": [".*/init$" , ".*/systemd$" ],
    "hook": "/usr/libexec/oci/hooks.d/oci-register-machine",
    "stages": [ "prestart", "poststop" ]
}

We also support regex on Annotations.

Hello @rhatdan,
First of all, your version of runc needs this commit: https://github.com/opencontainers/runc/commit/d7c264aaf1f655a64baa981d2d0bf7a78e4f50d9
If that's the case, you can simply use the binary nvidia-container-runtime-hook as a prestart hook.
This hook is shipped by our nvidia-container-runtime package. The instructions to setup the repo are here: https://nvidia.github.io/nvidia-container-runtime/

By the way, our hook detects if it has anything to do by checking the environment variables of the container.
If the container doesn't have NVIDIA_VISIBLE_DEVICES set, our hook will be no-op.

First of all, your version of runc needs this commit: opencontainers/runc@d7c264a

yup, the runc we use does have that!

I think regex on annotations would be even better, but I don't think we have a way to bake that into our base CUDA images on DockerHub. Dockerfiles labels are not transformed to annotations as far as I know.

Off-topic sorry, but what's your take on this comment? We created our hook to be compatible with runc, docker and CRI-O.

Our goal is to not run the hook at all if at all possible.  Since this hurts our performance.  I guess we could extend the hook checking code to look for environment variables being set,  Then you could add a regex to the config to tell us whether we should run them or not.
The Projectatomic/Docker package that we currently use in OpenShift just launches all hooks stored in a certain directory but we wanted to be smarter about that to improve our performance numbers, especially when the hook is only required for certain container images.
@mrunalp Could you examine the comment linked above.  I think Docker engineers view hooks differently then we do.  I believe there are use cases for both types of hooks.  But I forget the arguments.

Totally agree with the performance argument. But let's make sure it works as expected first :)
Then, we can either try to add annotations to our images (but will prevent users from bringing custom images), or filter on environment variables.
cc @3XX0

I think if you drop a config with something like
cat /usr/share/containers/oci/hooks.d/nvidia.json
{
    "cmd": [".*"],
    "hook": "/PATHTO/nvidahook",
    "stages": [ "prestart", "poststop" ]
}

Then CRI-O will run the hook in the prestart and poststop.  Not sure if you want it in both places.

We only need prestart. Do you need help in testing that? I haven't tried to setup CRI-O yet, so if you do have a machine with GPUs, it might be quicker for you to test it.

No I don't have the hardware to actually test it out.  I just wanted to point out how easy it would be to get it to work with CRI-O.  Please send me an email<EMAIL_ADDRESS>we can talk about this more via email.

My bad, I should have followed up earlier.
As @flx42 said, annotation filtering won't be useful with Docker since they decided not to convert LABEL to annotations. If you could support environment filtering as well that would be great

As @flx42 said, annotation filtering won't be useful with Docker since they decided not to convert LABEL to annotations. If you could support environment filtering as well that would be great

so you want to take LABEL(s) from images and set them as Kube annotation? we can easily do that

It would work too, but we were actually planning to deprecate our existing labels.
What do you think @3XX0?

Wait what are we talking about exactly :)

OCI annotations
CRI annotations
CRI labels
Docker labels

We could keep one label in our images but it should be something that users can easily add to their custom image or specify on the K8s command line

@flx42 We use hooks a lot and think that they are useful. create/start could be useful in some cases but one needs to evaluate what they are doing as the state of the container when viewed from a OCI hook vs something run in between create/start is different. Hooks could modify more things than what one could after runc create.

Currently, the undocumented (?) behavior is that the hook stage (prestart, poststart or poststop) is passed as argv[1].

This was also fixed with #1244, which now uses a stage environment variable.  The variable is still undocumented (I can file updated docs once #1355 lands), but moving it out of the arguments solves your issue.  Is there anything left to do here?  I think we can close this issue.

Hooks could modify more things than what one could after runc create.

Just to push back on this issue, I don't think there's anything that you can do in a hook that you couldn't do directly from crio taking advantage of the create / start split.  The benefit of hooks in general is that it's easy for callers to provide their own external executables.  It shouldn't matter if crio is running those executables itself at the proper times or delegating their execution to the runtime.  You could also support this sort of pluggable behavior with dynamic linking (or a hook-server API, etc., etc.); that would save the separate-hook-process overhead but be more complicated for callers to setup.

Is there anything left to do here? I think we can close this issue.

@RenaudWasTaken did you test with this patch? Can we close?

The variable is still undocumented (I can file updated docs once #1355 lands)…

To follow up on this point, I don't think we need the environment variable at all (#1360).  That shouldn't affect the Nvidia hook though, since you only inject it in pre-start.

If nvidea is checking for the environment variable then it could cause it to break.
https://github.com/projectatomic/oci-register-machine
https://github.com/projectatomic/oci-systemd-hook
https://github.com/projectatomic/oci-umount
Are the others that would need updating that I know about.

So the hooks actually work in 1.9
However, with master + PR #1345 the behavior seem to have changed I end up with the following error from the nvidia-hook:
starting container process caused "process_linux.go:348: container init caused \"process_linux.go:331: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: exec command: [/usr/bin/nvidia-container-cli --load-kmods configure<EMAIL_ADDRESS>--device=all --utility --compute --pid=31877 /var/lib/containers/storage/devicemapper/mnt/6d36db25c65b1fdde0a482c36b775627501a8968df6d5eb55ba43e8a466d2059/rootfs]\\\\nnvidia-container-cli: detection error: environment variable PATH not found\\\\n\\\"\""

@flx42 suggested that I add export PATH=/usr/sbin:/usr/bin:/sbin:/bin in the shell wrapper that I use but I'm a bit surprised by this behavior change.
My wrapper being a simple (btw I had to change nvidia-container-runtime to /usr/bin/nvidia-container-runtime-hook since the path wasn't set):
#! /bin/sh
/usr/bin/nvidia-container-runtime-hook -prestart

@wking @rhatdan do you know what might have changed that behavior?

… environment variable PATH not found…

My guess is that runc is just copying Env over to Go's Cmd and that Go uses the host environment if Env is nil.  I think that's a bug on runc's part (although the spec isn't clear enough to say for sure), but the change is due to the stage Env setting.  #1360 should return you to the old environment inheritance, at least until runc is patched to fix it ;).
I agree that you should set PATH explicitly if you need it.

Our hook now uses a default value for PATH: https://github.com/NVIDIA/nvidia-container-runtime/commit/95bc87201387845446d6d83b7c7815b348e2a92c

#1360 should return you to the old environment inheritance, at least until runc is patched to fix it ;).

opencontainers/runc#1738 is the patch removing the environment leakage you used to rely on.

@flx42 This issue is fixed for you now correct?

I think so, @RenaudWasTaken?

Last time I tested it that was good.
Is there a code freeze so that we can make sure there wasn't any regression?
I think we should also discuss if and how we can introduce some testing to
prevent future regressions.
Renaud Gaubert

Well we are running CRI-O v1.9.10 in production right now on OpenShift Online.  Our plan is to ship it in OpenShift 3.9 release which is coming in April I believe.  But we are pretty much frozen now, only bugfixes.

anything left from this issue? @RenaudWasTaken @flx42 @3XX0


Remove dependency on bootstrap

Handling of column metadata can basically stay the same, but implementing it by hand removes a lot of uneccessary stuff.

This is actually not necessary as bootstrap provides a css file with only the layouting rules.


Change return value of Keccak builtin's new

Change return value of Keccak builtin's new
Description
It was previously a Result<Self, RunnerError>, even though it could never return an Err value. This PR changes it to Self.
Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

Codecov Report

Merging #648 (b4438a9) into main (fd7edb4) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #648      +/-   ##
==========================================
- Coverage   93.70%   93.70%   -0.01%
==========================================
  Files          63       63
  Lines        4624     4622       -2
==========================================
- Hits         4333     4331       -2
  Misses        291      291

Impacted Files
Coverage Δ

src/vm/runners/builtin_runner/mod.rs
83.63% <ø> (ø)

src/vm/runners/builtin_runner/keccak.rs
82.14% <100.00%> (-0.32%)
:arrow_down:

src/vm/runners/cairo_runner.rs
94.54% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


feat: ensure version of podman desktop is >=1.8.0

We currently have no mechanism ensuring the extension is running in version of podman desktop above 1.8.0. We are using a lot of specific apis which are only available in version 1.8.x.
We need to have a basic check ensuring the requirements are met.

Extension container files typically have io.podman-desktop.api.version=">= 1.8.0" (AI Lab says >=1.7.0) and package.jsons list API dependencies. Shouldn't we have one path and solve this once in Podman Desktop vs every extension being loaded and having to put in a check?

to me it's a nice thing (not the recommended one) as even if we add that check in Podman Desktop like 1.10 people might try the extension on previous versions of Podman Desktop that doesn't implement the check
it's like a quick win.


As a user, I want the system to conduct integrated testing for user authentication and database storage so that I can trust that my data is handled securely and access to my account is reliable.

Verified that user profiles and account preferences is accurately maintained.

Tested the storage and retrieval of user data, ensuring data is correctly saved and retrieved


Host Own Nominatim Server (oldtitle: Adherence to nominatim usage policy)

Amongst others, the Nominatim usage policy lists auto-complete search as unnacceptable usage. also it states a hard limit of one request per second. We should also send some sort of ID identifying it as use by matchat.org.
related to #1095
child of #2820

@ waffle discussion column tagging: what's the question to be discussed here? :)
(this is design work that's open imo)
if the question is whether or not we should (given time) then that's a definitive yes. ultimatively we won't get around running our own services for that :)

Right now, we're not adhering to the usage policy at all, which means that nominatim might block us eventually. (auto-completing search, more than 1 request/second). I'm not convinced that we can adhere to the policy without big changes, it probably would be easier to run our own instance as @m0ru suggested.
Nominatim suggests https://geocoder.opencagedata.com and https://locationiq.com as alternative providers. As far as I can tell, both impose the 1 request/second limit on free accounts, which means that we would need to get a paid subscription if we want to keep searching for locations reasonably responsive.

@fkleedorfer does it seem reasonable for us to run a Nominatim instance in the future? If  so I would move this to "soon" or "later", if not we should debate different options or close this and create a new issue to "find ways to adhere to Nominatim usage policies"

Let's look into hosting the data and see how much time we spend doing that

moved to internal kanban board


Update library to support Swift 3.0

Updated the syntax to compile with Swift 3.0 (snapshot 12-4).

Also, I can't see the test results and hence can't see what's wrong.

Yep the CI server runs swift 2.2 which is why it breaks :)
I just created a "swift3" branch to merge your PR, please create another one on that branch :)
Thanks!


SNATed "need to frag" ICMP packet doesn't get forwarded to pod

Bug report

Assuming Pod A on Node A tries to send a packet of size 1450 to Node B and the network path is:
Pod A (MTU 1500) -> Node A (MTU 1500) -> Switch X (MTU 1420) -> Node B (MTU 1500)

Switch X would drop this packet and send back an ICMP packet saying "need to frag (mtu 1420)".
There are two issues with Cilium 1.8.2:

Cilium would drop the ICMP packet as invalid packet (https://github.com/cilium/cilium/issues/12854). Using brb0/cilium:skb-pull-v0 image mentioned by https://github.com/cilium/cilium/issues/12854#issuecomment-675569188 could work around this issue.

With the above issue worked around, the ICMP packet can be sent to Node A, but Cilium still doesn't forward it to Pod A. As a result, Pod A doesn't know it needs to fragment the packet of size 1450 and keeps retransmitting it, while Switch X keeps dropping it.

General Information

Cilium version (run cilium version)

The brb0/cilium:skb-pull-v0 image mentioned by https://github.com/cilium/cilium/issues/12854#issuecomment-675569188
Client: 1.8.90 f0e584d92 2020-08-14T12:33:50+02:00 go version go1.15 linux/amd64
Daemon: 1.8.90 f0e584d92 2020-08-14T12:33:50+02:00 go version go1.15 linux/amd64

Kernel version (run uname -a)

5.4.19

Orchestration system version in use (e.g. kubectl version, Mesos, ...)

v1.17.9

Link to relevant artifacts (policies, deployments scripts, ...)

deployment yaml

How to reproduce the issue
Construct a network scenario described in the above problem description to reproduce.

https://github.com/cilium/cilium/issues/12854#issuecomment-675088907

BTW, I'm using AWS VM.
# ethtool -i eth0
driver: ena
version: 2.1.0K
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Per the comment [1] in the issue you've called out, the reporter was using a certain NIC that led to drops. Also, the issue has been fixed in latest.
Did you run cilium monitor to see where exactly the drops were happening in your setup?
[1] https://github.com/cilium/cilium/issues/12854#issuecomment-675088907

Per the comment [1] in the issue you've called out, the reporter was using a certain NIC that led to drops. Also, the issue has been fixed in latest.
Did you run cilium monitor to see where exactly the drops were happening in your setup?
[1] #12854 (comment)

I'm already using the image with the fix mentioned in  #12854 .
Using Cilium 1.8.2, I can see the ICMP drop as invalid packet with cilium monitor. Using brb0/cilium:skb-pull-v0 image mentioned by https://github.com/cilium/cilium/issues/12854#issuecomment-675569188, I don't see any drop with cilium monitor, but the ICMP packet for "need to frag" still doesn't get forwarded to the Pod.

@qingkunl Can you run cilium monitor -t drop to validate that cilium is actually dropping the "need to frag" ICMP messages?

@qingkunl Can you run cilium monitor -t drop to validate that cilium is actually dropping the "need to frag" ICMP messages?

I don't see cilium drop anything, and I can confirm the "need to frag" ICMP messages received by the host with tcpdump -i eth0 icmp -nn. However, I don't see the "need to frag" ICMP messages in the Pod with tcpdump -i any icmp -nn. Any idea to check where it's dropped?

Did the ICMP packet had the dest IP addr == pod IP?

Did the ICMP packet had the dest IP addr == pod IP?

The dest IP is the node IP, which makes sense because the Pod packet is SNAT'ed when going out of the node. There should be some way to track the connection and forward the packet to Pod, like other SNAT Pod traffics.

OK, I see. Unfortunately, such functionality is not implemented in Cilium, but we would happily consider a PR with such additions.

This is still an issue

/remove-lifecycle stale

/remove-lifecycle stale

OK, I see. Unfortunately, such functionality is not implemented in Cilium, but we would happily consider a PR with such additions.

I will take the leads on it. Thanks.


excalidraw.com does not display anything on Safari for macOS

Hello,
I encountered an issue while attempting to access excalidraw.com using Safari. The website only displays a white page, with no content visible. However, the site functions correctly on Google Chrome.
System specifications:
macOS Ventura 13.3.1 (arm64)
Safari Version 16.4
Lockdown Mode: On
Could you please provide guidance on how to resolve this issue?
Thank you for your help.

Hi. Can you test without lockdown mode?

Unfortunately, I'm not able to.

Hey, @godrays if you're not able to find out how to turn off Lockdown mode on Mac, then try the following steps:

Choose the Apple menu  > System Settings.
From the sidebar, click Privacy & Security.
Scroll down to Lockdown Mode, then click Turn Off.
If prompted, enter the user password.
Click Turn Off & Restart.

Hi @Veer0x1,
I know how to turn it off definitely but I'm not allowed due to security restrictions.
Maybe someone else can try it here. I don't have a machine to try it.

unfortunately we don't have access to a device with lockdown mode to test on. Can you open the devtools console (opt-cmd-I) and check if there are any errors when you load excalidraw.com? 🙏

@godrays in fact, Safari 17 seems to disable IndexDB when being used in lockdown mode.
Apparently, you are able to "trust" websites and exclude them from the lockdown restrictions of Safari (or, more precisely, Webkit): https://support.apple.com/en-us/105120
Hopefully, this answer helps you. ^^


fix custom.scss path

just a minor fix in the config page.
and using this as an opportunity to say a huge thank you for creating this lovely thing! :heart:
that's exactly what I was looking for!
(the only caveat is that we can't use [[wikilinks]], but all the other advantages makes it tollerable :slightly_smiling_face:)

Thanks for the fix :)) Looking to support wiki-links at some point in the near future!!


docker log  was showing errors

I'm pretty sure they were coming from these copy commands.  It's OK that
these logs don't exist, so I piped stderr to /dev/null.
And, "mv" can be more efficient than "cp;rm".
And, mkdir -p could create /opt/vertica/config, so move it before the mv
And, chmod 755 is wrong for non-executables.  Instead add 644 to perms

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


⚠ Samsung has degraded performance

In 5212418, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2535 ms

Resolved: Samsung performance has improved in 006a713.


Hybrid Mode MVP

There are 3 main parts that will work together to make hybrid work.

Fn Server (API)
Fn LB
Fn Runners/Workers

At a high level, they interact like this:

Control Plane

Work Plane

Fn Server
←
Fn LB(s)

↓
↑
↓

Database
←
Fn Runner(s)

MQ

↓

Blob Store

?Blob Store

Where everything in the Work Plane talks to the Fn Server to tell it what to do.
As a bare minimum starting point, we should have 3 containers that we can run like this:
Start Control Plane:
docker run ... fnproject/fnserver

Start Work Plane
docker run ... fnproject/fnlb
docker run .... fnproject/fnrunner

Fn Server
This probably doesn't really have to change much except:

[ ] flag to disable async processing
[ ] new API endpoints to support below

Fn LB

[ ] allow runners to register themselves (simple API on LB)

Runners

When fnrunner starts, it will:

[ ] register itself with the fnlb
[ ] start asking the fnserver for async alls

For each call it gets, it will:

[x] execute call
[ ] report status to fnserver
[ ] send logs to fnserver (this could store logs in local blob store, but for first attempt, let's assume this isn't the case)

allow runners to register themselves (how to do this with multiple LBs running?)

it's backed by a db. just start lb with DB_URL=... same as server, supports mysql/pg.

new API endpoints to support below

I have a sketched out design doc for this api for fn server that I think will work & be simple, i can try to put it into something more palatable. was attempting to add reasonable MQ semantics at the same time, but it's possible we could/should punt this.

Am i right in thinking: async will  go :
Outside -> (0: push)  FnLB -> (1: push)  Server->  (2: push) MQ -> (3: (poss via API) pull) runner
If so then  direct MQ is a good start for 3 and then wrap in an API once that works I think

That sounds about right.  I don't think we'd want runner to directly access MQ though, would add another layer of authentication and what not that we'd have to think about. Runner should be pretty dumb for the most part and just get work (sync) or ask for work (async), run it, report results, that's basically all it should think about. And hopefully just talk to one thing.
In fact, we used to have a/tasks endpoint that already did this via the API, but I think it got removed in the recent gutting of core.

runner will also have to post work, for async. async requests will come in through the same lb as sync (in front of 'runners'), presumably. agree about direct access, shouldn't be too bad to proxy through api nodes.

Fnlb ... ?? (i know there's more to this)

I don't think so. the lb just needs to know about the set of nodes. in theory, in our k8s config somewhere, there is a hook we can call when we add a new 'runner' pod that calls the lb address to add itself, so the lb is mostly an operational task at this point. imo, we should just do authentication at the 'runner' level, not the lb level, to keep the lb from getting gummed up (in 2+ ways).

?Blob Store

it would be nice initially to have all data storage on the LHS of this dia. then the runner is just sending all data to the LHS api and doesn't have to worry about straddling 2+ things for certain things. I am still optimistic that nobody will want this entire hybrid deal and this will just be a pony show [and the log placement won't just be a line item].

I wonder if we could move async processing completely to RHS. Currently, control-plane is not really %100 control plane as it's in async processing path... We should be able to modify app/routes regardless of the load on the front door. (eg. MQ and call logs/status storage on RHS side versus mostly-read-only config DB on LHS.)

@skinowski one of the main objectives of all this is to keep the database and what not on the LHS so we/users don't have to maintain multiple databases/mqs/obstores.

MQ and call logs/status storage on RHS side versus mostly-read-only config DB on LHS.)

yea, it would be nice. if we could do this then we wouldn't need hybrid at all (and we could all be happy) and it would work the way we intended like it is now. we're putting that stuff on LHS mostly so that we only have to operate 1 version of it, in our own tenancy, and not in multiple customer tenancies. i.e. if we put MQ on RHS we would need N MQ's -- the diagram here lacks this context, but I am sure we have something (I'll link in non-public place).

@rdallman @treeder's comment clarified it. :-)  It makes sense now. And yes, I was thinking either N MQs (or perhaps isolated N topics) for each customer assuming that operational costs were manageable.

I'm going to make a start on this, namely the part

flag to disable async processing

First, running two instances of the fn server pointing at the same redis instance.
Then I'll add a flag so that one of them only serves requests to invoke asynchronous functions on /r (so it puts the request on the queue), and the other serves both synchronous requests and pulls requests from the queue.

should have a doc written up tomorrow of API design, would be great to split up work and get your thoughts (kafka & api implementation & testing & auth) @msgodf -- disabling async we do need, thanks!

@msgodf @skinowski I've started a doc here https://github.com/fnproject/fn/blob/hybrid-api/docs/developers/hybrid.md based on discussion today (in the flesh), feedback appreciated. But overall, pretty lightweight. mostly, we need to do some kafka reading. sync is really easy.

Shoud the /runner/... endpoints be api-versioned too, i.e. /runner/v1/...?

It's not clear to me how the partitions/topics are expected map to runners. Partitions are (essentially) static - which is to say there's an async process for expanding the number of partitions a topic has, but that expansion can take seconds. (Brokers also have a number of FDs open per partition they're handling.)
Additionally, the API nodes are the kafka consumers in this picture. If they're in the same consumer group then you may want as many partitions as API nodes (or some reasonably larger number) to balance load across API nodes.
However, using the runner node (or something derived from it) as a partition key means that the work will land in some partition. There's no guarantee that a (k8s) load-balanced call from any particular runner will land on an API node whose consumer is handling the partition associated with that runner. (In the extreme case, if there are more API nodes than partitions, it's possible that an API node will be "starved" and have no work to deliver.)
I think the expected model with kafka is also that topics are relatively static; the way the broker works, it doesn't sound like a topic per (app, route) combo is workable either.

It's possible that a particular kafka Consumer knows which partitions are in the set that are currently bound to it. The ConsumerGroup rebalance is another "eventual" kind of operation, but one option is for API nodes to gossip amongst themselves so that they know where a partition is being served from, then internally proxy a request for (partition X) from one API node to the one that owns its partition.

I am worried that there are layers between the runner nodes on the RHS, which have the information about what hot containers are running and therefore would prefer to dequeue a job that fits (because it would be efficient), and the MQ partitions on the LHS which could be partitioned with the same criteria for efficiency. Along the way, we don't just have the fn LB, there's likely to to be an OCI LB and a Kube service LB which could shuffle requests inefficiently because they don't know about the partitioning information. Basically, our final LB would have to undo the work that the OCI LB and the Kube LB have done.
The question is whether the partition-aware strategy that has to undo the OCI/Kube LBs distribution is really more efficient than a naive non-partition-aware pulling of jobs from any node, or whether the redirections at the last layer (where a request hits a pod which says "no, I'm not the right one, go there instead") add enough latency that statistically it's not worth the effort of doing it when the numbers are big. Also, when a user enqueues an async job, how much do they care about latency is another open question.
I don't know the answers, but I feel that not worrying about partitions at this stage makes the implementation simpler, and it can also be iteratively improved when we do have the data to determine the efficiency answer. :)

I don't know the answers, but I feel that not worrying about partitions at this stage makes the implementation simpler, and it can also be iteratively improved when we do have the data to determine the efficiency answer. :)

I wish this were possible, kafka does not seem to have any 'easy' way to provide MPMC semantics without thinking about partitioning. We need to have someway to have 1 process chewing on a partition, we can't just let every request ask a queue for the head (this has pros and cons, not having to worry about timeouts sounds... delightful). Initial thinking was that API nodes would have their own partition and be part of a consumer group, and this seems like the naive approach that would likely work but has at least one deficiency in that we lose distribution information for RHS processing. The thinking is that, there are likely a small set of API nodes and a large set of runner nodes, and we want a runner node to process some subset of calls so that we can re-use hot containers, image caching (the same reasons we have fnlb for sync). Can think about other ways to accomplish this.
The complication of the k8s / round-robin load balancer in the middle is something that didn't come to mind (thanks for pointing it out). It's kind of unfortunate that we have to proxy runner nodes over to the LHS to talk to kafka, in a 'normal' (non-hybrid) deployment runners (full fn servers) getting their own partition seems like it would work just fine (maybe optimal, even). It seems brittle to rely on having a 'sticky' (vs. round robin, et al) load balancer in between RHS and LHS so that kafka clients will work, but it seems like it would maybe close this hole? since this API is hanging off on the side we could open a long lived connection between an API node and a runner node so that 1 API node could serve a runner's partition to it. this is kind of smelly, need to marinate on this a bit.
Not completely bent on having a partition per runner, the main sticking point is the distribution, but even if we have a partition per API node we have an issue of routing a msg.Commit() (increment partition offset) to an API node where the consumer for that partition is available. :(

Partitions are (essentially) static - which is to say there's an async process for expanding the number of partitions a topic has, but that expansion can take seconds.

This sounds edible, we expect that the set of runners is scaling up and down but relatively infrequently (likely 10s of minutes). Not sure how well consumer groups will adapt to this, possibly a bad idea. API nodes will be less elastic and may make a better candidate.

Shoud the /runner/... endpoints be api-versioned too, i.e. /runner/v1/...?

/v1/runner makes sense, API nodes serve all /v1/ endpoints so it's uniform. good catch, thanks.

There are some other complications with effectively pre-assigning a task to a runner-oriented partition. There is no easy way to manage work stealing in that scenario -  runnner A might be busy for a long time, runner B (which favours the same hot set) free; but there's not an easy way to land the work there.
(If the intent is that the FNLB assigns an async task to a runner with the view that that work will be scheduled soon, then we'll need a way to ensure that capacity for it is reserved.)
You mentioned timeouts. The other question revolves around async work that turns up with a deadline. If that is fast approaching then the Call's "priority" for placement should rise, I presume.
Simple queues (especially under the constraint that multiplying topics or partitions is expensive) don't feel like a great fit here.
-- Excuse typos. Phone screens don't make great ketbroads.
-------- Original message --------
From: Reed Allman<EMAIL_ADDRESS>Date: 01/12/2017  6:17 p.m.  (GMT+00:00)
To: fnproject/fn<EMAIL_ADDRESS>Cc: jan grant<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [fnproject/fn] Hybrid Mode MVP (#531)
I don't know the answers, but I feel that not worrying about partitions at this stage makes the implementation simpler, and it can also be iteratively improved when we do have the data to determine the efficiency answer. :)
I wish this were possible, kafka does not seem to have any 'easy' way to provide MPMC semantics without thinking about partitioning. We need to have someway to have 1 process chewing on a partition, we can't just let every request ask a queue for the head (this has pros and cons, not having to worry about timeouts sounds... delightful). Initial thinking was that API nodes would have their own partition and be part of a consumer group, and this seems like the naive approach that would likely work but has at least one deficiency in that we lose distribution information for RHS processing. The thinking is that, there are likely a small set of API nodes and a large set of runner nodes, and we want a runner node to process some subset of calls so that we can re-use hot containers, image caching (the same reasons we have fnlb for sync). Can think about other ways to accomplish this.
The complication of the k8s / round-robin load balancer in the middle is something that didn't come to mind (thanks for pointing it out). It's kind of unfortunate that we have to proxy runner nodes over to the LHS to talk to kafka, in a 'normal' (non-hybrid) deployment runners (full fn servers) getting their own partition seems like it would work just fine (maybe optimal, even). It seems brittle to rely on having a 'sticky' (vs. round robin, et al) load balancer in between RHS and LHS so that kafka clients will work, but it seems like it would maybe close this hole? since this API is hanging off on the side we could open a long lived connection between an API node and a runner node so that 1 API node could serve a runner's partition to it. this is kind of smelly, need to marinate on this a bit.
Not completely bent on having a partition per runner, the main sticking point is the distribution, but even if we have a partition per API node we have an issue of routing a msg.Commit() (increment partition offset) to an API node where the consumer for that partition is available. :(
Partitions are (essentially) static - which is to say there's an async process for expanding the number of partitions a topic has, but that expansion can take seconds.
This sounds edible, we expect that the set of runners is scaling up and down but relatively infrequently (likely 10s of minutes). Not sure how well consumer groups will adapt to this, possibly a bad idea. API nodes will be less elastic and may make a better candidate.
Shoud the /runner/... endpoints be api-versioned too, i.e. /runner/v1/...?
/v1/runner makes sense, API nodes serve all /v1/ endpoints so it's uniform. good catch, thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/fnproject/fn","title":"fnproject/fn","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/fnproject/fn"}},"updates":{"snippets":[{"icon":"PERSON","message":"@rdallman in #531: \u003e I don't know the answers, but I feel that not worrying about partitions at this stage makes the implementation simpler, and it can also be iteratively improved when we do have the data to determine the efficiency answer. :)\r\n\r\nI wish this were possible, kafka does not seem to have any 'easy' way to provide MPMC semantics without thinking about partitioning. We need to have someway to have 1 process chewing on a partition, we can't just let every request ask a queue for the head (this has pros and cons, not having to worry about timeouts sounds... delightful). Initial thinking was that API nodes would have their own partition and be part of a consumer group, and this seems like the naive approach that would likely work but has at least one deficiency in that we lose distribution information for RHS processing. The thinking is that, there are likely a small set of API nodes and a large set of runner nodes, and we want a runner node to process some subset of calls so that we can re-use hot containers, image caching (the same reasons we have fnlb for sync). Can think about other ways to accomplish this.\r\n\r\nThe complication of the k8s / round-robin load balancer in the middle is something that didn't come to mind (thanks for pointing it out). It's kind of unfortunate that we have to proxy runner nodes over to the LHS to talk to kafka, in a 'normal' (non-hybrid) deployment runners (full fn servers) getting their own partition seems like it would work just fine (maybe optimal, even). It seems brittle to rely on having a 'sticky' (vs. round robin, et al) load balancer in between RHS and LHS so that kafka clients will work, but it seems like it would maybe close this hole? since this API is hanging off on the side we could open a long lived connection between an API node and a runner node so that 1 API node could serve a runner's partition to it. this is kind of smelly, need to marinate on this a bit.\r\n\r\nNot completely bent on having a partition per runner, the main sticking point is the distribution, but even if we have a partition per API node we have an issue of routing a msg.Commit() (increment partition offset) to an API node where the consumer for that partition is available. :(\r\n\r\n\u003e Partitions are (essentially) static - which is to say there's an async process for expanding the number of partitions a topic has, but that expansion can take seconds. \r\n\r\nThis sounds edible, we expect that the set of runners is scaling up and down but relatively infrequently (likely 10s of minutes). Not sure how well consumer groups will adapt to this, possibly a bad idea. API nodes will be less elastic and may make a better candidate. \r\n\r\n\u003e Shoud the /runner/... endpoints be api-versioned too, i.e. /runner/v1/...?\r\n\r\n/v1/runner makes sense, API nodes serve all /v1/ endpoints so it's uniform. good catch, thanks."}],"action":{"name":"View Issue","url":"https://github.com/fnproject/fn/issues/531#issuecomment-348568462"}}}

The other question revolves around async work that turns up with a deadline. If that is fast approaching then the Call's "priority" for placement should rise, I presume.

I am game to not have an idea of a deadline, as I may have interpreted this. I am somewhat concerned about the fact that we effectively need to implement real-timestamp-based priority queueing, but optimistic that we can use kafka's offsets as timestamps, to achieve delayed messages (I'm not sure this is the same as deadline? i.e. run this call at this time in the future X?), and even then I don't think we can possibly make any guarantees about the immediacy of running that; it'll be in line with anything else that came in and was scheduled to run before that time X. As far as priorities, our redis implementation has these but only uses p0. I would like to avoid adding explicit [p0,p1,p2] priorities to start (and forever, if we're being honest) since I think it's going to be quite a bit of work just to get one priority in.

There is no easy way to manage work stealing in that scenario

yep, agree. as proposed it is very optimistic that the node that enqueued it was routed to because it has enough room to run it once that is eventually dequeued, which may be very far in the future.
figuring out how to map a message that a runner has received from an API node to a request to delete that message to the same API node is still kind of what I'm stuck on. Even if all API nodes stay healthy, it seems like we're really fighting the kafka client semantics here. Apparently, they have an http gateway that you can stick in front of kafka to make it so consumers / producers can be less precise about exact positioning of messages wrt partitions, maybe this is the route we need to go down but damn, turtles. for reference: https://github.com/confluentinc/kafka-rest

On a different tack: if nobody picks up the runner to lb registration I'll do that on Monday (following the idea of a k8s Grouper; we already have a REST interface for manual poking into allGrouper).
-- Excuse typos. Phone screens don't make great ketbroads.
-------- Original message --------
From: Reed Allman<EMAIL_ADDRESS>Date: 02/12/2017  1:33 a.m.  (GMT+00:00)
To: fnproject/fn<EMAIL_ADDRESS>Cc: jan grant<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [fnproject/fn] Hybrid Mode MVP (#531)
The other question revolves around async work that turns up with a deadline. If that is fast approaching then the Call's "priority" for placement should rise, I presume.
I am game to not have an idea of a deadline, as I may have interpreted this. I am somewhat concerned about the fact that we effectively need to implement real-timestamp-based priority queueing, but optimistic that we can use kafka's offsets as timestamps, to achieve delayed messages (I'm not sure this is the same as deadline? i.e. run this call at this time in the future X?), and even then I don't think we can possibly make any guarantees about the immediacy of running that; it'll be in line with anything else that came in and was scheduled to run before that time X. As far as priorities, our redis implementation has these but only uses p0. I would like to avoid adding explicit [p0,p1,p2] priorities to start (and forever, if we're being honest) since I think it's going to be quite a bit of work just to get one priority in.
There is no easy way to manage work stealing in that scenario
yep, agree. as proposed it is very optimistic that the node that enqueued it was routed to because it has enough room to run it once that is eventually dequeued, which may be very far in the future.
figuring out how to map a message that a runner has received from an API node to a request to delete that message to the same API node is still kind of what I'm stuck on. Even if all API nodes stay healthy, it seems like we're really fighting the kafka client semantics here. Apparently, they have an http gateway that you can stick in front of kafka to make it so consumers / producers can be less precise about exact positioning of messages wrt partitions, maybe this is the route we need to go down but damn, turtles. for reference: https://github.com/confluentinc/kafka-rest
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/fnproject/fn","title":"fnproject/fn","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/fnproject/fn"}},"updates":{"snippets":[{"icon":"PERSON","message":"@rdallman in #531: \u003e  The other question revolves around async work that turns up with a deadline. If that is fast approaching then the Call's "priority" for placement should rise, I presume.\r\n\r\nI am game to not have an idea of a deadline, as I may have interpreted this. I am somewhat concerned about the fact that we effectively need to implement real-timestamp-based priority queueing, but optimistic that we can use kafka's offsets as timestamps, to achieve delayed messages (I'm not sure this is the same as deadline? i.e. run this call at this time in the future X?), and even then I don't think we can possibly make any guarantees about the immediacy of running that; it'll be in line with anything else that came in and was scheduled to run before that time X. As far as priorities, our redis implementation has these but only uses p0. I would like to avoid adding explicit [p0,p1,p2] priorities to start (and forever, if we're being honest) since I think it's going to be quite a bit of work just to get one priority in. \r\n\r\n\u003e There is no easy way to manage work stealing in that scenario\r\n\r\nyep, agree. as proposed it is very optimistic that the node that enqueued it was routed to because it has enough room to run it once that is eventually dequeued, which may be very far in the future. \r\n\r\nfiguring out how to map a message that a runner has received from an API node to a request to delete that message to the same API node is still kind of what I'm stuck on. Even if all API nodes stay healthy, it seems like we're really fighting the kafka client semantics here. Apparently, they have an http gateway that you can stick in front of kafka to make it so consumers / producers can be less precise about exact positioning of messages wrt partitions, maybe this is the route we need to go down but damn, turtles. for reference: https://github.com/confluentinc/kafka-rest"}],"action":{"name":"View Issue","url":"https://github.com/fnproject/fn/issues/531#issuecomment-348657162"}}}

The thinking is that, there are likely a small set of API nodes and a large set of runner nodes, and we want a runner node to process some subset of calls so that we can re-use hot containers, image caching

I'm still not 100% convinced about the partitioning of the RHS runners...
If we have a large number of runners but they are locked to the same partitions as API nodes (so statistically you have N api nodes and K * N workers), and if there's an imbalance of load on a set of functions (some with high load, some with low load), don't we risk that we have a pool of runners staying idle while others are overloaded like Jan said?
I think we need some form of work stealing, even though when you steal work you are "cold" and you have to pull images and start up containers. The question is how significant that is on async functions that the user has started with the expectation that "at some point they will complete". Maybe they don't care about the 100ms of container start, but they do about the few seconds of image pulling. Hm.
I'm wondering how statistics would work with work-stealing, maybe we get our desired effect anyway. If we have partitioned API nodes but naive runner nodes (which just pull the next job from whatever node the LBs happen to land the request on), then if a function is more loaded than others eventually all the runner nodes will cache its image just by virtue of statistics. The downside is that if all functions are loaded equally then all runner nodes will try to cache all images and that's a bit heavy.

figuring out how to map a message that a runner has received from an API node to a request to delete that message to the same API node is still kind of what I'm stuck on

From what I can see in the proposed spec, the runners pull (poll?) the API nodes for jobs to run when they call /dequeue, and /start doesn't appear to need to land on the same partition (the DB is the arbiter for the semantics). Only /finish needs to be partition-aware, but once a runner is executing a job it can know which partition it came from (the information could be in headers or in a field of the payload of the /dequeue response), so it can embed the same information in the /finish call. This way only one out of four endpoints (probably less than a quarter of the requests) needs to be routed properly - and we still need a solution for this, but at least we get work-stealing... and maybe if there are few requests that needs this routing it becomes feasible to have the API nodes do additional work to redirect the request undoing the interference of the intermediate LBs.

Anyway, going back to the spirit of this ticket, which MQ we use (e.g. kafka) is more of an implementation detail and I guess the main focus is the API (to which we can later add protocol-specific information, like the kafka partition info).
In general terms, the API detailed in your document makes sense. I'll push the minor fixes about the runner endpoints being under v1/ as well, and then coordinate with @msgodf - I guess we can start implementing the endpoints using the current MQ solution.

I think we need some form of work stealing, even though when you steal work you are "cold" and you have to pull images and start up containers. The question is how significant that is on async functions that the user has started with the expectation that "at some point they will complete". Maybe they don't care about the 100ms of container start, but they do about the few seconds of image pulling. Hm.

for async we aren't really bounding the queued time so I think users care much much less about the docker overhead. we can definitely use this to our advantage. however, I think that on our side of the house we do/should care about this overhead. as you pointed out, one issue is the disk space of caching all images. on a similar note, if we can leverage hot functions for async and shove them through a few nodes faster than, say, eating the startup time and pull time of the image across all machines, then we can also reduce the queued time not only for each route, but across all routes. queues getting backed up for async is probably going to be one of the most common customer complaints (we can wait to hit this bridge, probably, too). I agree we definitely need some kind of work stealing so that we can scale, I do think we need to keep sharding / distribution in mind. perhaps the better answer for now, though, is to punt, so we can move forward, with kafka specifically we have other implementation blockers atm.

the runners pull (poll?)

yea, poll is the intent. will clarify in doc.

and maybe if there are few requests needing this routing it becomes feasible to have the API nodes do additional work to redirect the request undoing the interference of the intermediate LBs.

this is an interesting idea. yea, we could have a little proxy among api nodes. the possibly-really-hokey but imo really-totally-okay is that the response from /dequeue returns the public IP address of the API node from which that message was consumed to use in /finish, the API nodes are going to be exposed to the internet anyway (granted, ideally by way of an LB). as currently proposed, we also need to route runner nodes to the same API node repeatedly in /dequeue, as in theory only one API node has a consumer open for each runner's partition (we could round robin through API nodes until we land in the right spot, but it seems wasteful). similarly, /enqueue needs to route to some API node that has a producer thread open on behalf of a runner's partition, this doesn't have to be the same API node as the consumer, however (doesn't buy us a lot). If we partition with RHS keying, I already smell the 2 API nodes need to not be able to have a producer / consumer open concurrently [I think?], which is pretty unappealing.

I guess we can start implementing the endpoints using the current MQ solution.

yep. I see 2 concrete and separable tasks that come out of this:

implement a data access interface layer for the agent that encapsulates the functionality we need, with one implementation that uses the models.Datastore and models.MessageQueue directly, and the other that uses a yet created runner API client (could omit this until after 2), need to shuffle code around first). the methods on this interface [can/should] map pretty easily to the API spec, Enqueue, Dequeue, Start and End (the latter 2 exist, though maybe should be moved around a little to be next to the other 2). Enqueue seems like we could omit as things are now, but it might be worth pushing down into agent.
implement the server API as outlined in the doc above (and if going above and beyond, get the go client bindings over with; we don't need to use swagger here imo, we don't really want users using these apis directly).

I'll take one if y'all want to take the other, you pick ;)

Do we need @msgodf 's patch to have a flag that separates API and runner nodes? It does touch the agent, but maybe we don't need it to get started.
The data access interface (1.) sounds interesting. I'll start doing that in the hybrid-api branch.

I'm also thinking that the runner nodes could learn where it's more efficient to /dequeue jobs from... we don't even need complicated ML for this, it should be sufficient to have a simple weighted probability table that is updated based on whether we successfully get an efficiently runnable job. Reinforcement learning, if you like, but the simplest version of it.
This has also the advantage that we don't need to worry about nodes moving around or being re-partitioned (the tables will update on their own eventually).

implement a data access interface layer for the agent that encapsulates the functionality we need

I've tried abstracting this at the data access layer, and I've managed a quick refactor (pushed a commit), but now I'm looking at it and I'm not convinced it's useful at that layer... so I've probably misinterpreted. From what I can see, I think the agent itself probably needs a refactor, like you say we "need to shuffle code around first".
What I envisage is a runnerAgent and an apiAgent (and maybe a fullAgent for the current implementation?), implementing Agent which will have the new methods corresponding to the new endpoints. This actually may supersede part of what @msgodf is doing, at that point the flag to switch mode becomes a decider for which struct is created.
Am I on the right track?

This actually may supersede part of what @msgodf is doing, at that point the flag to switch mode becomes a decider for which struct is created.

this sounds right, the flag will determine how to configure the agent. I guess agent's responsibility mostly is managing the pool of calls and the interfacing with the mq/db is pretty minimal was the thinking, so we can just shove something into the agent to use to access data when needed vs needing to change the agent at large (the surface area is really just GetCall/Submit). certainly, there are other ways to skin the cat.
what you pushed looks pretty good to me. once we have the runner API client thing, agent.New's signature can maybe look something more like the agent.GetCall where there's 2 ways to construct a data layer for the Agent and the Server can configure the correct one based on flags. but what you have looks good to me. this should slot in with Mark's stuff pretty easily, we can probably slide that in first then fix agent configuration ?

I think fnlb shouldn't make a load based decision on async requests, it should just round robin them. The state of fn servers at the time of MQ queuing could be very stale.
Since fnlb has the big picture, maybe it could be a proxy to the API servers. fn servers could poll API servers through fnlb, which could act as a switch board to route/intercept the responses to the proper fn server. Maybe this could help with /dequeue and /finish mapping issue (since probably fnlb will be in communication with all API servers.)

I guess agent's responsibility mostly is managing the pool of calls and the interfacing with the mq/db is pretty minimal
what you pushed looks pretty good to me

That's fine, but I was asking myself what will be responsible for handling the dequeue/start/finish API calls in the API-only node. The Agent doesn't surface the interface to do so, so will the Server go straight to the data? Even in that case we'll need some sort of "NoOp agent" for the API-only node... I suppose we'll cross that bridge when we get to it.

Also, currently we don't have an "update call" method in the datastore, and we'll need it to update its status (from queued to running to end state), so I'll add an implementation of that too, as an atomic thing (it must basically do a CAS).
We might want an index on some fields too, to speed up queries.

That's fine, but I was asking myself what will be responsible for handling the dequeue/start/finish API calls in the API-only node. The Agent doesn't surface the interface to do so, so will the Server go straight to the data?

this is what I was thinking. I should have a final draft today to PR, need the bit to shut things off to test it (or the agent beats me to dequeue ;) -- can see how it looks and go from there. Mark was discussing not starting an agent in the API nodes at all, which seems wise.

Also, currently we don't have an "update call" method in the datastore, ... so I'll add an implementation of that too, ...

thanks. i'll stub this out for now in start/finish. do you want to PR your agent changes or coordinating with merging @msgodf stuff ?

I'll coordinate with @msgodf. I've added the UpdateCall method and I'm writing tests at the moment, should push things soon to hybrid-api.

I've merged with @msgodf 's stuff in the hybrid-api branch. I could then merge all into hybrid-impl if you want. Shall we work on the same branch? It seems odd to have two.

sweet. yea, I wouldn't mind merging stuff into master and branching off of that, I don't think any of this is really all that intrusive wrt base functionality but we need to move code around and would be nice to stay up to date with master changes. thoughts? -> PR hybrid-api to master? I don't think order of landing hybrid-impl or hybrid-api to master matters, can rebase similarities out and there's not much new code overlap (if any).

i pushed a commit to hybrid-api with my changes and opened up a separate https://github.com/fnproject/fn/pull/581 (which is hybrid-api) which is merge-able to master. PTAL.
TODOs I see atm:

ensure possibility to start a *server.Server / binary without specifying MQ/DB/LOG (it would be nice if server.New reflected this, and each of those things were ServerOpts)
probably don't start an agent at all in API nodes? (agent.New could drop DB/MQ/LOG and use opts)
discuss whether API nodes should be able to enqueue async tasks (I think no, if anything just to reduce the surface area and complexity stuff, also keeps all call creation in runners (id gen, caching of apps/routes). just shut down all /r/ on API nodes is really straightforward)
create client bindings for the runner nodes to call runner API, wrap a new DataAccessLayer around this
examine possibility of letting call update be an idempotent set and having a separate conditional 'update status' ? at least, it seems like we can maneuver around a full call CAS with just the semantics we need. enqueue is insert, start is conditional status switch & add started_at, finish could be idempotent set.
other stuff?

after we get an MVP working with shitty redis mq we should prob get back to investigating kafka (we don't wanna make a redis operator and do that whole dance), seems like we're pretty close.
i'll try to get client stuff done meow

just tacked on a client to #581, it's kind of off on the side for now too so sliding it in (will work on DataAccessLayer / integration tests with it tomorrow unless someone beats me to it)

I've managed to get sync tasks running in split mode (yay) in https://github.com/fnproject/fn/tree/hybrid-datarappa branch (based on hybrid-mergy branch), this does a lot of shuffling around of the server config stuff mostly and fixes some of the client wiring bugs. at least, most of the plumbing is done now [I think]. for now, reverted the protocol back to the same semantics we have on master, we can fix this later.
i've run out of time for today, but async isn't working just yet, will merge into hybrid-mergy or master if we merge #581 once I fiddle with async a little on monday. but anyway notifying because it knocks out a bunch of those todos and moves stuff around a fair amount. I don't think #581 breaks anything on master so I left it without this for now in hopes of merging that.
to run split mode tasks on hybrid-datarappa (with a sync task set up):
FN_NODE_TYPE=api FN_LOG_LEVEL=debug ./fn &
FN_NODE_TYPE=runner FN_PORT=8081 FN_RUNNER_URL=http://localhost:8080 ./fn &
curl -d '{"name":"yodawg"}' -v localhost:8081/r/hot-app/hello
echo "ta da"

(quick note: "When fnrunner starts, it will: - register itself with the fnlb" is effectively done - the fnlb has the ability to discover runner nodes when running under k8s. In a non-k8s deployment, fnlb instances need to be launched with teh --nodes flag or the management interface poked.)

Good stuff!
The FN_RUNNER_URL new env var in hybrid-datarappa... it doesn't point to a runner node, it points to an API node where we can invoke the /v1/runner endpoints. I can see the reason for the name but it may be a bit confusing.
I have no suggestions though (we can't use FN_API_URL as that has another meaning).
I'm happy to merge the hybrid-mergy branch down to master as it does not affect the default case.

The FN_RUNNER_URL new env var in hybrid-datarappa

agreed, it's weird but the logical FN_API_URL is taken [by the cli, so not exactly]. toyed with FN_RUNNER_API_URL, FN_URL, FN_HYBRID_URL, happy to change it.
merged into master, thanks for reviewing. it should be easier to PR and review stuff against master now. i'll get async working today with the old messaging protocol.
meaty pieces left:

kafka
auth
operationalizing

(the checkboxes on the parent comment are not a good approximation of the work required to get this in, I'm changing them to a list so this doesn't look 'done' in github's UI as everything outlined was pretty basic)

opened https://github.com/fnproject/fn/pull/585 w/ today's work, I think it's ready. we can likely add /api/server tests of full sync/async tasks in this mode with 2 server.Server active & communicating on top of that work. the other thing to do is moving the cache from the datastore to the dataaccess layer, which shouldn't be too bad and at some point probably we should doc the api & behavior (maybe wait until auth/kafka?). have at it or I will get to it tomorrow.
auth & kafka will be hair balls & require some research/planning, we should divide and conquer. i'm not sure it's worth doing extensive [load] testing / operationalizing until these are finished.

I have added caching to the hybrid client in #585 but I'm not sure we should "move" the caching from the datastore to there. The datastore cache is still going to be useful in the api node and the "full" standalone node, I guess there are things other than the Agent which use GetApp and GetRoute.

Actually it turns out the datastore cache wasn't being used by anything else so I have now removed it.

I propose we change the env var for the runner API to FN_RUNNER_API_URL ( https://github.com/fnproject/fn/pull/592 ).
I'm toying with some helm chart changes to support a hybrid deployment, and setting FN_RUNNER_URL to something-api really looks odd.

I've just realised a minor issue about hybrid mode that I don't think we've addressed yet.
For a developer using the cli, FN_API_URL will have to point to the API nodes LB address, not the runner nodes LB address. This is fine. However, fn call is a development operation that will have to reach the /r/... endpoints which require using the runners LB address. We'll need a solution for this.

Hybrid deployment helm chart changes up for discussion in: https://github.com/fnproject/fn-helm/pull/9

Updated hybrid deployment PR to have two separate charts.
I have a proposal to solve the problems with the split mode and fn call.
We could have an FN_CONTROL_API_URL and an FN_WORK_API_URL as environment variables that the cli uses, respectively for control plane URL (/v1/...) and work plane URL (/r/...). However, for backwards compatibility (and for standalone deployments) if FN_API_URL is provided then it will be used for both the control plane URL and the work plane URL.
How does that sound?

sounds like a good plan. I'm not sure of the verbiage we want to use user facing, personally I find work/control plane not immediately very intuitive. I am also skeptical of being in small classes with other kids that didn't behave well as a child, however.
wdyt about re-using FN_API_URL to represent the /v1 endpoints and allowing FN_WORK_API_URL to make /r/ requests against runners (if provided, which overrides FN_API_URL for /r/ only)? I'd toss FN_RUNNER_API_URL around for usage in the CLI, but I guess we already use that one in the runner itself. I think 'runner' is more intuitive than 'work'. maybe FN_GATEWAY_URL (it will likely be a load balancer) ?


[Feature Request] GetRecordOnce in Inventory Setup

Can you add GetRecordOnce to Inventory Setup table?

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11018.


Initial release of Schale as its own package

This migrates the code we'd like available into its own package, now called Schale.
This includes migrating relevant integration tests for the schema and model hydration / instantiation functionality.
This includes a composer.json file describing version 0.1.0 of the package.

All good! Merging...


fix: publish page url

Description
publish page link on left navigation list is not correct.
Task Item
Closes #4982
Screenshots

weird commits history. open another PR


[Feature Request] Context Menu Hotkey - Mouse Right Click

Hello @kzhovn !!!
First of all, thank you very much for this plug-in! I's a great idea!
My FR is very simple: A hotkey to the mouse right click (Open Context Menu)
Why I'm requesting this ?
Unfortunately, MacOS don't have dedicated keyboard key to do mouse right click. If you search on Google it is not very simple to do in MacOS :(

Windows have a dedicated key
Linux have Shift + F10

This way, I really need a hotkey to access the Context Menu in Obsidian :)
Thanks for reading this!
Have a great day!

I don't think I'm going to be able to implement this soon, the API doesn't seem to support doing it the easy way and working around that will be quite difficult. Closing for now, I'll reopen it if I decide to work on it.

Thanks for your reply and your help.
I hope in the future Obsidian API brings new features that makes this easy to do.
Thanks for you help.


Add @typedef JSDoc annotaion to fix typestest

Add @typedef JSDoc annotaion to fix typestest. Close #16705

I have no idea how to work around it. Sorry.


global: initial release

Initial release of the reana-env-jupyter encapsulated runtime execution
environment. (closes #1)

Signed-off-by: Tibor Simko<EMAIL_ADDRESS>

Note: added pandas==0.22.0 matplotlib==2.1.2 to the requirements, without which the world population example notebook wouldn't be able to reproduce plots...


⚠ File access (beta) has degraded performance

In 2b057c1, File access (beta) (https://beta.fyle.uk/file/fish) experienced degraded performance:

HTTP code: 200
Response time: 3136 ms

Resolved: File access (beta) performance has improved in ca643ae.


Bugs in example "Single date Picker" as local build (Web)

Steps to reproduce

expo init
enter name for project
Choose a template: › blank (TypeScript)
cd to project
expo install @expo/vector-icons react-native-paper react-native-paper-dates
copy contents of the example to App.tsx

import * as React from 'react';
import { Button } from 'react-native-paper';
import { DatePickerModal } from 'react-native-paper-dates';

export default function ReadMeExampleSingle() {
  const [date, setDate] = React.useState<Date | undefined>(undefined);
  const [open, setOpen] = React.useState(false);

  const onDismissSingle = React.useCallback(() => {
    setOpen(false);
  }, [setOpen]);

  const onConfirmSingle = React.useCallback(
    (params) => {
      setOpen(false);
      setDate(params.date);
    },
    [setOpen, setDate]
  );

  return (
    <>
      <Button onPress={() => setOpen(true)} uppercase={false} mode="outlined">
        Pick single date
      </Button>
      <DatePickerModal
        // locale={'en'} optional, default: automatic
        mode="single"
        visible={open}
        onDismiss={onDismissSingle}
        date={date}
        onConfirm={onConfirmSingle}
        // validRange={{
        //   startDate: new Date(2021, 1, 2),  // optional
        //   endDate: new Date(), // optional
        // }}
        // onChange={} // same props as onConfirm but triggered without confirmed by user
        // saveLabel="Save" // optional
        // label="Select date" // optional
        // animationType="slide" // optional, default is 'slide' on ios/android and 'none' on web
      />
    </>
  );
}

expo start --web

Result

all elements of the DatePickerModal are collapsed to the position x=0 of the window
the button Pick single date does not do anything

@Tesla-Renting I faced the same problem but finally found the route cause is the  version of the react-native-web lib. this component requires versión 0.14.0 or greater.
Expo comes with versión 0.13.x so you need to manually upgrade it via:
npm install<EMAIL_ADDRESS>
The presuming root cause is this lib uses the react-native Modal component and it was implemented on React Native Web in version 0.14.0.

@Tesla-Renting I faced the same problem but finally found the route cause is the version of the react-native-web lib. this component requires versión 0.14.0 or greater.
Expo comes with versión 0.13.x so you need to manually upgrade it via:
npm install<EMAIL_ADDRESS>
The presuming root cause is this lib uses the react-native Modal component and it was implemented on React Native Web in version 0.14.0.
Also notice that you cannot install other versión of RNW. Versión 0.15 onwards needs React v17 and expo currently uses v16.
Regarding the button doing "nothing" is also related to the versión of RNW. It doesn't work on 0.13. This is presumably related to the last version of react-native-paper that maybe also requires some functionality not present on v 0.13.

Also expo install react-native-web updates the package to the latest version (currently 0.17.1). That solves the problem, but I am getting some errors and warnings in the console of the browser:
Warning: React does not recognize the `enterKeyHint` prop on a DOM element. If you intent[...]

Animated: `useNativeDriver` is not supported because the native animated module is missing. Falling ba[...]

but these are probably related to non-web-environments and are not correctly handled in the react-native-web version.

Also expo install react-native-web updates the package to the latest version (currently 0.17.1). That solves the problem, but I am getting some errors and warnings in the console of the browser:
Warning: React does not recognize the `enterKeyHint` prop on a DOM element. If you intent[...]

Animated: `useNativeDriver` is not supported because the native animated module is missing. Falling ba[...]

but these are probably related to non-web-environments and are not correctly handled in the react-native-web version.

It could also have to do with the fact that from version RNW 0.15 onwards React 17 is a peer dependency and maybe something else gets broken. I didn't update the Expo React version, so I stuck to React v16 and a so RNW 0.15+ is not supported formally.


Hs 2 changes

Edit from the feature branch on Github.com or Enterprise is coming in for review and approval

Approved


Rename GTU or G to CCD or C, respectively

Description
Steps to Reproduce
Expected Result
Actual Result
Versions

Software Version
OS
Browser
Mobile device, if applicable

@concordium-cl, this looks good to me on iOS 15 in v1.0(25).

Verified also on iOS 14.7.1, iPhone11, v1.0.25.


Fix duplicated Delete shortcut entries in Tiles Editor

I'm not sure if this is intended or a leftover from the tiles editor refactoring, but the TileSetAtlasSourceEditor uses different shortcuts for deleting the selected base tile and deleting the selected alternative tile. Their default key bindings are the same, only named differently (but display names are both Delete).
This results in two identical Delete shortcuts in the editor's shortcut list:

This PR merges tiles_editor/delete_tile into tiles_editor/delete.

Thanks!


Engineering borg side displacement is weird

Description

When putting hats on an engineering cyborg, the hats appeared correctly from the front but weird on the side (using wrong displacement map)
Reproduction

Place hat on borg, walk the borg to the left or right
Screenshots

Additional context

inventory offsets dont support directions and its not using displacement

borgs should be able to wear only top hats (lika caps, hardhats etc.)

inventory offsets dont support directions and its not using displacement

Oh yeah you're right... I don't know how to fix it then other than just making a custom sprite for every hat just for engi borg which sounds like a giant mess / hard to support / bad precedent

probably just needs displacement maps now?

yes thats the solution, make displacement maps for every borg and remove the inventory offsets, just have a borg inventory layout that specifies a slot and thats it
could even have something like making hats bend over a round head instead of having to sit flat


Update cmake-format style

Description
I think it would make sense to create a custom cmake-format config as there are some interesting options that we could make use of. One is --max-pargs-hwrap 2 this leads to all positional arguments (e.g. files or libraries) to wrap to a vertical layout after 2 args as seen in the following example:
 target_link_libraries(
-  velox_memcpy_meter PRIVATE velox_common_base velox_exception velox_time
-                             Folly::folly gflags::gflags)
+  velox_memcpy_meter
+  PRIVATE velox_common_base
+          velox_exception
+          velox_time
+          Folly::folly
+          gflags::gflags)

This has the advantage that diffs that modify the linked libraries are much easier to read as each lib is on a separate line. There are likely more sensible options that we could add in addition to this.
cc @kgpai

Implemented in #9948


feat : Having a single activity in which compiled event statistics is shown

Expected Behaviour
We can have a single activity where all event statistics can be compiled and shown to the user.
We do have the API endpoint

Would you like to work on the issue?
Yes

@iamareebjamal What are your views on this ?


Wyrd file caching behaviour from vagrant

When running an app in a vagrant box you can sometimes see olde versions of files served, which is deeply confusing.
This is NOT a cowboy specific problem (https://www.virtualbox.org/ticket/9069), but might be worth documenting somewhere.
http://lists.ninenines.eu/archives/extend/2015-September/000550.html

Basically: https://github.com/ninenines/cowboy/issues/812

ah, sorry, didn't realise it had been reported already. using NFS always seems to cause me different problems :(

Closing as duplicate of older ticket.


[Suggestion] Music Bot support

I'd be nice to have a support for a dedicated music user. It would be a reverse of other users mute status. Unmuted during the game and muted at discussion time.

Great idea! Our latest development efforts on the decouple branch (hoping to merge into master soon) will prevent from muting non-participating players (or music bots) when rounds begin, but we haven't quite yet worked on a functionality to reverse the mute for specific bots/users. One problem we might encounter is the speed at which mutes/unmutes happen; we saw issues with the speed of mute/unmute for 10 total users on the current master branch, so we want to make sure it doesn't result in delays for the other players :)

this should work now as long as the music bot isn't tracked by the discord bot.
closing.


feature: implement delete endpoint for Review

TODO: we should think about adding unit tests for iteration 2

TODO: we should think about adding unit tests for iteration 2

Added!


TextInput label overlaying with input text

Hello,
I'm new to react-native-material and I have the label text on top of the input text image when I use the :
<View/>
      <TextInput label="Email" variant="outlined" style={styles.textInput} />
</View/>

const styles = StyleSheet.create({
  textInput:{
    width: "80%",
    marginVertical: 10
  }
});

Thanks in advance for your help

I have the same problem

i have the same problem, help please

hey guys I was able to solve the problem, don't forget the value in your inputs, that solves that problem.

Hello,
I'm new to react-native-material and I have the label text on top of the input text image when I use the :
<View/>
      <TextInput label="Email" variant="outlined" style={styles.textInput} />
</View/>

const styles = StyleSheet.create({
  textInput:{
    width: "80%",
    marginVertical: 10
  }
});

Thanks in advance for your help

hey guys I was able to solve the problem, don't forget the value in your inputs, that solves that problem.

hey guys I was able to solve the problem, don't forget the value in your inputs, that solves that problem.

saved me a lot of time. thanks!


Analyse logout logs from rs

add 2 new logs relared to the issue

Added two new logs based on the type of exception that is thrown

@mulundapm Should we create a new issue to follow up on this next sprint?

@sifferhans ios is released and android is on review. You maybe close this when there is a related log coming in.


Consider other abstract machines

Is your feature request related to a problem? Please describe.
Probably it's better for performance, implementation difficulty, etc.
Additional context

Papers for (v, G)-Machine

http://citeseerx.ist.psu.edu/viewdoc/download?doi=<IP_ADDRESS>.6086&rep=rep1&type=pdf

Papers for Spineless G-Machine

https://www.researchgate.net/profile/Simon_Peyton_Jones/publication/234800678_The_spineless_G-machine/links/55db400f08aeb38e8a8b81f1/The-spineless-G-machine.pdf

Other references

https://citeseerx.ist.psu.edu/viewdoc/download?doi=<IP_ADDRESS>.4314&rep=rep1&type=pdf

STG is also not so complex.
See the paper: https://dl.acm.org/doi/pdf/10.1145/99370.99385


Transcripts over a position

Requested as a feature
This is part of the biocommons API which is not implemented yet.
The smart thing to do in local memory would be an interval tree you build lazily from JSON I the API is called.
Not sure about rest service maybe redis has something

https://pypi.org/project/intervaltree/

Working in branch "dev_tx_region"


Fix local local diff src code suppression

Pretty much what it says on the tin.

CodeChecker cmd diff -b reports_a -n reports_b --new

This command shows 0 reports.

Actually, both according to what I see locally, as well as what can be see in the tests attached, that is not the case. The report does show up in the NEW set.

I think we should discuss this question again, because I still can't see new reports for my example above, even if the source files are in different folders.


Office 365 SMTP Settings

I'm having some trouble adding either SMTP relay or a licensed user to the SMTP settings. First off, I don't have an environment.yml file to edit but I have an example.environment.yml file.

I've also modified smtp.rb with no success either

For both SMTP changes I've restarted the procodile too.
When I perform a foreman start under the Staytus directory it says that SMTP hasn't been configured.

You must create your own environment.yml file and edit the settings in there.
Type cp example.environment.yml environment.yml and then nano environment.yml to edit it and place the settings within that file.
Let me know if you get stuck.


broken page title and links in how-to guide

overview
File: themes/default/content/registry/packages/aws/how-to-guides/aws-py-apigateway-lambda-serverless.md
randomly noticed this today...
list page

detail page

Looks like this is actual content from the example itself: https://github.com/pulumi/examples/tree/master/aws-py-apigateway-lambda-serverless


Allow reading configuration from a local file

Need an option to read server configuration from a specified JSON file in the local filesystem.

Please use Hjson or Yaml.

Truth be told, using YAML is also controversial. I've seen numerous comments on HN/GH with people complaining that whitespace-only nature of YAML makes it hard for some people to edit it. 🤷♂ This is a bit painful to admit for me since both Elvis and I are huge YAML fans — it was in fact the first DSL for our schema (now we have ESDL).
While verbose and more machine than human friendly, JSON has some advantage: built-in support in every language and code editor there is + literally everybody is familiar with it. So if our config files aren't going to be huge I'd stick with JSON.
I also like TOML quite a bit, we can give it a try if we need to handle relatively complex configs.

Truth be told, using YAML is also controversial.

That's why I've listed Hjson as the first option.

While verbose and more machine than human friendly, JSON has some advantage:

It's not "more machine friendly" it's "less human-friendly".

So if our config files aren't going to be huge I'd stick with JSON.

If config is larger than two lines, it needs comments. Also trailing comma is a common issue both with writing configs and especially with versioning them.

I also like TOML quite a bit, we can give it a try if we need to handle relatively complex configs.

Toml is fine for simple configs having just few "sections". But structured data is much better even in JSON:
a. This is because Toml keys can be scattered around across dotted.keys and sections in different parts of file. That is a feature, but can quickly make config hardly readable. Scattered list of dicts are a special nightmare.
b. "Inline tables" (dicts denoted by curly braces) are single-line only. And you end up switching from inline mode to standard [table] after adding another key (which usually means also moving this entry to the end of the current table). Which often means you often can't group things together in a meaningful way.

Toml's scalars are only int/float/date/string. Which means size=100 is fine but size="100Mb" needs to be quoted. This makes values with units like 100Mb and 5sec harder to explain and handle and thus less common in configs (which is a bad thing). Multi-line strings are also more useful in Hjson (indentation is correct)

So Hjson is basically a right superset of JSON fixing comments and trailing comma (and unquoted strings), but without introducing indentation-sensitive syntax (which is mostly what Yaml is hated for). This is currently my favorite configuration format (for simple configs that don't need Yaml's anchors and tags) although I haven't used it in production too much at this time.

If config is larger than two lines, it needs comments.

This is a very good point against using JSON.

Having started using poetry recently, I've warmed up to TOML a whole lot. It's nearly as easy to edit in something like nano as an .ini file but is unambiguous and better standardized.
@tailhook I don't fully understand the use case for "highly structured data" you're imagining here as it relates to a database configuration.

@agritheory there are a bunch of things. Few examples:

Inline mappings are single-line only: key = {a='b', c='d'} is fine, but then if you need add another key, it must be converted to:[key]
a = 'b'
c = 'd'

and then, confusingly enough, this works:key = {a='b', c=[
  '1',
  '2',
]}

Sections can be messed up especially lists, let's see if you have a thing like this:[[sections]]
x = 1
[sections.subkey]
y = 2

This is already hard to read, but it's basically:{"sections": [
  {"x": 1,
   "subkey": {"y": 2}},
]}

And then, you want to add a new section. Intuition is to do this:[[section]]
x = 1
[[section]]
x = 2
[section.subkey]
y = 2

And you effectively moved subkey to a next section:{"sections": [
  {"x": 1},
  {"x": 2,
   "subkey": {"y": 2}},
]}

If you think that this is a lame mistake and contrived example, just note that between the [[section]] title and [[section.items]] can be screenful of lines (e.g. documentation comments). And someone may already put [another-key] in-between half year ago (and that, obviously, didn't break anything technically).


Being prompted to install missing packages when they are already installed on Python 3.12.1

I am trying to install and start ACME.
OS: Windows 11
Python version: 3.12.1
When starting ACME with python -m acme it is asking to install missing packages, however it seems that all required packages are already installed.
The log:
One or more required packages or modules (distutils) could not be found.
Please install the missing packages, e.g. by running the following command:

        C:\Users\synctechno\AppData\Local\Programs\Python\Python312\python.exe -m pip install -r requirements.txt

Do you want to install the missing packages now? [y/N] y
Requirement already satisfied: blinker==1.6.3 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 7)) (1.6.3)
Requirement already satisfied: cbor2==5.5.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 9)) (5.5.0)
Requirement already satisfied: certifi==2023.7.22 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 11)) (2023.7.22)
Requirement already satisfied: charset-normalizer==3.3.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 13)) (3.3.0)
Requirement already satisfied: click==8.1.7 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 15)) (8.1.7)
Requirement already satisfied: flask==3.0.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 17)) (3.0.0)
Requirement already satisfied: flask-cors==4.0.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 21)) (4.0.0)
Requirement already satisfied: idna==3.4 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 23)) (3.4)
Requirement already satisfied: importlib-metadata==6.8.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 25)) (6.8.0)
Requirement already satisfied: inquirerpy==0.3.4 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 27)) (0.3.4)
Requirement already satisfied: isodate==0.6.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 29)) (0.6.1)
Requirement already satisfied: itsdangerous==2.1.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 33)) (2.1.2)
Requirement already satisfied: jinja2==3.1.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 35)) (3.1.2)
Requirement already satisfied: linkify-it-py==2.0.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 37)) (2.0.2)
Requirement already satisfied: markdown-it-py[linkify,plugins]==3.0.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 39)) (3.0.0)
Requirement already satisfied: markupsafe==2.1.3 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 44)) (2.1.3)
Requirement already satisfied: mdit-py-plugins==0.4.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 48)) (0.4.0)
Requirement already satisfied: mdurl==0.1.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 50)) (0.1.2)
Requirement already satisfied: numpy==1.26.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 52)) (1.26.1)
Requirement already satisfied: paho-mqtt==1.6.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 54)) (1.6.1)
Requirement already satisfied: pfzy==0.3.4 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 56)) (0.3.4)
Requirement already satisfied: plotext==5.2.8 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 58)) (5.2.8)
Requirement already satisfied: prompt-toolkit==3.0.39 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 62)) (3.0.39)
Requirement already satisfied: pygments==2.16.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 64)) (2.16.1)
Requirement already satisfied: pyparsing==3.1.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 66)) (3.1.1)
Requirement already satisfied: python3-dtls==1.3.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 68)) (1.3.0)
Requirement already satisfied: rdflib==7.0.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 70)) (7.0.0)
Requirement already satisfied: requests==2.31.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 72)) (2.31.0)
Requirement already satisfied: rich==13.6.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 74)) (13.6.0)
Requirement already satisfied: shapely==2.0.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 78)) (2.0.2)
Requirement already satisfied: six==1.16.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 80)) (1.16.0)
Requirement already satisfied: textual==0.40.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 82)) (0.40.0)
Requirement already satisfied: textual-plotext==0.1.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 86)) (0.1.0)
Requirement already satisfied: tinydb==4.8.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 88)) (4.8.0)
Requirement already satisfied: typing-extensions==4.8.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 90)) (4.8.0)
Requirement already satisfied: uc-micro-py==1.0.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 92)) (1.0.2)
Requirement already satisfied: urllib3==2.0.7 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 94)) (2.0.7)
Requirement already satisfied: waitress==2.1.2 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 96)) (2.1.2)
Requirement already satisfied: wcwidth==0.2.8 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 98)) (0.2.8)
Requirement already satisfied: werkzeug==3.0.1 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 100)) (3.0.1)
Requirement already satisfied: zipp==3.17.0 in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from -r requirements.txt (line 102)) (3.17.0)
Requirement already satisfied: colorama in c:\users\synctechno\appdata\local\programs\python\python312\lib\site-packages (from click==8.1.7->-r requirements.txt (line 15)) (0.4.6)

[notice] A new release of pip is available: 23.2.1 -> 23.3.1
[notice] To update, run: python.exe -m pip install --upgrade pip

Do you want to start ACME now? [Y/n] y

One or more required packages or modules (distutils) could not be found.
Please install the missing packages, e.g. by running the following command:

        C:\Users\synctechno\AppData\Local\Programs\Python\Python312\python.exe -m pip install -r requirements.txt

Do you want to install the missing packages now? [y/N]

Thanks for reporting this.

Python version: 3.12.1

Could you please try Python 3.11.x ?

One or more required packages or modules (distutils) could not be found.

The problem is that the "distutils" package is not part of Python 3.12 anymore, but some of the external packages still use it. I want to give them some time to fix this issue before I will look for a workaround.

It turned out the import of "distutils" happens somewhere in ACME's code. I will fix this and a couple of other error that show up for Python 3.12 in the next release. Until then, please use Python 3.11.

Thanks Andreas. It works on Python 3.11.

Thanks again for reporting it.
I added a warning to the Installation instructions. There seem to be more breaking errors for 3.12 than I expected.

This should be now handled by the latest release


Field's css classes are removed after applying with_class filter

Sample code:
class SomeForm(forms.Form):
    # fields definitions here
    def __init__(self, *args, **kwargs):
        super(SomeForm, self).__init__(*args, **kwargs)
        self.fields['somefield'].widget.attrs['class'] = 'some_class'

After "uniforming" this form (adding uni_form's helper etc.) 'some_class' css class is removed from attrs.
This behaviour is caused by "uni_form.templatetags.uni_form_field.with_class" filter that overwrites attrs['class'] attribute. The filter is applied in field.html default template.
This issue was discussed at #106.

@restless can you please make sure this fixes your issue? Changes are in dev branch.
Thanks, regards
Miguel

Yup, that works. Thanks a lot.

Thank you for reporting it :) I'm glad it works


Allow to pass list directly to config

In the docs you suggest to set up a new module that will provide the config.
For just changing one config item its a bit much boilerplate.
This change allows one to just put the config like this:
config :flop_phoenix,
  pagination: [opts: [
    wrapper_attrs: [class: "flex"],
    pagination_list_attrs: [class: "order-2"],
    previous_link_attrs: [class: "order-1"],
    next_link_attrs: [class: "order-3"]
  ]]

coverage: 98.608% (-0.2%) from 98.805%
when pulling 92e89ccf7d9fdc1d98bd38f4854b58367f8862ca on ponychicken:patch-1
into dad6a180f2320da1110c177cdffbf196523edb38 on woylie:main.

I usually put those functions into my CoreComponents module.
Thanks!

coverage: 98.608% (-0.2%) from 98.805%
when pulling 7b2fb31ac6a059160b9e846d83af4978dba03696 on ponychicken:patch-1
into b4723e45a841b505b2ed6cf26c9b1301c51cb925 on woylie:main.


Batoto removing manga from site

Source name
Batoto 1.4.41
Source language
English
Describe your suggested feature
The way that Batoto removes manga from the site is just by changing the image and adding a message to the description. The message being: "This comic has been marked as deleted and the chapter list is not available."
A few examples:
https://bato.to/series/170876/its-easy-to-ban-access-blue-lock-dj
https://bato.to/series/167901/worker-bee
This makes it hard to know when to migrate an entry.
Is there any way to make it so when the message is detected it shows an error 404 or any type of error that would appear in the update log?
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I have updated the app to version 0.15.3.
[X] I will fill out all of the requested information in this form.

Hello. I saw that there was an pull request which mentioned this issue and the title said that the exception was added, but when my updates finish, I still don't see anything in the update log. Did something went wrong?

The linked PR does not address this issue. There was a relevant comment, this issue being 'other':

only keep the regex change and revert rest, I'll do the other change later
Originally posted by @AwkwardPeak7 in https://github.com/keiyoushi/extensions-source/issues/5853#issuecomment-2481281547


Support disabling tabs

To still show them in the tab bar but not allow user to click into them - e.g. based on roles.

+1 on this feature.  Sounds cool