Ball Device takes a long time to eject

This has happened several times, but is intermittent. I have a full Event Manager log. I can try to get a full Ball Device log, but since I can't count on this happening hopefully this enough.
Basically, from the time the switch for ball device bd_top_right_vuk is active (switch s_toprightvuk), nearly 9 seconds passed before it ejected. It took so long this time I almost killed MPF and restarted.
Not calling this a bug yet. Could be my config, but it seems strange because it's erratic. Hopefully this log indicates some sort of race or something.
Log: Archive 5.zip
ball_device config:
bd_top_right_vuk:
    ball_switches: s_TopRightVUK
    entrance_count_delay: 500ms
    eject_coil: c_TopRightVUK
    eject_targets: playfield
    exit_count_delay: 500ms
    confirm_eject_type: target
    console_log: Full

Maybe there is a full ball_device log for this? I'm not 100% sure I know how logging works now.
The Money Bags mode was running, so here's the config for that, too, just in case:
#config_version=4

mode:
  priority: 500
  start_events: start_money_bags_mode
  stop_events: money_bags_done

#todo
# intro dots
# mode timer
# money bag animation
# stage video?

event_player:
  mode_money_bags_started:
    mode_running|5s
    fade_out_base_music
#  logicblock_stop_adding_time_complete:
  logicblock_money_bags_counter_complete:  # brian added
    money_bags_done|5s
    money_bags_fade_out|3s
    money_bags_success|4s   # is there a fail mode todo
  timer_money_bags_timer_complete:
    money_bags_fail
    money_bags_done|1
  mode_money_bags_stopping:
    fade_in_base_music
  ball_will_end:
    money_bags_fail

ball_locks:
  money_bags_intro_lock:
    balls_to_lock: 1
    lock_devices: bd_lower_vuk
    enable_events: mode_money_bags_started|1
    request_new_balls_to_pf: False
    release_one_events: timer_mb_intro_timer_complete #probably switch this to an event fired by a show. Then delete timer
    disable_events: timer_mb_intro_timer_complete|1

#event_player:
#    mode_money_bags_started:
#        start_money_bags_timer
#    timer_money_bags_timer_complete:
#        money_bags_finished|2s

shots:
    left_kicking_target:
        switch: s_bottomkickingtarget
        show_tokens:
            led: l_left_longhorn
#            color: ffcc00
        advance_events: mode_money_bags_started
        disable_events: timer_money_bags_timer_complete
        ##debug: true
    spinner_to_vuk:
        switch_sequence: s_spinner, s_toprightvuk
        show_tokens:
            led: l_center_longhorn
        disable_events: timer_money_bags_timer_complete
#            color: ffcc00
        ##debug: true

shot_groups:
    money_bags:
        shots: left_kicking_target, spinner_to_vuk
        profile: advertise
#        enable_events: mode_money_bags_started
        disable_events: timer_money_bags_timer_complete
        rotate_events: money_bags_advertise_flashing_hit
        #debug: true

timers:
    mb_intro_timer:
        start_value: 3
        end_value: 0
        direction: down
        control_events:
            - action: start
              event: mode_money_bags_started
    money_bags_timer:
        start_value: 15
        end_value: 0
        direction: down
        max_value: 10
        tick_interval: 1.25s
        #restart_on_complete: true #not sure if this means go back to 10 and keep counting, or just reset to initial state
        control_events:
            - action: start
              event: timer_mb_intro_timer_complete
            - action: reset
              event: money_bags_advertise_flashing_hit
            - action: stop
              event: logicblock_money_bags_counter_complete

logic_blocks:
    counters:
        money_bags_counter:
            enable_events: mode_money_bags_started
            disable_events: mode_money_bags_ended
            count_events: money_bags_advertise_flashing_hit
            persist_state: true
            player_variable: money_bags_hit
            count_complete_value: 9
            starting_count: 0
            direction: up

# NEED A SHOW for start, complete, and ended before it's done. Mode can end at
# completion of show.

# This is where we set up the slides that play the different dots and stage slides during the mode.

slide_player:
  mode_money_bags_starting:
    mb_intro_dmd:
      target: dmd
    money_bags_stage:
      target: stage
  mode_running:
    money_bags_dmd:
      target: dmd
  logicblock_money_bags_counter_complete:
    money_bags_complete:
      target: dmd

# And here are the slides referenced above

slides:
  mb_intro_dmd:
    widgets:
      - type: text
        text: Shooting lit shots
        anchor_y: top
        style: dmd_small
        y: top-1
        anchor_x: right
        x: right-1
      - type: text
        text: collects and increases
        style: dmd_small
        anchor_y: bottom
        y: center
        anchor_x: right
        x: right-1
      - type: text
        text: Money Bags Value
        style: dmd_big
        anchor_y: bottom
        y: bottom+1
        anchor_x: right
        x: right-1
      - type: rectangle
        color: 000000
        height: 32
        width: 128
        opacity: .8
      - type: video
        video: mb_dmd_loop_2
        end_behavior: loop
        anchor_x: left
        x: left
    target: dmd
  money_bags_stage:
    widgets:
      - type: video
        video: mb_beer_thirty
        end_behavior: loop
        animations:
          money_bags_fade_out:
            - property: volume
              value: 0
              duration: 2s
  money_bags_dmd:
    widgets:
      - type: text
        text: Time left (money_bags_money_bags_timer_tick)
        anchor_y: bottom
        style: dmd_small
        y: bottom+1
        anchor_x: right
        x: right-1
      - type: text
        text: (score)
        number_grouping: true
        min_digits: 2
        anchor_x: right
        x: right-1
        y: middle
        style: tall title
      - type: text
        text: Each hit = 1,000,000 #todo this needs to show whatever the actual score is that we calculate as the mode progresses
        anchor_y: top
        style: dmd_small
        y: top-1
        anchor_x: right
        x: right-1
      - type: rectangle
        color: 000000
        height: 32
        width: 128
        opacity: .8
      - type: video
        video: mb_dmd_loop_2
        end_behavior: loop
        anchor_x: left
        x: left
  money_bags_complete:
    widgets:
      - type: text
        text: Money Bags
        anchor_y: top
        style: dmd_med
        y: top-4
        anchor_x: right
        x: right-9
      - type: text
        text: Complete!
        number_grouping: true
        min_digits: 2
        anchor_x: right
        x: right-6
        anchor_y: bottom
        y: bottom+1
        style: tall title
      - type: video
        video: mb_dmd_loop_2
        end_behavior: loop
        anchor_x: left
        x: left

scoring:
    money_bags_advertise_flashing_hit:
        score: 1000000

shot_profiles:
    advertise:
      states:
        - name: flashing
#          show: flash_color
          show: flash
        - name: unlit
          show: off
      loop: yes
      advance_on_hit: false

9s is within the default 10s eject timeout of your VuK. Was there a previous ball or a failed eject? I suppose you lower eject timeouts to 2-3s.

Oh wow, the default is 10s. That is way too long for this purpose. Thanks...just wanted to make sure it wasn't a strange ball device behavior.


Cache::many returns incorrect defaults

Laravel Version: 5.4.19
PHP Version: 7.0.15
Database Driver & Version: phpredis

Description:
Default values are only applied to null keys, not non-existing keys
Steps To Reproduce:
Cache::put('keyThatIsNull', null, 1);
dd(Cache::many([
    'keyThatIsNull' => 'You will see this string',
    'keyThatDoesNotExist' => 'But this default value does not work, you\'ll get false instead',
]));

output:
array:2 [
  "keyThatIsNull" => "You will see this string"
  "keyThatDoesNotExist" => false
]

Where did you get this? many() accepts an array of keys with no default values.

since it wasn't in the docs for cache, I had to look through the source. Check out line 124:
https://github.com/illuminate/cache/blob/master/Repository.php

I see now, but I can't replicate your issue:
\Cache::put('keyThatIsNull', null, 1);

    dd(\Cache::many([
        'keyThatIsNull' => 'You will see this string',
        'keyThatDoesNotExist' => 'But this default value does not work, you\'ll get false instead',
    ]));

The results is:
``
array:2 [▼
"keyThatIsNull" => "You will see this string"
"keyThatDoesNotExist" => "But this default value does not work, you'll get false instead"
]

