Trace cli in go

PR for https://github.com/crossplaneio/crossplane/issues/744
To do:

[x] Test and adapt "Simple Resource Class Selection" https://github.com/crossplaneio/crossplane/pull/926
[x] Better identifier, UID missing if object does not exist
[x] Adapt bootstrap.sh to include trace
[x] Ready/Pending/Missing states to highlight what is wrong
[x] Unit tests
[ ] Test different scenarios and edge case handling
[ ] Refactor: better naming, using constants, comments etc
[x] Polish graph output

Build & Install:
$ make build
$ make install

Trace a kubernetesapplication:
$ kubectl crossplane trace kubernetesapplication <name> -n <namespace>

Graph output:
# Graphviz needs to be installed first, e.g. brew install graphviz
$  kubectl crossplane trace kubernetesapplication <name> -n <namespace> -o dot |dot -Tpng > /tmp/output.png&& open /tmp/output.png

Would you be able to use more upbound-style commit messages? Here's the formula I've been using

Sure. I'll most probably, overwrite the commit history here with some sort of "Initial commit" for trace cli go project since the initial commits include experimental changes and I didn't follow well scoped commits.

What testing has been done?

I am mainly testing with wordpress stack example both happy path and also by intentionally breaking some stuff.

@suskin I still have something to do, but believe that PR is ready for review.
It would be great if you could have a chance to test on your side as well.

I forgot to mention, but I did some integration testing on my side as well. I used it to inspect the statuses for a mysqlinstance and a kubernetesapplication which I created as part of the Stacks guide. And I used it to watch the kubernetesapplication become ready over time. It was way better than doing those things without the tool!
As another note, we'll want to update some of the documentation - in this repo and in crossplane - to recommend that we use trace. The documentation will need to be updated before we consider the trace work to be complete.

Which cloud provider were you using?

I was using GCP, and I was also using Crossplane 0.3 instead of master


docs: fix performance value units

Thanks for contributing!

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Signed-off-by: ty-dc<EMAIL_ADDRESS>

cherrypick-release-v0.8


Track 'Truefit'

Vendor Site - https://www.creatorbyzmags.com/
Example Sites - https://www.shoecarnival.com/kids_nike_little_kid_air_max_sc_swoosh_sneakers/116442.html
Category - Personalisation
Detection - Look for script from domain '//cdn.truefitcorp.com/'

@rockeynebhwani Hey there
Vendor's site is not this by chance ?? https://www.truefit.com/en/Home

examples
https://www.landsend.com/
https://www.shoecarnival.com/
https://warpweftworld.com/

@rockeynebhwani understood the vendor here just from the previous request. All OK

Thanks @nurbek91 .. Copy / paste error on my part...


Correction for raw affiliation CR2P UMR 7207 MNHN CNRS SU, F-75005 Paris France; MCAM UMR 7245 MNHN CNRS, F-75005 Paris France

Correction needed for raw affiliation CR2P UMR 7207 MNHN CNRS SU, F-75005 Paris France; MCAM UMR 7245 MNHN CNRS, F-75005 Paris France
raw_affiliation_name: CR2P UMR 7207 MNHN CNRS SU, F-75005 Paris France; MCAM UMR 7245 MNHN CNRS, F-75005 Paris France
new_rors: 05pchb838;02feahw73;05ax2x637
previous_rors: 05pchb838;02feahw73
works_examples: W4385651127;W4385649909;W4362669858
contact: c2b06b319879d7f3aeb2121065efb4b4:8b71a73e769dccc1bb9a382ab2 @ sorbonne-universite.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-01. The new affiliations should be visible within the next 7 days.


Galley cleanup

Cleanups on galley, this is definitely not complete.

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
ee99e2748ff3f6977ab1c5e42d36dabfcc613e72
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Shared mount folder gets deleted when overwritten by a file from personal space

Description
When a user make an api request for copying a file from personal space on the top of the shared mounted root level folder then the whole shared folder and all the resources gets deleted.
Steps to reproduce a bug.

Create 2 users test1 and test2
test1 creates a file test1.txt
test2 user creates a folder called test2-folder
test2 user creates a file inside test2.txt inside test2-folder
test2 folder shares the folder test2-folder with test1 with permission can edit.
test1 accepts the shares
test1 copy the file test1.txt to /test2-folder

curl request to perform step 7
curl -ks -utest1:<password> -X COPY -H "DESTINATION:https://localhost:9200/dav/spaces/<user-test1-virtual-share-id>/test2-folder/" https://localhost:9200/dav/spaces/<user-test1-space-id>/test1.txt -v | xmllint --format -

to get <user-test1-virtual-share-id> and <user-test1-space-id> use following curl command
curl -k -X GET 'https://host.docker.internal:9200/graph/v1.0/me/drives' -utest1:<password> | jq

Actual Behavior
The server gives 500 error.
< HTTP/1.1 500 Internal Server Error
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Content-Security-Policy: default-src 'none';
< Date: Mon, 04 Sep 2023 11:17:39 GMT

Also the shared folder gets deleted both from shares space in test1 user and from personal space in test2.

Expected behavior
The behavior can not be performed from the UI but possible through API.
Or such Behavior should be forbidden in ocis by giving status code 403.
Needs some information and discussion regarding it.
Environment
oCIS= latest build

similar to https://github.com/owncloud/ocis/issues/6739 ?

Similar but in Personal space https://github.com/owncloud/ocis/issues/6983

