Include user_classes_count on stats message

This fixes a bug where errors are appearing in master. Although there doesn't appear to be any noticeable impact to Locust.
Locust version: 2.0.0b3
Locust4j version: master
The following error appears when running atest:

master_1   | [2021-08-14 21:42:06,719] 1e6ea2aa04b2/ERROR/root: Uncaught exception in event handler:
master_1   | Traceback (most recent call last):
master_1   |   File "/usr/local/lib/python3.8/site-packages/locust/event.py", line 40, in fire
master_1   |     handler(**kwargs)
master_1   |   File "/usr/local/lib/python3.8/site-packages/locust/runners.py", line 621, in on_worker_report
master_1   |     self.clients[client_id].user_classes_count = data["user_classes_count"]
master_1   | KeyError: 'user_classes_count'

Locust master expects user_classes_count to be included in stats message. This PR adds that.

Thanks!


Archived connections are not visible in ACL selector

The thing is we still try to send posts if they are archived. This might be an security flaw in certain situations.
Either we should not attempt to send messages to archived connections or we keep sending them but than also show them in the acl selector.
In the latter case the fix is to remove and abook_archived = 0 from the query in mod/acl.php on line 96

The technical description of the archived flag is that we won't waste resources polling these connections. They do sometimes get archived in error and direct delivery is still performed until either the hubloc or site is marked dead. So I'm going with option 2. Will check it in shortly.

I agree with option 2


bootil: unstable-2015-12-17 -> unstable-2019-11-18

Motivation for this change

update to latest + drop upstreamed patch

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 119721 at ce7d5a12 run on x86_64-linux 1

2 packages built successfully:

bootil
gmad

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/development/libraries/bootil/default.nix:30:3:
   |
30 |   installPhase = ''
   |   ^


Unable to use private networks with subnet size != 16

I have an existing network at Hetzner, to which I need to add a new cluster. I use the existing_network_name-feature for that, as per the docs:
networking:
  private_network:
    enabled: true
    subnet: <IP_ADDRESS>/12
    existing_network_name: "heo"

Unfortunately, since what I think was this commit, I am unable to add a new cluster. The relevant excerpt from the logs is:
[Instance prod-cx22-master2] Waiting for private network IP in subnet <IP_ADDRESS>/12 to be available... (Attempt 1/30)
[Instance prod-cx22-master2] Waiting for private network IP in subnet <IP_ADDRESS>/12 to be available... (Attempt 2/30)
[Instance prod-cx22-master2] Waiting for private network IP in subnet <IP_ADDRESS>/12 to be available... (Attempt 3/30)
^C

After some digging, it looks like the following is happening: the master_install_script.sh here script takes my <IP_ADDRESS>/12 subnet, removes the /12 and removes the last .0 making it 172.16.0.. As my subnet is actually a /12 and the server's new IP address is 172.18.X.Y (which is indeed part of the original /12), a simple grep will not match. This would be true for every subnet that is not a /16.
The same probably applies to worker_install_script.sh as well, although I haven't tried.
I think there should be a hint in the docs, if this is not going to be supported anymore.
Adopting the code to just support different sizes might be very difficult. There is some awk-magic around or one could use some inline Python. But maybe there's a better way than using grep on ip.
I don't know the code's intention to reasonably argue about that, but I may have a suggestion. Hetzner writes here, that their private network MTU is always 1450, while the public interface has a MTU of 1500. Instead of looking for a matching IP address, maybe the following could be an alternative?
ip -4 addr show | egrep -q "mtu 1450.+state UP"

Hello, I appreciate the recommendation to check the MTU, as it should always be effective. However, when I executed the command you suggested on my servers running Ubuntu 24.04, it didn't produce any output. The alternative command ip -4 addr show | awk '/mtu 1450/ && /state UP/ {getline; print $2}' does work, but in my situation, it returns two values. This is because I am using Cilium, which also has an MTU of 1450. Therefore, we need a more reliable method to obtain a single result for the actual private network interface.

It doesn't show an output, because I used the -q switch (because master_install_script.sh does that as well). Remove the -q or execute echo $? add the end. Is it really a problem that there will be two lines matching when using that regex? When Cilium is running, we can assume that k3s is already installed and we there don't need to wait for the interface to come up? Just guessing here, honestly.
I can offer some inline Python code, as I personally think this would be too complex for bash alone. But I don't know if this is a good solution. What do you think?
#!/bin/bash

SUBNET="<IP_ADDRESS>/12"

python3 - <<EOF "$SUBNET"
import netifaces, ipaddress, sys

network = ipaddress.ip_network(sys.argv[1])

for iface in netifaces.interfaces():
    ips = netifaces.ifaddresses(iface)
    if netifaces.AF_INET not in ips:
        continue
    for obj in ips[netifaces.AF_INET]:
        ip = ipaddress.ip_address(obj['addr'])
        if ip in network:
            sys.exit(0)

sys.exit(1)
EOF

if [ $? -eq 0 ]; then
	echo "ip in $SUBNET exists"
else
	echo "ip in $SUBNET does not exist"
fi

I still wasn't getting any results from your command, but I found a solution that correctly identifies the interface (just one):
ip -o link show | awk -F': ' '$2 !~ /cilium|br|flannel|docker|veth/ {print $2}' | xargs -I {} bash -c "ethtool {} &>/dev/null && echo {}" | while read -r iface; do mtu=$(ip link show "$iface" | awk '/mtu/ {print $5}'); if [ "$mtu" -eq 1450 ]; then echo "$iface"; fi; done

This method is sufficient for now since we're only using flannel and cilium.
We can't depend on Python or other tools because the worker installation script runs during the Cloud Init process with just sh when initializing autoscaled nodes (for static nodes, the script runs in regular bash), which imposes some limitations.
The command above works perfectly with the sh shell.
Could you possibly make a PR considering this? If not, I'll handle it, but I'm currently swamped with work.

is it related to my problem?

networking:
  ssh:
    port: 22
    use_agent: false # set to true if your key has a passphrase
    public_key_path: "~/.ssh/id_rsa.pub"
    private_key_path: "~/.ssh/id_rsa"
  allowed_networks:
    ssh:
      - <IP_ADDRESS>/0
    api: # this will firewall port 6443 on the nodes; it will NOT firewall the API load balancer
      - <IP_ADDRESS>/0
  public_network:
    ipv4: true
    ipv6: true
  private_network:
    enabled : true
    subnet: <IP_ADDRESS>/16
    existing_network_name: "infra"
  cni:
    enabled: true
    encryption: false
    mode: flannel
    ```

Your subnet size seems to be exactly 16, so... no?

is it related to my problem?
networking:
  ssh:
    port: 22
    use_agent: false # set to true if your key has a passphrase
    public_key_path: "~/.ssh/id_rsa.pub"
    private_key_path: "~/.ssh/id_rsa"
  allowed_networks:
    ssh:
      - <IP_ADDRESS>/0
    api: # this will firewall port 6443 on the nodes; it will NOT firewall the API load balancer
      - <IP_ADDRESS>/0
  public_network:
    ipv4: true
    ipv6: true
  private_network:
    enabled : true
    subnet: <IP_ADDRESS>/16
    existing_network_name: "infra"
  cni:
    enabled: true
    encryption: false
    mode: flannel
    ```

Are you sure <IP_ADDRESS>/16 is the correct subnet for the network "infra"?

sorry it was my fault
subnet != network )))

@ValentinVoigt Hi, I guess we can close this issue since there you opened a PR for the same problem? I haven't had a chance to test it unfortunately.

It was just to do a cleanup since we also have the pr but it's ok. We can keep this open for now.


deployment: drop David&mpj secrets/config

Since David has left: Drop David from the deployment config files: removing keys and access to deployments.

Pre-submit checklist:

Branch

