refactor(superset-ui-core): Migrate FallbackComponent.test to RTL

SUMMARY

Simple changes to utilize RTL instead of enzyme
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@eschutho thanks for reminding me, forgot in my haste to get a PR up. this is what you're thinking of, right?

@rtexelm yeah, that's perfect!


Updating Ephemeral Slack Messages

The docs say:
Currently, updating interactive messages are not supported by ephemeral messages, but you can still create them and listen to the events.

Are there any plans for adding support for this in the near future? Slack's own docs leads me to believe that it is possible (though it's not very clear how). Are there any known workarounds (within our outside of Botkit) for updating ephemeral messages?
Cheers,
Viktor

I just got a response from Slack and it seems like this isn't supported on their side yet.

Closing for now, feel free to create a new request when it is possible!


⚠ Bofrost.at has degraded performance

In 27a081d, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 852 ms

Resolved: Bofrost.at performance has improved in 51d768a.


Repeatable build process

I'm not submitting this to http://www.mattermost.org/feature-requests/ since it's not an app feature request.
Summary
In both of the following two use cases...

...trying to set up a development environment to be able to build the app in order to be able to contribute fixes
...trying to build every tagged release for a non-profit association I'm involved in

...I face difficulties getting the project to compile. There should be a reproducible way to build the app that is tested for every release.
Details
I have already built multiple versions of mattermost-mobile over the last few months. I cannot recall a single time where it just worked. Every time I faced different error messages, new dependencies, changed Android requirements, bugs related to RN, and similar.
The build instructions seem to be distributed over a few different places. In an attempt at saving myself work in the future, I tried coming up with a Dockerfile that should be able to build mattermost-mobile for Android:
https://github.com/coredump-ch/mattermost-mobile/commit/39879df1fbdfc44ec496f1bf84cc40978e829aef
This commit worked for version 1.14.0 but it fails for 1.16.1. This time the error message is Could not find org.webkit:android-jsc-intl:r224109. Maybe a changed Android toolchain dependency, I don't know.
If you want to grow mattermost-mobile as an open source project, and if it should be a viable way for enterprise customers to build a custom version of the app, you'll want to make it as easy as possible to compile it. Do you have any plans to try to automate the build process and its dependencies? Fastlane already simplifies a lot of this, but the dependencies still vary a lot from version to version.
In an ideal world, I would love to see the following:

A Dockerfile that contains all dependencies required to build mattermost-mobile
An instruction on how to parametrize the Dockerfile to build a custom version of the app
A release process where that Dockerfile is verified every time a release is made (or possibly even integrated into a CI pipeline to create nightly builds)

Right now the friction of simply getting mattermost-mobile to build for every new release is already that high that I don't have any motivation left for bugfix-attempts. Maybe that's just me, but if you are getting that feedback from customers as well (and if there are very few bugfixes or features contributed by the community) then maybe the processes should be improved.
Thanks for your work! Mobile development is not an easy ecosystem, and the JS world isn't easy either :slightly_smiling_face:

Thanks for the feedback @dbrgn
Even though I understand where you coming from, I have to say that we need to constantly bump dependencies versions for every platform: iOS, Android and JavaScript.
That said we do update the developer setup docs and the build your own docs every time that there is a change that can disrupt the build process
For example this PR: https://github.com/mattermost/mattermost-developer-documentation/pull/248 which is waiting review will update some needed changes for Android.
After all that is done you should be able to build the apps without issues by executing make build, make build-ios and/or make build-android
if there is something that you find that we omitted or that can be improve in the documentation please do let us know or better yet submit a PR against it.
@cpanato do you think is possible to add to the docs our Jenkins pipeline as an example so others can replicate it?
Finally @dbrgn if you find yourself having issues building the app (which I do suffer from them a few times when I need to update dependencies) you can reach me in the Mattermost community server and talk about it in the Native Mobile Apps channel.  My handle there is @elias

@enahum thanks for the quick reply! Those docs are much better than I had them in mind (last time I looked at them was over half a year ago).
If those instructions / dependencies could be put into a set of scripts or something like a Dockerfile that can be easily replicated in an isolated environment, I think that would really improve the situation tremendously.
I'll try again to build version 1.16.1 using the docs tonight or tomorrow.

@enahum yes, I will make a PR adding the Jenkins pipeline in the documentation. Also, the plan is opensource the code we have so far, but I need some time to review to check if there is not sensitive data.
but for now i will make a pr adding the code in the documentation.

assigning myself to make the pr :)

By the way, fastlane setup is missing in the developer setup docs. :slightly_smiling_face:

@dbrgn , You can freely fork the docker factory I made : https://github.com/BastienF/mattermost-mobile/tree/master/factory

I think an image factory might be a bit much, but regardless I will +1 here by linking to my own build; the CI file is for GitLab CI but it mostly uses a purpose-built Docker image and executor environment that should be easy enough to replicate using your preferred toolchain.

Going to close this issue as it hasn’t had any recent activity

There may not be activity here but I think this is still a valid issue.

For the record, I have given up on building a custom Mattermost app version, because every new release required hours of work to update the build scripts and fix problems during compilation. Right now we simply use the official Mattermost app, with the downsides like pushes going through Mattermost servers, users not being able to use two Mattermost servers simultaneously and not being able to pre-configure things like the server URL or logos.
Automating the entire build process in a repeatable environment (e.g. Docker) would also have the added benefit that reproducible builds become a possibility. Reproducible builds would allow you to prove that your release on Google Play was actually built from the sources you're publishing, and doesn't contain any changes / backdoors. (Not sure how easy this is to achieve with RN, in a pure Android app it's certainly possible.)
This feedback is not meant to say "Mattermost sucks", I'm still thankful for the work that's being invested (and as an Android developer I know how complex toolchains can be). I just hope it can be valuable feedback for improving the build process. If you're primarily targeting on-premise enterprise customers, then those will want to build their own apps. In that case, a simple, reliable and repeatable build process is invaluable.


Does "MATCHES" work?

From the documentation:
select 'foo' matches 'f';

The result is not shown, but if I try it, I experience the error:
$ sqlite-tools-osx-x86-3410000/sqlite3
SQLite version 3.41.0 2023-02-21 18:09:37
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .load ./regex0
sqlite> select 'foo' matches 'f';
Parse error: near "'f'": syntax error
  select 'foo' matches 'f';
                       ^--- error here

Is it supposed to work?
MacOS, official SQLite, latest everything.

My bad, that was a typo in the documentation. It has now been fixed, only the REGEXP operator works with that syntax (select 'foo' regexp 'f';), or any of the other functions listed in docs.md


Name of the boot partition

Could the "boot" partition be named "WIFIBRDCAST, like in the legacy 1.6rc6 ?

Are you referring to the Label when you mount the SD card under windows?

Yes, and under Linux to ...
It could be disturbing to some users not to find the WIFIBRDCAST SD card, which is mentioned in the wiki.

Please, should you add this for 1.6.
I'm sure that many users will not understand that "boot" is the new name for "WIFIBRDCAST" partition ...

I will try, below link for my personal reference.
https://ubuntuforums.org/showthread.php?t=1113236

I've found the command to do it :
fatlabel /dev/mmcblk0p1 WIFIBRDCAST
That's to be done from the Pi shell. So the command should be integrated into a "run-chroot.sh" script.

Feel up to making a pull request? Or should i add it sometime this week?

Please could you add this by yourself, because I don't know in which part of which script to add it !
Thanks.

I will make a PR

This pr should be reverted. Did not work. I think the dir location needs to be adjusted then the command should work

Yes you're right. /dev/mmcblk0p1 doesn't exist when we are in the script.
So I need to find the good loop path for this partition ...

This might be possible to do on one of the non chroot files (run file). Thanks for putting in the time and looking at this!

I have added code for this on 99-run.sh in the 04 stage.
It's running now as a final test, but all appears good, i'll commit in a few minutes i hope.
After that this issue will be closed

Thanks for your help guys !
I will replay all the script this evening with all latest PR.

I have added code for this on 99-run.sh in the 04 stage.

Are you sure ? I can't see anything new in 99-run.sh ...

It's not comitted yet, on my work pc, need to test it, but pretty sure it works

Ok, thanks

I have added code for this on 99-run.sh in the 04 stage.

Could you please share your code, so I could also test it ?

I double double checked it, so i assume it works for everyone.

I can confirm it works.


Fees is base currency subtracted from quote currency

Description

Fix fees in base currency not being subtracted from the quote currency
for crypto cash accounts. Updating regression tests to assert
portfolio, cashbook state and holdings state.

Related Issue

See https://www.quantconnect.com/forum/discussion/13111/cashbook-is-not-properly-updated/p1/comment-38737
Previous related PR https://github.com/QuantConnect/Lean/pull/6166
Motivation and Context

Correctly model fees
Requires Documentation Change

N/A
How Has This Been Tested?

Regression algorithms reproducing issue
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] Refactor (non-breaking change which improves implementation)
[ ] Performance (non-breaking change which improves performance. Please add associated performance test and results)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