Are you using phpredis?

Ok I've opened a PR with a fix: https://github.com/laravel/framework/pull/18984
Thanks :)

Thanks!


2241: Remove price-specific values from range-filter template

1. Why is this change necessary?
The current version of @Storefront/storefront/component/listing/filter/filter-range.html.twig uses several values specific to price-ranges. Most seriously, the name attribute of the input fields are hardwired to min-price and max-price (leading to several fields with the same name if more than one range filter is present).
In addition, the template uses a currencySymbol variable, which only makes sense for prices, a more generic variable name like unit is more appropriate. And the template uses a price variable to set the maximum allowed value for the input field to price.max - again, a more generic name is more appropriate.
2. What does this change do, exactly?

Modifies @Storefront/storefront/component/listing/filter/filter-range.html.twig to:

use the existing minKey and maxKey variables in the name property of the input fields instead of hardwired price values.
renames the currencySymbol variable to unit (which defaults to currencySymbol for backward compatibility)
Introduces two new variables minInputValue and maxInputValue (defaulting to 0 and price.max for backward compatibility)
Deprecate blocks component_filter_range_min_currency_symbol and component_filter_range_max_currency_symbol in favor of the new blocks component_filter_range_min_unit and component_filter_range_max_unit.
Rename css class filter-range-currency-symbol to filter-range-unit (also adjusted in corresponding .scss file)

Adjusts @Storefront/storefront/component/lists/filter-panel.html.twig to new interface (= adding minInputValue and maxInputValue, removing price-value).
Made range-filter-specific snippets more generic:

listing.filterRangeActiveMinLabel and listing.filterRangeActiveMaxLabel now insert displayName instead of being hardwired to Price.
listing.listing.filterRangeErrorMessage now speaks of "minimum value" and "maximum value" instead of "minimum price" and "maximum price".

As mentioned above, I have added deprecations for the renamed blocks, but without the correct version tags (as I don't know those yet). Also, the variables currencySymbol and price should probably be deprecated, as well, but I don't know how to do that (the docs don't say).
3. Describe each step to reproduce the issue or behaviour.
Create a template with the following code:
{% sw_include<EMAIL_ADDRESS>with {
    name: 'test',
    minKey: 'min-test',
    maxKey: 'max-test',
    displayName: 'Test',
} %}

The output of this template will use min-price and max-price as the name attribute instead of min-test and max-test.
4. Please link to the relevant issues (if any).
#2241
5. Checklist

[ ] I have written tests and verified that they fail without my change
[X] I have squashed any insignificant commits
[X] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

the deprecation tag always contains the next major version, which is currently 6.5.0 😉

Thanks for the info, @mitelg! Fixed the deprecation tags.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 9 committers have signed the CLA.:white_check_mark: svlauer:x: Dominik28111:x: leichteckig:x: SimonVorgers:x: Haberkamp:x: thuylt:x: King-of-Babylon:x: yusuftuer:x: keulinhoYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the review @msestendrup! I implemented the suggested changes, but there is one open issue (see comment above).
I've done this as a separate commit for now, will squash them once the PR is otherwise ready to be commited.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-19537
Please use this issue to track the state of your pull request.

Note: I also changed the use of ?? in filter-range.plugin.js to a != null ternary because webpack / babel (in the current shopware config) cannot handle the ?? operator.

Thanks for your contribution! We've merged your changes. :tada: :blue_heart:


Building OpenBLAS with desired lapack implementation

Hi,
I wondering if I can build OpenBLAS with another lapack implementation.
Is there an option in the Makefile for that. I saw OpenBLAS package for fedora doing something like that but by tweaking the Makefile.
Thanks in advance,
notoriou1pig

You can build just the BLAS and CBLAS parts of OpenBLAS and let your desired lapack implementation use it. For eg: reference lapack implementation can use any BLAS library.

This would be NO_LAPACK=1 and/or ONLY_CBLAS=1 (see Makefile.rule, the apparent redundancy in the options probably comes from the early GotoBLAS days)

Just out of curiosity, which LAPACK implementation do you have in mind ?

Hi isuruf and martin-frbg,
thanks for the quick replies.
Do you think the best choice is to build OpenBLAS with no LAPACK support and then build LAPACK with the desired BLAS implementation ?
Then, should I add libblas.so and libcblas.so manually ?
$ ln -s libopenblas.so libblas.so
$ ln -s libopenblas.so libcblas.so

For your information, I am working on the buildroot project (https://buildroot.org/).
The user is free to choose between LAPACK and CLAPACK implementation. I wish I can also add BLAS implementation like OpenBLAS. I will add ATLAS also if I can.
Regars,
notoriou1pig

Sounds vaguely similar to what the Debian folks do with their "alternatives" concept, perhaps you can  borrow some tricks from their patches to the stock OpenBLAS Makefiles ?


Handle forbidden status from Async call

When an update to a pod, service or job fails with 403 (forbidden), abort and record the result in the domain status

Passed Jenkins http://wls-jenkins.us.oracle.com/job/weblogic-kubernetes-operator-javatest/3381/


Implementation of Hash Tables with Linear Probing

Description 📜
In this documentation , I have explained  how to implement hash tables with Linear Probing  and  some operations like

Insertion an element in hash table
Searching an element in hash table
Deletion of an element in hash table
Fixes #4846

I also want this PR to be a part of hacktoberfest , so pls add hacktoberfest lable to it.

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] C/CPP

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

@kashishahuja2002 kindly review this !

@Suvraneel I have made the changes.


{Misc} Remove various Python 2.7 ImportError

Description
Taken from #30368
Remove the various Python 2.7 import fallbacks. This was mostly limited to urllib.
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Thank you for your contribution! We will review the pull request and get back to you soon.

@atombrella, Thank you very much for the contribution!


Annotate imported bookmarks with special tags?

Maybe add tags like imported-from:pinboard and imported-from:raindrop?

May revisit, but basically did this as a part of https://github.com/lmorchard/pebbling-club/commit/57e767238a5a0714fb276bf08e6ac8f4fdb5ca47


[Story] Fix Create Account Route

As a developer, I need to adjust the CSS styling for the new user form so that the elements will fit within the root box.
Acceptance Criteria:

[x] Given a new user,  when the user intends to make a new account, then the elements needed to be filled out in the form need to fit within the root box
[x] Given a new user form, when the window is resized, the elements should shrink/grow accordingly down to a minimum size

Finished with commit 8412ce4513588b283166b48f772c59bd74eaa8b7


Update azmodule test for version

Pull Request
Description
Description of changes: Updated Az module tests to check for a specific version of at least 10.0.0.
License
By submitting this pull request, I confirm that my contribution is made under the terms of the projects associated license.

@jtracey93 I updated the test to require at least 10.0.0 for AZ module. Are you cool with that or do you want to make it lower?

@oZakari im cool with it if it supports all we need. 10.2.0 is out so a minimum of 10.0.0 is fine by me


Nodejs with express: API request failed after few mins

I have nodejs application with express middleware. Bellow is my code:
var express = require("express");
var app = express();
var bodyParser = require("body-parser");
var router = express.Router();
var cors = require('cors');
var fs = require('fs');
var https = require('https');
app.use(cors());
app.use(bodyParser.json({limit: '50mb'}));
app.use(bodyParser.urlencoded({ limit: '50mb', "extended": false }));
app.use(express.static(path.join(__dirname, './demo')));
router.get("/", function (req, res) {
res.json({ "error": false, "message": "Hello World" });
});
app.use('/api', router);
var privateKey = fs.readFileSync('key.pem');
var certificate = fs.readFileSync('cert.pem');
var passphrase = 'pass';
var credentials = {key: privateKey, cert: certificate, passphrase:passphrase};
var server = https.createServer(credentials, app).listen(config.port);
server.timeout = 3600000;

When calling API from the ionic application located in the directory "demo" it works fine. But after few mins (near about 10-15 mins), API request gets failed (failed from the application). But if we reload the application or hit the API from postman/browser then it was working. Means node service is still running. But then why API calls are failing. What will be the possible errors? Please help. Thanks!

Hi @avinash0 are you saying it only happens when you use that ionic application? If so, can you please provide it? Also, can you provide more specific information on what exactly "API request gets failed" means?

When calling API from the application, it works fine. But after 9-10 mins API gets failed. API failed means the status is failed in browsers network tab and returns nothing. As it is failed, the API get highlighted in red color.

Hi @avinash0 I'm not really sure. Can you provide the specific steps I need to perform to see the error with the code you provided?

@avinash0 may be it can be helpful if you can give out server logs, May be your server shuts down, or resource doesnt respond,
I unable to make much sense out of the code you have provided.

I'm going to close this as it has been a few months.


The software does not work if there are spaces in the path.

If you put the windows build in a folder with gaps in it, the software does not start. ( I haven't tested Linux )

Hi there!
Thanks for this, I'll investigate it in the next couple days and send out a fix. Sorry about that super annoying, do you happen to be able to give me some more details about where and what you're trying to run it on?
(i.e, windows version, specific file path, rssh version)

Any version of WIndows, I ran it on 2019 server, and I only run it on windows server.
Any path with a space, for example I did C:\ProgramData\Package Cache\revssh.exe

Alright interesting, have you tried running the program with the --foreground flag?
E.g
revssh.exe --foreground <your.rssh.server.here>

Haven't tried it.

Cool I can replicate this :)

Great, waiting for a correction)

Sweet as, its now on the unstable branch if you want to pull and test that directly. I've tested it myself, but just wanna make sure.

Yeah, everything seems to be fine. Thank you.

Can I ask you a question about garble here? I successfully install the version you gave me, specify the path, but still no link to garble

I'd prefer if you opened that as a new issue so folk can search it if they need. Plus give me some more details about your setup :)
E.g give me your PATH, how you installed garble etc

Okay, I'll do it later.


How to call functions with buttons?

I would like to call functions on click of a toast button, how do we do that? Currently, only URLs are working.

basically looking for a callback feature.

I dont know whether this is possible or not, but i found this article. Maybe we can implement it in python?

How about something like this?
https://stackoverflow.com/questions/62828043/how-to-perform-a-function-when-toast-notification-is-clicked-in-python

It won't works, winotify doesn't use Windows Api to create notification. Instead, it used Powershell to create notification.
winotify generate temporary PS Script -> Powershell execute it -> notification shown

God, I love your winotify so much. I threw away win10toast for your library which works as intended. It would be the perfect one for Windows 10 Toast notifications if you could do callback. The win10toast can handle callbacks if you're interested.

Thanks for all your excitement to winotify . I've been working hard to make this feature, now I have some workaround for this. Can you guys check out Dev branch? Any suggestion will be appreciated :)
see test/callback_example.py for further explanation :)