[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[x] Relevant tickets are mentioned in commit messages

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[x] Reviewer requested

If you updated any cabal files or added Haskell packages:

[ ] nix-shell shell.nix --run updateMaterialized to update the materialized Nix files
[ ] Update hie-*.yaml files if needed

If you changed any Haskell files:

[ ] nix-shell shell.nix --run fix-stylish-haskell to fix any formatting issues

If you changed any Purescript files:

[ ] nix-shell shell.nix --run fix-purty to fix any formatting issues

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

@michaelpj as discussed on slack i am dropping you from the config files as well


docs: Proposal to provide better customization flexibility at compone…

…nt level
This ADR proposes the approach to provide better customization flexibility to all components of Open Data Hub.

Description

How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

@etirelli @danielezonca Could you please review


Added explanation in the readme about using git-lfs.

Ah didn't notice the last commit already updated the readme. This isn't relevant anymore.


Add support for zcrypt to Beaker plugin

Pull Request Checklist

[x] implement the feature
[ ] extend the test coverage
[x] mention the version
[x] include a release note

/packit test

/packit test


fixed an issue where status bar items can overflow

This PR fixes https://github.com/microsoft/vscode/issues/154708
I made the status bar scrollable and allowed horizontal scrolling of the status bar using mouse wheel or left/right arrow keys.

This is one of the only solutions I could think of where the beak has position: absolute but relative to the entire window, so even with overflow: hidden is set for the status bar, the beak is still displayed on top of everything when the bell is clicked.
https://user-images.githubusercontent.com/17908447/179778415-ec4360a0-f97a-4ab3-bf81-513aac4852d3.mp4


Unable to set property 'bridgevideosourcemode' to 'none' on org.asteriskjava.manager.event.BridgeCreateEvent

2018-02-01 00:04:32,128 WARN [org.asteriskjava.manager.internal.AbstractBuilder] Unable to set property 'bridgevideosourcemode' to 'none' on org.asteriskjava.manager.event.BridgeCreateEvent: no setter. Please report at https://github.com/asterisk-java/asterisk-java/issues

Now tracked in #234


Bump docs on staging

🚀 Deployed on https://62ccc8fd87c40b00a3e97bd0--cozy-fox-0defec.netlify.app


Add SkinnedMesh as an editable type

Hi, it would be great to have SkinnedMesh as an editable type, so that models with skeletal animations can be played/edited. Currently I believe only mesh is exposed.
Thanks so much!

Partially addressed by https://github.com/theatre-js/theatre/pull/108, although this doesn't get into animation / rigging controls.


[CI] TVM cache is broken

https://github.com/microsoft/hummingbird/issues/586#issuecomment-1201529514_
Link to the CI result page: Add Python 3.10 · microsoft/hummingbird@3c52b20
TODO: investigate

This seems to happen about once every 4-8 weeks.  I'm not sure if it's something we can control (on github's end?  I think?).  It's definitely been going on for a while  (example)!

Still failing :(

Right, the time we did get the green checkmark, it was because it rebuilt from scratch (which of course took 51 minutes...)
This is a new level of broken I think! 🤣

Apparently we can somehow clear it with the API

One weird thing...when I run the github API (to delete the MacOS TVM caches so we can move forward temporarily by rebuilding), I only ever see the MacOS ones saved.
I see the following  cache keys:
key": "macOS-7-3.9-tvm-0.9", "key": "macOS-7-3.10-tvm-0.9","key": "macOS-7-3.8-tvm-0.9","key": "macOS-6-3.9-tvm-0.9","key": "macOS-6-3.10-tvm-0.9","key": "macOS-6-3.8-tvm-0.9",
It looks like #609 changed line 85 to cache mac only instead of "not windows", which means  Linux is never cached, unless I am misunderstanding something?   That probably isn't related to our current issue, but maybe there is something else going on related to it?

Ah ok, nevermind. i see that on line 80 we always pip install Linux TVM now.
I was just trying to think back to a time when the cache worked more consistently and if something unexpected changed!


Memstore

Description
Putting back the memstore implementation as it serves well in cases where you use an emulator as a Go module and need to instantiate multiple instances. Since current alternative is only Badger which has a lot of overhead when used in-memory that is required. In the future I believe SQLite can also be added to the in-memory list, but I again believe that in cases where you need multiple instances spawn up it will still have the not needed overhead.

For contributor use:

[ ] Targeted PR against master branch
[ ] Linked to GitHub issue with discussion and accepted design OR link to spec that describes this work
[ ] Code follows the standards mentioned here
[ ] Updated relevant documentation
[ ] Re-reviewed Files changed in the GitHub PR explorer
[ ] Added appropriate labels

Codecov Report

Merging #262 (d2628a9) into master (5ea9da1) will decrease coverage by 2.15%.
The diff coverage is 19.58%.

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

@@            Coverage Diff             @@
##           master     #262      +/-   ##
==========================================
- Coverage   52.38%   50.22%   -2.16%
==========================================
  Files          26       27       +1
  Lines        2037     2176     +139
==========================================
+ Hits         1067     1093      +26
- Misses        845      956     +111
- Partials      125      127       +2

Flag
Coverage Δ

unittests
50.22% <19.58%> (-2.16%)
:arrow_down:

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

Impacted Files
Coverage Δ

server/server.go
48.50% <ø> (ø)

server/storage.go
37.20% <0.00%> (-3.82%)
:arrow_down:

storage/memstore/memstore.go
19.56% <19.56%> (ø)

blockchain.go
75.12% <100.00%> (+0.20%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


uneven distribution of content in policy.xsl

Here is example in documentation.
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Multiple-column_Layout#setting_break-inside

@yegor256 Could you approve start of workflows checks. Mine was ok

@Legolass322 thanks!

@Legolass322 Great work on your contribution! 🌟 You've earned +4 points: +4 base, with adjustments for code review (-16), comments (-4), and hits-of-code (-8). We've added +28 to ensure you receive recognition. Remember, quality and speed are key. Keep up the good work and we look forward to your next contribution!


XSS in inc/lib/Site.class.php when view post

Hello, I found a XSS vulnerability in URL: http://<IP_ADDRESS>/GeniXCMS/?post=1. Please confirm.

1.Use the latest version of GeniXCMS in github(20170523).
2.Use Internet Explorer.

Author: gaohuailiang
E-mail<EMAIL_ADDRESS>Huawei Weiran Labs

please tell me what version did you use ?
see at the bottom of the dashboard page.

Copyright 2017 GeniXCMS 1.0.2
I cloned the latest code in github yesterday : https://github.com/semplon/GeniXCMS
The vulnerable code is in inc/lib/Site.class.php:
line 92: <link rel="canonical" href="".$canonical."" />
The root cause is $canonical param not checked correctly in blow function, so that attackers could wirte some script code in uri, like http://your-ip/GeniXCMS/?post=1">
170     public static function canonical()
171     {
172         $protocol = stripos($_SERVER['SERVER_PROTOCOL'],'https') === true ? 'https://' : 'http://';
173
174         return $protocol.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
175     }


load file from url error

after "gulp build", I copied dist folder to my server's public directory, from where I can open the index.html in a Chrome browser.
For this build, there are two options: either load from computer or URL.
I have about 44 DCM files, from which med3web can construct 3D vision if I load them from computer.
When I tried to load them from URL (http://<IP_ADDRESS>:8000/files), I got the following errors:
GET http://<IP_ADDRESS>:8000/files/file_list.txt 404 (Not Found)
Loaded file list. 48 files will be loaded. 1st file in list is =
GET http://<IP_ADDRESS>:8000/files/<!DOCTYPE html> 404 (Not Found)
...
main.js:1134 Loading ratio = 0
main.js:911 DICM header NOT found
main.js:1134 Error load dicom folder
...
What are the requirements if I want to load DICOM files in a URL folder? Where can I find user manual?

Application can read Dicom files from specified URL location. There are some important notes to provide correct file naming, access, etc.
How to create your own Dicom files dataset

Prepare folder with Dicom (*.dcm) files in some local folder on your workstation. For example: D:/med3web/data/dicom/lungs It is important to have ONLY *.dcm files inside this folder

Run command

dir *.dcm /b > file_list.txt
This command will add "file_list.txt" file with all *.dcm files listing inside.

Create special file, named ".htaccess" and write following content in it:

Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Headers "Content-Type"
Header set Access-Control-Allow-Methods "GET"

Copy your local folder (containing *.dcm, .htaccess, file_lists.txt files) into your web server. For example on location: www.mysite.org/med3web/data/lungs

Check correct URL and access possibility for just created folder. Enter in url line:

www.mysite.org/med3web/data/lungs/file_list.txt
You should see *.dcm file listing in browser window.

Run Med3Web application, hosted on your server (dont use virtual server) and select "File -> Open by URL". Enter url

www.mysite.org/med3web/data/lungs
into Input URL text field and press "Load" button. It is important to remove trailing slash from your URL folder name.
If everything fine (your server work correctly) you will see in console window (console window can be open by pressing F12 in Chrome browser) following messages:
Dicom folder os loaded
Loaded file list. NNN files will be loaded. 1st file in list = XXXX.dcm
Loading ratio = 0
Loading ratio = 0.02
Loading ratio = 0.04
...

thx.
your tricks make it work now.


RFC: Add tasks to SHELL_PLUS_IMPORTS

I've added this configuration on multiple Resonant projects now. Wondering if others will find this useful too.

I realize it may also make sense to move this out of DevelopmentConfiguration and into the app mixin, as people sometimes use shell_plus in production.

After discussing with @danlamanna, we realized that django-extensions should probably be setup as a development-only dependency, since we just don't trust it enough to depend on it for production use. Of course, downstream developers can change this at their own risk.
@danlamanna is going to make the changes to make django-extensions dev-only more generally.

I occasionally run heroku exec ./manage.py shell_plus, but if this is a security concern, I could live without that ability.


ZEPPELIN-234

Dont submit the paragraph if its already running.

Please add unit tests to your findSimilarJob and "isSimilar" and to the affected schedulers.

Hi @djoelz thanks for the review. I am going a bit busy since last 2 weeks. I will take care of the comments in next few days.

@guptarajat Hi, any plan on finishing this PR?

No....you can close this PR. As I remember many of the issues I tried to address in this PR were fixed later on by other guys. Thanks for pinging me on this one.


Missing Add* function for Builtin operator FILL

@tensorflow/micro
System information

Host OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 18.04.5 LTS
TensorFlow installed from (source or binary): Source built locally
Tensorflow version (commit SHA if source): 771c870a81c1025c4886a4fb60ca33971e98c577
Target platform (e.g. Arm Mbed OS, Arduino Nano 33 etc.): nRF52840 DK

Describe the problem
I successfully converted my model to TF Lite for Microcontrollers and I am now trying to consume it from an nRF52840 DK target, but I get a failure when allocating the tensors:
[ERR] ./model/debug_log.cc:12: Didn't find op for builtin opcode 'FILL' version '1'. An older version of this builtin might be supported. Are you using an old TFLite binary with a newer model?
[ERR] ./model/debug_log.cc:12:
[ERR] ./model/debug_log.cc:12: Failed to get registration from op code FILL
[ERR] ./model/debug_log.cc:12:
[ERR] ./model/debug_log.cc:12: Failed starting model allocation.
[ERR] ./model/debug_log.cc:12:
[ERR] ./model/debug_log.cc:12: AllocateTensors() failed

Being proprietary software, unfortunately, I cannot share more details about the model used.
I already have a proposed resolution of the issue and I'm opening this Issue ticket in order to open a PR.
Please provide the exact sequence of commands/steps when you ran into the problem
The first step is building TFLM locally:
cd tensorflow
make -f tensorflow/lite/micro/tools/make/Makefile \
    TARGET=cortex_m_generic \
    TARGET_ARCH=cortex-m4+fp \
    TARGET_TOOLCHAIN_ROOT=/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/ \
    OPTIMIZED_KERNEL_DIR=cmsis_nn microlite

Once libtensorflow-microlite.a is built I can include it as a library in the Makefile of my project.
The second step is to consume my  TFLM model from th target nRF52840. The code fails within this function call:
void model_init(){
	// Set up logging
	static tflite::MicroErrorReporter micro_error_reporter;
	error_reporter = &micro_error_reporter;

	// Map the model into a usable data structure
	model = ::tflite::GetModel(g_model);
	if (model->version() != TFLITE_SCHEMA_VERSION) {
		TF_LITE_REPORT_ERROR(error_reporter,
				"Model provided is schema version %d not equal "
				"to supported version %d.\n",
				model->version(), TFLITE_SCHEMA_VERSION);
	}

	// This pulls in all the operation implementations we need
	static tflite::AllOpsResolver resolver;
	resolver.AddExpandDims();

	// Build an interpreter to run the model with.
	static tflite::MicroInterpreter static_interpreter(
			model, resolver, tensor_arena, kTensorArenaSize, error_reporter);
	interpreter = &static_interpreter;

	// Allocate memory from the tensor_arena for the model's tensors.
	TfLiteStatus allocate_status = interpreter->AllocateTensors();
	if (allocate_status != kTfLiteOk){
		TF_LITE_REPORT_ERROR(error_reporter, "AllocateTensors() failed");
		return;
	}

	// Obtain pointers to the model's input and output tensors.
	input = interpreter->input(0);
	output = interpreter->output(0);
}

Hi,
I created a PR with a fix (48144).
Apologies if did not respecting your contributing guidelines this time.
Cheers

Hi, could you please tell me how big is your libtensorflow-microlite.a?

Hi, could you please tell me how big is your libtensorflow-microlite.a?

Hi @napoleonwar, my libtensorflow-microlite.a seems to be 1.0 MB on my host. I currently don't know the size on the target though.

Hi @napoleonwar, my libtensorflow-microlite.a seems to be 1.0 MB on my host. I currently don't know the size on the target though.

Ok Thanks! I am wondering how big is it after you compiling the hello world example if you did before. Because in my case, the binary file is 350KB for this simplest example, it will become bigger for more complex cases. Did you get some result whose size is under 100KB by using TFLM?


startActivityForResult to get Camera picture result failed, the log show 【Couldn't find method canDrawOverlays, referenced from method com.facebook.react.ReactActivity.onCreate】

I create a module to get camera picture uri when camera result saved.
the step is below:
1). create an intent to start camera.
Intent cameraIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
    // we create a tmp file to save the result
    File path = Environment.getExternalStoragePublicDirectory(
            Environment.DIRECTORY_PICTURES);
    File imageFile;
    try {
        // Make sure the Pictures directory exists.
        path.mkdirs();
        imageFile = File.createTempFile("image_picker_capture_", ".jpg", path);
    } catch (IOException e) {
        e.printStackTrace();
        response.putString("error", e.getMessage());
        callback.invoke(response);
        return;
    }
    cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(imageFile));

2). startActivityForResult.
    try {
        mMainActivity.startActivityForResult(cameraIntent, REQUEST_LAUNCH_CAMERA);
    } catch (ActivityNotFoundException e) {
        e.printStackTrace();
    }

3). In MainActivity override onActivityResult method.
public void onActivityResult(final int requestCode, final int resultCode, final Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    mImagePicker.handleActivityResult(requestCode, resultCode, data);
}

2 in 10 times, this code work well, but 8 times the app instance is restart. The log show 【Couldn't find method canDrawOverlays, referenced from method com.facebook.react.ReactActivity.onCreate】. So the onActivityResult function can not receive the result.

The test enviroment is an android 4.4 mobile phone. compileSdkVersion is 23. targetSdkVersion is 22. RN 0.18.1

Have you proguard enabled by any chance?

Do you have*

@satya164 , I check the build.gradle, screenshot is below:

I only change targetSdkVerstion to 22.

The android os kill the activity which start camera for result. I override onConfigurationChanged in Mainactivity and add largeHeap in manifest, but sometimes(50%) the Mainactivity is still killed! I think this is not a issue with RN. Close it.


Make the application work as a web page and as a progressive web app

Pàdé runs installs as a browser extension and runs like a desktop application. In some use cases where browser extensions are not permitted, it is desirable to run Pàdé as basic web page or install and run as a progressive web app. This is most desired for mobile devices

In order to support a web page or progressive web app (PWA), a web server with web push support is required. This feature will require the Openfire Chat API plugin to host the Pàdé web application. Perform the following changes to Pàdé:

Enable Pàdé to work work as a PWA that installs like a native app on the desktop or mobile.

Support web push directly from Openfire using VAPID and a service worker to open Pàdé when messages are received and the user is offline.

Support single sign on with browser stored username/password using the Credential Management API. User should experience the Converse login or registration screen only once.

Adjust the already responsive Converse UI  for a mobile form factor

Handle PWA caching

Done. Changes implemented in version 1.2.8 and available in public web site
http://pade.chat
Register a new account and test it.
To deploy locally, you would need Openfire Chat API plugin version 0.9.5 Release 3
Installs on the  mobile phone home screen

Converse responsive UI

Installs on the desktop

Single sign-on with Credential Management API.

Web Push

This http://pade.chat accepts only new accounts? Wasn't able to login with my igniterealtime account.

This http://pade.chat accepts only new accounts?

Yes. The domain is pade.chat.

wow.
Just wow!


KeyError in gfk.py

When using model_stream(Model) in views I get this error :
Exception Type:	KeyError
Exception Value:	(15L, u'1')
Exception Location: site-packages/actstream/gfk.py in fetch_generic_relations, line 79
This Model works with follow() and unfollow()

i need a lot more info about this bug as I cannot recreate it

what db are you using?
what version of python and django are you running?
are you using the sites framework?
are you upgrading from an older version of django-activity-stream?
how are you making this Model?
what is the problem view doing?

any example source code and a dump of the actstream app would be helpful.

I'm using Mysql (with gis because of GeoDjango). Configured with utf8_swedish_ci
Python 2.6 and Django 1.3.1
I'm not using the sites framework
It's a new install, I'm using the lastest release.

The code example :
In my settings.py:
ACTSTREAM_ACTION_MODELS = ['auth.User']

My function to follow a stuff:
def followUser(request, userId):
	if not is_following_check(request.user, "user", userId):
		to_follow = User.objects.get(id=userId)
		follow(request.user, to_follow)

		return HttpResponse("success")
	else:
		return HttpResponse("error")

def is_following_check(user, who, whoId):

	if who == "user":

		to_check = User.objects.get(id=whoId)
		if is_following(user, to_check):
			return True
		else:
			return False

	else:
		return False

My function to get the stream :
def userStream(userId):
	user = User.objects.get(id=userId)
	user_activities = model_stream(user)

	return user_activities

And in the admin, I can see all the activities without any problem.
I found a "hack" to make it works in my dev environnement.
In gfk.py, lines 70+:

for item in qs:
			for gfk in gfk_fields:
				if getattr(item, gfk.fk_field) != None:
					ct_id_field = self.model._meta.get_field(gfk.ct_field).column
					try:
						setattr(item, gfk.name, data_map[(getattr(item, ct_id_field),
															getattr(item, gfk.fk_field))])
					except:
						print "error gfk"
						pass
		return qs


Add Loading Icon to Emergency  Kits List Page (Front End)

When the network is slow or API return response is slow, Emergency Kits list page shows "No Data Available" until the API returns data and displays it.
Proposal: Add loading icon similar to what is currently implemented for "Edit Emergency Kit" page.

Implemented in #60 PR


Need to prevent re-performing some JavaScript page setup actions when they've already been performed

The underlying issue is that the $(document).on('turbolinks:load', ); event can fire more than once on pages where it's previously fired. This mostly happens when using the browser's forward and back capability.
On metasmoke, we typically use the utility function onLoad() to add functions to be run on that event. There are a considerable number of places throughout the JavaScript where it's assumed that the operations which are being performed within the onLoad() callback are operating on HTML on which they have never been performed. When these are run a second time on the same DOM/HTML, it can result in a variety of unintended consequences, including multiple manipulations and adding multiple event listeners (when the event listener being added is not the same function Object; e.g. when it's anonymous) which are performing the same action.
There are, of course, also things which do need to be run again when the same DOM/HTML is presented to the user. As a result, it's not a case where we just need to prevent everything added through onLoad from being re-executed on the same DOM/HTML.