@DerekMelchin ran an algorithm with this PR branch to check out the results. Here are the logs:
2022-02-05 01:28:00 :   Before trade
2022-02-05 01:28:00 :   BTC : 0.0004995
2022-02-05 01:28:00 :   USDT : 54.047075
2022-02-05 01:28:00 :   ETH : 0.0
2022-02-05 01:28:00 :   Order Event: Time: 02/05/2022 01:28:00 OrderID: 1 EventID: 1 Symbol: ETHUSDT Status: Submitted Quantity: 0.0067 Message: Binance Order Event
2022-02-05 01:28:00 :   When buying currency pairs, using Cash account types, fees in base currency will be deducted from the filled quantity so virtual positions reflect actual holdings.
2022-02-05 01:28:00 :   Order Event: Time: 02/05/2022 01:28:00 OrderID: 1 EventID: 2 Symbol: ETHUSDT Status: Filled Quantity: 0.0067 FillQuantity: 0.0066933 FillPrice: 2980.4 OrderFee: 0.0000067 ETH Message: Binance Order Event Buy
2022-02-05 01:28:00 :   BTC : 0.0004995
2022-02-05 01:28:00 :   USDT : 34.078395
2022-02-05 01:28:00 :   ETH : 0.0066933

and here is the information from Binance page:

We can see that the values of ETH and USDT match the information in Binance before and after the trade.

For completeness, here is the "before" image of the Binance website.


Merge 2023-Q3-v2.7x into main

To be merged at release time.

The incorrect base branch in #883 and #884 and subsequent revert in #886 seems like it's led to this situation resulting in the changes from #762 not being recognized. We'll need to reapply updates from #762 to main after the fact.


Stack does not properly forward ref

Stack appears to accept a ref prop based on the TypeScript types, but this ref is not actually bound to the underlying element:
export function Example() {
  const ref = useRef<HTMLDivElement>(null)

  useEffect(() => console.log(ref.current))

  return <Stack {...props} ref={ref}>contents</Stack>
}

If Stack correctly forwarded its ref, the console would log an HTMLDivElement instance. However, it instead always logs null.

import React, { forwardRef } from "react";
const Stack = forwardRef((props, ref) => {
return (
<div {...props} ref={ref}>
{props.children}

);
});
export default Stack;

In React, when a ref is passed to a component, that component must forward the ref to a DOM element using React.forwardRef. If the Stack component does not implement forwardRef, the ref will not be attached to the underlying DOM element, resulting in ref.current being null or undefined.
import React, { useRef, useEffect } from 'react';
export function Example(props) {
const ref = useRef(null);
useEffect(() => {
console.log(ref.current);
}, []);
return <Stack {...props} ref={ref}>contents;
}

Primer First Responder, we'd love your help fixing this ref!


check if it is possible to have a public-facing GitHub project (I might need temporary admin privileges for that)

Closing this.
Even with admin privileges, it’s not possible.
It’ll require an organization admin.


feat(metrics): EpimetheusMetricsReporterApi a la PrometheusMetricsReporterApi

We can do this later if the Epimetheus PR gets merged and we deem that it has ROI.


Export size of windows desktop executable increased in 4.3 compared to 4.2.2

Tested versions
v4.3.stable.official [77dcf97d8]
v4.2.2.stable.official [15073afe3]
System information
Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; <IP_ADDRESS>81) - AMD Ryzen 5 5600H with Radeon Graphics (12 Threads)
Issue description
I have a newly created project with one scene of Node2D in Godot v4.2.2. Exported executable with default export template and embedded PCK has size of 67,984 KB. The same project in v4.3 when exported with the same settings and "Compressed binary tokens" weights 82,151 KB. Hasn't 4.3 version aimed towards executable's size reduction? Or is this a feature for Web export only?
Steps to reproduce

Create new project.
Add Node2D and save scene.
Export project with Windows Desktop option and embedded PCK.

Minimal reproduction project (MRP)
MRP.zip

Godot 4.3 has more features, which means more code, and thus an increase in binary size.
14 MB increase is significant though and should be looked into. Part of it is probably the new D3D12 renderer, but I wouldn't expect it to be that heavy.

And I do not see any significant difference between beta1 and beta3 sizes in local builds (about 260 KiB increase). Maybe something in the build containers was changed?

I checked, the size increase started in beta2, which coincides with the update of build containers from Fedora 39 to Fedora 40: https://github.com/godotengine/build-containers/pull/141
So it seems the mingw-gcc update got us significantly bigger binaries too.


fix: virtualized thread height (theme v2)

🎯 Goal
Fix the bug, when the virtualized message list had 0 height in Thread.
🛠 Implementation details
Besides the height fix, also missing thread start styling has been applied in Thread's virtualized message list.
🎨 UI Changes
Non-virtualized thread

Fixed virtualized thread

:tada: This PR is included in version 3.5.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


riscv: Implement AES-192

Hello Christoph,
Your code was included in a series targeting the Linux kernel, and I noticed that the AES-192 restriction only applies to key schedule generation but not the AES transformations themselves, and so AES-192 can be supported just fine as long as we use generate the key schedule correctly.
I updated your .pl routines for the Linux kernel already, so I thought I'd contribute those changes to your OpenSSL code as well.
Kind regards,
Ard.

Hi Ard,
Thank you for the patch! I will test it and will include it then in the PR for OpenSSL (https://github.com/openssl/openssl/pull/20149).
Thanks,
Christoph


Distributed Training - Checkpoint Files Not Created.

Expected Behavior

Checkpoint files should be created: model/variables/variables_temp/part-00000-of-00001.data-00000-of-00001
After merge, these should be deleted.

Actual Behavior

Checkpoint files are not created therefore deletion process fails.

Steps to Reproduce the Problem
MODEL_DIR = BUCKET_URI

CMDARGS = ["--epochs=5", "--batch_size=16", "--distribute=multiworker"]

try:
   model = job.run(
       model_display_name="jharding_boston_" + UUID,
       args=CMDARGS,
       replica_count=4,
       machine_type=TRAIN_COMPUTE,
       accelerator_type=TRAIN_GPU.name,
       accelerator_count=TRAIN_NGPU,
       base_output_dir=MODEL_DIR,
       sync=True,
   )
except Exception as e:
   # may fail duing model.save() -- seems to be some issue when merging checkpoints from the workers
   print(e)

Set distribute=multiworker

Specifications

Notebook: notebooks/official/training/distributed_hyperparameter_tuning.ipynb
Version: 'tensorflow==2.5.0', 'tensorflow_datasets==1.3.0
Platform: VertexAI

Error Message
Training failed with:
code: 3
message: "The replica workerpool1-0 exited with a non-zero status of 1. Termination reason: Error. \nTraceback (most recent call last):\n  [...]\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/training/tracking/util.py", line 1219, in save\n    file_prefix_tensor, object_graph_tensor, options)\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/training/tracking/util.py", line 1164, in _save_cached_when_graph_building\n    save_op = saver.save(file_prefix, options=options)\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/training/saving/functional_saver.py", line 300, in save\n    return save_fn()\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/training/saving/functional_saver.py", line 287, in save_fn\n    sharded_prefixes, file_prefix, delete_old_dirs=True)\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/ops/gen_io_ops.py", line 504, in merge_v2_checkpoints\n    delete_old_dirs=delete_old_dirs, name=name, ctx=_ctx)\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/ops/gen_io_ops.py", line 528, in merge_v2_checkpoints_eager_fallback\n    attrs=_attrs, ctx=ctx, name=name)\n  File "/opt/conda/lib/python3.7/site-packages/tensorflow/python/eager/execute.py", line 60, in quick_execute\n    inputs, attrs, num_outputs)\ntensorflow.python.framework.errors_impl.NotFoundError: Error executing an HTTP request: HTTP response code 404 with body '{\n  "error": {\n    "code": 404,\n    "message": "No such object: jharding-distributed/model/variables/variables_temp/part-00000-of-00001.data-00000-of-00001",\n    "errors": [\n      {\n        "message": "No such object: jharding-distributed/model/variables/variables_temp/part-00000-of-00001.data-00000-of-00001",\n        "domain": "global",\n        "reason": "notFound"\n      }\n    ]\n  }\n}\n'\n\t when deleting gs://jharding-distributed/model/variables/variables_temp/part-00000-of-00001.data-00000-of-00001 [Op:MergeV2Checkpoints]

notebook passes CI/CD test


Entrypoint improvements/lint fixes

Why do we need this change?
There's several potential gotcha in the entrypoint that could result in
some removal/deletion of data that would be unexpected. As well instead
of using a double negative, leverage the appropriate test argument to
clarify the goal
What effects does this change have?

Replace ! -z with -n
Repace the straight rm -rf $NOMINATIM_POSTGRESQL_DATA_PATH with a safe
alternative that won't potentially result in deletion of /*

Thank you!


Downgrade Go version to ensure compatibility

with dependencies and tooling

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/lgtm
Thanks for extending the compatibility of the code!

/approve


AttributeError: 'tuple' object has no attribute 'size'

Everytime forward function includes unpacking a tensor using .size() , this error happens:

AttributeError                            Traceback (most recent call last)
 in ()
