addMany() methods for links, scripts and stylesheets.

addMany() methods in links, scripts and stylesheets helpers could reduce the need of re-defining a lot of parameters for all the paths.

This doesn't make much sense in JSP/Facelets EL, as there is no simple solution for composing arrays/lists, which means it would only complicate stuff.


[tfchain val] test a sync with new prune flags

https://github.com/threefoldtech/grid_deployment/commit/e4de06b7c9ece11da35c57805e9e843995174485

on a node that is setup correctly, I'm not able to find peers on devnet to sync
root@zos-tst ~/grid_deployment/tfchain-validator/devnet # docker logs tfchain-validator
2024-09-04 14:03:34.080  INFO main sc_cli::runner: Substrate Node
2024-09-04 14:03:34.081  INFO main sc_cli::runner: ✌  version 2.7.0-rc4-unknown
2024-09-04 14:03:34.081  INFO main sc_cli::runner: ❤  by<EMAIL_ADDRESS>2017-2024
2024-09-04 14:03:34.081  INFO main sc_cli::runner: 📋 Chain specification: TF Chain Devnet
2024-09-04 14:03:34.081  INFO main sc_cli::runner: 🏷  Node name: dev-val-sync-tst
2024-09-04 14:03:34.081  INFO main sc_cli::runner: 👤 Role: AUTHORITY
2024-09-04 14:03:34.081  INFO main sc_cli::runner: 💾 Database: RocksDb at /storage/chains/tfchain_devnet/db/full
2024-09-04 14:03:34.275  WARN main sc_service::config: Using default protocol ID "sup" because none is configured in the chain specs
2024-09-04 14:03:34.275  INFO main sub-libp2p: 🏷  Local node identity is: 12D3KooWHe3EhmkiBQExosLMknMUzidiRLYifyNsAecdM1WyY8JL
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Operating system: linux
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 CPU architecture: x86_64
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Target environment: gnu
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 CPU: 12th Gen Intel(R) Core(TM) i5-12500
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 CPU cores: 6
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Memory: 64108MB
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Kernel: 6.8.0-40-generic
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Linux distribution: Ubuntu 22.04.3 LTS
2024-09-04 14:03:34.279  INFO main sc_sysinfo: 💻 Virtual machine: no
2024-09-04 14:03:34.279  INFO main sc_service::builder: 📦 Highest known block at #0
2024-09-04 14:03:34.279  INFO                 main sc_rpc_server: Running JSON-RPC server: addr=<IP_ADDRESS>:9944, allowed origins=["http://localhost:*", "http://<IP_ADDRESS>:*", "https://localhost:*", "https://<IP_ADDRESS>:*", "https://polkadot.js.org"]
2024-09-04 14:03:34.279  INFO tokio-runtime-worker substrate_prometheus_endpoint: 〽 Prometheus exporter started at <IP_ADDRESS>:9615
2024-09-04 14:03:39.280  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:03:44.281  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:03:49.282  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:03:54.282  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:03:59.283  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:04.284  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:09.284  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:14.285  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:19.285  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:24.286  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:29.287  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:34.287  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:39.288  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:44.289  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0
2024-09-04 14:04:49.289  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xbb7f…66be), finalized #0 (0xbb7f…66be), ⬇ 0 ⬆ 0