re-tested. I got 409 error. Probably we fixed it. but api tests still fail
curl -ks -ueinstein:relativity -X COPY -H "DESTINATION:https://localhost:9200/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/f1" https://localhost:9200/dav/spaces/6ffe6045-c967-44ef-8210-0b269eaeabc6%244c510ada-c86b-4815-8820-42cdf82c3d51/New%20file.txt -v | xmllint --format -
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: O=Acme Corp; CN=OCIS
*  start date: Jan 11 13:17:56 2024 GMT
*  expire date: Jan 10 13:17:56 2025 GMT
*  issuer: O=Acme Corp; CN=OCIS
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'einstein'
> COPY /dav/spaces/6ffe6045-c967-44ef-8210-0b269eaeabc6%244c510ada-c86b-4815-8820-42cdf82c3d51/New%20file.txt HTTP/1.1
> Host: localhost:9200
> Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ==
> User-Agent: curl/7.86.0
> Accept: */*
> DESTINATION:https://localhost:9200/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668-a365-4782-871e-d44447bbc668/f1
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 409 Conflict

Issue still exists.
Steps:

admin creates file afile.txt
demo creates folder myfolder
demo shares myfolder with admin (editor role)
admin tries to COPY afile.txt to myfolder

curl -XCOPY "https://localhost:9200/dav/spaces/<personal-space-id>/afile.txt" \
-H"DESTINATION: https://localhost:9200/dav/spaces/<virtual-shares-drive-id>/myfolder" \
-uadmin:admin -vk

Result:

500 Internal Server Error
admin lost the share
demo lost the myfolder folder -> moved to trashbin

Issue still exists:
Steps:

admin creates a file testFile.txt
einstein creates a folder shareFolder
einstein shares a folder shareFolder with admin with Editor role (sharing API, or sharingNG-graph API)
admin tries to COPY testFile.txt to shareFolder in Shares space

curl -ks -uadmin:admin -X COPY -H "DESTINATION:https://localhost:9200/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668\$a0ca6a90-a365-4782-871e-d44447bbc668/shareFolder" https://localhost:9200/dav/spaces/f3681943-78f1-415d-b84d-12ac5953b526\$ee17dd67-9574-49d6-9d69-fc75ea7ae07e/testFile.txt -v | xmllint --format -

Result:

HTTP/1.1 412 Precondition Failed
admin lost the share
einstein lost the shareFolder folder -> moved to trashbin


Player position reported switches to different player after death

This is more of a heads-up instead of a bug. A Bethesda feature, sortof ...
I wrote a snippet of code to get a player's path in each round, by subscribing to the tickDone event and adding each player's current position to a list. Now I noticed some rather unusual paths; in short, once the player is dead, the position reported for this player is the position of a different second player ( might be the killer's pos - didnt check).
This can be simply bypassed by checking if the player is alive each tick and if not adding the last position alive to the list every tick.
Still think of it as a noteworthy feature.

It switches to the player they are spectating, to be exact.


Populate variable with ACR hostname on "login" using Docker task

It should be possible to derive the ACR hostname having only a service connection available.
That is, for a given service connection, the Docker task should make available to hostname, i.e. <name>.azurecr.io which is registered with that service connection.
See for example the following unanswered post:
https://stackoverflow.com/questions/67921817/derive-the-acr-name-from-a-service-connection-in-azure-devops-pipeline

After the docker login command is run, the ${DOCKER_CONFIG} environment variable is set (or reused) and the connection information is saved to ${DOCKER_CONFIG}/config.json. The config file will not exist before the login command though, so you might need to specifically call the login command first before any buildAndPush or push commands.
If logged in with a service connection, this file should look something like (formatted here for readability):
{
  "auths": {
    "https://gcr.io/container-registry-999999/": {
      "auth": "SomeMonsterBase64EncodedStringAuthThing",
      "email": ""
    }
  },
  "HttpHeaders": { "X-Meta-Source-Client": "VSTS" }
}

You can see mine here is for gcr.io but I assume the hostname should be there for an ACR service connection.
When I tested this, it thought the service connection name was secret so it obfuscated it from the pipeline logs, so I added a publish task to let you see what that value ends up being (you won't need the publish after you get it working)
- script: echo "##vso[task.setvariable variable=serviceConnectionHostname]$(jq '.auths|keys|first' ${DOCKER_CONFIG}/config.json)"
  displayName: Set serviceConnectionHostname from Service Connection

- script: echo "$(serviceConnectionHostname)" > serviceHostname.txt
  displayName: Output serviceConnectionHostname

- publish: serviceHostname.txt
  artifact: serviceHostname

Hope this helps 👍

I actually did take a look there but found that there is no entry ${DOCKER_CONFIG}/config.json for the ACR.


Enable getting randomized colormaps for compressed maps

Compressing maps can lead to overlapping region labels and hence while parcellationmap.compress relabels the regions, parcellationmap.get_colormap may result in the same colors being used for different regions. This commit suggests a solution: generate a randomized colormap for compressed maps, which is saved locally and can be loaded next time get_colormap is invoked on the same compressed map.
Example:
import siibra
from nilearn import plotting

jubrain_mpm = siibra.get_map(parcellation="julich 2.9", space="mni152", maptype="labelled")

jubrain_mpm_whole = jubrain_mpm.compress()

plotting.view_img(jubrain_mpm_whole.fetch(), cmap=jubrain_mpm_whole.get_colormap(), symmetric_cmap=False)

# repeat the plot to confirm the load mechanism
plotting.view_img(jubrain_mpm_whole.fetch(), cmap=jubrain_mpm_whole.get_colormap(), symmetric_cmap=False)

# It also supports coloring only the selected regions:
plotting.view_img(jubrain_mpm_whole.fetch(),
    cmap=jubrain_mpm_whole.get_colormap(["Area TPJ (STG/SMG) right", "Frontal-to-Temporal-I (GapMap) left"]),
    symmetric_cmap=False)

For discussion: While _create_randomized_colormap and _load_randomized_colormap are not user-end methods, it can potentially be employed by users. We can also create a load_colormap() for users' custom colormaps (might be particularly useful for colorblind users).

The problem with this approach, as I see it, is that colour maps often are not made in the vacuum.
For example, Jülich brain hoc1 is always purple ish, and if it appears any other colour, it might be uncanny.

The problem with this approach, as I see it, is that colour maps often are not made in the vacuum.
For example, Jülich brain hoc1 is always purple ish, and if it appears any other colour, it might be uncanny.

I see what you mean. From this thought process, I had thought about an alternative version where the code employs a different shade/tone if there is a label clash. I've gone with this approach also considering coloring for maps with no pre-assigned colormaps. But this can be a contingency instead.
What do you think of the shade/tone-idea? (I can make changes accordingly and commit)

The problem with this approach, as I see it, is that colour maps often are not made in the vacuum.
For example, Jülich brain hoc1 is always purple ish, and if it appears any other colour, it might be uncanny.

I see what you mean. From this thought process, I had thought about an alternative version where the code employs a different shade/tone if there is a label clash. I've gone with this approach also considering coloring for maps with no pre-assigned colormaps. But this can be a contingency instead. What do you think of the shade/tone-idea? (I can make changes accordingly and commit)

I think the following would be prudent:

for jba 2.9 in mni152, generate plot, screenshot, and attach to this PR for the following:

before this PR
this PR
your new proposed solution (different shade/tone)

The first screenshot would hopefully demonstrate the problem, and last two screenshots would present two different solutions. When compared visually, it would be a/ alot easier to tell there is a probem and b/ decide on which is the more favoured solution, and in which way we can make improvements

* for jba 2.9 in mni152, generate plot, screenshot, and attach to this PR for the following:

  * before this PR

  * this PR

  * your new proposed solution (different shade/tone)

I do like the different shade version for compressed maps and if you also agree, I'll make a new commit with this version.
I think we should still leave the randomized colormap getter and load colormap as options for users when the map does not have a built-in color scheme. This way, they could employ different colormaps when the need arises. What do you think?

I am not sure if I fully understand the problem behind these ideas.
In general, I would not implement much colormap functionality in siibra. There are other libraries that provide functionality to create random or high contrast colormaps. The idea in siibra was only to allow to retrieve a colormap of a supported parcellation, if the parcellation specification has colors defined. I would not recommend to add functionality to create new colormaps, since this is not really part of siibra's scope and we would need to maintain, document and discuss it without a real need.
If possible, a compressed map should provide a colormap that preserves the colors of the original parcellation map. IS there a case where this cannot be achieved by just remapping the original colormap to the new label indices?


[hermes] listen to the protocol and make epoch pack

subscribe and/or download latest known blocks
pack done epoch when reaching epoch stability (k, plus margin of safety)

These changes require that we first move some code out of ariadne and into exe-common, right? What in particular do you want to move @vincenthz ?

I think most of the network has been moved already.
now the stepping stone would be to start connecting on the native network, and keep
trying to diff the local state vs the network state:
looping:

ask network's state
download all the blocks we don't have yet as individual blobs

then:

check periodically if there's some packing work to do: is there a epoch worth of packing to do, and the latest block of an epoch is now considered stable (block is now "old enough" in the chain)


provide dbus session to FHS privateTmp

Description of changes
https://github.com/NixOS/nixpkgs/pull/275857 isolated FHSenv's /tmp with privateTmp = true  (for all I know only steam) to address https://github.com/ValveSoftware/steam-for-linux/issues/9121. This broke (https://github.com/NixOS/nixpkgs/issues/276755) steam on systems which rely on passing the DBUS address as a /tmp/dbus-* path.
This change bwrap binds all /tmp/dbus-* files into the isolated /tmp
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I'd rather base it on the environment variable used to find the bus, rather than everything of a particular form in /tmp. It's more robust when some other system uses a different naming scheme in /tmp for the same thing, and also doesn't bind mount unnecessary things.

I'd rather base it on the environment variable used to find the bus, rather than everything of a particular form in /tmp. It's more robust when some other system uses a different naming scheme in /tmp for the same thing, and also doesn't bind mount unnecessary things.
Also, can you change the commit message and PR title to something starting with buildFHSEnv: , as described here.

I tried for a bit but I am running into syntax errors from nixos-rebuild when trying to use common bash features.
I don't have time for this and will just close it. We have a fix already anyway (disabling the privateTmp).

I'll probably get to working on this soon.


Relationship between the bounding box dimension and detection rate performance

Hello
Which of the following bounding boxes used while training a nodule detection model results in a good performing nodule detector ?

A tighter bounding box as shown below

or 2. Or a loose bounding box like below

Thanks
Rajesh

Dear @Rajesh-ParaxialTech ,
I think there is no right or wrong for this answer since every bounding box has a uncertainty in its position and different raters will give you vastly different boxes.
Generally speaking, a smaller bounding box will be more difficult to detect since the IoU decreases cubicly -> i.e. being 1 voxel off will give you a lower IoU if the ground truth is smaller.
The looser bounding box on the other hand is less precisely defined, e.g. if you draw the box slightly bigger or smaller the box would still adhere to the defined standard but be different for the detection model i.e. the predictions of the model will likely converge to somewhere in the middle of the annotation uncertainty which might again lead to lower IoU values for some boxes.
In the end, I would argue that this highly depends on the goal of the detection model, e.g. for diagnostic use cases where a coarse localization is needed there won't be a huge difference between the annotation styles - as long as the annotations remain consistent, if the style changes in the dataset performance will be degraded
Note: for nnDetection you need to convert the boxes into instance segmentation mask, usually that is not a problem though :)
Best,
Michael


Support for powf operations

Requested feature: powf
Use case: I want to verify a function that uses powf
Link to relevant documentation (Rust reference, Nomicon, RFC): https://doc.rust-lang.org/std/primitive.f64.html#method.powf
Test case:

pub fn f(a: u64) -> u64 {
    const C: f64 = 0.618;
    (a as f64).powf(C) as u64
}

#[cfg(kani)]
mod verification {
    use super::*;

    #[kani::proof]
    fn verify_f() {
        const LIMIT: u64 = 10;
        let x: u64 = kani::any();
        let y: u64 = kani::any();
        kani::assume(x < LIMIT || x > u64::MAX - LIMIT);
        kani::assume(y < LIMIT || y > u64::MAX - LIMIT);
        kani::assume(x > y);
        let x_ = f(x);
        let y_ = f(y);
        assert!(x_ >= y_);
    }
}

The docs suggest Numerics are fully supported. Without floats, I think "partial" would be more appropriate.

Thanks for creating this issue, @nickgarfield.
This is related to #2763. Now that support has been added in CBMC (https://github.com/diffblue/cbmc/pull/7906), this should be doable.

Hi @nickgarfield , do you mind explaining the test case you attached? Does it test a well-known numerical property or why do you think it should pass?
The reason I'm asking is that I have a development version with the powf64 intrinsic, but the result I'm getting is not the one you're expecting:
SUMMARY:
 ** 1 of 89 failed
Failed Checks: assertion failed: x_ >= y_
 File: "powf_example.rs", line 20, in verification::verify_f

VERIFICATION:- FAILED
Verification Time: 0.59359556s

Concrete playback returns these inputs:
#[test]
fn kani_concrete_playback_verify_f_9913905681601751135() {
    let concrete_vals: Vec<Vec<u8>> = vec![
        //<PHONE_NUMBER>3709551608ul
        vec![248, 255, 255, 255, 255, 255, 255, 255],
        //<PHONE_NUMBER>3709551606ul
        vec![246, 255, 255, 255, 255, 255, 255, 255],
    ];
    kani::concrete_playback_run(concrete_vals, verify_f);
}

Running the test case with those inputs doesn't cause it to panic. It's possible that the intrinsic is over-approximating too much, but first I'd like to know more about your test case.

The docs suggest Numerics are fully supported. Without floats, I think "partial" would be more appropriate.

I don't agree with this assessment. What we're missing support for are the pow* intrinsics which appear as "Not supported" in the table summarizing support for intrinsics.

Does it test a well-known numerical property or why do you think it should pass?

I drafted this example rather quickly. It might have some bugs. I was trying to write a proof to show f(x) > f(y) if x > y.

We were discussing this issue now. We suspect it's a spurious failure due to over-approximation, but haven't determined it yet.
@celinval notes that, for the intrinsics that over-approximate, we should find a way to alert the user about such behaviors. This isn't the first time users are confused, see #1342 for another example.


popovers: Manage this user.

Fixes #18944
Admins can now manage users directly from the three-dot menu for that user.
Testing plan:
All tests passes. Visual testing alongside discussions on how the frontend should look.
GIFs or screenshots:

@johanehinger any chance you have time to update this?  If not, perhaps @sahil839 can clean it up as something we can integrate.

@timabbott @sahil839 Yes, please go ahead. I will not have any more time to spend on this issue. And I think it was a little bit too much for me. I will instead focus on learning about mock testing in #20137. Please let me know if you do end up using anything from my proposed solution.

Thanks for all your work on this @johanehinger. This was implemented in #20373.


bluealsa and bluealsa-aplay sound is non constant

I'm using the system as a way to play audio from my phone to a Pi with an I2S sound card.
Bluez5 is setup and I have the following commands for bluez-alsa :

bluealsa -i hci0 -p a2dp-sink
bluealsa-aplay -d hw:0  -v  00:00:00:00:00:00
Selected configuration:
HCI device: hci0
PCM device: hw:0
PCM buffer time: 500000 us
PCM period time: 100000 us
Bluetooth device(s): ANY
Profile: A2DP

My android phone connects and the audio is routed to the Pi. I can hear the audio coming through in patches from the phone, however long gaps between. It is stereo.
You can listen here :
https://drive.google.com/file/d/1922x6iXofnortUnxkr511fsLj8-GjROn/view?usp=sharing
The audio sounds like playback is much too fast.
I have tried using the plughw:0 device, but get the same problem.

I've also done a test with altering the buffer and period time :
bluealsa-aplay -d hw:0 --profile-a2dp --pcm-period-time=200  --pcm-buffer-time
=100 -v 00:00:00:00:00:00
Still sounds patchy ...
https://drive.google.com/file/d/1PRboBiSfkXn7xHEXbU5e_cuOYtjHkz4u/view?usp=sharing

I tested with a USB bluetooth dongle. It works well.
Turns out the problem is with the Pi3 inbuilt bluetooth hardware. I have tried turning wifi off and playing with flow control - but nothing comes of it.
Anyone who has setup the Pi3 using buildroot (not raspbian) with suggestions are welcome.

This appears to be an issue with RPi firmware and/or UART config. It is very likely fixed by updating firmware and OS. I think it is not a bluez-alsa issue.


Revert "Revert "Restrict cluster, machinepool and machinedeployment names""

Reverts giantswarm/kyverno-policies-ux#44 (reverts the reversion PR)
We had to revert https://github.com/giantswarm/kyverno-policies-ux/pull/38, because some customers have machine deployments that start with a number.
As discussed in the issue, this PR simply removes the number-related rules for machine deployments and machine pools. This way we don't have problems with customers currently violating that policy. As soon as we migrate to CAPI machine pool and machine deployment names will be prefixed with the cluster name, which is still checked by the cluster-names policy. Therefore in CAPI we implicitly ensure that machine pools and machine deployments don't start with a number.

Applying the policies to each MC yields the following results:
MCs with problematic CRs:

golem

MCs for which opsctl login did not work:

installation
problem

goat
CA expired

icecream
Post "https://athena.g8s.icecream.westeurope.azure.gigantic.io/graphql": EOF

gorgoth
Post "https://athena.g8s.gorgoth.gridscale.kvm.gigantic.io/graphql": EOF

goten
Post "https://athena.goten.gaws.gigantic.io/graphql": EOF

goose
Post "https://athena.goose.azuretest.gigantic.io/graphql": EOF

gmc
Post "https://athena.gmc.test.gigantic.io/graphql": dial tcp <IP_ADDRESS>:443: connect: no route to host

gubble
Post "https://athena.gubble.test.gigantic.io/graphql": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I will try to fix the problematic CRs in golem and investigate why opsctl login does not work for the other ones.

Team Phoenix will take care of goat.
https://github.com/giantswarm/giantswarm/issues/27481
We wait with merging & releasing until that's done.

The problem with goat is fixed. This is ready to be released now.

I double-checked whether there are no resources that violate these policies and I overlooked some when first looking:
====================goku====================

Applying 4 policy rules to 15 resources...

policy cluster-names -> resource org-df-test/Cluster/2db3k failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

pass: 36, fail: 2, warn: 0, error: 0, skip: 41
====================gollum====================

Applying 4 policy rules to 6 resources...

policy cluster-names -> resource org-giantswarm/Cluster/5jka7 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

pass: 14, fail: 2, warn: 0, error: 0, skip: 16
====================snail====================
W0816 08:30:18.157757   22269 warnings.go:70] cluster.x-k8s.io/v1alpha4 MachinePool is deprecated; use cluster.x-k8s.io/v1beta1 MachinePool
W0816 08:30:18.245199   22269 warnings.go:70] cluster.x-k8s.io/v1alpha4 MachineDeployment is deprecated; use cluster.x-k8s.io/v1beta1 MachineDeployment
W0816 08:30:18.312019   22269 warnings.go:70] cluster.x-k8s.io/v1alpha4 Cluster is deprecated; use cluster.x-k8s.io/v1beta1 Cluster
W0816 08:30:18.343854   22269 warnings.go:70] cluster.x-k8s.io/v1alpha3 MachineDeployment is deprecated; use cluster.x-k8s.io/v1beta1 MachineDeployment
W0816 08:30:18.382202   22269 warnings.go:70] cluster.x-k8s.io/v1alpha3 MachinePool is deprecated; use cluster.x-k8s.io/v1beta1 MachinePool
W0816 08:30:18.413439   22269 warnings.go:70] cluster.x-k8s.io/v1alpha3 Cluster is deprecated; use cluster.x-k8s.io/v1beta1 Cluster

Applying 4 policy rules to 8 resources...

policy cluster-names -> resource /Cluster/sample-customer failed:
1. cluster-name-maximum-length: cluster name must be no longer than 10 characters

policy cluster-names -> resource org-sample/Cluster/sample-customer failed:
1. cluster-name-maximum-length: cluster name must be no longer than 10 characters

pass: 18, fail: 4, warn: 0, error: 0, skip: 21
====================viking====================

Applying 4 policy rules to 129 resources...

policy cluster-names -> resource org-apix-nonprod/Cluster/0d77f failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-g-n-e/Cluster/3a77d failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-rewards-prod/Cluster/21f0d failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-securenet/Cluster/8c409 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-vodafone-id-prd/Cluster/3p5ny failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-multi-tenant/Cluster/0ohqb failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-vodafone-id/Cluster/2t4ky failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-securenet/Cluster/7pf9a failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-d-x-l/Cluster/48but failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-algov-prod/Cluster/3d319 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-gateways-playground/Cluster/5e1e5 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-digital-pt/Cluster/7fkvu failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-chatbot-nonprod/Cluster/0a452 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-d-x-l/Cluster/5y4cr failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-g-i-g/Cluster/9vcqy failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

policy cluster-names -> resource org-vbps/Cluster/3pwt7 failed:
2. cluster-name-does-not-start-with-number: cluster name must not start with a number

pass: 320, fail: 32, warn: 0, error: 0, skip: 340


Restore ability to utilize updated_at for check_cols snapshots

Restore ability to configure and utilize updated_at for snapshots using the check_cols strategy
resolves #5076
Description

Checklist

[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have added information about my change to be included in the CHANGELOG.

@cla-bot check

The change looks good! Can we add a test for this case so we don't accidentally break this next time?

Will work on some test cases for this.


adding active tab to breadcrumb

closely review L186 - L188 (commented out some code, that is possibly used in some packages)

@sbeaver-netgate
i think some of the code from pkg_edit.php got copied to pkg.php a couple of days ago:
see: https://github.com/pfsense/pfsense/commit/8cfdeb2ef63e283fad931f220d1f1930651097d4

Ah yes. That explains it. Thanks!
Steve
Stephen Beaver | +1<PHONE_NUMBER>;239 |<EMAIL_ADDRESS>| www.netgate.com

On Dec 21, 2015, at 10:49 AM, heper<EMAIL_ADDRESS>wrote:
@sbeaver-netgate https://github.com/sbeaver-netgate
i think some of the code from pkg_edit.php got copied to pkg.php a couple of days ago:
see: 8cfdeb2 https://github.com/pfsense/pfsense/commit/8cfdeb2ef63e283fad931f220d1f1930651097d4
—
Reply to this email directly or view it on GitHub https://github.com/pfsense/pfsense/pull/2304#issuecomment-166336428.


Donations not working

I downloaded the app using F-Droid. When I click the donate button the next screen that pops up has the Thank You message but the Donate button is greyed out with a HTTP 500 Internal Server Error.

I am getting (almost) the same error. I got a HTTP 410 instead of 500.

Same errors for me. I've wanted to donate some sats for a long time but never can.

Same problem

Hi, thanks for reporting. I got a bit busy with my life and forgot to maintain the server.
Lesson learned. I try to change it and add just LN address instead (or something).


Translate not working for ionic date-time.

I want to translate ionic date-time.
ionic usually works like following code to translate date-time
<ion-datetime displayFormat="DDDD MMM D, YYYY" [(ngModel)]="myDate" monthNames="janeiro, fevereiro, march, ..." ></ion-datetime>
I'm using monthNames="{{ 'MONTHS' | translate }}" or [monthNames]="'MONTHS' | translate" as translation rules of ng2-translate but its not work just showing an error Cannot read property 'length' of undefined.
in en.json file I use
{
"MONTHS": "Janua,Febru,Mar,Apr,May,June,Jul,Augus,September,October,November,December"
}

If there are any other solution please answer.

Try adding a space after each comma:
"Janua, Febru, Mar, Apr, May, June, Jul, Augus, September, October, November, December"

Someone?

Hi,
Despite I am quite new using ionic, I found a solution to this issue, hope it helps someone.
In html use:
[monthNames]="months_names"
Then in ts:
this.months_names = this.translate.instant("MONTHS");


fix HTML of filter refresh on history page

Similar to #2705 but affects the History page.

Fixed by #2890.


[move-package] Fix issue where we werent' removing build artifacts between builds

This fixes an issue where testing or dev-mode artifacts could still exist on disk if you first compiled a package in dev or test mode and then compiled in non-dev or test mode.
This adds a test to make sure these artifacts are deleted.

/land

:broken_heart: Test Failed - ci-test

/land


Document ID and time is logged + Drawing tool logging bug

This PR Addresses two tickets:
Check DocumentID on View/Comment log events
https://www.pivotaltracker.com/n/projects/2441242/stories/183725028

Document ID and time is logged when we open up a document both ways (open manually vs clicking on a document in the commented document view) , event type is of VIEW_SHOW_COMPARISON_DOCUMENT. Previously only opening manually a document logged the event, added functionality for clicking on a document in commented document view.

Verify when you post a comment, the document ID and time are logged and the event is "ADD_RESPONSE_COMMENT_FOR_DOCUMENT"

Bogus Draw Tool logging on the left side view
https://www.pivotaltracker.com/n/projects/2441242/stories/183808548
Previously, when you opened any document that had a drawing tile in it, it would log DRAWING_TOOL_CHANGE for every drawing tile in the document. I added some logic inside of drawing-content.ts that should prevent DRAWING_TOOL_CHANGE being logged.

FYI: There will almost certainly be substantial conflicts between this PR and my logging refactor PR.

I suppose I'll just wait until @scytacki merges your PR then pull latest main, test and request review on my PR @kswenson

FYI: There will almost certainly be substantial conflicts between this PR and my logging refactor PR.

@kswenson, I suppose I'll just wait until @scytacki merges your PR then pull latest main, test and request review on my PR

Yours is functionality for the next release, so I suspect the better path would be to merge yours first and then have @scytacki or me deal with the resulting conflicts. Just wanted to point it out.

👍 LGTM @scytacki should weigh in on whether checking the action name in this way is the best way to prevent the unnecessary log message. Also, the conflict with my PR shouldn't be too hard to fix.

@scytacki and I just chatted and this seems fine. We also discussed that it could go where onTileAction is called around here but the only tile logging on onTileAction is this one so it doesn't really matter.


CI runs fail with charms in error: ImagePullBackOff": Back-off pulling image "registry.jujucharms.com

It seems like there is an intermittent issue when deploying charms from Charmhub in GH runners, which fail to deploy with the status message: unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/4jn95wlrsfo1po9wfu....
This error message suggests there is an error when pulling the image from the registry.jujucharms.com/ container registry, but this information has to be confirmed because these  are sometimes linked to low storage.
Important to note, this error goes away after re-running the CI, as mentioned before, it seems like an intermittent issue, but has happened consistently across other PRs at least once.
Environment
This has only happened in GH runners during integration test execution and has only been observed in the kfp-operators repository.
In the event we observe this error in other repositories, we should transfer the issue to canonial/bundle-kubeflow.

NOTE: if this issue happens in other repositories, please transfer to canonical/bundle-kubeflow.

Possible causes
It can be either the registry is not working correctly OR we could be running out of storage in the GH runners.
Examples of CIs where this behaviour has been observed

https://github.com/canonical/kfp-operators/actions/runs/5716319711/job/15514631356#step:8:38
https://github.com/canonical/kfp-operators/actions/runs/5726957265/job/15518414482#step:8:28
https://github.com/canonical/kfp-operators/actions/runs/5730163441/job/15533052295#step:5:77

Thanks @i-chvets, I was exactly looking for this kind of log minio res:oci-image@1755999 blocked 0/1 minio ckf-1.7/stable 186 <IP_ADDRESS> no 0/1 nodes are available: 1 node(s) had untolerated taint {node.kubernetes.io/disk-pressure: }. preemption: 0/1 nodes .... That is a symptom of the machine running out of resources. We shall investigate a bit more.

I've seen this failure in some of our Juju CI before (just simple bootstrap/smoke tests). Probably something to do with K8s storage on GH runners, rather than an issue with the specific charm.

@barrettj12 it is so strange because we are actually using an action to increase the storage in our GH runners, plus for some folks this has happened in beefier machines. The strangest part is that this seems to resolve after a while in some cases.

Came across this when deploying CKF on microK8s deployed to an AWS EC2 Instance type of t3.2xlarge using Ubuntu image and having an 80GB volume. This happened for jupyter-controller charm.
Nothing insteresting in juju debug-log --replay --include application-jupyter-controller
Logs
application-jupyter-controller: 08:03:40 INFO juju.cmd running jujud [2.9.44 9b1d995577fda4545f9d3f227633eaa3948af7ea gc go1.20.5]
application-jupyter-controller: 08:03:40 DEBUG juju.cmd   args: []string{"/var/lib/juju/tools/jujud", "caasoperator", "--application-name=jupyter-controller", "--debug"}
application-jupyter-controller: 08:03:40 DEBUG juju.agent read agent config, format "2.0"
application-jupyter-controller: 08:03:40 INFO juju.worker.upgradesteps upgrade steps for 2.9.44 have already been run.
application-jupyter-controller: 08:03:40 INFO juju.cmd.jujud caas operator application-jupyter-controller start (2.9.44 [gc])
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "caas-units-manager" manifold worker started at 2023-08-08 08:03:40.752105275 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "agent" manifold worker started at 2023-08-08 08:03:40.752150301 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "caas-units-manager" manifold worker completed successfully
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "clock" manifold worker started at 2023-08-08 08:03:40.752323674 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.introspection introspection worker listening on "@jujud-application-jupyter-controller"
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "api-config-watcher" manifold worker started at 2023-08-08 08:03:40.75281497 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "upgrade-steps-gate" manifold worker started at 2023-08-08 08:03:40.752843541 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.introspection stats worker now serving
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "caas-units-manager" manifold worker started at 2023-08-08 08:03:40.762761058 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.apicaller connecting with old password
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "upgrade-steps-flag" manifold worker started at 2023-08-08 08:03:40.76417535 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.api looked up controller-service.controller-microk8s-localhost.svc.cluster.local -> [<IP_ADDRESS>]
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "migration-fortress" manifold worker started at 2023-08-08 08:03:40.775571726 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.api successfully dialed "wss://controller-service.controller-microk8s-localhost.svc.cluster.local:17070/model/bb9a51f1-9044-49dc-8174-307e1943c792/api"
application-jupyter-controller: 08:03:40 INFO juju.api connection established to "wss://controller-service.controller-microk8s-localhost.svc.cluster.local:17070/model/bb9a51f1-9044-49dc-8174-307e1943c792/api"
application-jupyter-controller: 08:03:40 INFO juju.worker.apicaller [bb9a51] "application-jupyter-controller" successfully connected to "controller-service.controller-microk8s-localhost.svc.cluster.local:17070"
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "api-caller" manifold worker started at 2023-08-08 08:03:40.781765193 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "caas-units-manager" manifold worker completed successfully
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "caas-units-manager" manifold worker started at 2023-08-08 08:03:40.79101777 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "upgrade-steps-runner" manifold worker started at 2023-08-08 08:03:40.791113897 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "upgrade-steps-runner" manifold worker completed successfully
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "migration-minion" manifold worker started at 2023-08-08 08:03:40.793410802 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "log-sender" manifold worker started at 2023-08-08 08:03:40.793487571 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "upgrader" manifold worker started at 2023-08-08 08:03:40.793555676 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "migration-inactive-flag" manifold worker started at 2023-08-08 08:03:40.794859219 +0000 UTC
application-jupyter-controller: 08:03:40 INFO juju.worker.migrationminion migration phase is now: NONE
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "charm-dir" manifold worker started at 2023-08-08 08:03:40.806019266 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "proxy-config-updater" manifold worker started at 2023-08-08 08:03:40.806143122 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "api-address-updater" manifold worker started at 2023-08-08 08:03:40.806223093 +0000 UTC
application-jupyter-controller: 08:03:40 DEBUG juju.worker.logger initial log config: "<root>=DEBUG"
application-jupyter-controller: 08:03:40 DEBUG juju.worker.dependency "logging-config-updater" manifold worker started at 2023-08-08 08:03:40.80632682 +0000 UTC
application-jupyter-controller: 08:03:40 INFO juju.worker.logger logger worker started
application-jupyter-controller: 08:03:40 INFO juju.worker.caasupgrader abort check blocked until version event received
application-jupyter-controller: 08:03:40 DEBUG juju.worker.caasupgrader current agent binary version: 2.9.44
application-jupyter-controller: 08:03:40 INFO juju.worker.caasupgrader unblocking abort check
application-jupyter-controller: 08:03:40 DEBUG juju.worker.logger reconfiguring logging from "<root>=DEBUG" to "<root>=INFO"
application-jupyter-controller: 08:03:40 WARNING juju.worker.proxyupdater unable to set snap core settings [proxy.http= proxy.https= proxy.store=]: exec: "snap": executable file not found in $PATH, output: ""
application-jupyter-controller: 08:03:40 INFO juju.worker.caasoperator.charm downloading ch:amd64/focal/jupyter-controller-607 from API server
application-jupyter-controller: 08:03:40 INFO juju.downloader downloading from ch:amd64/focal/jupyter-controller-607
application-jupyter-controller: 08:03:41 INFO juju.downloader download complete ("ch:amd64/focal/jupyter-controller-607")
application-jupyter-controller: 08:03:41 INFO juju.downloader download verified ("ch:amd64/focal/jupyter-controller-607")
application-jupyter-controller: 08:04:06 INFO juju.worker.caasoperator operator "jupyter-controller" started
application-jupyter-controller: 08:04:06 INFO juju.worker.caasoperator.runner start "jupyter-controller/0"
application-jupyter-controller: 08:04:06 INFO juju.agent.tools ensure jujuc symlinks in /var/lib/juju/tools/unit-jupyter-controller-0
application-jupyter-controller: 08:04:06 INFO juju.worker.leadership jupyter-controller/0 promoted to leadership of jupyter-controller
application-jupyter-controller: 08:04:06 INFO juju.worker.caasoperator.uniter.jupyter-controller/0 unit "jupyter-controller/0" started
application-jupyter-controller: 08:04:06 INFO juju.worker.caasoperator.uniter.jupyter-controller/0 resuming charm install
application-jupyter-controller: 08:04:06 INFO juju.worker.caasoperator.uniter.jupyter-controller/0.charm downloading ch:amd64/focal/jupyter-controller-607 from API server
application-jupyter-controller: 08:04:06 INFO juju.downloader downloading from ch:amd64/focal/jupyter-controller-607
application-jupyter-controller: 08:04:06 INFO juju.downloader download complete ("ch:amd64/focal/jupyter-controller-607")
application-jupyter-controller: 08:04:06 INFO juju.downloader download verified ("ch:amd64/focal/jupyter-controller-607")
application-jupyter-controller: 08:04:37 INFO juju.worker.caasoperator.uniter.jupyter-controller/0 hooks are retried true
application-jupyter-controller: 08:04:37 INFO juju.worker.caasoperator.uniter.jupyter-controller/0 found queued "install" hook
application-jupyter-controller: 08:04:38 INFO unit.jupyter-controller/0.juju-log Running legacy hooks/install.
application-jupyter-controller: 08:04:39 WARNING unit.jupyter-controller/0.juju-log 0 containers are present in metadata.yaml and refresh_event was not specified. Defaulting to update_status. Metrics IP may not be set in a timely fashion.

First part of results of kubectl logs jupyter-controller-776fcbf4bc-hh5kf -n kubeflow. I don't see anything related here as well. Is there a chance this pod got recreated? I ran a juju resolved jupyter-controller-0 before getting the logs.

Defaulted container "jupyter-controller" out of: jupyter-controller, juju-pod-init (init)
I0808 08:37:01.614048       1 request.go:665] Waited for 1.038423544s due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/apis/install.istio.io/v1alpha1?timeout=32s
1.6914838221678545e+09	INFO	controller-runtime.metrics	Metrics server is starting to listen	{"addr": ":8080"}
1.6914838221683755e+09	INFO	setup	starting manager
1.6914838221701238e+09	INFO	Starting server	{"kind": "health probe", "addr": "[::]:8081"}
1.6914838221701345e+09	INFO	Starting server	{"path": "/metrics", "kind": "metrics", "addr": "[::]:8080"}
1.6914838221702387e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1beta1.Notebook"}
1.6914838221702564e+09	INFO	controller.Culler	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1beta1.Notebook"}
1.691483822170275e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1.StatefulSet"}
1.6914838221702797e+09	INFO	controller.Culler	Starting Controller	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook"}
1.6914838221702847e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1.Service"}
1.6914838221702945e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *unstructured.Unstructured"}
1.691483822170307e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1.Pod"}
1.6914838221703138e+09	INFO	controller.notebook	Starting EventSource	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "source": "kind source: *v1.Event"}
1.691483822170319e+09	INFO	controller.notebook	Starting Controller	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook"}
1.6914838222729275e+09	INFO	controller.Culler	Starting workers	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "worker count": 1}
1.691483822273092e+09	INFO	controller.notebook	Starting workers	{"reconciler group": "kubeflow.org", "reconciler kind": "Notebook", "worker count": 1}

kubectl describe node ip-172-31-18-179

Name:               ip-172-31-18-179
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=ip-172-31-18-179
                    kubernetes.io/os=linux
                    microk8s.io/cluster=true
                    node.kubernetes.io/microk8s-controlplane=microk8s-controlplane
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    projectcalico.org/IPv4Address: <IP_ADDRESS>/20
                    projectcalico.org/IPv4VXLANTunnelAddr: <IP_ADDRESS>
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 08 Aug 2023 07:58:25 +0000
Taints:             <none>
Unschedulable:      false
Lease:
  HolderIdentity:  ip-172-31-18-179
  AcquireTime:     <unset>
  RenewTime:       Tue, 08 Aug 2023 09:20:26 +0000
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Tue, 08 Aug 2023 07:59:20 +0000   Tue, 08 Aug 2023 07:59:20 +0000   CalicoIsUp                   Calico is running on this node
  MemoryPressure       False   Tue, 08 Aug 2023 09:16:51 +0000   Tue, 08 Aug 2023 07:58:25 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Tue, 08 Aug 2023 09:16:51 +0000   Tue, 08 Aug 2023 07:58:25 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Tue, 08 Aug 2023 09:16:51 +0000   Tue, 08 Aug 2023 07:58:25 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Tue, 08 Aug 2023 09:16:51 +0000   Tue, 08 Aug 2023 07:58:57 +0000   KubeletReady                 kubelet is posting ready status. AppArmor enabled
Addresses:
  InternalIP:  <IP_ADDRESS>
  Hostname:    ip-172-31-18-179
Capacity:
  cpu:                8
  ephemeral-storage:  81106868Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             32512104Ki
  pods:               110
Allocatable:
  cpu:                8
  ephemeral-storage:  80058292Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             32409704Ki
  pods:               110
System Info:
  Machine ID:                    ec20d13942c55ebeb59a971d6829ba1e
  System UUID:                   ec20d139-42c5-5ebe-b59a-971d6829ba1e
  Boot ID:                       7aa6f4de-bff9-4c9b-8e9d-553aff575f4d
  Kernel Version:                5.19.0-1025-aws
  OS Image:                      Ubuntu 22.04.2 LTS
  Operating System:              linux
  Architecture:                  amd64
  Container Runtime Version:     containerd://1.5.13
  Kubelet Version:               v1.24.16-2+40f0d5a1bef7b4
  Kube-Proxy Version:            v1.24.16-2+40f0d5a1bef7b4
Non-terminated Pods:             (83 in total)
  Namespace                      Name                                                CPU Requests  CPU Limits   Memory Requests  Memory Limits          Age
  ---------                      ----                                                ------------  ----------   ---------------  -------------          ---
  kube-system                    calico-node-flmn4                                   250m (3%)     0 (0%)       0 (0%)           0 (0%)                 81m
  kube-system                    calico-kube-controllers-74959db457-2mnhq            0 (0%)        0 (0%)       0 (0%)           0 (0%)                 81m
  kube-system                    coredns-66bcf65bb8-mr7mg                            100m (1%)     0 (0%)       70Mi (0%)        170Mi (0%)             81m
  metallb-system                 controller-5d468955f-r2tqg                          100m (1%)     100m (1%)    100Mi (0%)       100Mi (0%)             80m
  metallb-system                 speaker-rzdhj                                       100m (1%)     100m (1%)    100Mi (0%)       100Mi (0%)             80m
  ingress                        nginx-ingress-microk8s-controller-mlv4h             0 (0%)        0 (0%)       0 (0%)           0 (0%)                 80m
  kube-system                    hostpath-provisioner-78cb89d65b-g2h8f               0 (0%)        0 (0%)       0 (0%)           0 (0%)                 80m
  controller-microk8s-localhost  controller-0                                        0 (0%)        0 (0%)       3Gi (9%)         3Gi (9%)               78m
  controller-microk8s-localhost  modeloperator-6645d9855d-5pknp                      0 (0%)        0 (0%)       0 (0%)           0 (0%)                 78m
  kubeflow                       modeloperator-6cd9dccc8d-2vrwt                      0 (0%)        0 (0%)       0 (0%)           0 (0%)                 78m
  kubeflow                       admission-webhook-operator-0                        0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       argo-controller-operator-0                          0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       argo-server-operator-0                              0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       jupyter-controller-operator-0                       0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       katib-controller-operator-0                         0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       istio-ingressgateway-0                              0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       admission-webhook-5dbbc5587f-tv7rp                  0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       dex-auth-0                                          0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       istiod-58687f9d68-5ls6r                             500m (6%)     0 (0%)       2Gi (6%)         0 (0%)                 75m
  kubeflow                       jupyter-ui-0                                        0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       katib-db-manager-0                                  0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       istio-pilot-0                                       0 (0%)        0 (0%)       0 (0%)           0 (0%)                 77m
  kubeflow                       katib-ui-0                                          0 (0%)        0 (0%)       0 (0%)           0 (0%)                 75m
  kubeflow                       argo-server-794d85d985-lgddb                        0 (0%)        0 (0%)       0 (0%)           0 (0%)                 76m
  kubeflow                       knative-eventing-0                                  0 (0%)        0 (0%)       0 (0%)           0 (0%)                 75m
  kubeflow                       kubeflow-roles-0                                    0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       kfp-viewer-operator-0                               0 (0%)        0 (0%)       0 (0%)           0 (0%)                 73m
  kubeflow                       knative-serving-0                                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       kfp-viz-operator-0                                  0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-profile-controller-operator-0                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-schedwf-operator-0                              0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-ui-operator-0                                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-persistence-operator-0                          0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       oidc-gatekeeper-operator-0                          0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       tensorboards-web-app-operator-0                     0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       kubeflow-volumes-operator-0                         0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       minio-operator-0                                    0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       tensorboard-controller-operator-0                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       metacontroller-operator-0                           0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       istio-ingressgateway-workload-5dcdfb989-92qd8       10m (0%)      2 (25%)      40Mi (0%)        1Gi (3%)               75m
  kubeflow                       katib-db-0                                          0 (0%)        0 (0%)       4Gi (12%)        4Gi (12%)              76m
  kubeflow                       kfp-db-0                                            0 (0%)        0 (0%)       4Gi (12%)        4Gi (12%)              75m
  kubeflow                       katib-controller-788c9557d8-xfn6n                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       kubeflow-dashboard-0                                0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       seldon-controller-manager-0                         0 (0%)        0 (0%)       0 (0%)           0 (0%)                 73m
  kubeflow                       metacontroller-operator-charm-0                     0 (0%)        0 (0%)       0 (0%)           0 (0%)                 73m
  kubeflow                       training-operator-0                                 0 (0%)        0 (0%)       0 (0%)           0 (0%)                 73m
  kubeflow                       kfp-viewer-57d8c7ff85-4fvkw                         0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-api-0                                           0 (0%)        0 (0%)       0 (0%)           0 (0%)                 75m
  kubeflow                       kfp-viz-674f44759f-7kn4j                            0 (0%)        0 (0%)       0 (0%)           0 (0%)                 72m
  kubeflow                       kfp-schedwf-846dcf5597-9fjt6                        0 (0%)        0 (0%)       0 (0%)           0 (0%)                 71m
  kubeflow                       tensorboards-web-app-75fd7f7844-7ckz5               0 (0%)        0 (0%)       0 (0%)           0 (0%)                 70m
  kubeflow                       kubeflow-volumes-6d6d4df675-bvq77                   0 (0%)        0 (0%)       0 (0%)           0 (0%)                 70m
  kubeflow                       tensorboard-controller-74cc66698c-2qrhp             0 (0%)        0 (0%)       0 (0%)           0 (0%)                 70m
  kubeflow                       minio-0                                             0 (0%)        0 (0%)       0 (0%)           0 (0%)                 70m
  kubeflow                       argo-controller-7bb96878f8-jh5h9                    0 (0%)        0 (0%)       0 (0%)           0 (0%)                 69m
  kubeflow                       kfp-profile-controller-6fbc6d4569-k2gw8             0 (0%)        0 (0%)       0 (0%)           0 (0%)                 69m
  kubeflow                       jupyter-controller-776fcbf4bc-hh5kf                 0 (0%)        0 (0%)       0 (0%)           0 (0%)                 75m
  knative-serving                autoscaler-bc7d6c9c9-87k8f                          100m (1%)     1 (12%)      100Mi (0%)       1000Mi (3%)            67m
  knative-serving                activator-5f6b4bf5c8-f2j6z                          300m (3%)     1 (12%)      60Mi (0%)        600Mi (1%)             67m
  knative-serving                controller-687d88ff56-t4n6g                         100m (1%)     1 (12%)      100Mi (0%)       1000Mi (3%)            67m
  knative-serving                domain-mapping-69cc86d8d5-lfq5g                     30m (0%)      300m (3%)    40Mi (0%)        400Mi (1%)             67m
  knative-serving                domainmapping-webhook-65dfdd9b96-27kwq              100m (1%)     500m (6%)    100Mi (0%)       500Mi (1%)             67m
  knative-serving                webhook-587cdd8dd7-k5z5p                            100m (1%)     500m (6%)    100Mi (0%)       500Mi (1%)             67m
  knative-serving                autoscaler-hpa-6469fbb6cd-cfzkt                     30m (0%)      300m (3%)    40Mi (0%)        400Mi (1%)             67m
  kubeflow                       knative-operator-0                                  0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  knative-eventing               eventing-webhook-7d5b577c94-tjfnd                   100m (1%)     200m (2%)    50Mi (0%)        200Mi (0%)             66m
  knative-serving                net-istio-controller-5fc4cc65f7-k6h2s               30m (0%)      300m (3%)    40Mi (0%)        400Mi (1%)             66m
  knative-serving                net-istio-webhook-6c5b7cbdd5-9bggq                  20m (0%)      200m (2%)    20Mi (0%)        200Mi (0%)             66m
  knative-eventing               imc-controller-769d8b7f66-d6v9b                     0 (0%)        0 (0%)       0 (0%)           0 (0%)                 66m
  knative-eventing               imc-dispatcher-55979cf74b-z68h9                     0 (0%)        0 (0%)       0 (0%)           0 (0%)                 66m
  knative-eventing               mt-broker-filter-56b5d6d697-2dmzp                   100m (1%)     0 (0%)       100Mi (0%)       0 (0%)                 66m
  knative-eventing               mt-broker-ingress-5c4d45dfd6-5fhj6                  100m (1%)     0 (0%)       100Mi (0%)       0 (0%)                 66m
  knative-eventing               mt-broker-controller-66b756f8bb-z5kjv               100m (1%)     0 (0%)       100Mi (0%)       0 (0%)                 66m
  knative-eventing               eventing-controller-7f448655c8-7d9fr                100m (1%)     0 (0%)       100Mi (0%)       0 (0%)                 67m
  kubeflow                       kfp-persistence-54b57dc756-chzg8                    0 (0%)        0 (0%)       0 (0%)           0 (0%)                 62m
  kubeflow                       kserve-controller-0                                 0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       kubeflow-profiles-0                                 0 (0%)        0 (0%)       0 (0%)           0 (0%)                 74m
  kubeflow                       kfp-ui-6d79ddcf79-bws8p                             0 (0%)        0 (0%)       0 (0%)           0 (0%)                 62m
  kubeflow                       oidc-gatekeeper-697dc55959-bz2dq                    0 (0%)        0 (0%)       0 (0%)           0 (0%)                 38m
  kubeflow-user                  ml-pipeline-ui-artifact-5675b8f595-8b9d6            110m (1%)     2100m (26%)  198Mi (0%)       1524Mi (4%)            36m
  kubeflow-user                  ml-pipeline-visualizationserver-5568776585-9bxc5    150m (1%)     2500m (31%)  328Mi (1%)       2Gi (6%)               36m
  kubeflow-user                  vscode-0                                            1100m (13%)   3200m (40%)  8320Mi (26%)<PHONE_NUMBER>4400m (34%)  35m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests       Limits
  --------           --------       ------
  cpu                3730m (46%)    15300m (191%)
  memory             23518Mi (74%)<PHONE_NUMBER>4400m (102%)
  ephemeral-storage  0 (0%)         0 (0%)
  hugepages-1Gi      0 (0%)         0 (0%)
  hugepages-2Mi      0 (0%)         0 (0%)
Events:              <none>

@NohaIhab this may affect the CKF 1.8 release, we may want to prioritise a fix for the issue.
cc: @kimwnasptd

This error message suggests there is an error when pulling the image from the registry.jujucharms.com container registry, but this information has to be confirmed because these are sometimes linked to low storage.

Are we sure this is linked to low storage? From my experience ImagePullBackOff has happened only when the image that we want to pull doesn't exist at all. If that's the case could it have to do something with

how our GH actions are bundling images to registry.jujucharms.com when we publish a charm
how our CI is running publishing/deploying the charms to run

??
Yes, let's prioritise this bug from next pulse. The first thing I would check is to indeed make sure that the ImagePullBackOff bug doesn't happen due to low storage.

Just another bump. This issue happening constantly in deployment of KF on GCP:
kserve-controller/0*          error        idle   <IP_ADDRESS>                     unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/9sv4hhxzp6mbtgn0yn...
kubeflow-profiles/0*          error        idle   <IP_ADDRESS>                     unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/4jn95wlrsfo1po9wfu...
katib-controller/0*           error        idle   <IP_ADDRESS>  443/TCP,8080/TCP   crash loop backoff: back-off 5m0s restarting failed container=katib-controller pod=katib-controller-596dfcf6f6-6n8b4_...

I saw something interesting in another PR, where I saw ImagePullBackOff errors
https://github.com/canonical/kfp-operators/actions/runs/5979649899/job/16224169467?pr=269
It happened in KFP API tests which

Deploy kfp-api charm from local charm file, and use the upstream docker image directly
Deploy the kfp-viz charm from CharmHub
Deploy the minio charm from CharmHub

What ended up happening is the kfp-viz and minio Charms were initially getting ImagePullBackOff errors, but then ended up becoming active.
Specifically these were the relevant (pytest) logs:
INFO     juju.model:model.py:2618 Waiting for model:
  kfp-api/0 [allocating] waiting: agent initializing
  kfp-viz/0 [allocating] waiting: installing agent
  kfp-db/0 [allocating] waiting: installing agent
  minio/0 [allocating] waiting: installing agent
...
INFO     juju.model:model.py:2618 Waiting for model:
  kfp-viz/0 [idle] active:
  minio/0 [idle] active:
...
INFO     juju.model:model.py:2618 Waiting for model:
  kfp-viz/0 [idle] error: unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/c2o31yht1y825t6n49mwko4wyel0rracnrjn5/oci-image@sha256:3de6f3cae504f087ecdae39063d6b0557d8ce20e4948ef0a4f8afba6c3e3cf27"
  minio/0 [idle] active:
...
INFO     juju.model:model.py:2618 Waiting for model:
  kfp-viz/0 [idle] error: unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/c2o31yht1y825t6n49mwko4wyel0rracnrjn5/oci-image@sha256:3de6f3cae504f087ecdae39063d6b0557d8ce20e4948ef0a4f8afba6c3e3cf27"
  minio/0 [idle] error: unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/81j63o4a2ldarn1umc22iyjz1q9l9g0sx5b8j/oci-image@sha256:1755999849a392bdf00b77[87](https://github.com/canonical/kfp-operators/actions/runs/5979649899/job/16224169467?pr=269#step:5:88)05f4cf5c1c971a1ef55a17e9075e56f8d58bdc2f"
...
INFO     juju.model:model.py:2618 Waiting for model:
  kfp-viz/0 [idle] active:
  minio/0 [idle] error: unknown container reason "ImagePullBackOff": Back-off pulling image "registry.jujucharms.com/charm/81j63o4a2ldarn1umc22iyjz1q9l9g0sx5b8j/oci-image@sha256:1755999849a392bdf00b778705f4cf5c1c971a1ef55a17e9075e56f8d58bdc2f"
...
INFO     juju.model:model.py:2618 Waiting for model:
  minio/0 [idle] active:
PASSED

@barrettj12 I think this means that the problem is not disk space, since they end up fetching the images, but rather some other transient error we need to understand. Do you think otherwise? Do you have any suggestions on how we could tackle and debug this further?

According to the snap store team (comment here), the issue "could be related to load spikes on the VMs running the registry." The team has increased the resources on those machines to prevent the issue and we should stop running into it.
I'm leaving this issue open until we stop seeing the error, will check back in a week.


Create issue on Nextra repo on focus and tab ordering on article pages

Uffda, missing explanations and screenshots. A quick test did not trigger the memory on the details of the issue.


feat:sftp support relative path

Codecov Report
Patch coverage: 90.90% and project coverage change: -0.02 :warning:

Comparison is base (f1b27fc) 98.14% compared to head (f50cc72) 98.12%.

:exclamation: Current head f50cc72 differs from pull request most recent head ae5e71e. Consider uploading reports for the commit ae5e71e to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #256      +/-   ##
==========================================
- Coverage   98.14%   98.12%   -0.02%
==========================================
  Files          37       37
  Lines        5108     5107       -1
==========================================
- Hits         5013     5011       -2
- Misses         95       96       +1

Impacted Files
Coverage Δ

megfile/sftp_path.py
91.03% <90.90%> (-0.12%)
:arrow_down:

... and 4 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[docs] Further template the CSS API descriptions

Minimise manual translations on Crowdin

The review of the API generation is a bit more challenging now. I feel the need to display the HTML output.

I was conscious of the trade-off. If it proves to be a problem, it should be straightforward to test that the "reconstructed" string matches the source.

The review of the API generation is a bit more challenging now. I feel the need to display the HTML output.

I was conscious of the trade-off. If it proves to be a problem, it should be straightforward to test that the "reconstructed" string matches the source.

The review of the API generation is a bit more challenging now.

I've simplified it, so it should be much clearer now.

The review of the API generation is a bit more challenging now.

I've simplified it, so it should be much clearer now.


Pass the index of the object to a block when using *_list methods

When using one of the *_list methods, allow the block to receive the object's index.
posts = build_list(:post, 10, title: 'Post number') do |post, i|
  post.title = "#{post.title} #{i + 1}"
end

posts.first.title # => "Post number 1"
# ...
posts.last.title  # => "Post number 10"

I had played around with something similar a while back (see https://github.com/thoughtbot/factory_bot/tree/dc-list-index-play). One thing to consider is that calling the block with a different number of arguments could be a breaking change if anyone is passing in a lambda (lambdas raise an ArgumentError if you pass the wrong number of arguments).
@aledustet 's comment about introducing a new *_list_with_index method rather than changing the existing methods would solve this. That might be the cleanest approach. On my branch I was doing an arity check.
We should also add some documentation for this so people can find and use it.

Closing since there hasn't been activity for a while. I am not opposed to this change, and if anybody wants to take this to the finish line please feel free to open a separate PR (preserving the commit of the original author).

I'd love this change, and would like to get it done! Here's the new PR for it ⬆


Add Code Formatter to follow defined Code Style

Hi.
Can you add your used Code Formatting Rules. I personally prefer it for IntelliJ IDEA, but whatever you have, it will help.
So ta4j project use Eclipse Code-Formatter XML. Might be, you can have a look there and use this.
Thanks,
André.

I also use IntelliJ IDEA for auto-formatting. To be honest, it's been ages since I configured it, but what I definitely changed is to use tabs as the default indent for all languages.
Until recently, I didn't know the formatter-maven-plugin used by the ta4j project, it seems to be a pretty useful tool to make code formatting independend of any IDE. Maybe I will add this Maven plugin to ta4j-extended, but I don't know when I have time for it.

I hope I didn't sound too harsh on your last PR, it's just not nice when the Git history shows almost all lines changed, simply to an automatic conversion from tabs to spaces. ;-)

No, it's understandable that you take care of your code style. i will do the same with my code and i have my own code style. ;-)
Can you export your intellij format settings and add to your project? I will reformat my code with that code style.
Thanks.

As Information: In my Fork (https://github.com/Andre0711er/ta4j-extended) i just added the code formatter with plugin which is used on ta4j parent project
is deadly easy to use it:
mvn formatter:format
cleans whole code based on defined formatter xml file.
might be a good idea, to bring it on same level as ta4j main project.

I'll take a look soon :+1:


Split out Writer code from EXtra-data

This is an initial implementation of a library for writing EuXFEL files.
The implementation is split out from EXtra-data/writer2-alt.
Features:

writing multi-train arrays at once
writing data by trains
check of data consistency
buffering (direct writing is also an option)
automatic sequence splitting
aliases for source name
parameterization of datasets and sources
constructor in plain style

For details, see European-XFEL/EXtra-data#181

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@e541f4c). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   78.08%
=======================================
  Files           ?        4
  Lines           ?      616
  Branches        ?        0
=======================================
  Hits            ?      481
  Misses          ?      135
  Partials        ?        0

Continue to review full report at Codecov.

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


Python 3.7 support

When is Python 3.7 support coming for creating docs with RTD? Sphinx already supports it and we can create the docs ourselves with no issue but when using RTD, we get errors regarding missing imports that only exist in 3.7.

Hi @naor2013! Unfortunately, we don't have this into our roadmap yet.
I'm not sure if this could be part of our 4.0 Docker image or not: https://github.com/rtfd/readthedocs-docker-images
I think it shouldn't be a big change in the image (just add 3.7 from pyenv) but what is taking some time is testing and deploy the images.

Thanks! Thanks. For now, we'll make our own docs so we can wait. take your time and keep doing an awesome job! :D

You can also skip installation of those dependencies and mock them out in your docs. Agreed that 3.7 would be helpful though, I think we can add it to our 4.1 RC image. Moving this to rtfd/readthedocs-docker-images#72

@naor2013 You can use conda to do 3.7 at the moment if it is a pressing need.  See https://github.com/rtfd/readthedocs-docker-images/pull/73 for notes and a patch.


Too much existentialism allowed. needs more moderation smh

joke

Joke or not, be warned: this game will become highly existential over time. Now would be a great time to brush up on your Kierkegaard.


Support for VK_KHR_shader_float16_int8 float16 capability

Hi,
already opened SPIRV-Cross issue..
https://github.com/KhronosGroup/SPIRV-Cross/issues/783
interested in float16 part of the spec.. altough int8 support would be nice also.. don't know if Metal also supports it natively..
maybe it's very easy to implement seeing:
https://github.com/KhronosGroup/MoltenVK/issues/86
thanks..

Just as soon as Vulkan-Headers picks up the 1.1.95 changes...


Feature/automatic reverse domain creation

I've created my own non solution of creating auto PTR records. This way is different from #102
In my pull request I've solved the automatic reverse domain creation with the user privileges of the original domain. And now I working on the record deleting and updating. In this case it isn't necessary to send set-ptr: auto in PATCH to pdnsd, and it is working on older version <4.0.0 of it.
I'll create in this pull request the following things:

[x] safely update, delete the existing ptr records
[x] ability on gui to choose of creating ptr records from A or AAAA

Please review my solution and discuss.
UPDATE:
I'll create a NATIVE auto-ptr functionality to my own
* [ ] Use pdnsd set-ptr record
UPDATE2:
I see that the native version of auto-ptr functionality isnt working very well in all conditions.

I finished it, ready to pull ;)

@petersipos will it be possible to create one "10.in-addr.arpa" zone instead of "1.0.10.in-addr.arpa", "2.0.10.in-addr.arpa", etc?

@olfway Hmm well, it needs to support A and B type of IP addresses not just C... hmm yeah.
But this feature doesn't support it yet.

@petersipos maybe it should do something like this?

check if "1.0.10.in-addr.arpa" exists and then use it
check if "0.10.in-addr.arpa" exists and then use it
check if "10.in-addr.arpa" exists and then use it
if nothing found, then create "1.0.10.in-addr.arpa" and use it

i used <IP_ADDRESS> as example here, it should do the same for any ip address

Haven't read the code yet -- but does this PR also address IPv6 PTRs?

@jallakim Yes it creates the reverse domain for ipv6 addresses too and also creates the IPv6 PTRs...
@olfway I try to figure out an elegant solution for this request :)

@petersipos, then the discussion you're having (1.0.10.in-addr.arpa vs. 10.in-addr.arpa) is just as relevant (if not more relevant) for IPv6 PTRs.

I also have to verifiy if this breaks PRETTY_IPV6_PTR (my "problem", not yours, I guess).

@jallakim it works fine with the PRETTY_IPV6_PTR settings
Yes I agree, the support of IP classes is relevant, but when we speak about IPv4 adresses we have just 3 class types (A,B,C quiet simple...) but in IPv6 this task began will be more difficult.
The most difficutl question is, how can we give an elegant and user friendly solution in the GUI to manage the required IP classes.

@olfway Yes it will be maybe a simple solution for IPv4 addresses.

@petersipos from dns point of view, there is no A, B or C classes, it's just subdomains
so for ipv6 zone "<IP_ADDRESS>.8.b.d.<IP_ADDRESS>.2.ip6.arpa."
you can check exact domain first and if it's not found, strip one subdomain and check again (up to ip6.arpa?)
if nothing found - create "<IP_ADDRESS>.8.b.d.<IP_ADDRESS>.2.ip6.arpa."

yes is it possible, and simple.

@olfway and @jallakim I've finished the corrections what you mentioned. (The same way as you mentioned). Please check it.
Now this modification check the existing reverse lookup domain zones from the highest level, and if find one add the PTR records there. If not exists create the lowest possible reverse lookup domain zone and create the PTRs there. Also works with IPv4 and IPv6.
When I check the IPv6 domain I check just the domains:
1.3.f.7.[b.c.e.f.f.f.9.2.c.<IP_ADDRESS>.<IP_ADDRESS>.<IP_ADDRESS>.<IP_ADDRESS>.8.e.f.ip6.arpa.] (in thre brackets)
Maybe I may check all of the digits?

@petersipos thanks!
from the code, it seems that it will auto-create "in-addr.arpa" zone in case it will not find more specific one
am i right?

no, it whouldn't create in-addr.arpa, just eg. 192.in-addr.arpa
You need to create an in-addr.arpa zone? Isn't so difficult to modify, but it sounds a littlebit wired to me.

The PR is ready :)

@ngoduykhanh hello! What do you think about this PR? Did you have time to overlook this? :) Thank for reply ;)

@petersipos : Sorry for the delay, I didn't have time to look at this. I will review your PR. Thanks a lot.

Only I inquired :) non urgent. Thanks.

@petersipos : Your changes look good to me. Merging. Thanks for this awesome PR!


Adguard Sync Error 403 Forbidden

I have 2 Adguard instances set up on two separate Google Cloud VPSs.  They are not set up in docker.  I have firewall rules to allow ports 8080, 80, and 443.  I set up Adguard sync on a separate docker server according to the instructions provided and instructions I found in a couple of YouTube videos.  When I published the container, I get the following error in the logs.
2023-12-18T16:21:20.639Z	ERROR	sync	sync/sync.go:153	Error getting origin status	{"from": "<IP_ADDRESS>:80", "error": "403 Forbidden(Forbidden)"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:153
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/go/src/app/pkg/sync/sync.go:76
I can ping each of the adguard instances from the docker server, and I can reach the management console websites for each of the adguard instances.  I'm at a loss for what's happening.  Any help would be appreciated.

Hi @smorgan134
Please provide debug logs, otherwise I an not assist you: https://github.com/bakito/adguardhome-sync?tab=readme-ov-file#log-level

Where can I get the debug logs?

By setting the env variable LOG_LEVEL=debug

Here is the log entry I get...
2023-12-19T17:05:16.684Z	INFO	sync	sync/sync.go:38	AdGuardHome sync	{"version": "v0.5.2", "build": "2023-11-23T07:13:51Z", "os": "linux", "arch": "amd64"}
2023-12-19T17:05:16.685Z	DEBUG	sync	types/types.go:70	Using config	{"config": {"origin":{"url":"http://<IP_ADDRESS>","apiPath":"/control","username":"mn","password":"e$","insecureSkipVerify":false,"autoSetup":false,"interfaceName":""},"replica":{"url":"http://<IP_ADDRESS>","apiPath":"/control","username":"mn","password":"e$","insecureSkipVerify":false,"autoSetup":false,"interfaceName":""},"cron":"*/1 * * * ","runOnStart":true,"api":{"port":8080},"features":{"dns":{"accessLists":true,"serverConfig":true,"rewrites":true},"dhcp":{"serverConfig":true,"staticLeases":true},"generalSettings":true,"queryLogConfig":true,"statsConfig":true,"clientSettings":true,"services":true,"filters":true}}}
2023-12-19T17:05:16.685Z	INFO	sync	sync/sync.go:65	Setup cronjob	{"cron": "/1 * * * *", "next-execution": "2023-12-19T17:06:00.000Z"}
2023-12-19T17:05:16.685Z	INFO	sync	sync/http.go:57	Starting API server	{"port": 8080}
2023-12-19T17:05:16.685Z	INFO	sync	sync/sync.go:75	Running sync on startup
2023-12-19T17:05:16.686Z	DEBUG	client	client/client-methods.go:16	do get	{"host": "<IP_ADDRESS>", "method": "GET", "path": "status", "username": "mvadmin"}
2023-12-19T17:05:16.768Z	DEBUG	client	client/client-methods.go:32	got response	{"host": "<IP_ADDRESS>", "method": "GET", "path": "status", "username": "mvadmin", "status": 403, "body": "Forbidden", "content-type": ["text/plain; charset=utf-8"]}
2023-12-19T17:05:16.768Z	ERROR	sync	sync/sync.go:153	Error getting origin status	{"from": "<IP_ADDRESS>", "error": "403 Forbidden(Forbidden)"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:153
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/go/src/app/pkg/sync/sync.go:76

403 means something is wrong with authentication.
How is your config?
How do you start the container?
Did you chechk https://github.com/bakito/adguardhome-sync/wiki/FAQ ?

Here is my docker-compose file...
version: "2.1"
services:
adguardhome-sync:
image: ghcr.io/bakito/adguardhome-sync
container_name: adguardhome-sync
command: run
environment:
LOG_LEVEL: "debug"
ORIGIN_URL: "http://<IP_ADDRESS>"
ORIGIN_USERNAME: "username"
ORIGIN_PASSWORD: 'password with special characters'
REPLICA_URL: "http://<IP_ADDRESS>"
REPLICA_USERNAME: "username"
REPLICA_PASSWORD: 'password with special characters'
CRON: "*/1 * * * *"
RUNONSTART: true
ports:
- 8080:8080
restart: unless-stopped
I changed the double quotes I had around the password for single quotes like it suggests because my password has special characters.  It is still giving me the same error.  See log below.
2023-12-19T17:33:00.030Z	DEBUG	client	client/client-methods.go:16	do get	{"host": "<IP_ADDRESS>", "method": "GET", "path": "status", "username": "mvadmin"}
2023-12-19T17:33:00.114Z	DEBUG	client	client/client-methods.go:32	got response	{"host": "<IP_ADDRESS>", "method": "GET", "path": "status", "username": "mvadmin", "status": 403, "body": "Forbidden", "content-type": ["text/plain; charset=utf-8"]}
2023-12-19T17:33:00.114Z	ERROR	sync	sync/sync.go:153	Error getting origin status	{"from": "<IP_ADDRESS>", "error": "403 Forbidden(Forbidden)"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:153
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func2
/go/src/app/pkg/sync/sync.go:59
github.com/robfig/cron/v3.FuncJob.Run
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:136
github.com/robfig/cron/v3.(*Cron).startJob.func1
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:312

can you reach the adguardhome instances from the server where adguardhome is running?
curl -u '<username>:<password>' http://<IP_ADDRESS>/control/status -v

or with special characters
export AGH_AUTH=$(echo -n '<username>:<password>' | base64)
curl -H "Authorization: Basic ${AGH_AUTH}" http://<IP_ADDRESS>/control/status -v

Please also check the logs of adguardhome, any errors there?

This is what I got using...
export AGH_AUTH=$(echo -n ':' | base64)
curl -H "Authorization: Basic ${AGH_AUTH}" http://<IP_ADDRESS>/control/status -v

Trying <IP_ADDRESS>:80...
Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 80 (#0)

GET /control/status HTTP/1.1
Host: <IP_ADDRESS>
User-Agent: curl/7.81.0
Accept: /
Authorization: Basic bXZhZG1pbjplZ3IxTVVTRSRlZ3IxTVVTRSQ=

Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: AdGuardHome/v0.107.43
< Vary: Accept-Encoding
< Date: Tue, 19 Dec 2023 19:41:54 GMT
< Content-Length: 245
<
{"version":"v0.107.43","language":"","dns_addresses":["<IP_ADDRESS>","::1","<IP_ADDRESS>","fe80::4001:aff:fe86:3204%ens4"],"dns_port":53,"http_port":80,"protection_disabled_duration":0,"protection_enabled":true,"dhcp_available":true,"running":true}
Connection #0 to host <IP_ADDRESS> left intact

I'm not sure where to find the Adguard Log files.

do you have dollar signs in your password, then you'll need to escape them according to docker-compose documentation:
https://github.com/compose-spec/compose-spec/blob/master/spec.md#interpolation
Password: 'my$ecurePWD' -> docker-compose 'my$$ecurePWD'

You can use a $$ (double-dollar sign) when your configuration needs a literal dollar sign. This also prevents Compose from interpolating a value, so a $$ allows you to refer to environment variables that you don't want processed by Compose.

I got the dollar signs out of my password and did the trick! Thanks for your help!


Enhancement: More information about plugins

Contact Details
No response
What features would you like to see added?
When browsing the plugin store, you only get a short description and an icon.
There is no information, if this plugin is "built-in", if it got sourced from somewhere else, if it makes API calls to somewhere else, no developer information, no privacy policy, nothing.
For example, the Web Search plugin.
I search through this repo and couldn't find any reference to where this Plugin is the defined, where it gets 'sourced' from and so on.
So I took a look at the /api/plguins request and saw that the icon for this plugin is loaded from https://websearch.plugsugar.com/. After this, I searched for this link in the repo and only then found it. https://github.com/danny-avila/LibreChat/blob/main/api/app/clients/tools/.well-known/web_search.json
There is at least some contact information and a website for it, so the data would be there.
More details
What I really like on chat.openai.com is, that if a GPT makes a web request, it will ask the user first, if it should be allowed to make a web request to "example.com". And then there are the buttons, allow, always allow or deny. And it needs to have a privacy policy attached to be published.

But this could be another feature request
Which components are impacted by your request?
UI, Plugins
Pictures
No response
Code of Conduct

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

if a GPT makes a web request, it will ask the user first, if it should be allowed to make a web request to "example.com".

This is a new behavior, and the current plugin system mimics the old way where this was never done.
I was unaware you could toggle the asking on/off for GPTs and I'll have to keep that in mind.
GPTs are coming to LibreChat. That said, I may just add these warnings to the plugin store descriptions, since the plugins system will be somewhat be deprecated in favor of GPTs and don't want to invest a lot of time adding the complexity here. I may revisit it later for non-OpenAI LLMs
I'll keep this in mind to mimic the behavior for GPTs as much as possible.

@danny-avila sorry to hijack this issue, but I just saw, that the plugins mode always uses 'gpt-4' even though I have selected gpt-4 turbo (gpt-4-1106-preview) in the dropdown, and I also don't have gpt-4 in the PLUGIN_MODELS. Any idea why that is?

ah yes I know why, a bit of an oversight. Going to fix this now and write some unit tests for it


Mssql app filter

Enables MSSQL and AAP filters. We need to send insights-mssql-system and insights-ansible-system with the Appollo client request headers to filter by respective new filters.

On stage/beta env, systems table is not reacting to global filter changes. This is fixed by storing changed global filters in Appollo client cache and providing those filters into customFilters prop of the InventoryTable component to force the table reload new data. According to docs, saving any data type to that cache is safe.

Fixes Lint configuration and errors.

@RedHatInsights/team-interact a review is appreciated!

@MichalSajdik thanks for the review :)


#427 preserve JSON key order in output if supported

Because 2.6 does not support object_pairs_hook, this behaviour only kicks in on 2.7 or later.

Coverage decreased (-0.03%) to 93.563% when pulling 02457fb455c0111c433c6b9d4c79461a77401872 on carlfish:squashed into 497a91711af7c97dcb70fe113a11cd90a7e070fd on jkbrzt:master.

Coverage decreased (-0.03%) to 93.563% when pulling e5e4eef9c6fadb7fd09165d1bc662f50442c06e4 on carlfish:squashed into 497a91711af7c97dcb70fe113a11cd90a7e070fd on jkbrzt:master.

Coverage decreased (-0.03%) to 93.563% when pulling e5e4eef9c6fadb7fd09165d1bc662f50442c06e4 on carlfish:squashed into 497a91711af7c97dcb70fe113a11cd90a7e070fd on jkbrzt:master.

If you're making this change then please (should it be approved) also add a change to the readme to reflect this, there is currently a reference to ordering in the readme (16 - Terminal output)

Coverage increased (+0.005%) to 93.6% when pulling eaf49595e06d36f1d4adabb370b823bb870ea491 on carlfish:squashed into 497a91711af7c97dcb70fe113a11cd90a7e070fd on jkbrzt:master.

Any movement on this? Would like to see this merged.

from the main project README it's already saying Python3 preferred, could you also declare the minimum requirement is Python2.7 and then no support for Python2.6 and below;
Then merge it for #427 please; waited too long time.

the whole Python2 deprecated;   some maintainer can take a look of the pending PRs?   from contributor graphs it looks like @jakubroztocil @msabramo still active?

I need this modification :(

Just released v2.2.0 that addresses this issue. Learn about about the new --unsorted, --sorted and --format-options here: https://httpie.org/docs#colors-and-formatting


Improve the node & faucet logs

As evidenced in #483, our logs are missing useful context.
A lot of this context is going missing because we are using structured error enums which aren't encapsulating the inner error.
Common suggestion is to prefer anyhow for errors in an application as usually we don't care about the what, only that an error happened. For libs instead thiserror/structure errors are suggested but these are just guidelines.
In general, we should use anyhow if we don't care to match on the exact error variant.

Common suggestion is to prefer anyhow for errors in an application as usually we don't care about the what, only that an error happened. For libs instead thiserror/structure errors are suggested but these are just guidelines.

I think this is roughly how things work now, no? Basically, we use thiserror in the libs and use anyhow in the miden-node binary.

I think this is roughly how things work now, no? Basically, we use thiserror in the libs and use anyhow in the miden-node binary.

Correct; however these are just rough rules of thumb. The more accurate gauge is whether one cares about the error variants at all. Or put slightly differently - are our rpc, store and block-producer crates libraries, or are they just components on the node binary split into separate crates for organization/decoupling purposes?
Semantic games aside though, we just need to ensure that we don't lose any important context along the way. Something like anyhow makes that easier, but this is of course just as possible with thiserror or the other error types - just a bit more effort and care required. Though one does lose line info which could be helpful in logs.

Hmm now that I've logged on to the actual instance, the logs provided initially seem to be truncated.
Error: Failed to serve store: initialisation of the Api has failed: Genesis block error: Failed to read genesis file "./genesis.dat": No such file or directory (os error 2)

On site logs appear to be fine ito context so maybe this is a non-issue. Could be worth taking a look regardless.

Related to #499.


Closes #48: Adds .hcl file support.

Adds .hcl as part of the files that are considered written in Terrafom
This PR would resolve #48

Sorry for my late reaction, I must have overlooked setting notifications up correctly, done now.
Thanks for your sensible contribution, will merge now :)


The role of the Master node is displayed abnormally

Our cluster has three master nodes, including the leader, but all three master nodes are displayed as follower.

What's the problem with this?


note io-streams supports purely/impurely

io-streams now supports purely and impurely via fold_ and foldM_
See https://hackage.haskell.org/package/io-streams-<IP_ADDRESS>/docs/System-IO-Streams-Combinators.html#g:1  I modified the documentation of purely to bring this out. This maintains the idea of registering when libraries support purely unless there come to be more than a few, as was done with mono-traversable.  I'm not sure it's well worded, see what you think.

This looks great to me!