1 from torchsummary import summary
2 net3 = SSRN_LSTM(200,16).to(device)
----> 3 print(summary(net3,(1,7,7,200)))
5 frames
/usr/local/lib/python3.6/dist-packages/torchsummary/torchsummary.py in summary(model, input_size, batch_size, device)
70     # make a forward pass
71     # print(x.shape)
---> 72     model(*x)
73
74     # remove these hooks
/usr/local/lib/python3.6/dist-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
530             result = self._slow_forward(*input, **kwargs)
531         else:
--> 532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
534             hook_result = hook(self, input, result)
 in forward(self, x)
18         r_in = c_out.view(batch_size, time_steps, -1)
19
---> 20         r_out, (_, _) = self.rnn(r_in)
21
22         r_out2 = self.linear(r_out[:, -1, :])
/usr/local/lib/python3.6/dist-packages/torch/nn/modules/module.py in call(self, *input, **kwargs)
532             result = self.forward(*input, **kwargs)
533         for hook in self._forward_hooks.values():
--> 534             hook_result = hook(self, input, result)
535             if hook_result is not None:
536                 result = hook_result
/usr/local/lib/python3.6/dist-packages/torchsummary/torchsummary.py in hook(module, input, output)
21             if isinstance(output, (list, tuple)):
22                 summary[m_key]["output_shape"] = [
---> 23                     [-1] + list(o.size())[1:] for o in output
24                 ]
25             else:
/usr/local/lib/python3.6/dist-packages/torchsummary/torchsummary.py in (.0)
21             if isinstance(output, (list, tuple)):
22                 summary[m_key]["output_shape"] = [
---> 23                     [-1] + list(o.size())[1:] for o in output
24                 ]
25             else:
AttributeError: 'tuple' object has no attribute 'size'

cc: @sksq96

Line that caused this :
def forward(self, x):
batch_size, time_steps ,height, width , channels= x.size()

Same issue for me as well.

@vandana-rajan  this problem actually doesn't occur to me all the time. idk why this is so mysterious.

@vandana-rajan thank you for this link

See #124

yep, this error is related to LSTM output.


Attribute resolution

In reference to documentation: http://pywinauto.github.io/docs/dev_notes.html#attribute-resolution, it say: app.dlg.control
what is the best way to acces to button "Purge": w_customer.tabfolder_customer.tabpage_invoices.tabfolder_years.tabpage_2015.Purge.Click() ?
app.w_customer.Purge.Click() # Exists tabpage_2014, tabpage_2013, ...
or
app.w_customer['tabfolder_customer'].['tabpage_invoices'].['tabfolder_years'].['tabpage_2015'].['Purge'].Click()

It's hard to give a concrete tips without knowing your GUI layout. Generally, I'd suggest you to stick to "Dialog.control" model and break it on several small basic steps. Something as following:

Get app object:  app = app.start("path_to_your_app.exe")
Get the main dialog: dlg = app.top_window_() or dlg = app["window title"]
Get a tab control on the dialog: tab_ctrl = dlg["tab control name"]
Select the right tab page: tab_ctrl.Select("tab page name")
Run an action on the control on that page: tab_ctrl.Purge.Click()

Not sure if it applicable for your case but notice that .Net applications currently are only partially supported by Pywinauto.

app.dlg.control means that control is found in the whole controls tree under the dialog. So further expansion is not supported. If you need to click a button on another tab, you may do something like that:
app.dlg.TabControl.Select("tab name")
app.dlg.Purge.Click()

This is much shorter than following a lot of tabs.
Some debugging tricks can be useful:

app.dlg.PrintControlIdentifiers() method prints all available controls with corresponding access name for each one.
app.dlg.control.WrapperObject() with just typed . (dot) will give you the most useful list of available methods for the control. There are 2 equivalent constructions: app.dlg.Purge.WrapperObject().Click() (for debugging) and app.dlg.Purge.Click() (for better readable scripts). But app.dlg.Purge is not equivalent to app.dlg.Purge.WrapperObject(). The first one is a description only (the control may not actually exist at some moment), while the wrapper object is for already found control.

These tips and tricks can be moved to the documentation. So marking the issue as enhancement.

This is explained in new Getting Started Guide.


Fix for Ruby SDK v2.0.0

@jsmartt and @tmiotto what do you guys think about the cookbook version and the ruby sdk version parameter?

@hdiomede , I think the cookbook version is good, but for the sdk version, we can do ~> 2.0 (or ~> 2.0.0 at the least). We won't want to have to update this cookbook for bug fixes in the SDK, or minor version improvements either for that matter.

Regarding the Cookbook version, the plan is not to release yet, but it would be good to change the version so it can be different from the release.
My suggestion is to change it to the next master version and add one suffix like -dev or -alpha, since we don't know if our next release would be a bugfix, minor update or major update.
Following that, the version here would be 1.0.0-dev, but I'm open to suggestions. Any other ideas @jsmartt  @hdiomede ?

I'd say if we're not going to release, we don't need to mess with the version at all. I'd also avoid the -dev or -alpha versions and just keep it simple. When we're ready to release, we can bump the version.


added TopK to bandwidth_per_src_subnet

This PR uses the timebased TopK feature in the standard metrics produced by flp. The relevant metric is flp_bandwidth_per_source_subnet, with Topk=5, showing the 5 subnets with the most traffic in the most recent minute.

Codecov Report

Merging #306 (56f81a0) into main (c4e2f41) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #306      +/-   ##
==========================================
- Coverage   68.98%   68.94%   -0.05%
==========================================
  Files          82       82
  Lines        4756     4756
==========================================
- Hits         3281     3279       -2
- Misses       1276     1279       +3
+ Partials      199      198       -1

Flag
Coverage Δ

unittests
68.94% <ø> (-0.05%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/pipeline/ingest/ingest_collector.go
48.12% <0.00%> (-1.51%)
:arrow_down:

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


Configure /docker-entrypoint.d via a ConfigMap

What this PR does / why we need it:
Allow /docker-entrypoint.d to be populated via a ConfigMap. This is useful to install dependencies required by builds (ie. gcloud, kubectl, etc).
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] Chart Version bumped
[x] Variables are documented in the README.md

@tjwallace thanks for all your PRs, can you please consolidate all four Pas to one?
Also please bump chart version.

@rimusz 👍 done in #65


chore(ci): Use npm@5 on CI services

Changes:

Update all CI services to use Node@8 and npm@5
Remove preshrinkwrap script (now obsolete)
Move npm-shrinkwrap.json -> package-lock.json

Pending issues:

[x] Ubuntu 12.04 docker base image on Linux unsupported by Node@8 package

Problem solved by using tj/n to install Node

[x] npm@5: Installing npm@latest fails in Docker – https://github.com/npm/npm/issues/16807

Problem solved by using tj/n to install Node

[x] npm@5: Incorrect unmet peer dependency error – https://github.com/npm/npm/issues/16925

[ ] Await<EMAIL_ADDRESS>OR
[x] Use a patched version of html-angular-validate to circumvent this

[x] Node ABI mismatch for node-sass in sanity-checks – https://github.com/sass/node-sass/pull/1999

[ ] Await new version of node-sass with the above fix to be published

Travis CI build error:
/etcher/dist/electron-linux-x64-dependencies /etcher
Unhandled rejection Error: Invalid tag name " --production": Tags may not have any characters that encodeURIComponent encodes.
    at invalidTagName (/usr/local/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:76:15)
    at fromRegistry (/usr/local/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:265:13)
    at resolve (/usr/local/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:66:12)
    at npa (/usr/local/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:39:10)
    at /usr/local/lib/node_modules/npm/lib/install/deps.js:200:16
    at /usr/local/lib/node_modules/npm/node_modules/slide/lib/async-map.js:52:35
    at Array.forEach (native)
    at /usr/local/lib/node_modules/npm/node_modules/slide/lib/async-map.js:52:11
    at Array.forEach (native)
    at asyncMap (/usr/local/lib/node_modules/npm/node_modules/slide/lib/async-map.js:51:8)
    at exports.getAllMetadata (/usr/local/lib/node_modules/npm/lib/install/deps.js:199:3)
    at Installer.loadArgMetadata (/usr/local/lib/node_modules/npm/lib/install.js:325:3)
    at /usr/local/lib/node_modules/npm/lib/install.js:648:16
    at BB.join.then (/usr/local/lib/node_modules/npm/lib/install/read-shrinkwrap.js:41:16)
    at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)

AppVeyor build error:
./node_modules/.bin/npx ELECTRON_RUN_AS_NODE=1 electron  lib/gui/scss/main.scss > lib/gui/css/main.css
C:\projects\etcher\node_modules\npx\node_modules\npm-package-arg\npa.js:265
      throw invalidTagName(spec)
      ^
Error: Invalid tag name "ELECTRON_RUN_AS_NODE=1": Tags may not have any characters that encodeURIComponent encodes.
    at invalidTagName (C:\projects\etcher\node_modules\npx\node_modules\npm-package-arg\npa.js:76:15)
    at fromRegistry (C:\projects\etcher\node_modules\npx\node_modules\npm-package-arg\npa.js:265:13)
    at resolve (C:\projects\etcher\node_modules\npx\node_modules\npm-package-arg\npa.js:66:12)
    at npa (C:\projects\etcher\node_modules\npx\node_modules\npm-package-arg\npa.js:39:10)
    at parseArgs (C:\projects\etcher\node_modules\npx\parse-args.js:94:23)
    at Object.<anonymous> (C:\projects\etcher\node_modules\npx\index.js:20:6)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3