There are a variety of ways by which this can be addressed. We probably want a combination of approaches. As a first swag at how to address this, we should probably change the onLoad() semantics such that by default callbacks are not called a second time for DOMs which have already had onLoad() callbacks called on them. We could have as an option when adding the callback through onLoad() that the callback will always be called, which would then place the burden of making sure not to perform double actions on the callback.
It's unclear to me if we need to handle the case where the turbolinks:load event is fired on HTML which has already been manipulated, but which is a new DOM. In such a case, HTML manipulations would have occurred, but any event listeners would need to be (re-)added to the newly recreated DOM. I know we do experience the case where it's the same DOM, which retains the previously added event listeners.

On Firefox 103, testing indicated that the browser's forward and back buttons resulted in similar replacement of the document.body as is normally done by Turbolinks, but the HTML which is used for the replacement is the already modified HTML from the recent visit. In other words, the JavaScript context is kept and events on the window and document are kept, but all events on the document.body, or lower, are removed. This is very similar to a normal Turbolinks transition to a new page, just that the already modified HTML is used for the document.body replacement.


feat: Add option to config to set runtime socket address

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #647

Superseded by #930


Updated dependencies

Coverage remained the same at 95.168% when pulling d524236830e6749a7f23dc4df478e6bc5aa8b1d7 on jeffm13:master into d1ec79c0ed69e679d565e2f4dcf39bb87bfc97bd on franciscogouveia:master.