sync issue resolved with correct image version (that includes the bootnodes): https://github.com/threefoldtech/grid_deployment/commit/9770d7fb0fa0d239448962d90b9600e19df875b7
Sync test started: https://telemetry.tfchain.grid.tf/#list/0xbb7f298ba5fca8802040061ddd0ca6406832238b7825ebfa66927cc25ec666be
root@zos-tst ~/grid_deployment/tfchain-validator/devnet # docker logs tfchain-validator
2024-09-04 14:18:32.519  INFO main sc_cli::runner: Substrate Node
2024-09-04 14:18:32.519  INFO main sc_cli::runner: ✌  version 2.9.0-unknown
2024-09-04 14:18:32.519  INFO main sc_cli::runner: ❤  by<EMAIL_ADDRESS>2017-2024
2024-09-04 14:18:32.519  INFO main sc_cli::runner: 📋 Chain specification: TF Chain Devnet
2024-09-04 14:18:32.519  INFO main sc_cli::runner: 🏷  Node name: dev-val-sync-tst
2024-09-04 14:18:32.519  INFO main sc_cli::runner: 👤 Role: AUTHORITY
2024-09-04 14:18:32.519  INFO main sc_cli::runner: 💾 Database: RocksDb at /storage/chains/tfchain_devnet/db/full
2024-09-04 14:18:33.088  INFO main sc_service::client::client: 🔨 Initializing Genesis block/state (state: 0x6a2e…4030, header-hash: 0xbb7f…66be)
2024-09-04 14:18:33.091  INFO main grandpa: 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2024-09-04 14:18:33.224  WARN main sc_service::config: Using default protocol ID "sup" because none is configured in the chain specs
2024-09-04 14:18:33.224  INFO main sub-libp2p: 🏷  Local node identity is: 12D3KooWHe3EhmkiBQExosLMknMUzidiRLYifyNsAecdM1WyY8JL
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Operating system: linux
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 CPU architecture: x86_64
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Target environment: gnu
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 CPU: 12th Gen Intel(R) Core(TM) i5-12500
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 CPU cores: 6
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Memory: 64108MB
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Kernel: 6.8.0-40-generic
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Linux distribution: Ubuntu 22.04.4 LTS
2024-09-04 14:18:33.228  INFO main sc_sysinfo: 💻 Virtual machine: no
2024-09-04 14:18:33.228  INFO main sc_service::builder: 📦 Highest known block at #0
2024-09-04 14:18:33.228  INFO tokio-runtime-worker substrate_prometheus_endpoint: 〽 Prometheus exporter started at <IP_ADDRESS>:9615
2024-09-04 14:18:33.228  INFO                 main sc_rpc_server: Running JSON-RPC server: addr=<IP_ADDRESS>:9944, allowed origins=["http://localhost:*", "http://<IP_ADDRESS>:*", "https://localhost:*", "https://<IP_ADDRESS>:*", "https://polkadot.js.org"]
2024-09-04 14:18:33.816  INFO tokio-runtime-worker sub-libp2p: 🔍 Discovered new external address for our node: /ip4/<IP_ADDRESS>/tcp/30333/p2p/12D3KooWHe3EhmkiBQExosLMknMUzidiRLYifyNsAecdM1WyY8JL
2024-09-04 14:18:34.268  WARN tokio-runtime-worker peerset: Report 12D3KooWB1WjEfiobvuoqUV9PzdTBFS36Cei7NpkwogzqY6oJ9ba: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.227  WARN tokio-runtime-worker peerset: Report 12D3KooWMkj7iVNGcTUgwbZN5i5taQDnyk8oMQ4akAEv3apAYc4Z: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.254  WARN tokio-runtime-worker peerset: Report 12D3KooWBPGEVpQcCo7LcYp3PZdTojkub2TQZf4fzisznxtV7XhG: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.258  WARN tokio-runtime-worker peerset: Report 12D3KooWK3QKc4HBSFPuHnGth9voyGLkVDFVXSKQSkpr8wD9QXSp: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.268  WARN tokio-runtime-worker peerset: Report 12D3KooWSCFtAPQRRa5uw2QhwsC77NfCv1mxHJjWQhUrRANkoYyx: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.269  WARN tokio-runtime-worker peerset: Report 12D3KooWE19pLyW7LHkCDQPttrkDtquNt89LLUZtpXayv2Uc8dd2: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:35.270  WARN tokio-runtime-worker peerset: Report 12D3KooWLh6ZJu9NYCVZoX1HFwF52ztk4Pg2ztY8UWvUe1CFSYnf: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:36.226  WARN tokio-runtime-worker peerset: Report 12D3KooWEa179ngCGUH625sALh6KxgzGwva4x68JYs9VSThhkESm: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:36.252  WARN tokio-runtime-worker peerset: Report 12D3KooWG3nvgcM3hYoru19A7C79meUNATFWRhwd7tsyj2huMGnz: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:36.308  WARN tokio-runtime-worker peerset: Report 12D3KooWFGwAsgLYuNhTa5XbSxdNqCLojXPbJRQhtNZAUohmPZfB: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:37.271  WARN tokio-runtime-worker peerset: Report 12D3KooWLkEMTViyC1fzU8FzT9HGQtroZZVUaeGP4JQo2fVF9B22: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:37.560  WARN tokio-runtime-worker peerset: Report 12D3KooWBGXALhTf9vY6WstH2ub3R8uMTY584vkeszuhAXL3CypH: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:38.229  INFO tokio-runtime-worker substrate: ⚙  Syncing, target=#12678797 (8 peers), best: #5524 (0xed8c…bf42), finalized #5120 (0x766f…661f), ⬇ 403.2kiB/s ⬆ 11.9kiB/s
2024-09-04 14:18:38.268  WARN tokio-runtime-worker peerset: Report 12D3KooWNuRL8uSKAgDyW1Qx49uTdnbXdzk5i2Z1b5m65Nj6cE7V: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:39.275  WARN tokio-runtime-worker peerset: Report 12D3KooWCxk23wdThnKKrr4aDeusSDDh8NCPYM6RkBi1LgkCTVVX: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:40.227  WARN tokio-runtime-worker peerset: Report 12D3KooWES1jUpjghmZGEKyZfej5WtXAGCPZAxVHw7xGUe5mCssp: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:43.229  INFO tokio-runtime-worker substrate: ⚙  Syncing 968.0 bps, target=#12678798 (9 peers), best: #10364 (0xadf8…0f6c), finalized #10240 (0x310a…6c4e), ⬇ 230.0kiB/s ⬆ 1.9kiB/s
2024-09-04 14:18:44.267  WARN tokio-runtime-worker peerset: Report 12D3KooWJgFf1DciJANgpoVUNe7Zavq6Wkge1obiZXwaGBT7ks4z: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
2024-09-04 14:18:45.268  WARN tokio-runtime-worker peerset: Report 12D3KooWKwZcU3S3Wwu1ppgk5FrFcdUVcT3LUZTMsGdxodMVAtT1: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.