where is the dev branch ? how do i access it? test folder doesn't have this file callback_Example.py

you know how to use git & github right?
it's on https://github.com/versa-syahptr/winotify/tree/dev
clone it to your machine

I don't ... is that a challenge ?

no, I'm just asking,
maybe anyone else can do it?

Don't worry, I got the access now... I'll test it as well

Unfortunately, I don't use Git too... Maybe you can upload it to PyPI to a beta version or something so we can test it out

ok then, try this pip install winotify==1.1.0.dev0

You could make another file with the function you wanted to do. you could put it like this as the action r'C:/Users/{username}/Desktop/projects/function.py'

You can call the function with add_activated(). Also, activationType must be protocol or system. arguments can be snooze , dismiss,  file: or http:
https://github.com/GitHub30/win11toast/blob/75daeadca9248bf514b40ee789cea4324580c97d/win11toast.py#L163
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-action


Make vault client submit proof using 'confirm' messages and add fallback to other archive nodes on error

Once we changed the stellar-relay pallet to also consider 'Confim' SCP messages as part of a proof in #360, we need to add some changes to the vault client so that he is able to build such a proof using the entries from a Stellar archive.
We should:

[ ] Change the logic about building a proof from an archived entry such that the vault client uses all 'externalized' and 'confirm' statements that are available in that archive entry. Note that a valid proof always has to contain at least 1 externalized message, if that's not the case we should fall back to a different archive node.
[ ] Add some error handling that makes the vault client fall back to a different Stellar archive node in case the execute... extrinsic fails with a selection of error messages. Basically, all errors thrown particularly by the stellar-relay pallet can be considered worth a retry because we should always be able to build a proper proof using an archive entry. An error thrown by the stellar-relay would indicate that the entry is faulty and we should try again with the entry of another archive node.

Hey team! Please add your planning poker estimate with Zenhub @TorstenStueber @b-yap


Workaround for misused cuda dependent attributes

the cuda_dependent_attributes_ member was misused as storage in
__getstate__ which results in errors after re-pickling the unpickled
model since __getstate__ expects strings in
cuda_dependent_attributes_.

Sorry I don't quite get it. In what way is cuda_dependent_attributes_ being misused as a storage?

Sorry I don't quite get it. In what way is cuda_dependent_attributes_ being misused as a storage?

It was, before PR #431, see https://github.com/dnouri/skorch/pull/431/files#diff-5d1f8e13ab8b822b72e9b295cf7301c5L1412. The result of torch.save was stored in state['cuda_dependent_attributes_'].

Okay, I misread that.
Is it possible to make a unit test that triggers the bug this PR fixes?

OK I left this issue open for too long so I had to roll this up from the beginning to reproduce it.
Essentially, there are two bugs here that either prevent loading old pickle files or re-pickling them with 0.5.1:

loading old pickle with 0.5.1, then pickling it again breaks since self.cuda_dependent_attributes_ is mangled by pre-0.5.1 pickling. This is hard to unit test and a temporary issue, so I'll attach a script to reproduce this issue but won't add a unit test
there is a broken check in __setstate_050__ which might fail when the module of the pickled net is not initialized

I'm currently working on the script to reproduce (1) and a fix for (2).

It might be a good idea to test for issue (2) though. I'll see if I can write up a test tomorrow.

@BenjaminBossan Please review again.

Nice, thanks for making the effort to reproduce the error with a test. LGTM


Storybook: all cards with deep links are broken

There seems to be a bug on the site that displays all of the Backstage Storybook examples where anything with a deep link displays:

Something went wrong here. Please contact #backstage for help.

Expected Behavior

Card examples that use links ("deepLink") display properly in the Backstage Storybook examples.
Current Behavior

It seems multiple card types that include links all are broken in the Storybook display:
https://backstage.io/storybook/?path=/story/data-display-progress-card--link-in-footer

Possible Solution

Not sure.  When I reproduce cards, for example an InfoCard with a deep link locally in a sample new plugin I'm testing, it works fine!
Steps to Reproduce

Visit the following pages which seem for me to all display broken:

https://backstage.io/storybook/?path=/story/layout-information-card--link-in-footer
https://backstage.io/storybook/?path=/story/layout-tabbed-card--with-footer-link
https://backstage.io/storybook/?path=/story/data-display-progress-card--link-in-footer

Context

Your Environment

NodeJS Version (v12): n/a
Operating System and Version (e.g. Ubuntu 14.04): Windows 10 1901
Browser Information: Microsoft Edge (Chrome)

Is it possible that it is broken since #3258?

Yep probably.