Great! Thanks
Sorry the long time to merge it, time is short on this side :)


Extended Attributes.cs with ChoiceFormatOptions.

I find strongly typed ChoiceFormats less error-prone than strings.

Thanks for the pull request, but since these values are typically used in textual templates where the visual look is an important part of the definition, I'm rejecting this pull request.  In a little more detail:
"{0}. {1}" more clearly communicates a 1.  template than ChoiceFormat.Number + ". " + ChoiceFormat.FieldName.  (And it should probably be ChoiceFormat.FieldDescription if we were going to take the request since Description is the general term for {1}.


Edit root.go for binding ENV variables

Resolves #230
Changes:

Adds cli commands for updating the config file using the flags and environment variables

Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Other (please describe):

Testing
Requires testing

[ ] Yes
[x] No

In case you checked yes, did you write tests??

[ ] Yes
[ ] No

Comments about testing , should you have some (optional)
Further comments (optional)
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

I think the function handleConfig does the job of updating the viper config parameters. Does that solve the purpose or should I think of separating Viper and Cobra more?

Closing in favor of #295


webpage is not responsive #158

Description
added media query to the collection page so that the collection page is now responsive
issue no. #158
Related Issues

Closes #

Type of PR

[X] ()

Screenshots / videos (if applicable)

https://github.com/user-attachments/assets/eb261de3-5307-420b-b707-3e90fa75f1ae
Checklist

[X] I have gone through the contributing guide
[X] I have updated my branch and synced it with project main branch before making this PR
[X] I have performed a self-review of my code
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[X] I have commented my code, particularly in hard-to-understand areas.

Additional context:

@Kratik1093 make all html pages responsive.

@Anjaliavv51 ok i will do that to all the html pages

okay


HBASE-28832 Upgrade from bootstrap 3.4.1 to non vulnerable version 5.3.3

This is the backport of https://github.com/apache/hbase/pull/6490/ for branch-2.5.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

-0 :warning:
yetus
0m  7s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m  8s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 52s

branch-2.5 passed

+1 :green_heart:
compile
1m 49s

branch-2.5 passed

+1 :green_heart:
javadoc
3m  0s

branch-2.5 passed

+1 :green_heart:
shadedjars
4m 30s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 30s

the patch passed

+1 :green_heart:
compile
1m 51s

the patch passed

+1 :green_heart:
javac
1m 51s

the patch passed

+1 :green_heart:
javadoc
2m 57s

the patch passed

+1 :green_heart:
shadedjars
4m 30s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
29m 36s
/patch-unit-root.txt
root in the patch failed.

60m 23s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 89710360b4a9 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / f87e217beede4e24fd1fb8941b331d25f6420bdb

Default Java
Eclipse Adoptium-11.0.23+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/testReport/

Max. process+thread count
2309 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 46s

Docker mode activated.

-0 :warning:
yetus
0m  4s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 28s

branch-2.5 passed

+1 :green_heart:
compile
1m 35s

branch-2.5 passed

+1 :green_heart:
javadoc
2m 36s

branch-2.5 passed

+1 :green_heart:
shadedjars
5m  4s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 17s

the patch passed

+1 :green_heart:
compile
1m 40s

the patch passed

+1 :green_heart:
javac
1m 40s

the patch passed

+1 :green_heart:
javadoc
2m 51s

the patch passed

+1 :green_heart:
shadedjars
5m  5s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
36m 15s
/patch-unit-root.txt
root in the patch failed.

63m 58s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 159b8720f0f9 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / f87e217beede4e24fd1fb8941b331d25f6420bdb

Default Java
Temurin-1.8.0_412-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/testReport/

Max. process+thread count
2653 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 45s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jshint
0m  0s

jshint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m  9s

branch-2.5 passed

+1 :green_heart:
compile
5m 18s

branch-2.5 passed

+1 :green_heart:
checkstyle
1m 12s

branch-2.5 passed

+1 :green_heart:
spotbugs
10m 43s

branch-2.5 passed

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 55s

the patch passed

+1 :green_heart:
compile
5m 17s

the patch passed

+1 :green_heart:
javac
5m 17s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  9s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
spotbugs
11m 19s

the patch passed

+1 :green_heart:
hadoopcheck
21m 57s

Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 44s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 55s

The patch does not generate ASF License warnings.

69m 28s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless jshint shellcheck shelldocs

uname
Linux fdf48a790631 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / f87e217beede4e24fd1fb8941b331d25f6420bdb

Default Java
Eclipse Adoptium-11.0.23+9

Max. process+thread count
181 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/console

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 50s

Docker mode activated.

-0 :warning:
yetus
0m  6s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m  8s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 48s

branch-2.5 passed

+1 :green_heart:
compile
1m 50s

branch-2.5 passed

+1 :green_heart:
javadoc
3m  1s

branch-2.5 passed

+1 :green_heart:
shadedjars
4m 29s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 26s

the patch passed

+1 :green_heart:
compile
1m 50s

the patch passed

+1 :green_heart:
javac
1m 50s

the patch passed

+1 :green_heart:
javadoc
3m  1s

the patch passed

+1 :green_heart:
shadedjars
4m 26s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
38m 59s
/patch-unit-root.txt
root in the patch failed.

67m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux f8229c3abc43 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / f87e217beede4e24fd1fb8941b331d25f6420bdb

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/testReport/

Max. process+thread count
2442 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Test failures seems to be unrelated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 51s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jshint
0m  0s

jshint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  1s

branch-2.5 passed

+1 :green_heart:
compile
5m 35s

branch-2.5 passed

+1 :green_heart:
checkstyle
1m 21s

branch-2.5 passed

+1 :green_heart:
spotbugs
14m 12s

branch-2.5 passed

-1 :x:
spotless
0m 44s

branch has 1 errors when running spotless:check, run spotless:apply to fix.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 30s

the patch passed

+1 :green_heart:
compile
4m 47s

the patch passed

+1 :green_heart:
javac
4m 47s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 57s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
spotbugs
17m 23s

the patch passed

+1 :green_heart:
hadoopcheck
25m 42s

Patch does not cause any errors with Hadoop 2.10.2 or 3.2.4 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 58s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
1m  5s

The patch does not generate ASF License warnings.

86m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless jshint shellcheck shelldocs

uname
Linux 323cc74f49a3 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / 8f248f16c473a34f1840ac88ab2f6c5f5533b33c

Default Java
Eclipse Adoptium-11.0.23+9

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/artifact/yetus-general-check/output/branch-spotless.txt

Max. process+thread count
179 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/console

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 46s

Docker mode activated.

-0 :warning:
yetus
0m  6s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 10s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 53s

branch-2.5 passed

+1 :green_heart:
compile
1m 58s

branch-2.5 passed

+1 :green_heart:
javadoc
3m  1s

branch-2.5 passed

+1 :green_heart:
shadedjars
5m 18s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 40s

the patch passed

+1 :green_heart:
compile
2m  0s

the patch passed

+1 :green_heart:
javac
2m  0s

the patch passed

+1 :green_heart:
javadoc
2m 59s

the patch passed

+1 :green_heart:
shadedjars
5m 18s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
445m 36s
/patch-unit-root.txt
root in the patch failed.

478m 59s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 1332294b6fa5 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / 8f248f16c473a34f1840ac88ab2f6c5f5533b33c

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/testReport/

Max. process+thread count
5047 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 58s

Docker mode activated.

-0 :warning:
yetus
0m  7s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 16s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 46s

branch-2.5 passed

+1 :green_heart:
compile
1m 57s

branch-2.5 passed

+1 :green_heart:
javadoc
3m 25s

branch-2.5 passed

+1 :green_heart:
shadedjars
5m 15s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 13s

the patch passed

+1 :green_heart:
compile
1m 59s

the patch passed

+1 :green_heart:
javac
1m 59s

the patch passed

+1 :green_heart:
javadoc
3m  4s

the patch passed

+1 :green_heart:
shadedjars
4m 52s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
467m 18s
/patch-unit-root.txt
root in the patch failed.

502m  7s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 87b0dfb9f42a 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / 8f248f16c473a34f1840ac88ab2f6c5f5533b33c

Default Java
Eclipse Adoptium-11.0.23+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/testReport/

Max. process+thread count
4812 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 45s

Docker mode activated.

-0 :warning:
yetus
0m  6s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.5 Compile Tests _

+0 :ok:
mvndep
0m 10s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 15s

branch-2.5 passed

+1 :green_heart:
compile
1m 41s

branch-2.5 passed

+1 :green_heart:
javadoc
4m 13s

branch-2.5 passed

+1 :green_heart:
shadedjars
5m 38s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 25s

the patch passed

+1 :green_heart:
compile
2m 10s

the patch passed

+1 :green_heart:
javac
2m 10s

the patch passed

+1 :green_heart:
javadoc
4m 56s

the patch passed

+1 :green_heart:
shadedjars
5m 24s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
546m 48s
/patch-unit-root.txt
root in the patch failed.

584m  7s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6525

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 6f0f589dd56f 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.5 / 8f248f16c473a34f1840ac88ab2f6c5f5533b33c

Default Java
Temurin-1.8.0_412-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/testReport/

Max. process+thread count
4770 (vs. ulimit of 30000)

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6525/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.


Rework reflection system: fix blending of stacked sprites, integrate into sprite rending with parallax foreground sprites

will be released with 1.11.0


Merge developer-1 with main

Merging developer-1 branch with main
The following additions were made:

added three new Jupyter notebooks
added 'image' directory containing required screenshots for questions 11 and 12

Ready for merging


need to focus on start

how to make this picker to focus on selectedDate at widget building??

Updated in version 1.0.1.
Thank you for your request.


Rationalize python configuration on pyproject.toml and update build system to hatch

Issue description / feature objectives
The recommended method fro managing python packages now is using pyproject.toml which we already have (based on this: https://packaging.python.org/en/latest/).
setup.py is no longer a pseudo-requirement as you can put in different build systems.  The python packing authority is supporting a number of them. hatch and hatchling is the most popular to the modernized tools.
Caveats / Assumptions

The default new hatch project setup has a src directory. This will not be used.

Completion Criteria

Build system is replaced with hatch
As many as possible of the configuration files are converged on pyproject.toml

I've done a little baseline work on this already. One interesting side-complication that has come up is we get the greatest benefit (in terms of stack and number of dependencies) when we converge on ruff for linting and formatting which is the default.
Ruff, by default is pedantic, even when excluding the quote style (it defaults to double quotes). Most of the differences are related to two topics:

Changes that relate to how to do type annotations with python 3.9 and above (which was not the default when trestle was first created)

String formatting as it applies to logs (moving to lazy evaluation where possible for logs).

We'll need to discuss this before moving forward.
1121 UP006
 445 G004
 375 TRY003
 341 SLF001
 289 FA100
 276 EM102
 255 FBT001
 222 UP035
 206 UP009
 148 ARG001
 130 RUF100
 123 FBT002
 122 BLE001
 116 PLR0402
 115 EM101
 114 W605
 114 UP007
  99 I001
  93 RET504
  91 SIM118
  81 B904
  80 G003
  48 PERF401
  43 UP039
  35 TRY301
  32 PT006
  31 RET505
  30 PLR2004
  29 SIM300
  29 PLW2901
  24 SIM108
  23 UP015
  23 RUF012
  23 ISC003
  21 PT003
  20 SIM102
  19 TRY300
  18 TD004
  18 SIM115
  17 TRY400
  17 TRY002
  17 RUF013
  17 RUF010
  15 TCH001
  15 PT012
  15 E721
  14 PLR5501
  13 ARG002
  12 PT007
  11 SIM201
   9 RUF005
   9 PIE794
   9 DTZ011
   8 RUF015
   8 PIE804
   7 PERF102
   6 UP028
   6 RUF003
   6 RET507
   6 PT011
   6 PLR1722
   6 PLR1714
   6 PERF402
   6 DTZ005
   6 B017
   5 UP008
   5 TRY201
   5 SIM105
   5 PT018
   4 TID252
   4 S101
   4 RET503
   4 PIE790
   4 N806
   4 ARG004
   3 UP018
   3 TCH003
   3 SIM910
   3 SIM210
   3 SIM114
   3 SIM113
   3 SIM110
   3 S314
   3 PT017
   3 FLY002
   2 W292
   2 UP024
   2 SIM212
   2 SIM211
   2 SIM101
   2 S105
   2 RET508
   2 RET506
   2 PLR1701
   2 PIE810
   2 PIE808
   2 N803
   2 INP001
   1 UP037
   1 UP003
   1 TRY302
   1 TRY004
   1 SIM117
   1 SIM103
   1 S605
   1 S602
   1 RSE102
   1 PT014
   1 PLW0129
   1 PLR0133
   1 PLE1205
   1 N817
   1 N804
   1 E999
   1 E713
   1 DTZ006
   1 DTZ002
   1 B018
   1 B016

Just discussing on community call
Make this step 1: Cut across from setup.py -> pyproject.toml
Step 2: start at ruff
Step 3: cut across linters including pre-commits


Provision/configure HashiCorp Vault , grant access

see also https://github.com/os-climate/os_c_data_commons/issues/270

pending cluster creation

cluster created.  work in progress - week of 27-Mar

Vault sso documentation: https://github.com/Gregory-Pereira/Vault-SSO-for-Openshift/tree/document-vault-and-vault-oidc-setup
Op1st vault docs: https://github.com/operate-first/apps/tree/master/docs/content/vault_eso/docs

@MightyNerdEric verified working.


Credentials rate limit ui

Task/Issue URL: https://app.asana.com/0/488551667048375/1206017382069031/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3913

PR #3933   👈

This stack of pull requests is managed by Graphite.


Revert "Restrict RemoteASTTypeBuilder::findModule() to the list of lo…

…aded modules."
This reverts commit 30ea6ec66cdc662f13ae149defda7224df8b7f36.
LLDB is smarter than I expected it to be.  One of the failing tests
"metatype" is very short and does not import any modules
whatsoever. It turns out that swift_runtime->GetMetadataPromise()
creates a RemoteAST with the Scratch AST context. LLDB does not
pre-import any modules for the scratch AST context.
Using the scratch context is actually the behavior we'd want for all
kinds of dynamic type resolution, since we need to handle the
worst-case dynamic type (a tuple of existentials that each originate
from different modules that don't import each other) gracefully.
So what I'm going to try next is revert the RemoteAST change and try
to get the dynamic type resolution in this case to use the scratch AST
context instead of the per-module AST context.
I'm still going to add a flag to RemoteAST to indicate wether
importing other modules should be allowed or not and set that
according to whether this is a module context or the scratch context.
rdar://problem/40950542

test with https://github.com/apple/swift-lldb/pull/706
@swift-ci test


com.alibaba.dubbo.common.URL不能使用邮箱作为用户名

com.alibaba.dubbo.common.URL.valueof()中如果用户名或密码中包含@字段，导致解析错误
i = url.indexOf("@");需要将此字段改为i = url.lastIndexOf("@");

We will improve the URL interpreting logic, thanks a lot.

Hi, thanks for reporting, could you please send a pull request to fix it?

I'm not convinced that this bug report is valid.
From RFC 3986
authority      = [ userinfo "@" ] host [ ":" port ]
userinfo    = ( unreserved / pct-encoded / sub-delims / ":" )
unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims     = "!" / "$" / "&" / "'" / "(" / ")" / "" / "+" / "," / ";" / "="
The '@' character is not a valid character for the userinfo. If use of a '@' is required then it would need to be %nn encoded. Multiple '@' before those host looks to be invalid and should probably be rejected.

We can refer what java.lang.URL does.
I think change to lastIndexOf() brings no harm,  there's also no need to add error promotion. But we should remove the '@' use cases in UT.


air wavelengths and vacuum correction

I have a cube for which the spectral axis is the air wavelength. After being puzzled for a while as to why the conversion of the spectral axis to velocity didn't agree with my calculation, I looked at the code and found that if the AWAV parameter is present in the header the spectral axis is converted to vacuum before the velocity conversion. Two questions about this:

It would be great if it were stated in the documentation that this is happening, since it took a while to figure out what was going on.

The air-to-vacuum conversion applied uses standard temperature and pressure, which isn't appropriate to spectra calibrated from line lists measured at high altitude observatories. Is it possible to allow the user to control how the vacuum correction is performed through something like the ref_index package?

I know air wavelengths aren't supported, but unfortunately many optical pipelines still use them.

Adding it to the docs is certainly important; I had overlooked it because I haven't encountered an air wavelength cube yet.
I think something like you suggest in (2) is possible, but I'm not immediately sure how.  It probably is described in the FITS paper.

Thanks. I don't think that paper discusses how to change the correction, but the ref_index package I linked above is an example.


Uniform Mesh Converter Parameter Mapping and Power Parameter Recalculations

The problem statement is as follows - The uniform mesh converter currently performs block-level parameter mapping between a uniform mesh assembly/core to a detailed mesh assembly/core. During this data transfer process, parameters like linPow or data that is relative to the number of pins/components in the destination assembly must be considered. Right now only a volume weighting is being applied, but in instances of pin-level quantities we should also recalculate power-like parameters based on the target number of pins.
One example where this rears its head is in an internal application where we have moving control rods using the nonUniformAssemFlags and in some parts of the assembly is a DUCT block that contains no pins, but when the global flux calculation is performed there are some CONTROL blocks that are homogenized into the DUCT block. When the global flux calculation sees the power and goes to compute linPow it sees that there are in fact "pins" in this homogenized region, but when the flux/power results are mapped back to the DUCT and other CONTROL blocks the DUCT does not contain any pins. Again, this leads the results to show a pin-level linear power in the DUCT blocks because of the way the uniform mesh converter is treating the migration of data, but this parameter should actually be zeroed out.
I recommend that the ARMI develop team consider tracking dependencies of parameters in terms of other parameters within certain parameter setters. Ideally, we need to just map flux data back to core assemblies in this conversion process and then recalculate all flux-dependent parameters (i.e., reaction rates, power, linear powers, etc.). Right now only the recalculation of reaction rates is handled and therefore there is a chance that power and power-like data is incorrect.

Can we have a meeting to discuss the requirements of the new non-uniform assembly feature?
I feel like we're starting down the road of making many little PRs, like we did with the Axial Expansion feature recently.
I really think it would be better to define a high-level view of this new feature, define requirements, then lay out a good high-level design before starting work.  That's a good strategy for medium-to-large features, so we don't have a never-ending stream of little changes and fixes (which lead to messier code, which is harder to update and fix).

Sure. All the changes to the uniform mesher have been to (1) extend it's parameter handling and remove hard-coded parameter names, and (2) refractors to expose the API in a different way to downstream plugins and applications. The underlying scope of this class has not changed in that it's job is to make a reactor core model that has a uniform axial mesh, consistent with some user mesh input or derived from the reference assembly.

we have too many stale block parameters

That's a really good point.
I would even split that into two separate problems:

We have some totally unused parameters, and we have no way to find them.
I bet ARMI has some parameters that should be moved to a specific Plugin.

@ntouran Any ideas how I would go about finding unused parameters?

I have them documented and I can share @john-science


What are the blockers for running 1000 pods per node.

Hi,
I just started playing with kubernetes on bare-metal servers. I wonder how many pods I can start per server. According to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/test/e2e/density.go#L175 k8s should support 30 pods/node, but for bare metal deployments it is very low. Do you have some list of blockers to scale it up to 1000 pods/node ( or at least few 100s ) ?
I am mostly interested in kubelet/docker limitations.

cc @dchen1107 @vishh

The last time I tried it:

file descriptors in docker
inotify handles in docker
OOM

If you have a 64 GB machine and you assume every pod needs a paltry 100 MB
of memory, that's about 650 pods.  That doesn't count system overhead which
is a few percent of the machine.  Getting to a 1000 pods means heavy
oversubscription, and in general that will probably be a bad experience
until we retrain the system and the kernel to handle priorities better.
That said, getting to 300 pods should be feasible, it's just going to be a
matter of chipping away at the problems that arise.
On Fri, Jul 31, 2015 at 7:08 AM, lleszczu<EMAIL_ADDRESS>wrote:

Hi,
I just started playing with kubernetes on bare-metal servers. I wonder how
many pods I can start per server. According to
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/test/e2e/density.go#L175
k8s should support 30 pods/node, but for bare metal deployments it is very
low. Do you have some list of blockers to scale it up to 1000 pods/node (
or at least few 100s ) ?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/12082.

During my initial tests I was able to start about 250 pods on a single node, with 32GB of RAM, but I am interested in feasibility of running it on something like 128-256GB. So memory wouldn't be a problem. Right know first issue I can see is simply starting that many pods. From what I can see docker daemon is not handling very well communication with kubelet. (  https://github.com/GoogleCloudPlatform/kubernetes/issues/12099 )

@thockin gives a good list of potential issues. Besides that, there are scalability / performance issue in today's kubelet. To manage all those pods on node, kubelet performs a lot of heavy operations on docker during its sync loop. We are working on improving it for 1.1 release. The first thing we are experimenting is using docker event stream.
I did some measurement before 1.0 release on 32 cores, 28.2GB RAM VM, kubelet can reliably manage 150 pods (each pod has 2 containers).

@dchen1107 do you have some numbers, what would be expected number of pods after switching to event streams ? Should we expect 2x boost or 10x ?

cc/ @yujuhong who is experimenting docker event stream. YuJu, is any data we could share?

I am still working on the design doc, and haven't had a working prototype yet. I do expect cpu usage and docker requests to drop significantly if we switch to docker event stream (or similar things). I will update once I get some numbers.

@yujuhong is there any public place where we can track progress on that ?

@yujuhong is there any public place where we can track progress on that ?

@lleszczu, I just created an issue for this, and will update later.


How does athena calling other programmes ?

without installing  virtualenv, I have installed all the  required software and add in my environment path
(add the /path/to/software/bin to ~/.bashrc), and the athena were installed in ~/miniconda2/bin/athena-meta, when I run athena, the output showed that could not find bwa command:
$ athena-meta config.json
============================== bin_reads ==============================
1 chunks to run. Starting...
2018-11-19 21:11:04 - --starting logging BinMetaReadsStep --
2018-11-19 21:11:04 - get seed contigs from input assembly
2018-11-19 21:11:04 - computing seed coverages (required pass thru *bam)
2018-11-19 21:11:04 -   3 total inputs seeds covering 809 bases
2018-11-19 21:11:04 -   1 input seed contigs >= 400bp and >= 10.0x coverage covering 400 bases
2018-11-19 21:11:04 - created 2 bins from seeds
2018-11-19 21:11:04 - -> finished running step; time elapsed: 0:00:00.030149
2018-11-19 21:11:04 - --stopping logging--
--> bin_reads completed.
============================== index_reads ==============================
1 chunks to run. Starting...
2018-11-19 21:11:04 - --starting logging IndexReadsStep_tianchen --
2018-11-19 21:11:04 - index fastq /home/tianchen/10x/barcoded.fastq
2018-11-19 21:11:04 - done
2018-11-19 21:11:04 - -> finished running step; time elapsed: 0:00:00.004956
2018-11-19 21:11:04 - --stopping logging--
--> index_reads completed.
============================== assemble_bins ==============================
2 chunks to run. Starting...
2018-11-19 21:11:05 - --starting logging AssembleMetaBinnedStep.bin.0 --
2018-11-19 21:11:05 - performing local assembly for 1 seeds
2018-11-19 21:11:05 - --starting logging AssembleMetaBinnedStep.bin.1 --
2018-11-19 21:11:05 - targeting 100x short-read subassembly coverage
2018-11-19 21:11:05 - using barcodes mapped within 10000bp from seed end-points for seed subassembly
2018-11-19 21:11:05 - performing local assembly for 0 seeds
2018-11-19 21:11:05 - targeting 100x short-read subassembly coverage
2018-11-19 21:11:05 - using barcodes mapped within 10000bp from seed end-points for seed subassembly
2018-11-19 21:11:05 - assembling barcoded reads for seed k99_25
2018-11-19 21:11:05 - merging all outputs
2018-11-19 21:11:05 - done
2018-11-19 21:11:05 - removing bin directory ./working/bin.1
2018-11-19 21:11:05 - -> finished running step; time elapsed: 0:00:00.000714
2018-11-19 21:11:05 - --stopping logging--
2018-11-19 21:11:05 - determing local assemblies
2018-11-19 21:11:05 - 0 initial link candidates to check
2018-11-19 21:11:05 -   - 0 pass reciprocal filtering
2018-11-19 21:11:05 - root-ctg:k99_25;numreads:136;checks:0;trunc-checks:False;asms:0;trunc-asms:False
2018-11-19 21:11:05 -   - found 1 candidates
2018-11-19 21:11:05 - performing local assemblies
2018-11-19 21:11:05 - assembling with neighbor None
2018-11-19 21:11:05 -   - 92 orig barcodes
2018-11-19 21:11:05 -   - 92 downsampled barcodes
2018-11-19 21:11:05 -   - 43.18x estimated local coverage
2018-11-19 21:11:05 -   - 2 min_support required
number of threads 2
reads 184
long reads 10
seed contigs 1
extra reads 0
read_length 150
kmer 20
kmers 4233 4243
merge bubble 0
contigs: 3 n50: 293 max: 293 mean: 125 total length: 375 n80: 62
aligned 8 reads
confirmed bases: 79 correct reads: 0 bases: 0
distance mean 86 sd 0
seed contigs 1 local contigs 6
kmer 40
kmers 931 926
merge bubble 0
contigs: 1 n50: 293 max: 293 mean: 293 total length: 293 n80: 293
aligned 8 reads
confirmed bases: 79 correct reads: 0 bases: 0
distance mean 86 sd 0
seed contigs 1 local contigs 2
kmer 60
kmers 354 354
merge bubble 0
contigs: 1 n50: 293 max: 293 mean: 293 total length: 293 n80: 293
aligned 8 reads
confirmed bases: 79 correct reads: 0 bases: 0
distance mean 86 sd 0
seed contigs 1 local contigs 2
kmer 80
kmers 330 328
merge bubble 0
contigs: 1 n50: 293 max: 293 mean: 293 total length: 293 n80: 293
aligned 8 reads
confirmed bases: 79 correct reads: 0 bases: 0
distance mean 86 sd 0
seed contigs 1 local contigs 2
kmer 100
kmers 194 193
merge bubble 0
contigs: 1 n50: 0 max: 0 mean: 0 total length: 0 n80: 0
aligning seed contigs

0 aligned
hit 0 connected components
retained 0 of 0 contigs
reads 184
aligned 0 reads
distance mean -nan sd -nan
invalid insert distance
:::: -11
2018-11-19 21:11:05 - something funky happened while running idba_ud (got error code -11) but there's not much we can do so continuing
2018-11-19 21:11:05 - failed to produce correctly formatted contigs in ./working/bin.0/asm/k99_25/local-asm.0/contig.fa
2018-11-19 21:11:05 -   - finished 1
2018-11-19 21:11:05 - merge long output contigs from local assemblies
2018-11-19 21:11:05 - contig path for local asm k99_25_None.0 not generated
2018-11-19 21:11:05 -   - 0 contigs covering 0 bases
2018-11-19 21:11:05 - merging all outputs
2018-11-19 21:11:05 - done
2018-11-19 21:11:05 - removing bin directory ./working/bin.0
2018-11-19 21:11:05 - -> finished running step; time elapsed: 0:00:00.428354
2018-11-19 21:11:05 - --stopping logging--
--> assemble_bins completed.

============================== assemble_olc ==============================
1 chunks to run. Starting...
2018-11-19 21:11:05 - --starting logging AssembleOLCStep --
2018-11-19 21:11:05 - jointly overlap-assemble
2018-11-19 21:11:05 - merge input contigs
cmd bwa mem -t 4 /home/tianchen/10x/final.contigs.fa ./results/olc/pre-flye-input-contigs.fa | samtools view -bS - | samtools sort -o ./results/olc/align-inputs.bam -
/bin/sh: bwa: command not found
cmd samtools index ./results/olc/align-inputs.bam
2018-11-19 21:11:05 - filter short subassembled contigs and merge with seeds
2018-11-19 21:11:05 - ========== Exception ==========
2018-11-19 21:11:05 - Traceback (most recent call last):
2018-11-19 21:11:05 -   File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/pipeline.py", line 50, in _run_chunk
2018-11-19 21:11:05 -     chunk.run()
2018-11-19 21:11:05 -   File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/stages/assemble_olc.py", line 96, in run
2018-11-19 21:11:05 -     premergedfiltfa_path,
2018-11-19 21:11:05 -   File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/stages/assemble_olc.py", line 160, in filter_inputs
2018-11-19 21:11:05 -     ctg_size_map = util.get_fasta_sizes(mergedfa_path)
2018-11-19 21:11:05 -   File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/mlib/util.py", line 151, in get_fasta_sizes
2018-11-19 21:11:05 -     fasta = pysam.FastaFile(fa_path)
2018-11-19 21:11:05 -   File "pysam/libcfaidx.pyx", line 123, in pysam.libcfaidx.FastaFile.cinit
2018-11-19 21:11:05 -   File "pysam/libcfaidx.pyx", line 183, in pysam.libcfaidx.FastaFile._open
2018-11-19 21:11:05 - IOError: error when opening file ./results/olc/pre-flye-input-contigs.fa
2018-11-19 21:11:05 -
2018-11-19 21:11:05 - error when opening file ./results/olc/pre-flye-input-contigs.fa
Traceback (most recent call last):
File "/home/tianchen/miniconda2/bin/athena-meta", line 11, in
sys.exit(main())
File "/home/tianchen/miniconda2/lib/python2.7/site-packages/main.py", line 104, in main
run(options)
File "/home/tianchen/miniconda2/lib/python2.7/site-packages/main.py", line 36, in run
runner.run_stage(stage, stage_name)
File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/pipeline.py", line 33, in run_stage
cluster.map(_run_chunk, to_run)
File "/home/tianchen/miniconda2/lib/python2.7/site-packages/athena/cluster.py", line 43, in map
return pool.map_async(fn, args).get(9999999)
File "/home/tianchen/miniconda2/lib/python2.7/multiprocessing/pool.py", line 572, in get
raise self._value
IOError: error when opening file ./results/olc/pre-flye-input-contigs.fa
and also, the error showed that fail to open the ./results/olc/pre-flye-input-contigs.fa.
I think I need help,thanks!

If it's easier for setup, please see #13.  Athena can now be installed using conda.


"Hub Operator FID is not set" via docker even already set in .env

I has setting .env file like documents has guided but
after running I got warning sign that telling "Hub Operator FID is not set " as per image below

but I already set it in .env file as per image below

you can have a try like this.
docker compose down hubble, then up it again.
make sure that docker init the .env and make the $XXX variable active.

same issue, i put .env file in  /home/node/app/apps/hubble

same here:
{"message":"✅ | Bootstrapping from 4 peers\n","timestamp":"2024-06-25T06:20:26.201Z","type":"out","process_id":0,"app_name":"hubble"}
{"message":"⚠  | Hub Operator FID is not set\n","timestamp":"2024-06-25T06:20:26.201Z","type":"out","process_id":0,"app_name":"hubble"}```

I can confirm have been config .env file.

Currently, it seems that only the custody FID created with warpcast is recognized as valid. As a temporary workaround, we are manually modifying the .env file to make it work. When I inquired about this issue with farquest, they advised me to report it in this repository.

The same for me. Any solution for that?

getting same error message. defining the FID in docker-compose.yml, doesn't help either.

Same issue. Anyone can help me?

I got the same issue:
2024-07-07 12:47:05 {"message":"⚠  | Hub Operator FID is not set\n","timestamp":"2024-07-07T05:47:05.873Z","type":"out","process_id":0,"app_name":"hubble"}
please help


portaudio: explicitly disable parallel building

Can't we just use the patch you linked, until it's included in an upstream release?

I was not able to apply it easily as it relies on prior changes in the tree:
       > applying patch /nix/store/l9fic7b4ri966hmay3c4pdsnw7ipy3s7-28d2781d9216115543aa3f0a0ffb7b4ee0fac551.patch
       > patching file configure.in
       > Hunk #1 FAILED at 377.


[VM Restore]: Support restoring to a target VM different than the source

What this PR does / why we need it:
This PR adds support to restore a snapshot to a target VM that is different from the source VM. For exmaple, VM 1 could take a snapshot and restore it to VM 2 could restore from that snapshot. Before this PR such action is considered as an error.
This change is a first step towards supporting VM cloning. To have a better context, I suggest taking a look on the design proposal, and especially this comment that summarizes up the path forward.

Summary of the changes that were made:

Possibility to restore to a VM that is different than the source VM

Such a restore is valid only if the target VM does not exist. In this case, the target VM would be auto-created by the restore controller.
If the target VM both exists and is different than the source VM - the restore is considered illegal and would be rejected by validation webhooks.

New restore.Spec.Patches field of type []string is now added to the VirtualMachineRestore object.

These patches are being applied on the target VM during the restore contoller's reconciliation loop.
This facilitates a way to create a new VM that is different than the source VM without adding any custom logic to the restore controller.
The idea is that the cloning controller, which includes the different cloning options and logic, would use this mechanism to instruct the restore controller on how to modify the source VM. For example, this can be used to change a cloned VM's MAC address.

Release note:

Snapshot restores now support restoring to a target VM different than the source

/cc @mhenriks @davidvossel FYI

/retest

/retest

As-is, the target vm must exist before the restore action takes place.  I was surprised by that.  I think the target should probably be created if it does no exist.  Opinions @davidvossel @ShellyKa13?

As-is, the target vm must exist before the restore action takes place. I was surprised by that. I think the target should probably be created if it does no exist. Opinions @davidvossel @ShellyKa13?

Here are some motivations for this desicion:

In my mind, this capability isn't meant to be used in a stand-alone flow. Essentially, restoring to a new VM is a partial clone in the sense that the new VM is a clone without strapping identity characteristics. For example:

Labels / annotations cloning cannot be controlled (which especially bad when metadata labels are involved)

Disk serials / smbios serials / ssh hostname / mac address, etc' aren't being re-generated
This is exactly why we would have a dedicated cloning CRD & controller. As laid out in the design proposal, this step is only here to allow the cloning API to function. I don't think that there's a use case in which a human user would restore into a new VM directly and not during a cloning process.
Note: As laid out in DP, the clone API would have a source and target fields. As a first step, the only valid source would be a VM. In the future, I think it'd be great to support a Snapshot being a source. This way a snapshot could be made, then cloned to a new VM whenever needed (this could serve as an alternative to Templates in certain scenarios). Therefore, even if we don't want to perform a traditional VM cloning it should only be done through the cloning API.

A lot of logic around Kubernetes behaves that way. For example, if a Pod cannot be scheduled, it will stay in "Scheduling" phase until something happens. When a PVC is requested, it will seek a PV to mount to until it appears, etc. A restore waiting for its target VM is, in my eyes, a fairly regular Kubernetes behavior.

I haven't read the design before checking this PR and I was also surprised that the target VM needed to exist before doing the restore, I thought this was just a first phase of the implementation.
I think it should have been the use case if from I understand from the proposal and Itamars' comment that there a problem with regenerating new mac address and other stuff. If that's really the case then I guess it is acceptable that restore will only restore to an existing target vm since it should only be done by the clone API and the clone APi will be responsible for creating a VM with the needed generated stuff and then triggering the restore with it as target.
Although again, it's kind of doing half of the responsibility of the restore so it should be done only if there is no other way to solve the regeneration problem.
@itamarh regarding the "note" you mentioned actually it sounds to me like a simpler first step for cloning to use a snapshot as the source of the clone instead of making the clone API first do the snapshot and then use the snapshot as the source for the restore to a new vm target.

@iholder-redhat code looks good to me.
However, looks like the flake-checker tripped on one of the new functional tests

I haven't read the design before checking this PR and I was also surprised that the target VM needed to exist before doing the restore, I thought this was just a first phase of the implementation. I think it should have been the use case if from I understand from the proposal and Itamars' comment that there a problem with regenerating new mac address and other stuff. If that's really the case then I guess it is acceptable that restore will only restore to an existing target vm since it should only be done by the clone API and the clone APi will be responsible for creating a VM with the needed generated stuff and then triggering the restore with it as target. Although again, it's kind of doing half of the responsibility of the restore so it should be done only if there is no other way to solve the regeneration problem.

I see your point, but I think this is a fairly regular Kubernetes behavior. For example, when we perform migration, virt-controller schedules a "dummy" virt-launcher on the target node. This virt-launcher, by itself, isn't valid in any way. We count that when it is scheduled, one of virt-handler's controllers would pick it up and perform the actual migration. It's common that controllers utilize one another to complete their task when every controller does a partial job so that eventually the whole task is completed.
The point of having a Clone API is to decouple the cloning mechanism (which its main job is to create a target VM with stripped/regenerated identify) from the snapshot/restore API. It's fair to say "the snapshot/restore controller is responsible for taking a snapshot and restoring it. that's it. if you restore to the same VM - you're safe. If you restore to a new VM - it's up to you to make sure it is a valid one".

@itamarh regarding the "note" you mentioned actually it sounds to me like a simpler first step for cloning to use a snapshot as the source of the clone instead of making the clone API first do the snapshot and then use the snapshot as the source for the restore to a new vm target.

You're right, although from an implementation point of view it doesn't make things a lot easier (the extra step which is creating a snapshot is fairly easy). Therefore I'd prefer we have a basic cloning mechanism that is the most useful from the user perspective. Adding support for cloning from a snapshot is expected to be very easy.

@iholder-redhat code looks good to me. However, looks like the flake-checker tripped on one of the new functional tests

@jean-edouard
Thanks for having a look!
I've ran this functest locally for 30 times in a row and it passed every single time.
Maybe CI is overloaded? I saw relatively many fails in the past few days.
let's try again.
/test pull-kubevirt-check-tests-for-flakes

@jean-edouard not clear to me why it keeps failing on the check-flakes lane. It passed locally and for all the other compute lanes. Maybe CI is flakie/overloaded?

/retest

/retest
ping @mhenriks @ShellyKa13

@iholder-redhat I think the restore API should be useful on it's own and not just in the context of the clone API.  And I am not buying the "eventual consistency is normal" rationale presented here.  This flow does not seem normal to me.
Given:  VM Foo does not exist anymore, but a snapshot of Foo does.

Create VMRestore with VM Foo as target
Sometime later, create VM Foo with bogus spec
Wait for VMRestore to complete

My concern is with step 2.
If step 1 fails (target does not exist), that would make more sense to me I think.  But don't see why we cannot just create the target.
What do you think @davidvossel?

@iholder-redhat I think the restore API should be useful on it's own and not just in the context of the clone API. And I am not buying the "eventual consistency is normal" rationale presented here. This flow does not seem normal to me.
Given: VM Foo does not exist anymore, but a snapshot of Foo does.
Create VMRestore with VM Foo as target
Sometime later, create VM Foo with bogus spec
Wait for VMRestore to complete
My concern is with step 2.
If step 1 fails (target does not exist), that would make more sense to me I think. But don't see why we cannot just create the target.
What do you think @davidvossel?

I think I'd prefer the restore object creates the target VM... and my primary reasoning here is just to avoid clobbering an existing VM on accident. So if restore targets a VM that already exists, i think that should fail validation simply as a safety check.
basically, my concern here is more about people accidentally shooting themselves in the foot with the restore object rather than usability. Ultimately the clone API will deliver the usability part, we just need the restore part to be safe.

I think I'd prefer the restore object creates the target VM... and my primary reasoning here is just to avoid clobbering an existing VM on accident. So if restore targets a VM that already exists, i think that should fail validation simply as a safety check.

Interesting point.  So a restore target must not exist and will be created unless it is the original VM from the VMSsnapshot source?  Sounds good to me

I think I'd prefer the restore object creates the target VM... and my primary reasoning here is just to avoid clobbering an existing VM on accident. So if restore targets a VM that already exists, i think that should fail validation simply as a safety check.
basically, my concern here is more about people accidentally shooting themselves in the foot with the restore object rather than usability. Ultimately the clone API will deliver the usability part, we just need the restore part to be safe.

There are basically 3 ways to restore snapshots:

Restoring to the same VM that took the snapshot.
Cloning - creating a new VM then restoring to it.
Creating a "baseline" / "template" / "golden image" - meaning a VM that would serve as a starting point for every workload.

To further explain usage 3: an admin can create a VM, get it to a desired initial state, then take a snapshot. Then, 5 new VMs can be created from snapshot (=cloned). The admin then knows that it is always possible to "reset" the VMs to their initial state by re-restoring. This can be useful, for example, with VM Pools.
With your idea we sacrifice this usability which can be valuable IMO.

and my primary reasoning here is just to avoid clobbering an existing VM on accident.

I'm not sure I understand the difference between restoring to a new or an old VM. In both scenarios restoring by accident can happen and is dangerous in the exact same way.

Interesting point. So a restore target must not exist and will be created unless it is the original VM from the VMSsnapshot source? Sounds good to me

@mhenriks I think this rule (a restore target must not exist and will be created unless it is the original VM from the VMSsnapshot source?) is complicated and is very hard to understand from the user's perspective. It would surprise the user and it wouldn't be clear why it exists at all.

TLDR: I can settle on creating the target VM, but I don't think we should disallow re-restoring to a different VM then the source.

@davidvossel @mhenriks
Technically, what does it mean to create the target VM?

What is the name of the target VM?
Do we simply copy the spec? What about MAC address / smbios serial, etc?

Creating a target VM for a restore object (which has stipped / regenerated identity) is essentially cloning. Using the same logic for restores does not make sense for me.
In essence, cloning controller would perform these sub-tasks to perform cloning:

Create a snapshot
Create a target VM with stipped / regenerated identity
Restore to this new VM
Delete snapshot

The main step here is 2. Again, it doesn't IMO to have this logic in restore controller.
@mhenriks:

And I am not buying the "eventual consistency is normal" rationale presented here. This flow does not seem normal to me.

If step 1 fails (target does not exist), that would make more sense to me I think. But don't see why we cannot just create the target.

As said above, it is problematic to create the target.
 The "not buying it" / "this flow does not seem normal to me" do not provide very convincing reasoning IMHO. Most of Kubernetes components work that way and it's common for controllers to use and complete each other. Even if I put the technical difficulties aside here, I'm still not sure what's the big problem here to begin with.

TLDR: If you insist on not waiting for the target VM (although I'm not convinced), I would suggest to fail right away if it does not exist as creating the target VM is problematic because it demands stipping identity which is a cloning logic.

With your idea we sacrifice this usability which can be valuable IMO.

Auto creating the VM shouldn't impact usability. the use case you describe where we want the ability to clone multiple new VMs from a snapshot should be possible with what i'm describing.
Is there a technical reason you can't automatically create the VM for the clone when using the restore object? I'd prefer that due to the safety concerns I raised in my previous comment.

I think this rule (a restore target must not exist and will be created unless it is the original VM from the VMSsnapshot source) is complicated and is very hard to understand from the user's perspective. It would surprise the user and it wouldn't be clear why it exists at all.

I don't want us to add the ability to clobber an existing VM with another VM's restore object.  So, we can create a new VM from a restore, or restore the exact VM the restore object came from... but not use a restore object to clobber an existing (different) VM.

PR is ready to review again @ShellyKa13 @mhenriks @davidvossel
The main changes are:

If target VM does not exist, it's being created
An optional VmPaches field is now added to the restore CRD

These patches are applied offline (i.e. not through Kubernetes API, but on locally marshalled objects)
The patches are applied before target VM creation as well as during reconciliation

Unit & functional tests are added

Please note that the new changes reside only in the last 3 commits - if you already reviewed this PR, reviewing the last 3 commits should be enough.
Thanks in advance for reviewing :+1:

/retest

/test pull-kubevirt-e2e-kind-1.23-vgpu-nonroot

/retest

/retest

/retest

@davidvossel @ShellyKa13 @mhenriks
I had some issues with MAC address collisions in the functional tests.
The PR is now ready to review. Thanks.
/retest

/lgtm

/retest

/lgtm cancel

/test pull-kubevirt-e2e-k8s-1.21-sig-compute-migrations

/retest

/retest

/retest

/retest

/retest

/retest

/test pull-kubevirt-e2e-k8s-1.23-sig-compute-migrations-nonroot


Add basic unit/integration tests for ported code

Now that basic functioning code has been ported over from 'old' dds, write baseline integration/unit tests to enable changes to be made moving forward

Can be closed when https://github.com/wellcomecollection/iiif-builder/pull/33 is merged