make[1]: *** [sass] Error 1
make[1]: Leaving directory `/c/projects/etcher'
make: *** [sanity-checks] Error 2
Command exited with code 2

Regarding the Invalid tag name CI errors, I found https://github.com/npm/npm/issues/17049

Would the Appveyor issue be fixed by changing

$(NPX) ELECTRON_RUN_AS_NODE=1 electron $(which node-sass) lib/gui/scss/main.scss > lib/gui/css/main.css

to
ELECTRON_RUN_AS_NODE=1 $(NPX) electron $(which node-sass) lib/gui/scss/main.scss > lib/gui/css/main.css

(in Makefile) ?
Although perhaps it would make more sense to install node-sass in the same way as we install uglify-es ?  IMHO relying on $(which node-sass) looks a bit ugly.

Looks like the Travis issue is somehow coming from scripts/build/dependencies-npm.sh ?

Although perhaps it would make more sense to install node-sass in the same way as we install uglify-es ? IMHO relying on $(which node-sass) looks a bit ugly.

@lurch I agree – we'd probably run into issue with not all of us using the same globally installed node-sass version, and that tripping up the sanity checks...

Should this PR also include some of the changes from #1514 ? Or are they each addressing orthogonal problems?

Yep, let's wait for npm v5 to stabilise, and then retry

Hopefully it'll be "3rd time lucky", LOL.


[Docs] Instructions to build Nighthawk are incomplete

Hello,
we were notified recently that the instructions on how to build Nighthawk are incomplete.
We are addressing this in the Nighthawk repository in PR#838. How would you like to approach it here. Do we update https://getnighthawk.dev/docs/building-nighthawk/ with a copy of these instructions? Or do we link to the Nighthawk's README? Open to other suggestions of course.

Hey @mum4k can you assign me this task?

This issue has been open for some time with no recent activity, unassigning to open it up for new contributors to give it a go.

Hi. I'm sure this is an Open Issue. I'd like to work on it!!


CI: remove setup.py based jobs from GitHub Actions and run less on merge to main

This also improves the python-dbg build, as well as makes visible that that job tests ATLAS as the BLAS/LAPACK library (that worked pleasantly well).
There was one failing test, test_signaltools.py::test_lfilter_bad_object. That's super niche and we've had problems with it before, so I just skipped it when running in a debug interpreter.
Running CI on merges of PRs to main is a waste of resources, and I find myself writing [skip ci] in merge commits a lot. I disabled those to save resources. We did that for NumPy too recently, and that has worked fine.

The new job is green. But not sure about the symbol hiding part. Can you confirm?

Good catch, thanks. I'll need to fix that up.

All green and tests seems ok now. Lets get this in. Thanks Ralf.

Very satisfying I must say, this PR 😄

Totally, almost nothing is running now 😃


vocab_size mismatch

Hey,
I have trained the DocParser model on my custom dataset to predict some new entities using your code. Model is trained successfully. But during inference time, I am getting the size mismatch. I figured out that there are few more tokens added to the model and those are the tokens that I want to predict on my dataset.
How can I update the code for inference to predict the new tokens?
I got this error
RuntimeError: Error(s) in loading state_dict for VisionEncoderDecoderModel:
size mismatch for decoder.model.decoder.embed_tokens.weight: copying a param with shape torch.Size([57552, 1024]) from checkpoint, the shape in current model is torch.Size([57525, 1024]).
size mismatch for decoder.lm_head.weight: copying a param with shape torch.Size([57552, 1024]) from checkpoint, the shape in current model is torch.Size([57525, 1024]).

Hello, You need to save the tokenizer (if not already done) and load the saved version before loading the weights

Hello, You need to save the tokenizer (if not already done) and load the saved version before loading the weights

Can you help on how to load the tokenizer? where I need to make changes?

Can you tell why the model is always giving {'text_sequence': ''} as the output regardless of any token asked to be predicted?

@mohit-rathod Sorry for the late reply. Could you check the input IDs and confirm if the labels are appropriately masked as expected? If they are, there might be a dataset bias to consider I guess.


support globs in artifact path

ready for review but not ready for merge until captain supports a grouping concept
todo

[x] write a test to confirm this works
[x] update documentation
[ ] add some kind of grouping uuid to the artifact model in captain
[x] upload specific filename to captain

haven't used TypeScript before (nor am I really using it here) but fun!

@kylekthompson what's the uuid on an artifact used for? Do we want a single uuid per artifact? per glob?

can we safely group by artifact name?

I guess rather than a UUID I'd rather pass

file path for artifacts
requested path (e.g. the glob) for grouping id.

Thoughts?

Re: the UUID discussion, my understanding is that we're using this string to match the artifacts and make a subsequent API call that the artifact has been uploaded. I think it should be safe to use the file path, assuming that the identifiers are only used within the span of a single execution of upload-captain-artifact. However, I could see somebody having multiple uploads within the same job that are actually different file paths:
job:
  name: whatever
  steps:
    - run: cd subdir1 && bundle exec rspec --write-to-path rspec.json
    - uses: rwx-research/upload-captain-artifact
      with:
        -path: rspec.json
    - run: cd subdir2 && bundle exec rspec --write-to-path rspec.json
    - uses: rwx-research/upload-captain-artifact
      with:
        -path: rspec.json

I'm pretty sure that usage will still be fine, but the slight risk that we have ambiguous identifiers and mess something up makes me feel inclined to continue using random UUIDs. If It's completely behind the scenes, we don't really gain anything by swapping the random identifier with a specific one. That said, I could also see passing up the glob pattern and/or specific file path since I imagine that metadata around the test results could be helpful in display or for diagnostics.

helpful. I assumed a fixed working directory.


[TextField] Jest Snapshot not compatable due to JSDom ScrollHeight Issue

Problem description
TextField is not compatable with the new Jest Snapshot feature because it uses JSDom.  shadow.scrollheight throws an error.
Steps to reproduce
Try to take a snapshot of a textfield in jest and error is thrown due to this.refs.shadow being null
Proposed fix
if(!shadow) return; on line 125 prevents js dom from breaking.
Versions

Material-UI: 0.15.4
React: 15.3.1
Browser: js-dom
Jest: Jest 15

I'm wondering. Is 2d2b3292 solving that issue?

We stopped using snapshots due to issues with a bunch of libraries.  We
have been using an alternative solution.
Regards,
Greg
The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any
On Sun, Dec 18, 2016 at 5:27 PM, Olivier Tassinari<EMAIL_ADDRESS>
wrote:

I'm wondering. Is 2d2b329
https://github.com/callemall/material-ui/commit/2d2b3292663c5a742c238b6d9ff2d1500fdd42f4
solving that issue?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/callemall/material-ui/issues/5279#issuecomment-267851687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABAuFagk2WpakwZCUh_yTDbx8b13u9R0ks5rJbNFgaJpZM4KJLxp
.

I think that #5015 closed this issue. I'm closing it for now. Thanks for raising that point.


chore: upgrade to eslint9

Upgrade eslint and @antfu/eslint-config, and fix some eslint errors.

It looks like the plugin packaged code uses commonjs syntax, maybe we shouldn't add the "type": "module" field.

It looks like the plugin packaged code uses commonjs syntax, maybe we shouldn't add the "type": "module" field.

Yeah, vscode extensions cannot be ESM

The test seems to be consistently failing, but it doesn't seem to be caused by my changes.


Remove ipdb from requirements file

ipdb is not used by testing suite. To avoid installing extra dependencies, remove it from requirements file. Developers who find ipdb helpful can install the package themselves.
The change was initially driven by the fact that ipdb was not installable on Fedora 41 because of its missing Python 3.13 support, which made the Sentry SDK build fail due to unsatisfied build requirements.

General Notes
Thank you for contributing to sentry-python!
Please add tests to validate your changes, and lint your code using tox -e linters.
Running the test suite on your PR might require maintainer approval. Some tests (AWS Lambda) additionally require a maintainer to add a special label to run and will fail if the label is not present.
For maintainers
Sensitive test suites require maintainer review to ensure that tests do not compromise our secrets. This review must be repeated after any code revisions.
Before running sensitive test suites, please carefully check the PR. Then, apply the Trigger: tests using secrets label. The label will be removed after any code changes to enforce our policy requiring maintainers to review all code revisions before running sensitive tests.

Thank you for the contribution! I would suggest that we simply remove the ipdb dependency completely

@szokeasaurusrex I agree! Done.

@szokeasaurusrex I noticed your change in the PR title. I agree, this looks better. I can change commit message accordingly. Should I or you do not want extra CI runs?

@rominf We usually use "Squash and merge" to merge PRs to master, and I am able to edit the commit message used in the merge. I was already planning to update the commit message accordingly, as that is the easiest way to fix the commit message (no CI rerun needed).
But, thanks for checking!


feat/add otel to integration tests

This PR adds otel to the integration tests but for some reason the traces aren't being picked up by the tracer for otel. This is a non-func change but a very good/close example for us to have in the codebase as to how you might set up tracing for a test.
I've also added a flag to the compiler for the integration tests which allows us to run something like:
buck2 run lib/dal:test-integration -- integration_test::rebaser --nocapture -Z unstable-options --format json --report-time
This generates a json report output from the tests which we can then pass to buildkite via the buildkite-test-collector crate which this PR also adds. This CLI has also been added to the nix flake, so it's available in CI but also locally for testing.

bors try

This is an example of what the pipeline needs to be adjusted to to pass these metrics up in CI:
---
steps:
  - group: ":test_tube: tests"
    key: tests
    steps:

      - agents:
          queue: default
          arch: x86_64
          os: linux
        command: "buck2 run root//lib/dal:test-integration -- --nocapture -Z unstable-options --format json --report-time | buildkite-test-collector"
        env:
          SI_TEST_LOG: debug
          RUST_BACKTRACE: full
          PASS_THROUGH_ENV_VARS: "CI BUILDKITE_ANALYTICS_TOKEN BUILDKITE_BRANCH BUILDKITE_MESSAGE BUILDKITE_BUILD_URL BUILDKITE_COMMIT BUILDKITE_JOB_ID"
        label: ":blue_book: :linux: test-integration (root//lib/dal:test-integration)"
        plugins:
          - "docker-compose#v4.14.0":
              run: app
              config: ".ci/docker-compose.test-integration.yml"
              mount-checkout: true
              env-propagation-list: "PASS_THROUGH_ENV_VARS"
              volumes:
                - /workdir/buck-out
                - /workdir/target
                - /workdir/tmp
        timeout_in_minutes: 125
        priority: 5

bors merge

bors merge

Previous failure was due to github outage/flakiness


Rackspace Load Balancer 'members' - weight and condition

This patch adds support for "weight" and "condition" attributes of Rackspace load balancer members, as documented
In addition, calls to the Rackspace driver.get_balancer() will now return a LoadBalancer with the list of members in extra['members'].

Merged in r1221010.
Thanks.


chore: rename "generate ageclasses" -> "generate raceclasses

Ageclass -> Raceclass

Motivation for renaming: function actually created raceclasses based on contestants ageclass property. command and resulting class should reflect that.
Illustration:

Agreed. Since the entity name is raceclasses we should call the method generate raceclasses. I will update the GUI.


:seedling: Ignore docker builds

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] PR title follows the guidelines defined in  https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

ignore docker builds for non-main branches
ignore docker builds for *.md

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Codecov Report

Merging #1651 (ca92e04) into main (674146c) will increase coverage by 2.84%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1651      +/-   ##
==========================================
+ Coverage   56.10%   58.95%   +2.84%
==========================================
  Files          72       72
  Lines        6495     6495
==========================================
+ Hits         3644     3829     +185
+ Misses       2606     2415     -191
- Partials      245      251       +6


HBASE-26458 Add UNSET_SNAPSHOT_PROP and fix TTL defaulting

See JIRA for detail: https://issues.apache.org/jira/browse/HBASE-26458
The bug is that the default value for TTL when no explicit TTL is -1, but the snapshot validation that applies hbase.master.snapshot.ttl looks for 0. Both should use -1, and share the value in a constant.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  1s
master passed

+1 :green_heart:
compile
5m  1s
master passed

+1 :green_heart:
checkstyle
1m 58s
master passed

+1 :green_heart:
spotbugs
3m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 47s
the patch passed

+1 :green_heart:
compile
4m 52s
the patch passed

+1 :green_heart:
javac
4m 52s
the patch passed

+1 :green_heart:
checkstyle
1m 54s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
19m 26s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
4m 19s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 41s
The patch does not generate ASF License warnings.

59m 55s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux b6a16d707873 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 1c47f80d83

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

modules
C: hbase-common hbase-client hbase-server U: .

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 42s
master passed

+1 :green_heart:
compile
2m 13s
master passed

+1 :green_heart:
shadedjars
8m 17s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 35s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 32s
the patch passed

+1 :green_heart:
compile
2m 12s
the patch passed

+1 :green_heart:
javac
2m 12s
the patch passed

+1 :green_heart:
shadedjars
8m 20s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 34s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m  2s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 32s
hbase-client in the patch passed.

+1 :green_heart:
unit
137m 33s
hbase-server in the patch passed.

178m 29s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux de2c7bf6c6fa 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 1c47f80d83

Default Java
AdoptOpenJDK-11.0.10+9

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

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

modules
C: hbase-common hbase-client hbase-server U: .

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  8s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 38s
master passed

+1 :green_heart:
compile
1m 57s
master passed

+1 :green_heart:
shadedjars
9m  4s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 24s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 16s
the patch passed

+1 :green_heart:
compile
1m 57s
the patch passed

+1 :green_heart:
javac
1m 57s
the patch passed

+1 :green_heart:
shadedjars
9m  4s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 20s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 56s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 35s
hbase-client in the patch passed.

+1 :green_heart:
unit
213m  2s
hbase-server in the patch passed.

254m 17s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 021f437fa253 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 1c47f80d83

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-common hbase-client hbase-server U: .

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

@joswiatek Since attached patches over the Jira no longer triggers QA, can you once create PRs for branch-2 and branch-1? Once we have the QA, all PRs will be merged and branch-2 change can be cherry-picked to 2.4 and 2.3 release branches.

I think in the release note, we'b better mention clearly about the broken behavior in the past, and how it is changed after this fix.

+1

Oh wait, now I recall why client and server side have different default TTL values.

SnapshotDescription is used at client side to store TTL value. Now, the default value is -1 if not specified.
Now, while creating snapshot, SnapshotDescription is converted to SnapshotProtos.SnapshotDescription and here is the logic for TTL conversion:
    if (snapshotDesc.getTtl() != -1L &&
        snapshotDesc.getTtl() < TimeUnit.MILLISECONDS.toSeconds(Long.MAX_VALUE)) {
      builder.setTtl(snapshotDesc.getTtl());
    }

Hence, by default -1 won't be set in SnapshotProtos.SnapshotDescription and the default value of SnapshotProtos.SnapshotDescription will be used:
message SnapshotDescription {
  required string name = 1;
  optional string table = 2; // not needed for delete, but checked for in taking snapshot
  optional int64 creation_time = 3 [default = 0];
  enum Type {
    DISABLED = 0;
    FLUSH = 1;
    SKIPFLUSH = 2;
  }
  optional Type type = 4 [default = FLUSH];
  optional int32 version = 5;
  optional string owner = 6;
  optional UsersAndPermissions users_and_permissions = 7;
  optional int64 ttl = 8 [default = 0];
  optional int64 max_file_size = 9 [default = 0];
}

As per this proto message, default value of TTL for SnapshotProtos.SnapshotDescription would be 0.
Hence, as per this logic, 0 is NO_SNAPSHOT_TTL_SPECIFIED and default TTL will be used that we set with config hbase.master.snapshot.ttl.
    long ttl = snapshot.getTtl();
    // set default ttl(sec) if it is not set already or the value is out of the range
    if (ttl == SnapshotDescriptionUtils.NO_SNAPSHOT_TTL_SPECIFIED ||
        ttl > TimeUnit.MILLISECONDS.toSeconds(Long.MAX_VALUE)) {
      final long defaultSnapshotTtl = conf.getLong(HConstants.DEFAULT_SNAPSHOT_TTL_CONFIG_KEY,
          HConstants.DEFAULT_SNAPSHOT_TTL);
      if (LOG.isDebugEnabled()) {
        LOG.debug("Snapshot current TTL value: {} resetting it to default value: {}", ttl,
            defaultSnapshotTtl);
      }
      ttl = defaultSnapshotTtl;
    }
    SnapshotDescription.Builder builder = snapshot.toBuilder();
    builder.setTtl(ttl);
    snapshot = builder.build();

@joswiatek No specifying TTL while creating snapshot should result in using default TTL as specified by hbase.master.snapshot.ttl. For the testing purpose, value of hbase.master.cleaner.snapshot.interval can be reduced to test this scenario so that SnapshotCleanerChore would be able to delete expired snapshots.
Also, here is the SnapshotCleanerChore logic that would delete only snapshots with value > 0 and value < Long.MAX:
        long snapshotTtl = snapshotDescription.getTtl();
        /*
         * Backward compatibility after the patch deployment on HMaster
         * Any snapshot with ttl 0 is to be considered as snapshot to keep FOREVER
         * Default ttl value specified by<EMAIL_ADDRESS>         */
        if (snapshotCreatedTime > 0 && snapshotTtl > 0 &&
                snapshotTtl < TimeUnit.MILLISECONDS.toSeconds(Long.MAX_VALUE)) {
          long currentTime = EnvironmentEdgeManager.currentTime();
          if ((snapshotCreatedTime + TimeUnit.SECONDS.toMillis(snapshotTtl)) < currentTime) {
            LOG.info("Event: {} Name: {}, CreatedTime: {}, TTL: {}, currentTime: {}",
                    DELETE_SNAPSHOT_EVENT, snapshotDescription.getName(), snapshotCreatedTime,
                    snapshotTtl, currentTime);
            deleteExpiredSnapshot(snapshotDescription);
          }
        }

I am confident that the current logic should work fine for the case where client doesn't specify snapshot resulting into using TTL specified by config hbase.master.snapshot.ttl.

The only case that might require behaviour change is when user specifies TTL 0:
> snapshot 'mytable', 'snapshot1234', {TTL => 0}

This snapshot would also be eligible to be deleted as per config hbase.master.snapshot.ttl because this config is applicable at entire cluster.
If use specifies TTL value less than -1, then that snapshot will never be deleted based on TTL.
Here is the current behaviour:

If client wants to create specific snapshot that should live forever regardless of hbase.master.snapshot.ttl config value, then they should specify TTL < -1.
If we don't want to enable TTL at entire cluster level, no need of any config change because the default value of hbase.master.snapshot.ttl is 0, which represents TTL Forever at server side.

It's also important to note that SnapshotCleanerChore can be enabled/disabled using shell command: snapshot_cleanup_switch. More details in the section Enable/Disable Snapshot Auto Cleanup on running cluster here

I just tested this locally on master branch.
Configs:

hbase.master.cleaner.snapshot.interval
10000

Shell commands and respective outputs:

snapshot 't1', 's2'
Took 2.1034 seconds

snapshot 't1', 's3', {TTL => -2}
Took 1.0925 seconds
=> [{"TTL"=>-2}]

snapshot 't1', 's1', {TTL => 5}
Took 2.1023 seconds
=> [{"TTL"=>5}]

After 5sec, the snapshot was gone.

Configs:

hbase.master.cleaner.snapshot.interval
10000

hbase.master.snapshot.ttl
20

Shell commands and respective outputs:

snapshot 't1', 's4'
Took 2.7291 seconds

Snapshot 's4' gets created with TTL 20 sec because of config hbase.master.snapshot.ttl:

After 20s, it was gone:

snapshot 't1', 's5', {TTL => -10}
Took 2.1079 seconds
=> [{"TTL"=>-10}]

TTL with negative values will stay forever regardless of any server side config changes.
TTL with positive values will be gone after TTL expires.
Snapshot created without specifying TTL will always have TTL values represented by config hbase.master.snapshot.ttl.

Thank you for digging into this! I totally missed the protobuf component. It is great to see this is working on master HEAD.
After reviewing these new protobuf details, I think the behavior where hbase.master.snapshot.ttl is ignored is only present on branch-1. On branch-1, the builder just directly takes the value from the snapshotProps, so -1 is actually sent and it does not match NO_SNAPSHOT_TTL_SPECIFIED, and the config is not applied. See here.
    SnapshotDescription.Builder builder = SnapshotDescription.newBuilder();
    builder.setTable(tableName.getNameAsString());
    builder.setName(snapshotName);
    builder.setType(type);
    builder.setTtl(getTtlFromSnapshotProps(snapshotProps));
    snapshot(builder.build());

On a branch-1 build, I do see snapshots being created with a -1 TTL when the default config is set.
Configs:
  <property>
    <name>hbase.master.snapshot.ttl</name>
    <value>600</value>
  </property>

Shell commands and outputs
snapshot 't1', 's1'

Snapshot is actually created with a TTL of -1 instead of 600

updating default value in proto message is considered as incompatible change

I am not experienced with protobuf, so I will take your word about defaults here. One question: is changing the logic around building the protobuf also an incompatible change? If we can update the TTL conversion logic to allow for sending -1, then the code changes in this PR will make sense and allow for the currently documented behavior to be fulfilled.
If that's not possible, I can update this PR with the clarifying doc changes as suggested.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 58s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 29s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 29s
master passed

+1 :green_heart:
compile
9m 54s
master passed

+1 :green_heart:
checkstyle
2m 12s
master passed

+0 :ok:
refguide
3m 47s
branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
spotbugs
15m 28s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 35s
the patch passed

+1 :green_heart:
compile
10m 21s
the patch passed

+1 :green_heart:
javac
10m 21s
the patch passed

+1 :green_heart:
checkstyle
2m 12s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+0 :ok:
refguide
4m  5s
patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
hadoopcheck
20m 49s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
14m 41s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 56s
The patch does not generate ASF License warnings.

104m 40s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile refguide

uname
Linux 9d17c07c44f8 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-1.8.0_282-b08

refguide
https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/2/yetus-general-check/output/branch-site/book.html

refguide
https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/2/yetus-general-check/output/patch-site/book.html

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

modules
C: hbase-common hbase-client hbase-server . U: .

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 50s
master passed

+1 :green_heart:
compile
3m 13s
master passed

+1 :green_heart:
shadedjars
8m 22s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 19s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 26s
the patch passed

+1 :green_heart:
compile
3m 12s
the patch passed

+1 :green_heart:
javac
3m 12s
the patch passed

+1 :green_heart:
shadedjars
8m 15s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 25s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
207m 40s
root in the patch passed.

253m 39s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 4770328ba33d 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-11.0.10+9

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

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

modules
C: hbase-common hbase-client hbase-server . U: .

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
6m 14s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 31s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 19s
master passed

+1 :green_heart:
compile
3m  0s
master passed

+1 :green_heart:
shadedjars
9m  8s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 33s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 15s
the patch passed

+1 :green_heart:
compile
3m  0s
the patch passed

+1 :green_heart:
javac
3m  0s
the patch passed

+1 :green_heart:
shadedjars
9m  9s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 38s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
425m 50s
root in the patch passed.

475m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8d50511c12e6 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-common hbase-client hbase-server . U: .

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

I've included the additional doc suggestions, thanks for the review y'all

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 32s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  2s
master passed

+1 :green_heart:
compile
9m 23s
master passed

+1 :green_heart:
checkstyle
2m 20s
master passed

+0 :ok:
refguide
3m 31s
branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
spotbugs
15m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 53s
the patch passed

+1 :green_heart:
compile
8m 54s
the patch passed

+1 :green_heart:
javac
8m 54s
the patch passed

+1 :green_heart:
checkstyle
1m 56s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+0 :ok:
refguide
3m 25s
patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.

+1 :green_heart:
hadoopcheck
19m 14s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
14m 43s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 56s
The patch does not generate ASF License warnings.

97m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile refguide

uname
Linux ab9684e32957 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 04635f405a

Default Java
AdoptOpenJDK-1.8.0_282-b08

refguide
https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/3/yetus-general-check/output/branch-site/book.html

refguide
https://nightlies.apache.org/hbase/HBase/HBase-PreCommit-GitHub-PR/PR-3852/3/yetus-general-check/output/patch-site/book.html

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

modules
C: hbase-common hbase-client hbase-server . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 32s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  6s
master passed

+1 :green_heart:
compile
3m 31s
master passed

+1 :green_heart:
shadedjars
9m  7s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
5m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m  2s
the patch passed

+1 :green_heart:
compile
3m 36s
the patch passed

+1 :green_heart:
javac
3m 36s
the patch passed

+1 :green_heart:
shadedjars
9m  4s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
213m 21s
root in the patch passed.

264m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 08b0618e844b 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 04635f405a

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/testReport/

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

modules
C: hbase-common hbase-client hbase-server . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  5s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 19s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 17s
master passed

+1 :green_heart:
compile
3m 33s
master passed

+1 :green_heart:
shadedjars
10m 27s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 33s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m  1s
the patch passed

+1 :green_heart:
compile
3m 31s
the patch passed

+1 :green_heart:
javac
3m 31s
the patch passed

+1 :green_heart:
shadedjars
10m 29s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
4m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
505m  5s
root in the patch passed.

556m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 39cbe1f7cbd2 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 04635f405a

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/testReport/

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

modules
C: hbase-common hbase-client hbase-server . U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3852/3/console

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

Thanks @joswiatek. Left one comment on #3857 for branch-1 backport. Once done, will merge both PRs.


[Feature] Move the "change event date range" upstream

Is there an existing feature request for this?

[X] I have searched the existing issues

Describe the Feature
Currently, "change event date range" does not apply to the staging models. Because of this, dbt build takes a very long time to complete. On my Amplitude Dataset, there are ~65M events since 2019, and it takes ~15 minutes to run the amplitude models. Most of this time is spent generating the staging models.
Describe alternatives you've considered
I created a temporary clone of the raw event table and pointed the package towards it, and that drastically reduced the amount of time it tool to build the models. However, I cannot do this programmatically with dbt, as we keep our raw tables in a separate snowflake database that the dbt role cannot write tables to.
Are you interested in contributing this feature?

[ ] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
[X] No.

Anything else?
No response

Hi @jon-openspace thanks so much for opening this feature request!
I think this is a completely reasonable request and would greatly improve the performance of the package and downstream transformations. This would result in a bit different behavior for our staging models from our other packages (we typically try not to filter out data in the staging models); however, this package should be an exception since the event data can grow in volume and manage to be unusable with the run time if we don't filter out in the staging model.
I will accept this Feature and plan to provide an update once our team starts working on this. Thanks again!

Feature added in the latest release
https://github.com/fivetran/dbt_amplitude_source


max_seq_length and per_device_train_batch_size

Hi,
I wonder what max_seq_length and per_device_train_batch_size for huggyllama/llama-7b you are using in all experiments?
I'm trying to use max_seq_length=2048 and per_device_batch_size=2 on 4xA100 80GB gpus with deepspeed as you provided in [finetune_with_accelerate.sh](https://github.com/allenai/open-instruct/blob/main/scripts/finetune_with_accelerate.sh).
I constantly meet CUDA OOM error.
Seeking your help.

The script provided  in finetune_with_accelerate.sh is what we used for training the 7B model. Did you also set --use_flash_attn?


Short solution needed: "How to map values in data frame using mapping function" (python-pandas)

Please help us write most modern and shortest code solution for this issue:
How to map values in data frame using mapping function (technology: python-pandas)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

How to map values in data frame using mapping function


Add support for HTTP/2 Prior Knowledge to the server implementation

Problem
Right now we support HTTP/2 only as a negotiated protocol via ALPN. This is unfortunate as HTTP/2 is just as good cleartext as it is over TLS.
Solution
Add HTTP/2 prior knowledge detection to the cleartext pathway for the server. This is done by looking for the magic preface which is not valid as a HTTP/1.x message preface and initialize the pipeline accordingly.

Sadly, it looks like there isn't a way to use the Jdk HttpClient to test H2-prior-knowledge. 😞

@hamnis, what are your thoughts on testing this? The existing tests show that the cleartext -> http/1.x pathway work. There just isn't a way to test the prior-knowledge pathway since we don't appear to have a capable client on hand.

@hamnis, if you're happy with this it should be good to merge. Thanks for taking a look!


Submit 0.24 version of Intel Device Plugins Operator to https://operatorhub.io/

Depends: #835
Change capabilities to seamless upgrade.

@hj-johannes-lee I added a note here to say that the operator capabilities need changing

https://github.com/k8s-operatorhub/community-operators/pull/1264
https://github.com/k8s-operatorhub/community-operators/pull/1280
https://operatorhub.io/operator/intel-device-plugins-operator/alpha/intel-device-plugins-operator.v0.24.0


Add support for HDP <IP_ADDRESS>

HDP <IP_ADDRESS> has been released. Make this release the new default profile.

0.1.9 has been released with HDP <IP_ADDRESS> support.


Architecture for external dependencies

Apologies for the lengthiness, there's a fair bit to compress:
I am working for a digital bank and we use this library, the only caveat is that AES256GCM isn't supported.
We've had our upstream vendor give us a hand and it looks like we would be able to expand this library to supported it...
Now ideally I'd like to contribute this back upstream and not keep it in a silo.
Here comes the gotcha: CryptoKit is only supported on iOS >= 13.0, and many companies/people still support 12 or even 11 due to the number of devices still out there such as iPhone 6 etc.
Long story short, this functionality - even if optional would require https://github.com/krzyzanowskim/CryptoSwift.
Now the tricky bit:

Currently there are no external dependencies for the library building itself.
JOSESwift is supporting both Carthage and CocoaPods. (So does CryptoSwift)

Here's my thinking....
We don't want to force anything upon a user but if they want AES256GCM we'd need to add this library, the library would be needed.
I know for a fact cocoa pods wouldn't require the project files as it constructs a new one based on the pod spec.
I am less familiar with Carthage but believe that it will use the existing xcproject file, and so the current project.
Here are the two viable options as far as I can see it:

As a direct dependency:
CryptoSwift module is added as a dependency for this JOSESwift via pod and Carthage respectively. Now if someone was to open up the project itself and build it from Xcode it would need a (1) pod or (2) cartfile to install the module, or swift package manager. My only holdout here is that the project needs to utilise one of the 3 package managers if someone directly opens the project (pod of course won't care since it creates a new one from scratch every time based on the spec).

As an injectable dependency
This would be more work for the client perhaps, but would alleviate changing dependencies.
I imagine this JoseSwift exposes a protocol for what it needs to be like GenericEncrypterStrategy

In order to actually use AES256GCM, we'd need to fulfil the dependency:
There is both JWEHeader and Encrypter, which we'd either:
a) Inject the encryption provider per instance (in the constructor most likely)
b) Inject it into the module via some static property (JoseSwift.provider = Foo.Bar or something)
While one needs to be careful with static stuff, at a module/library level is possibly  ok (option b). The first option (a) would lead to longer initialisation etc.
It would also be possible to implement a default provider of CryptoKit allowing iOS >= 13.0 to not do any work.
Do not have this as of yet, but it would merely conform to the expected protocol for a GenericEncrypterStrategy .
Eager to hear the thoughts of people who maintain this @daniel-mohemian et. al.

Hey @mitchins!
Thanks for your well thought out suggestion. We really appreciate that you are willing to put work into contributing your changes back upstream for everyone to use.
When we open sourced JOSESwift we decided that we would only trust cryptographic libraries that come straight from Apple (Security.framework, CommonCrypto, CryptoKit). That's why we haven't added any features that would require us to include third party cryptographic implementations like CryptoSwift. We'd like to keep it this way. Therefore, adding CryptoSwift as a direct dependency to JOSESwift is not an option for us at this time.
Option 2, as suggested by you, would be our preferred way to tackle this. Since the beginning, we have considered to support injectable, replaceable cryptographic implementations to work around the fact that Apple doesn't support all algorithms that the RFCs define. Unfortunately, we never got around to implement this but it should definitely be possible to do this.
I'm thinking of something like an optional parameter in the Encrypter's/Decrypter's encrypt/decrypt functions. We already have ContentEncryper/ContentDecrypter protocols for which we instantiate  concrete implementations based on the specified algorithm in the above mentioned encrypt/decrypt functions (e.g. here). Assuming we allow the user to specify their own implementation of this protocol we could use that implementation instead of instantiating the default one.
A good way of solving this would probably be to first add native A*GCM support using CryptoKit for iOS13+ and then in a second pull request allow the user to optionally overwrite this default implementation by specifying their own content encryption implementations.
Let me know what you think!

Hey @mitchins!
Thanks for your well thought out suggestion. We really appreciate that you are willing to put work into contributing your changes back upstream for everyone to use.
When we open sourced JOSESwift we decided that we would only trust cryptographic libraries that come straight from Apple (Security.framework, CommonCrypto, CryptoKit). That's why we haven't added any features that would require us to include third party cryptographic implementations like CryptoSwift. We'd like to keep it this way. Therefore, adding CryptoSwift as a direct dependency to JOSESwift is not an option for us at this time.
Option 2, as suggested by you, would be our preferred way to tackle this. Since the beginning, we have considered to support injectable, replaceable cryptographic implementations to work around the fact that Apple doesn't support all algorithms that the RFCs define. Unfortunately, we never got around to implement this but it should definitely be possible to do this.
I'm thinking of something like an optional parameter in the Encrypter's/Decrypter's encrypt/decrypt functions. We already have ContentEncryper/ContentDecrypter protocols for which we instantiate  concrete implementations based on the specified algorithm in the above mentioned encrypt/decrypt functions (e.g. here). Assuming we allow the user to specify their own implementation of this protocol we could use that implementation instead of instantiating the default one.
A good way of solving this would probably be to first add native A*GCM support using CryptoKit for iOS13+ and then in a second pull request allow the user to optionally overwrite this default implementation by specifying their own content encryption implementations.
Let me know what you think!

Now that we have https://github.com/apple/swift-crypto would that be acceptable as a library coming straight from Apple?

Good point. It's an Apple maintained project so yeah I think we could get behind that.

I would love to see support for A256GCM since I need that for one of our projects. Thanks to @mitchins, I was able to get a prototype working and it seems to be fairly easy with CryptoKit. However, this would require this project to bump its minimum targets (iOS from 10 to 13 and watchOS from 4 to 6). Would that be acceptable?

We managed to get this going with the standard crypto libraries…
I’ll try and dig it out
Sent from my iPhone

On 11 Aug 2022, at 22:17, Tobias Hagemann @.***> wrote:

I would love to see support for A256GCM since I need that for one of our projects. Thanks to @mitchins, I was able to get a prototype working and it seems to be fairly easy with CryptoKit. However, this would require this project to bump its minimum targets (iOS from 10 to 13 and watchOS from 4 to 6). Would that be acceptable?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

That would be great! But sounds like using private API of CommonCrypto, is that right? https://stackoverflow.com/a/36634956

@tobihagemann we used the CryptoSwift library.
Actually I can't take the credit it was done by our partners in order to use their APIs.
This was done back on 2.3.1
https://github.com/mitchins/JOSESwift/tree/release/2.3.1
Differences between 2.3.1 and changes we made:
https://github.com/mitchins/JOSESwift/pull/1/files
It might be problematic to merge back.
We are expecting to ditch iOS 12.x support soon and focus on 13+, so that means the CryptoKit would be fine...
For anyone else requiring iOS 12 support, the above fork of 2.3.1 should work fine.

Ah, I understand. I wouldn't consider CryptoSwift "standard" though (as have been mentioned here) but I appreciate you sharing your code. It will help me a lot and I'll try to open a new PR that uses CryptoKit. I leave it to JOSESwift's maintainers if they're willing to increase the minimum targets.

@mitchins I see you implemented A256GCM in your fork. I need A128GCM though, and I am no crypto expert.
Is it just a matter of performing a few changes on your code, or do I need to completely rewrite your code?
Any help will be much appreciated.
Thank you!

Version 3.0.0 now includes native AESGCM support for content encryption via Apple's CryptoKit.
Moreover it adds support for plugging in custom crypto implementations. JOSESwift still ships with platform native crypto implementations only. But you can now create your own signers/verifiers and encrypters/decypters using whatever crypto implementation you want.
We still need to write up some documentation for that. In the meantime, have a look here for details: https://github.com/airsidemobile/JOSESwift/pull/343.
Let me know if there's questions or concerns.


New HA

https://github.com/rancher/cattle/pull/2253

https://github.com/rancher/rancher/issues/6685


Android Basics: xml-layouts

URL of codelab
In which task and step of the codelab can this issue be found?
Describe the problem
Steps to reproduce?

Go to...
Click on...
See error...

Versions
Android Studio version:
API version of the emulator:
Additional information
Include screenshots if they would be useful in clarifying the problem.

Emulator not perform well hang also


Hovering on using enum ... gives out hex value instead of enumeration name.

In the following code:
enum class Foo {Bar, Baz};

void test() {
  using enum Foo;
  Bar;
}

hovering over Bar; (line 5) gives the following tip:

Note the hex value (pointer address?) instead of enum name.
Originally posted by @i-ky in https://github.com/clangd/clangd/issues/1281#issuecomment-1240760281

I debugged a bit and it looks like the reason for this is that explicitReferenceTargets (Hover.cpp:1058) in this case returns two NamedDecls, where the first is a UsingEnumDecl and the second is a EnumConstantDecl.
Hover then assumes the first element of the returned vector is always the one we need, even though we'd want the EnumConstantDecl in this case.
This btw also happens for other using declarations:
namespace ns { void foo(); }
void bar() {
    using ns::foo;
    foo(); // <- Hover refers to the using declaration instead of the function declaration
}

One solution would be to check if the first element is a BaseUsingDecl and if so use the second item of explicitReferenceTargets instead of the first one. With this, the regression test I added passes and all other Hover tests as well.
Or maybe explicitReferenceTargets itself should be fixed?
@sam-mccall @HighCommander4 what do you guys think?

Proposed fix: https://reviews.llvm.org/D133664


Show subtasks in task details view.

Add a subtasks section to the details view which lists all subtasks in chronological order. Use the PARENT_ID column to find subtasks of a specific parent task.


Enhance User Job Application form UI

Title: Enhancement Proposal: Update User Job Application Form UI
Description
The current UI of the Job Application Form page could benefit from an update to improve usability, visual appeal, and accessibility. This enhancement proposal aims to address these aspects by suggesting updates to the form layout, styling, and interaction elements.
Expected Outcome
A more intuitive and visually appealing form that enhances the application experience for users across all devices and ensures accessibility compliance.

@Devmangrani I plan to maintain the consistency of the website but improve the form field to have a more professional outlook. The design above is not the final one - it is just an inspiration. I would work on it for that clean and professional look.
Please assign this to me. Thank you

Thank you for this thoughtful enhancement proposal, @AfubeAngel
Your approach to refining the Job Application Form UI sounds great. Go ahead with the updates, and thank you for focusing on a professional, consistent look for the site.
Looking forward to seeing your contributions!


Referring dynamic IP ranges allocated by IPAM to VPCs in the route tables

Describe the bug
We are using IPAM to allocate IP ranges to VPC. While defining Transit Gateway Route tables, I need to provide the Workload accounts's IP address range as "destinationCidrBlock" which is not readily known because it is dynamically allocated by IPAM.
We can use known IP Address Ranges directly in route tables, but I can't seem to find a way in the documentation to refer dynamic IP ranges allocated by IPAM to VPCs in the route tables be it Transit Gateway or any other route tables.
To Reproduce
Define a Route table and try to add a destinationCidrBlock which is dynamically allocated by IPAM.
Expected behavior
Should be able to refer the IP Address range dynamically allocated by IPAM in route tables.
Please complete the following information about the solution:

[ ] Version: v1.6.2
[ ] Region: ap-southeast-2
[ ] Was the solution modified from the version published on this repository? N
[ ] If the answer to the previous question was yes, are the changes available on GitHub? N/A
[ ] Have you checked your service quotas for the services this solution uses?
[ ] Were there any errors in the CloudWatch Logs?

Screenshots
N/A
Additional context
N/A

Hi @vforvarun , thanks for reaching out to the Landing Zone Accelerator team.
The functionality you are describing is not currently supported in the LZA, though you should be able to solve this problem using native Transit Gateway functionality.
When creating the attachment between the VPC and TGW, you can utilize route propagation to automatically add the CIDR of the VPC as a new route to Transit Gateway route table(s).
This can be accomplished in the LZA config one of two ways:

Set defaultRouteTablePropagation to enable - this will automatically create propagated routes for new VPC attachments created on the Transit Gateway.
Specify specific route tables to propagate the route to on the transitGatewayAttachment configuration property of the VPC.


[WIP] Various fixes in getting started guide and docstrings [skip ci]

Signed-off-by: Sergey Khoroshavin<EMAIL_ADDRESS>

Concerning commit https://github.com/hyperledger/indy-sdk/pull/556/commits/7c9f5b870050032630a4e1e1f4cd79af56b9f5d6: after looking through the rest of notebook I'm not sure if this change is valid - it might just be better to rename few _verkey variables to _keys. The main reason for this change is that I felt it misleading to have the very same data (although from different sources) in variables those naming is quite different semantically. Feedback is very welcome.
Also it might be better to refactor onboarding function into different parts to separate actors better, but this is out of scope of this PR, I'm going to open an issue to discuss this.


I460 comments admin

Fixes #460

Found it.
It's because I made them all comments to commentable: valid_mp3 (Asset)
I'll create a new asset so that we don't pollute the pool.

These Percy conflicts were actually legit (due to new asset and its comments)
So I approved them.
Ready for your blessing and merge.

Updated fixture for comment (I confused user vs commenter and gave user incorrect asset). Should be good to go now @sudara

Approved the changes in Percy (new asset that I added to .yml file is apparently hot on the charts of alonetone :) so it pushed the other records down.

I think Percy is complaining because I approved a change in https://github.com/sudara/alonetone/pull/538 😭 Can't win with him :/

Renamed the title to be clear about primary purpose of the branch.


Feature requests

A few things that came to mind when using this:

Possibility to increase font size. I know that increasing my terminal font size would do the trick, but I'd like to keep my terminal configuration intact, but would like to increase just the speed reader text font size a bit to make it easier on the eyes.
Possibility to configure how many words to show. I find it a bit difficult to keep up with the context, when only one word is showing, and found out a few other speed readers where one could set the amount of words to show at the same time. Three words seemed like a good amount at least for me.

Thanks for your time on the project! Keep up the good work.

Possibility to configure how many words to show.

This is a tricky issue to solve properly, i.e. at a level beyond merely counting how many space tokens to allow before computing midpoint and updating the display. Consider the fact that texts can often contain acronyms that have a far higher information density than the three words "I did not", despite having far fewer letters.


Methods without setting the proper ClimateEntityFeature

Logger: homeassistant.components.climate
Source: components/climate/init.py:354
Integration: Климат (documentation, issues)
First occurred: 16:27:06 (1 occurrences)
Last logged: 16:27:06
Entity None (<class 'custom_components.yandex_station.climate.YandexClimate'>) implements HVACMode(s): heat, off and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at https://github.com/AlexxIT/YandexStation/issues

https://github.com/AlexxIT/YandexStation/releases/tag/v3.14.0


RightAlt-letter on Czech keyboard doesn't work

Your Windows build number:  (Type ver at a Windows Command Prompt)
10.0.18362.113

What you're doing and what's happening: (Copy & paste specific commands and their output, or include screenshots)
I am using the Czech keyboard. We write some characters like | by pressing RightAlt-W. There are more characters like that, all are accessible using Right Alt.

What's wrong / what should be happening instead:
When I press the shortcut, no character is written in the output.

Duplicate of #521


CORA dashboard - Cannot create duplicate export name

Hello Team,
When following the three steps mentioned in the below documentation to deploy CORA dashboard:
https://catalog.workshops.aws/awscid/en-US/data-exports#deployment
Step 1 is successful but in step 2 the stack (CID-DataExports-Source) failed to deploy in the management account with error, “Received response status [FAILED] from custom resource. Message returned: An error occurred (ValidationException) when calling the CreateExport operation: Cannot create duplicate export name.”
What can I do or where do I go to, to confirm if I have an existing data export with the same name? If it does exist, do I delete this and then retry the deployment?

Data exports stack can be just one. You can have multiple data exports there.
If you have a usecase for multiple stacks please let me know.

If you already have CID-DataExports-Source you can just enable COH report there by updating the stack

Closing. Please comment if still an issue.