```
Uncaught Error: useHref() may be used only in the context of a  component.
    at l (index.js:1)
    at useHref (index.js:24)
    at index.js:6
    at renderWithHooks (react-dom.development.js:14803)
    at updateForwardRef (react-dom.development.js:16816)
    at beginWork (react-dom.development.js:18645)
    at HTMLUnknownElement.callCallback (react-dom.development.js:188)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:237)
    at invokeGuardedCallback (react-dom.development.js:292)
    at beginWork$1 (react-dom.development.js:23203)
react-dom.development.js:19527 The above error occurred in the  component:
    in Link (created by ForwardRef(Typography))
    in ForwardRef(Typography) (created by WithStyles(ForwardRef(Typography)))
    in WithStyles(ForwardRef(Typography)) (created by ForwardRef(Link))
    in ForwardRef(Link) (created by WithStyles(ForwardRef(Link)))
    in WithStyles(ForwardRef(Link)) (at Link.tsx:35)
    in Link (at BottomLink.tsx:56)
    in div (at BottomLink.tsx:54)
    in BottomLink (at InfoCard.tsx:223)
    in ErrorBoundary (at InfoCard.tsx:191)
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by ForwardRef(Card))
    in ForwardRef(Card) (created by WithStyles(ForwardRef(Card)))
    in WithStyles(ForwardRef(Card)) (at InfoCard.tsx:190)
    in InfoCard (at Page.stories.tsx:146)
    in div (created by ForwardRef(Grid))
    in ForwardRef(Grid) (created by WithStyles(ForwardRef(Grid)))
    in WithStyles(ForwardRef(Grid)) (at Page.stories.tsx:145)
    in div (created by ForwardRef(Grid))
    in ForwardRef(Grid) (created by WithStyles(ForwardRef(Grid)))
    in WithStyles(ForwardRef(Grid)) (at Page.stories.tsx:114)
    in DataGrid (at Page.stories.tsx:218)
    in article (at Content.tsx:54)
    in Content (at Page.stories.tsx:216)
    in div (at Page.tsx:45)
    in ThemeProvider (at Page.tsx:39)
    in Page (at Page.stories.tsx:206)
    in div (at Page.stories.tsx:205)
    in article (at Content.tsx:54)
    in Content (at preview.js:14)
    in CssBaseline (created by WithStyles(CssBaseline))
    in WithStyles(CssBaseline) (at preview.js:12)
    in ThemeProvider (at preview.js:11)
    in ApiProvider (at preview.js:10)
    in storyFn
    in ErrorBoundary
React will try to recreate this component tree from scratch using the error boundary you provided, ErrorBoundary.
logCapturedError @ react-dom.development.js:19527
ErrorBoundary.tsx:44 ErrorBoundary, error: Error: useHref() may be used only in the context of a  component., info: [object Object]
componentDidCatch @ ErrorBoundary.tsx:44
index.js:1 Uncaught Error: useHref() may be used only in the context of a  component.
at l (index.js:1)
at useHref (index.js:24)
at index.js:6
at renderWithHooks (react-dom.development.js:14803)
at updateForwardRef (react-dom.development.js:16816)
at beginWork (react-dom.development.js:18645)
at HTMLUnknownElement.callCallback (react-dom.development.js:188)
at Object.invokeGuardedCallbackDev (react-dom.development.js:237)
at invokeGuardedCallback (react-dom.development.js:292)
at beginWork$1 (react-dom.development.js:23203)
react-dom.development.js:19527 The above error occurred in the  component:
in Link (created by ForwardRef(Typography))
in ForwardRef(Typography) (created by WithStyles(ForwardRef(Typography)))
in WithStyles(ForwardRef(Typography)) (created by ForwardRef(Link))
in ForwardRef(Link) (created by WithStyles(ForwardRef(Link)))
in WithStyles(ForwardRef(Link)) (at Link.tsx:35)
in Link (at BottomLink.tsx:56)
in div (at BottomLink.tsx:54)
in BottomLink (at InfoCard.tsx:223)
in ErrorBoundary (at InfoCard.tsx:191)
in div (created by ForwardRef(Paper))
in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
in WithStyles(ForwardRef(Paper)) (created by ForwardRef(Card))
in ForwardRef(Card) (created by WithStyles(ForwardRef(Card)))
in WithStyles(ForwardRef(Card)) (at InfoCard.tsx:190)
in InfoCard (at InfoCard.stories.tsx:70)
in div (created by ForwardRef(Grid))
in ForwardRef(Grid) (created by WithStyles(ForwardRef(Grid)))
in WithStyles(ForwardRef(Grid)) (at InfoCard.stories.tsx:48)
in div (created by ForwardRef(Grid))
in ForwardRef(Grid) (created by WithStyles(ForwardRef(Grid)))
in WithStyles(ForwardRef(Grid)) (at InfoCard.stories.tsx:47)
in Wrapper (at InfoCard.stories.tsx:69)
in article (at Content.tsx:54)
in Content (at preview.js:14)
in CssBaseline (created by WithStyles(CssBaseline))
in WithStyles(CssBaseline) (at preview.js:12)
in ThemeProvider (at preview.js:11)
in ApiProvider (at preview.js:10)
in storyFn
in ErrorBoundary
React will try to recreate this component tree from scratch using the error boundary you provided, ErrorBoundary.
logCapturedError @ react-dom.development.js:19527
ErrorBoundary.tsx:44 ErrorBoundary, error: Error: useHref() may be used only in the context of a  component., info: [object Object]
componentDidCatch @ ErrorBoundary.tsx:44
</summary

Pull request is up!


Increasing requests and limits for the istio-ingressgateway envoy proxies.

How to categorize this PR?

/area performance
/kind regression
What this PR does / why we need it:
Increasing requests and limits for the istio-ingressgateway envoy proxies. Also, limit worker threads.
We have seen throttling on envoy proxies on busy seeds that can be circumvented with higher requests and limits.
In addition, the memory consumption of the envoy can be lowered by limiting the worker threads to the amount of CPU available to the container process.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

 SNI feature gate: Prevent throttling by increasing requests and limits for the istio-ingressgateway envoy proxies & limit the used worker threads.

/needs cherry-pick


Suggestion: Item Highlight in Quad Stashtabs while Selling

Hi there,
You already have the Item highlight on normal premium stashtabs while selling.
And i was Wondering if it would be possible to do the same at Quad Stashtabs.
I am mostly sell through Quad Tabs.
Thanks alot if you would consider that.

Hi, thanks for creating an issue. I'm able to use the highlight command also on Quad Stashtabs. Are you getting any error?

Hey,
no it is kind of working but the highlighted square is not on the item its rather 10 spaces down or to the left or right. and it wasn a one time issue.

Hm, the highlight function is part of the game. My tool only copies the item text into the search box. Could you please provide a screenshot?


I can get my access_scope even if shop_url without api_key??

I can get my access_scope even if shop_url without api_key

[8] pry(#<Shopify::AccessScope>)> ShopifyAPI::Base.site = shop_url
=><EMAIL_ADDRESS>[9] pry(#<Shopify::AccessScope>)> ShopifyAPI::Base.api_version = '2019-10'
=> "2019-10"
[10] pry(#<Shopify::AccessScope>)> ShopifyAPI::AccessScope.find(:all)&.map(&:handle)
=> ["read_content", "read_customers", "write_inventory", "write_orders", "write_products", "read_product_listings", "write_customers", "write_checkouts", "read_content", "read_all_orders", "read_inventory", "read_orders", "read_products", "read_customers", "read_checkouts"]

if shop_url without password

[2] pry(#<Shopify::AccessScope>)> ShopifyAPI::Base.site = shop_url
=><EMAIL_ADDRESS>[3] pry(#<Shopify::AccessScope>)> ShopifyAPI::Base.api_version = '2019-04'
=> "2019-04"
[4] pry(#<Shopify::AccessScope>)> ShopifyAPI::AccessScope.find(:all)&.map(&:handle)
ActiveResource::UnauthorizedAccess: Failed.  Response code = 401.  Response message = Unauthorized.

This is because passwords are unique as well as the ApiKey. The API can find your app by it's secret and then allow your request.


Model processors vs. directly calling function on parsed model

Question: how is using a model processor is different from simply calling a function taking a model after the parsing is complete?

No difference. Model processor is only a convenience that ensures that calling a processor is not forgotten.

I think that we should not close question issues to make them more visible.

I think that we should not close question issues to make them more visible.

Can we introduce an "answered question" . This will make it easier to "see" what issues are "open" or not...


[Docs] quickstart for ICON

Ok. What are your plans of putting envs into icon-repo?
I think it would makes sense to agree on a common folder-structure like config/cscs/spack or config/cscs/spack-envs


Specify missing void parameter in function declarators

Fixes: https://trac.macports.org/ticket/68320

See https://github.com/macports/macports-base/pull/301#issuecomment-1783645161 regarding CI failure.

Looks good to me. But I did not try to confirm whether this caught all warnings of this kind.

Currently, this PR does not address all -Wstrict-prototypes warnings. It only tries to deal with any which MacPorts itself would be responsible for. There are plenty more in vendor (Tcl, etc.) and autoconf tests; should this PR instead deal with those as well?
Also, this would only resolves warnings seen in make all and the macOS 13 build log the ticket referred to; I have not combed through the code to see if that missed any others (e.g. not compiled or hidden from the compiler).

Added fix for the one -Wstrict-prototypes warning seen during the Tcl 8.6.13 build. It will probably be accepted by upstream for Tcl 8.6.14.

Currently, this PR does not address all -Wstrict-prototypes warnings. It only tries to deal with any which MacPorts itself would be responsible for. There are plenty more in vendor (Tcl, etc.) and autoconf tests; should this PR instead deal with those as well?

I agree if we need it, we should try to submit this upstream if they did not already address this. Then sync it with a new upstream version. Just as you did now. :smiley:
Our patches to the vendored sources should be kept minimal and only apply build fixes we absolutely need. And vendored code throws other warnings as well.


Create loratap_wifi_curtain_switch_double.yaml

I am still not sure why it does show the state unknown when  the state is fully it is Open or Close

As noted on #867
If the position reliably indicates the current position of the blind, including when it is opened/closed by the control dp, then you can duplicate that dp as current_position as is done in the benexmart_blind_motor config. Due to a huge variety of Tuya curtain/blind controllers with different behaviours, the position dp is not considered reliable as an indicator of the true position of the cover.

Thanks for review :-) I'll make the ammendments .


Simplifies README and moves example to top level

Describe your changes and why you are making these changes
The previous README example was too complicated and didn't have a screenshot. This PR fixes that by using a simplified example and adding a screenshot.
Users also shared that they weren't sure where to find example code, so the examples directory has been moved from sdk/examples to the top level.
Related issue number (if any)
Checklist before requesting a review

[x] I have created a descriptive PR title. The PR title should complete the sentence "This PR...".
[x] I have performed a self-review of my code.
[N/A] I have included a small demo of the changes. For the UI, this would be a screenshot or a Loom video.
[N/A] If this is a new feature, I have added unit tests and integration tests.
[N/A] I have manually run the integration tests and they are passing.
[N/A] All features on the UI continue to work correctly.

Waiting to merge this until Joey finishes up his Colab notebook, so we can include a link to that here.


The default app long name includes Microsoft which throws warning Test and Distribute step

When publishing the test app. The manifest set the app long name to include "Microsoft Teams". App Studio throws this error:
"Full name should not contain “Microsoft” or any of the Microsoft product names (e.g. "Excel")."

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 98cd21c7-e87c-3c5b-7574-998a355f9f08
Version Independent ID: 5e312707-facc-03fc-af59-90267d0c7b8a
Content: Get started with C#/.NET - Teams
Content Source: msteams-platform/get-started/get-started-dotnet-app-studio.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

@jthake-msft We are working on updating the sample to reflect the expected behavior. Thanks!!

Fixed, thanks!


Add EditEventCommand and EditEventCommand test classes

I do not know what went wrong. I just commented the test case


Add ESXi integration

What does this PR do?
Adds the ESXi integration
Motivation
Provide a way to monitor a vSphere environment in a distributed way, without the vCenter
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Changelog entries must be created for modifications to shipped code
[ ] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.

Thanks, created DOCS-7804 for documentation team review.


reuse

normal cell reuse corver placeholder,and the placeHolder only need one, too many is not good.

this is the way to build placeholder exactly as your table view or custom view.


How to speed up bots answers?

Dear devs,
Could you give me please some hints, how to speed up companion answers? Because waiting time with their feedback is so long.
May be some settings in project files. Our some hints about services what app uses (I meant to upgrade something).
Thanks in advance!

Hi there, I believe the slowness is happening to the Vicuna bot. We're working on a #PR to speed it up. The GPT ones should be fairly fast.

I am using chatgpt bot and the response time for me is around 1.2 minutes on average. Is there any way to make the response faster?

If it's with ChatGPT the response should be a lot faster than 1.2 min unless the endpoint is congested.


Using skipunannotated throws error

Activating skipunannotated yields
Run jakebailey/pyright-action@v1
/usr/bin/docker exec  0570a425a99594c7f7200fb917406d6e67ce96052308507cba4db691694b18bd sh -c "cat /etc/*release | grep ^ID"
pyright 1.1.232, node v16.20.2, pyright-action 1.7.0
/__e/node16/bin/node /__t/pyright/1.1.232/x64/package/index.js --skipunannotated true --outputjson
Loading configuration file at /sage/pyrightconfig.json
Assuming Python platform Linux
stubPath /sage/typings is not a valid directory.
Searching for source files
File or directory "/sage/true" does not exist.
No source files found.

It might be because of the old version (that we have to use for some unrelated reason), but I think the args should be simply --skipunannotated --outputjson instead of --skipunannotated true --outputjson

This seems to just be a copy paste bug on my part, will fix.

I won't get to it until the morning, but for now you can work around this with extra_args.

Fixed in 1.7.1.


findspam.py: Anchor pattern_websites

So spam.co does not match notspam.com

I'm pretty sure pattern-matching websites is intentionally non-anchored, because we're looking for specific keywords in a domain name rather than trying to match specific domain names. For instance, we currently catch the domain xxxfreehdporn DOT com, but AFAICT we would not if the reason was anchored.

My understanding is that many of the regexes in pattern_websites are explicitly intended to start matching from anywhere within a word, not just at word boundaries. In other words, the lack of having \b bookends is intentional. Some of the regexes may benefit, but that would be on a case by case basis. It appears that adding this would break the intended operation of at least some of those regexes.
What is the problem that this change is attempting to address?

Also, if bookending is going to be added, it's probably preferable to do it once in the string in which the .format() is substituting into, rather than add \b to the beginning/end of each sub-pattern.

The specific issue is that almost all fps from this reason is due to fragment matches; however I agree that this may reduce detection and may be harmful to the overall goal.


Refactor FlavorAssigner

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Simplifies FlavorAssigner in preparation for #3405
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Change, and in some scenarios fix, the status message displayed to user when a workload doesn't fit in available capacity.

/lgtm

/lgtm

thanks for the review!

/release-note-edit
Change, and in some scenarios fix, the status message displayed to user when a workload doesn't fit in available capacity.

/kind bug
Due to the inaccurate message as per https://github.com/kubernetes-sigs/kueue/pull/3536#discussion_r1842569501.

/cherry-pick release-0.8


KAFKA-1695: Adding zookeeper authentication. Zookeeper acls should be set so only broker can modify zk entries with the exception of /consumers.

The change is backward compatible, all modified functions have a default so it should not break any scripts.
If a user enabled zookeeper authentication by adding "java.security.auth.login.config=some-jaas-file.jaas"  where some-jaas-file.jaas has Client section, then they are essentially locking all broker zookeeper entries so only users/processes that has access to the keytab or knows the digest user/secret listed in Client section can modify those entries. Please see https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zookeeper+and+SASL Section "JAAS conf file: Kerberos authentication".

@gwenshap Given you were the original author of the jira , it would be great if you can review this. Also let me know if you think adding a SECUTIRY.md at top level which describes how kafka zookeeper interaction and kafka znodes can be secured with acls makes sense.

I'll be happy to review, but - doesn't this depend on Kafka having kerberos tickets first? Otherwise we can't really check if Kafka manages to access these znode.

@gwenshap "doesn't this depend on Kafka having kerberos tickets first?" is a little ambiguous. If you mean kafka security work which allows kafka server to run with a keytab and authenticates client connecting to kafka then that is not needed for this.
For supporting this, zookeeper server needs to be configured to support security.
In addition, Kafka brokers needs to start with -Djava.security.auth.login.config=/path/to/client/jaas/file.conf where file.conf will need to have following section:
Client { // used for zookeeper connection
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/etc/security/keytabs/kafka.service.keytab"
storeKey=true
useTicketCache=false
serviceName="zookeeper"
<EMAIL_ADDRESS>};
Just by doing this we can assure all zookeeper nodes are secured with acls. So if you meant the second option where a keytab is configured to access zookeeper , then yes we need that. Another option is to use digest by specifying the following and in this case no keytabs are required:
Client {
org.apache.zookeeper.server.auth.DigestLoginModule required
username="bob"
password="bobsecret";
};
I haven't tested the digest approach but don't see why it wont work. Will update the PR once I have tested with digests too.

@gwenshap Took me sometime to get the whole digest setup working. With the above specified Client section and only this patch over trunk I was able to secure zookeeper nodes. Kafka and zookeeper connections were authenticated using digests so no keytabs were required.
For all nodes the acls were set as following:
[zk: c6401.ambari.apache.org:2181(CONNECTED) 41]getAcl  /brokers/ids
'world,'anyone
: r
'sasl,'bob
: cdrwa
[zk: c6401.ambari.apache.org:2181(CONNECTED) 35] getAcl  /brokers/ids/0
'world,'anyone
: r
'sasl,'bob
: cdrwa
One issue I found was even though the producer was able to produce successfully, consumer failed to consume until I started consumer such that it also had access to the same client section as above. This should not be required given all nodes allow anyone to read and /consumers is open for anyone to write.
[zk: c6401.ambari.apache.org:2181(CONNECTED) 39] getAcl consumers
'world,'anyone
: cdrwa
Stepping through the code it seems like somehow the code gets stuck in ConsoleConsumer when it tries to check existence of some broker here https://github.com/apache/kafka/blob/43b92f8b1ce8140c432edf11b0c842f5fbe04120/core/src/main/scala/kafka/tools/ConsoleConsumer.scala#L129. Its not throwing exceptions, its not exiting , it just gets stuck forever at that statement. Seems like some bug in ZkClient but I will have to debug further.

@gwenshap so further debugging and it turned out to be an issue with my jaas. The consumer works even without specifying in client section as expected.
So this change alone is sufficient to secure zookeeper entries and kafka -> zookeeper communication.

Looking at the patch, there seem to be some unrelated stuff in there.
I assume you'll clean it up. Should I be looking at anything except zkutils file?
Zookeeper configured for security is understandable.
The extra Kafka configuration (i.e. starting with an extra flag and an extra config file), was this covered in one of the security KIPs? Because I remember hearing some objections to extra configuration files but I don't remember how it got resolved...

The only file to look at is ZkUtil. Cleaning everything else up.

Not sure why Pull request shows the diff, these changes are from commits that were merged to trunk and I just rebased on top of them. The files other than ZkUtil are identical.

@Parth-Brahmbhatt, you merged instead of rebasing. That's the reason why the commits are still there.

@ijuma The commits are ok, Why does it show the file diff? Given the files are identical I would expect it to show no diff. I thought it might be a whitespace issue but adding ?w=1 still does not change the diff. I will probably have to take my 2 commits, and git --force push but then we will lost all the conversations.

@Parth-Brahmbhatt, I looked at your branch more closely and the commit graph looks weird. In particular, the following commit appears twice in the graph with 2 different parents:
"KAFKA-1695: Zookeeper acls should be set so only broker can modify zk entries with the exception of /consumers."
The end result is that the files diff is showing the combined changes in the commits listed here (which includes some commits from trunk indeed):
https://github.com/apache/kafka/pull/93/commits
I think the only thing to do here is to rebase so that we end up with a nice and linear history. If you don't want to lose the comments attached to existing commits, you can push to a new branch, close this PR and open a new one linking to this one.

@fpj, can you please take a look at this when you have a chance?

The patch in general looks good. It creates some default acls and adds a parameter to all calls that create znodes. With this patch, however, ConsumersPatch is left wide open, and it is probably not ideal to leave it like that, but perhaps will go away with the new consumer making it less of a problem. An option to strengthen the security here is to use authentication, check it here:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zookeeper+and+SASL

@Parth-Brahmbhatt, @fpj Any suggestions on how we should test this? Some automated tests would be good.

@fpj consumers will probably run with identities that are widely different from kafka's own zookeeper identity and I think we should not force the users to chose from

distribute kafka's zookeeper identity (keytab or digest) to all consumers
manually set acls on /consumer for each consumer they want to allow.

That is why /consumer is open. However entries created under it will be written by consumers them self and as long as they are using our libraries, it will use the same ZkUtil class and those entries will be secured so only consumers in same group with same identity will be able to write to them. Even though /consumer is open , as children are secured no user will be able to delete /consumer.
I am not sure what you meant by use "Zookeeper+and+SASL" to strengthen security. This PR sets the correct acls and leaves what authentication scheme is used to client which they can control by specifying their preferred scheme(digest, sasl) in Client section of the jaas. We should not need to change anything in this PR to support SASL over zookeeper.

@Parth-Brahmbhatt thanks for the clarification. Is there going to be any documentation the default behavior and possibly giving recommendations for how users should configure the system? And you're also right about the SASL configuration, and it would be nice to say somewhere that the option is available. Kafka users are not necessarily super knowledgeable on the features of ZK.

The website documentation should be updated (http://kafka.apache.org/documentation.html). We have a JIRA for SSL/TLS (https://issues.apache.org/jira/browse/KAFKA-2441), we should probably have one for ZK auth too.

@ijuma addressed other styling comments as far as testing goes I actually tried adding a unit test based on digest, however the issue is we are on zkClient-0.5 and the APIs to actually getAcl for nodes are not part of this release. Those APIs will be part of the next release whenever it happens. In absence of the getAcl API there is no way for us to verify that correct acls are set.
@ijuma  and @fpj I will be happy to add the documentation for "Securing kafka zookeeper nodes". Should I just add a wiki page right away? I originally thought it might be better to wait till the final version of PR gets merged and then create the wiki page as wikis seem to be published right away but I could add a wiki page right now and make a bolt RED notice on top to indicate it is still under review. Let me know either ways.

@Parth-Brahmbhatt Yes, a wiki page with a disclaimer at the top sounds good.

@Parth-Brahmbhatt, it looks like zkclient 0.6 will be out very soon (https://github.com/sgroschupf/zkclient/commits/master). We can perhaps upgrade to that so that we can write the missing tests.

@ijuma I wrote a very basic unit test to check the acls are correctly set in secure setup. However ZkUtils is an "object" and its isSecure variable is initialized on first reference to ZkUtil. This means if the unit test runs in isolation (in a new JVM) it passes , however if it runs in the same JVM (default gradle behavior to reuse the same jvm for all test cases) as some other unit test depending on the order of execution one of the 2 test case will fail. I can think of 2 alternatives

Fork a new JVM for each test case. Obvious disadvantage of tests taking longer to run. On my machine it increased the test execution time by 54 seconds (Total time: 5 mins 27.038 secs instead of
Total time: 4 mins 21.574 secs).
Make isSecure a method that dynamically returns true or false and getAcls also dynamically. This has the obvious disadvantage of re parsing the jaas file on each zkUtil call that tries to write something to decide if zookeeper is secured or not which practically should not change in real production.

I also explored if there is a way to reload an object instance but that just seems like an even worst heck. Let me know if you can think of any other less hecky option.
You can see the actual unit test https://github.com/Parth-Brahmbhatt/kafka/commit/ebedba5629e6253aac7976ed4a0fc1dbde5fffdd
and the changes to build.gradle to make it spawn one jvm per unit test is https://github.com/Parth-Brahmbhatt/kafka/commit/7f5bba888350f0ae9d8d3878fa0e0016168c2ee5

@ijuma any suggestions for the last comment?

I'll add my thoughts in an hour or so. Sorry for the delay.

@Parth-Brahmbhatt, there are two usual paths when one runs into a situation like this:

Convert the object into a class so that parameters can be passed during instantiation
Use an implicit parameter in the object methods to pass a context object implicitly

For option 1, we could have a class parameter called defaultAcls and the code that did the read of the system property, parsing and so on would be elsewhere. This separation is a nice bonus. Sadly, I think this change would affect quite a few files. I am not aware of an automated refactoring tool for this, but it would be worth checking.
For option 2, there would be an implicit parameter in every method with the acls. Due to the way implicits work, you'd want to introduce a new type for it (e.g ZkAcls). It involves some repetition as it needs to be part of every method. It could perhaps replace the acls parameter though. In order to make this implicit automatically available, you could add the default implementation in the companion object of ZkAcls (the compiler will look there if it can't find one in scope). In a test, you can create a different implicit and put it in scope so that it's used before the one in the companion object. I think this way may be less invasive although it's less clear than option 1, especially for someone who is not very familiar with Scala's implicit resolution rules.
Before we go in either direction, it may be worth discussing this with another committer (maybe @junrao and/or @gwenshap). In my opinion, reading a property inside a Scala object to control behaviour is something to be avoided as it makes testing much harder as can be seen here.

@ijuma @Parth-Brahmbhatt
I had another look at this PR, and I was trying to implement the following approach. For methods that create znodes in ZkUtils, instead of passing an instance of ZkClient I pass an instance of ZkClientContext, which contains an instance of ZkClient, the implementation of isSecure, and DefaultAcls (I moved the latter two from ZkUtils). The calls in ZkUtils ended up looking like this:
private def createParentPath(client: ZkClientContext, path: String)(acls: List[ACL] = client.DefaultAcls): Unit

Note that I've split the list of parameters into two, so that I could change the default ACL. I don't find the syntax super cute, but it works. To instantiate ZkClientContext, I require a parameter for the java.security.auth.login.config property so that isSecure executes properly. As I was trying to do this, a problem I came across is that in thekafka.admin package, we are making calls to ZkUtils due to command line execution. In such cases, it isn't clear how we will enforce that the command sets the login config property so that we declare the calls to ZkUtils secure. In general, the main problem I came across as I was making changes was exactly determining what the current configuration is.
But, let's go by parts. First, I'm interested in knowing if you find the above approach acceptable. Second, even without the approach above, how are you planning on enforcing that the calls via command line are executed securely?
Hope it makes sense.

@fpj, I like the idea of passing a ZkClientContext that includes the authentication information. You could use an implicit parameter to make it even easier to use, potentially. Having the acls as a separate parameter list is a bit annoying because one can't just exclude the second parameter list.
Good question about the admin package. I can look into it, but perhaps @junrao knows.

for the admin package part, I was assuming that we will just modify https://github.com/apache/kafka/blob/trunk/bin/kafka-run-class.sh so if user sets KAFKA_JAAS param we will set the java.security.auth.login.config to the value of that param. If they forget to set the environment variable the command line script will fail indicating it could not write to zookeeper because of authorization issue as long as the brokers them self were started with correct environment variables at least once.
The ZkClientContext change seems very invasive given we will have to change every caller and I don't quite understand how it is much different from making all callers pass a acls param + making getDefaultAcl a method that dynamically gets the acl each time by evaluating isSecure. May be I just don't understand the proposal well enough.

@Parth-Brahmbhatt

If they forget to set the environment variable the command line script will fail indicating it could not
write to zookeeper because of authorization issue as long as the brokers them self were started with ç
correct environment variables at least once.

I don't understand why the script would fail. Not setting the parameter implicitly means that security is off as I'm reading this patch. Also, I'm thinking that a user could intentionally not set the parameter to run the admin command in a non-secure fashion. Could you clarify if this is being taken care of and how, please?

The ZkClientContext change seems very invasive
It indeed requires to change all callers, and I won't say it isn't a pain. But, the intention is to avoid having to determine values for isSecureand DefaultAcls in a static object.

Sorry for not explaining it in a better way. I was trying to say that if the brokers were started with correct parameter , by setting KAFKA_JAAS environment variable, on startup it should set the correct acls as part of makeSurePersistentPathExists, unless the brokers are being moved from an unsecure environment to a secure environment in which case all the paths will already exist. To handle the case where all paths already exists I need to add makeSureCorrectAcls are set which was not added in the original PR as my pr to get/set acl in zkCli was only available in zkClient-0.6 onwards which is now merged into kafka.
Once these acls are set ocrrectly, even if a client script that needs to write to zookeeper gets started without KAFKA_JAAS variable it will fail because zookeeper should reject any write request that is not authorized. Does that make sense?

@Parth-Brahmbhatt
The default is CREATOR_ALL which means that only zk clients with the right credentials will be able to create children in the kafka subtree or modify nodes in that tree. If the client running something from the command line doesn't pass the right credentials, then the default will be OPEN, but it doesn't matter because of the acls already in zookeeper. Is that a correct assessment? Will you add makeSureCorrectAcls?
About the ZkClientContext discussion, I'd like to reach an agreement on what to do about the fact that we are reading a configuration parameter from a static object. What I proposed does increase the number of changes and the files it touches. The current PR is much nicer in this sense because it is all in ZkUtils. But, it sounds like we need a better way of controlling the behavior of the calls in ZkUtils. I'm not we can do it without changes in other classes, but I'm open to suggestions. Also, check the comment from @ismael about the implicit parameter, maybe you find that option better.

@Parth-Brahmbhatt, as @fpj is saying, the fact that we read a system property in order to define the isSecure val in a Scala object (which is a JVM-wide singleton) is not great because it makes testing harder. ZkUtils is meant to be a place for utility methods with no state (see https://code.google.com/p/google-singleton-detector/ for reasons why one should avoid singletons).
I previously outlined the options as I saw it:

Convert the object into a class so that parameters can be passed during instantiation
Use an implicit parameter in the object methods to pass a context object implicitly

@fpj's proposal is a variation of two that moves ZkClient into the context object (which makes sense) and doesn't make the parameter implicit (which is up for discussion I think).
If my arguments have not been convincing enough, then we could keep the singleton and change the isSecured val to a var that could be changed from tests only. I personally seriously dislike this approach, but I mention it because @junrao said that it could be OK if the ability to change isSecured was only needed for tests.

The current patch seems to work well for a new cluster. If ZK credential is set properly in the brokers, the top level paths will be created to only allow authenticated clients to create child nodes. If some one runs the acl cli w/o ZK credential, the command will fail.
If there is already an existing cluster, we have to think through the upgrade path. I am not sure adding the support of makeSureCorrectAcls in ZkUtils is ideal. Suppose you do that and do a rolling upgrade. After the first broker is upgraded, the acl for existing ZK paths will be set and the rest of the brokers won't be able to write to ZK any more. This can be problematic since the rest of the brokers may need to write to ZK for doing controller related stuff, for changing ISRs, for creating new topics, etc.
One alternative is the following. We introduce a broker config set.zookeeper.acl, which defaults to false. ZK acls will only be set if set.zookeeper.acl is true. We also make a separate ZKSecurityMigrationTool that will take the ZK credential and set the acl on all existing ZK paths managed by Kafka. To do the upgrade, we (1) rolling restart all Kafka brokers to pass in the ZK credential (after this step, all brokers can read from ZK if acl is set, but they are not setting the acl yet); (2) do a second rolling restart of all brokers by setting set.zookeeper.acl to true (after this step, new ZK paths will be created with acl); (3) run ZKSecurityMigrationTool to set acl on all existing ZK paths. After this point, ZK is secured. Nobody can change the data in ZK w/o ZK credential. Will that work? If this works, we will probably need to make ZkUtils a class so that we can pass in the config set.zookeeper.acl.

Jun, you are right, I did not consider the rolling upgrade scenario. The steps you described will work. If we make ZkUtils a class I guess we will have to change a lot of code but it will also address the concerns that @ijuma raised?

@Parth-Brahmbhatt @junrao @ijuma
I don't have a very strong preference between creating a context class or making ZkUtils a class, you can solve the problem of making it easier to test both ways. However, given the current structure of ZkUtils, I find it more elegant to introduce an extended zk context rather than making them all class methods. But again, I believe we can get the same functionality we need both ways and the amount of changes seems to be roughly the same.
On the issue of rolling upgrades (good point!), the approach described sounds good, but I think we can avoid the second rolling start by using a /kafka/issecured znode or some other name like that. During the rolling restart, we set set.zookeeper.acl on all brokers and they set a watch on that znode. Once the znode is created, brokers start using credentials. That same znode could serve as a general mechanism to indicate that a Kafka cluster is secured. Such a znode can be created either by the external tool (ZKSecurityMigrationTool) or by the last broker in the sequence of the rolling restart.

@fpj So far, we only store topic/clientId level configs in ZK. All broker level configs are stored in broker configuration file. While having a /kafka/issecured ZK path is also fine, for consistency, it's probably better to stick with a broker config.
Also, just to make sure. If a ZK client is authenticated, but doesn't set acl when creating a ZK path, any client can read/write this path, right?

@junrao As long as the acls are set with "anyone can read/write/create/delete" any authenticated or unauthenticated client will be able to perform that operation.
@fpj I don't really have anything against introducing the zkContext and if I understand correctly with that approach, ZkUtil will still be a scala "object" and we will just replace zkClient param in all the methods with zkContext. Makes sense to me.

@Parth-Brahmbhatt If the acl is not provided when creating a path, does it get the "anyone has full permission" acl by default?
Also, it seems that in this patch, we only need to set the ACL when creating a ZK path. It doesn't seem that we need to set it during an update.

@Parth-Brahmbhatt I had sometime today (I'm in a different time zone) and I end up working on the changes to make ZkUtils a class. @ijuma  and I had a short conversation offline and ended up concluding that it is an approach more common in the current code base.
The patch I'm working on is based on yours, and if you're ok with it, I'd like to propose a new PR with these changes. It also includes all the recent commits, so it isn't stale. Let me know if you're ok with it, please. You've done all the work so far and I don't want you to feel that I'm interfering with your progress.
@junrao

While having a /kafka/issecured ZK path is also fine, for consistency, it's probably better to stick with a broker config.

Ok, let me think about this, I really don't like the idea of two rolling starts, but maybe the alternatives aren't great.

If a ZK client is authenticated, but doesn't set acl when creating a ZK path, any client can read/write this path, right?

You always need to pass an acl parameter, even if the parameter open unsafe. If it is open unsafe, then yeah, anyone can read/write/add children.

@junrao by default all nodes have "anyone has full permission".
@fpj I don't really have a preference one way or another. If you have a patch with ZkUtils as a class feel free to post a PR.  Thanks for helping out.

Ok, thanks @Parth-Brahmbhatt. I should be able to create an initial PR tomorrow. I have the main code compiling, but not tests. I fix the tests before I push the initial PR.

Can we please close this PR since ZK authentication was integrated via #303?


Selected Tab in sideNav doesn't have sufficient contrast.

Ensure that interface controls have a luminosity contrast ratio of 3:1 or more.
Currently the background-color is #fafafa and selected tab background color is #d8e3e9.
Current Contrast ratio is 1.25:1 .  This value has to be more than 3:1.
Contract checker : https://www.levelaccess.com/color-contrast-checker/

Please use our bug report format when submitting issues, it helps us to properly understand your report. Otherwise we are less likely to triage and prioritize it without proper information.
From the limited information, it sounds like the report is the contrast between the two background colors is not considered sufficient. However, the text is also bolded to indicate selection. I don't believe this is an issue.
@chlane can you advise?

See https://github.com/vmware/clarity/issues/4378 as an example

This is a valid issue Nick @ncaskey04  and I checked it out.  The CSS causing this issue is below. Please choose a color combination that yields a 3:1 contrast ratio.
.sidenav .nav-group .nav-list .nav-link.active {
background: #d8e3e9;
background: var(--clr-sidenav-link-active-bg-color,#d8e3e9);
color: #000;
color: var(--clr-sidenav-link-active-color,#000);
}
.main-container {
display: flex;
flex-direction: column;
height: 100vh;
background: #fafafa;
background: var(--clr-global-app-background,#fafafa);
}

There is a workaround available to update the color as needed for the immediate moment.
Clarity cares deeply about accessibility, and we work with our accessibility team to identify and triage issues. We have an internal tracking system to identify and verify accessibility issues, which has captured this already. Some issues with Clarity Angular are difficult to solve without causing side effects or breaking changes, and we have to balance concerns with fixing issues and breaking changes. As we build out Clarity Core, we are able to address these root cause accessibility issues and recommend adopting the Clarity Core implementations as they become available. We are closing this issue as we have the issues tracked internally. Please follow our development and releases to see when we release relevant Clarity Core components to make this possible.


error: "Running setfiles on install tree failed: [Errno 2] No such file or dir: 'setfiles': 'setfiles'**"

$ sh build.sh
.....
2021-02-24 19:22:58,436: Error in atexit._run_exitfuncs:
2021-02-24 19:22:58,437: Traceback (most recent call last):
2021-02-24 19:22:58,437: File "/usr/lib/python3.6/site-packages/dasbus/client/handler.py", line 477, in _get_method_reply
2021-02-24 19:22:58,437: return self._handle_method_error(error)
2021-02-24 19:22:58,437: File "/usr/lib/python3.6/site-packages/dasbus/client/handler.py", line 497, in _handle_method_error
2021-02-24 19:22:58,437: raise exception from None
2021-02-24 19:22:58,437: dasbus.error.DBusError: umount of /mnt/sysimage/run failed (32)
2021-02-24 19:22:58,617: Running setfiles on install tree failed: [Errno 2] No such file or dir: 'setfiles': 'setfiles'
2021-02-24 19:26:46,610: Disk Image install successful
2021-02-24 19:26:46,625: SUMMARY
2021-02-24 19:26:46,625: -------
2021-02-24 19:26:46,627: Logs are in /root/docker-images
2021-02-24 19:26:46,629: Disk image is at /root/docker-images/result/almalinux-8-docker.tar.xz
2021-02-24 19:26:46,629: Results are in /root/docker-images/result

@hjimmy at this point script is not failing due this error, continue with process after the error outputs the tar file. Do you see any problem in output file due this error?

@hjimmy I am closing this issue. We can reopen if found more details or impact on output


HBASE-26604 Replace new allocation with ThreadLocal in CellBlockBuilder to reduce GC

https://issues.apache.org/jira/browse/HBASE-26604

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 58s
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 14s
Maven dependency ordering for branch

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
javadoc
0m 43s
the patch passed

_ Other Tests _

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

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

36m 14s

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-3964/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-26604

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d5156483ac25 4.15.0-162-generic #170-Ubuntu SMP Mon Oct 18 11:38:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / da616c00c7

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

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

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3964/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
0m 32s
Docker mode activated.

-0 :warning:
yetus
0m  2s
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 15s
Maven dependency ordering for branch

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

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

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

36m 14s

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-3964/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-26604

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux bc8325b2fb79 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 / da616c00c7

Default Java
AdoptOpenJDK-11.0.10+9

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

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

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

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3964/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
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 17s
Maven dependency ordering for branch

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

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

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

+1 :green_heart:
spotbugs
2m  8s
master passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
checkstyle
0m 57s
the patch passed

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

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

+1 :green_heart:
spotbugs
2m 33s
the patch passed

_ Other Tests _

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

54m 57s

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-3964/1/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-26604

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 3cd705d6c191 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / da616c00c7

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3964/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.


Merge Develop into Master 10.12.17 - custom field limits

@Whatthefoxsays - the custom field stuff went out today. that combining with the the fact that I'll be out on Friday means I think we should do our weekly release towards the end of the day tomorrow

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.11 out of 12 committers have signed the CLA.:white_check_mark: alfredlucero:white_check_mark: Whatthefoxsays:white_check_mark: vkolova:white_check_mark: NexWeb:white_check_mark: machinshin:white_check_mark: thinkingserious:white_check_mark: ciceropablo:white_check_mark: Braunson:white_check_mark: ksigler7:white_check_mark: lierluis:white_check_mark: cjohnwagner:x: sjepsteinYou have signed the CLA already but the status is still pending? Let us recheck it.

Hello @ksigler7,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


Head request in Alamofire 4

The below head request was throwing following error
responseSerializationFailed(Alamofire.AFError.ResponseSerializationFailureReason.inputDataNilOrZeroLength)
  Alamofire.request(AppConstants.musicFileURL + musicFilename, method: .head, parameters: nil, encoding: JSONEncoding.default, headers:headers)

            .responseJSON { responseStr in

                print("HEAD \(responseStr)")

                //print FAILURE: responseSerializationFailed(Alamofire.AFError.ResponseSerializationFailureReason.inputDataNilOrZeroLength)

                guard responseStr.result.isSuccess else {
                    return
                }
        }

Thanks for the report! HEAD requests are just rare enough to get through our testing in this instance. We'll work on an update this weekend.

I got the same problem here. I was supposing the .head request would have a specific response type other than JSON, since it doesn't have a body to parse. But I can't find documentation about it.
Any thoughts or directions?

@jshier has put together #1775 to address this issue. We're not going to pull this PR into the Alamofire 4.1.0 because we still have some backwards compatibility issues to work out. However, I'd like to close this issue out and have everyone redirect all further comments to #1775.
Thanks everyone! 🍻