If I cancel chose file  before upload when creating service by yaml file, it is still able to upload and create service.

In GitLab by @wknet123 on Dec 25, 2018, 18:51

In GitLab by @luotian-github on Nov 8, 2019, 08:02
Please wei ting check it

In GitLab by @sokril on Nov 8, 2019, 08:02
Please yanqing fix it

In GitLab by @liyanq528 on Nov 8, 2019, 08:02
Pr #1924

In GitLab by @sokril on Nov 8, 2019, 08:30
closed

In GitLab by @sokril on Nov 8, 2019, 08:30
assigned to @luotian-github

In GitLab by @liyanq528 on Nov 12, 2019, 03:07
mentioned in merge request !1175


Make bpf kubectl run test more robust

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Waiting a bit inside of the container should make the overall test more robust.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

Codecov Report

Merging #747 (6f3c163) into main (e1231d2) will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #747      +/-   ##
==========================================
+ Coverage   53.94%   54.03%   +0.08%
==========================================
  Files          41       42       +1
  Lines        4121     4129       +8
==========================================
+ Hits         2223     2231       +8
  Misses       1831     1831
  Partials       67       67

/test pull-security-profiles-operator-test-e2e

/test pull-security-profiles-operator-test-e2e


Increase C++ test coverage

Unit tests:

Ingest
Database class
Stdlib kernels

End-to-end tests:

Different samplings: big stride, small stride, sparse rows, joins
Op graphs: different DAG topologies, CPU-GPU and GPU-CPU memory transfers

Think this is now largely covered by the existing C++ tests and also the Python tests.


Fix issue with properties being reinstated from ancestors

This issue was caused by removed properties in a new classes parent(s), being added into the new class by using properties from further ancestors. This change ensures that only properties of direct parents are used.
New test added which demonstrated this, as prior to fix, _TestSubSubclassRemoveProperty would fail to initialise, as it would expect property_a to be provided on initialisation, despite being fixed value in parent.
Also tidied up handling of properties, as there was multiple loops, assignments, etc. that weren't needed or could be consolidated.

Only other thing that could be addressed the same time is the signature for __new__ and __prepare__ where PyCharm is complaining that the first argument is conventionally called mcs. Not terribly worried if it doesn't happen, but seems this is a opportunity to do that minor tidy.

Not sure about this, as I've never seen mcs used before. Python standard library uses mcls in ABC module.

Only other thing that could be addressed the same time is the signature for __new__ and __prepare__ where PyCharm is complaining that the first argument is conventionally called mcs. Not terribly worried if it doesn't happen, but seems this is a opportunity to do that minor tidy.

Not sure about this, as I've never seen mcs used before. Python standard library uses mcls in ABC module.

Fine, leave it.


feat: styling header + basic landing page

Summary | Résumé
Temporary styling for the footer of the documentation page as well as very basic styling for the landing page.
Note: This styling is temporary and will be adjusted in the future.

@ethanWallace PR is updated with your requested changes, please review again.


Support env var defaults.

Support {scie.env.*} placeholders setting default values for the env
var when not set in the environment. Further, allow those defaults to
come from placeholders (recursively). This allows, amongst other things,
over-riding scie lift manifest user-metadata on an opt-in basis
per-scie.
This facility will be useful for allowing ptexed scies to use alternate
URLs to download files behind corporate firewalls while ensuring file
sizes and hashes remain locked into the scie-embedded manifest and
un-changeable. In other words, you can change where a scie ultimately
materializes from, but you cannot change its contents.
Closes #45

I'll plow ahead and merge this by Wednesday afternoon. I'll always be happy for review feedback that comes later, but that's also just a bonus and I don't expect that either.

I'll plow ahead and merge this by Wednesday afternoon. I'll always be happy for review feedback that comes later, but that's also just a bonus and I don't expect that either.

Cool, I wouldn't be able to review this one this week - requires a bit more brainpower than I will have access to.


Client certificate revocation need a restart and won't work past the first one.

Contrary to what is stated in clients.md, the OpenVPN server won't deny client access based on the CRL before the container is restarted : because ovpn_initpki does not generate a CRL, the "--crl-verify" "$OPENVPN/crl.pem" argument won't be passed to OpenVPN on first launch.
After a first revocation, CRL generation with easyrsa and container restart, OpenVPN will correctly deny client access, but subsequent revocations won't be picked up because of the hardlink hack used in ovpn_run :
# Use a hacky hardlink as the CRL Needs to be readable by the user/group
# OpenVPN is running as.  Only pass arguments to OpenVPN if it's found.
if [ -r "$EASYRSA_PKI/crl.pem" ]; then
    if [ ! -r "$OPENVPN/crl.pem" ]; then
        ln "$EASYRSA_PKI/crl.pem" "$OPENVPN/crl.pem"
        chmod 644 "$OPENVPN/crl.pem"
    fi
    addArg "--crl-verify" "$OPENVPN/crl.pem"
fi

easyrsa gen-crl does not modify the crl.pem file in place but rather remove it and re-create a new one (verified by the new file's inode, different from the hardlinked one), so any easyrsa gen-crl issued after the hardlink has been created will break it, and ovpn_run won't pick up the change because it only check for file existence.
I'm working on a fix, I'll submit a pull request soon.

Related to #101
Lets continue discussion in your PR or in the original issue.  Closing this issue.