text:
Screen reader does not announce search result information for select culture to load combo box.

Describe the bug
Screen reader does not announce updated search result information for select value combo box. it only announces the typed latter information.
Screen reader dependent users will be impacted, they will not be aware about updated result as screen reader does not announce about this.
To Reproduce
Steps to reproduce the behavior:
1.Open URL in edge dev browser.
2.Open Narrator using 'Ctrl + Win + Enter' key.
3.Navigate to the Select Valus dropdown using tab key and press enter.
4.Enter value in search field and observe the issue.
Alternatively link your repo with a sample project that can be run.
URL
Expected behavior
Screen reader should announce updated search result information for Select Value combo box..
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
OS Build: Windows 11 Enterprise 22H2 (25267.1250)
Edge Dev Browser: Version 111.0.1652.0 (Official build) dev (64-bit)
Attachment
https://github.com/radzenhq/radzen-blazor/assets/93735775/73bde1b6-5e5a-41f1-b28b-3b81ef528802

Fixed in https://github.com/radzenhq/radzen-blazor/commit/347942668d9003788403ec4e315ae2bfcec68263

authors: enchev msftedad

repo: radzenhq/radzen-blazor


text:
send feature - multiple destination addresses and improved utxo display and selection

Resolved issue 113 and issue 114
Added the feature to allow sending to multiple destinations

Added a -l flag for the user to control whether or not the output option list should be selected automatically or manually.
If the flag is not provided, the best-sized input is selected automatically, shown to the user and used for the transaction if the user agree to continue

if the -l flag is provided, the best-sized input is provided as default selection for the user who is provided with the option to either use it or manually select the inputs for the transaction.
The list is sorted by the amount given a tabular display showing receiving address, amount, date and no of confirmations

#114 has been updated to no longer include a list flag for the send-custom command.
Instead, after user enters destination addresses and amounts, ask user whether to manually chose inputs for the transaction or not:
Would you like to (a)utomatically or (m)anually select inputs? (A/m)

If user choses to automatically select inputs, run your best size algorithm to decide what utxos to use as inputs for the transaction. No need to display the automatically selected inputs at this time.
If user choses manual selection, list the utxos and ask user to select the unspent outputs to use as inputs for the new transaction:
Select unspent outputs to use as inputs for this transaction (e.g. 1-4,6)

Regardless of the user's choice, we should have a list of utxos to use as inputs for this transaction. If the user choses manual selection, it may be appropriate to calculate the total sum selected by the user and confirm that it is not less than the total send amount. If it is less, inform the user and ask the user to make a new selection.
Afterwards, request for the spending password and display a following prompt using the format specified in #115:
You are about to spend the input(s)
9.423 DCR from TsgUAq54uZ6GW1VQwgjtgG7KB68pJwy73dJ
and send
2.123 DCR to TsgQwgjtgG7KB68pJwyUAq54uZ6GW1V73dJ
1.123 DCR to TsgJwyUAq54uZ6GWQwgjtgG7KB68p1V83dJ
Do you want to broadcast it? (y/n): y
Sent. Txid b5f844895a4e5b4e496929be0356e8435a8c30976d6bd59a29539fddd37fc9d7

When I update amount for a previously added destination address, the numbering should not increase

Destination 2 was an update to destination 1, so I should have been asked for Destination address 2 again

Everything looks good, just this https://github.com/raedahgroup/godcr/pull/119#issuecomment-451311595 I thought was resolved, still there.

source: gharchive/pull-request

authors: ademuanthony itswisdomagain

repo: raedahgroup/godcr

license: ISC

license_type: permissive

license_source: github-api


text:
LC queries PFS for direct transfer on the mainnet

Thanks for filing a bug report :-)
Please treat this is as a provisional issue. I am re-verifying everything again so that i reproduce this reliably
Scenario:
LC browser node
0x9307b1EE0f1299547F8F46A268efbd6089Ce81B2
subkey account:
0x07d036DbC602F0191a4bC8e217fe48d34cD4a230
LC CLI node
0x5d3c715dfec88ee0C1a14C2B6ed3b0878612581c
node build/index.js --eth-rpc-endpoint http://10.104.6.7:8545 --api-address "http://localhost:5010" --keystore-path /home/devaki/.ethereum/keystore/ --address 0x5d3c715dfec88ee0C1a14C2B6ed3b0878612581c --log-file node-5d3c71-mainnet-24thFeb2021.log --password-file password_file.txt --accept-disclaimer --enable-monitoring

Steps to Reproduce

yarn build
npx serve -l 8080 ./dist

.env.production
VUE_APP_MATRIX_LIST_URL=https://raw.githubusercontent.com/raiden-network/raiden-service-bundle/master/known_servers/known_servers-production-v1.2.0.json
VUE_APP_ALLOW_MAINNET=true
VUE_APP_HUB=hub.raiden.eth
VUE_APP_IMPRINT=https://raiden.network/privacy.html
VUE_APP_TERMS=https://github.com/raiden-network/light-client/blob/master/TERMS.md

Expected Result

LC should directly proceed to transfer

Actual Result

Additional Infos (Optional)
LC browser logs
raiden_0x07d036DbC602F0191a4bC8e217fe48d34cD4a230_2021-02-24T13_18_23.400Z.log
LC CLI logs
node-5d3c71-mainnet-24thFeb2021.log

There's one case where LC can and should try to request PFS for direct transfers: your partner is online, you don't have enough capacity on the direct channel with them, but you may have enough capacity on a channel with another peer; the rationale is that, even though the direct route isn't suitable, maybe PFS could give you an indirect route which is.
Please, check if this is the case, try to balance or deposit on the channel to ensure there's enough capacity for the transfer, and check if this is still the case.

The error shown has nothing to do with this "issue": it's caused by the auto-pfs code trying to contact and validate the registered PFSs, but some of them isn't responding properly, so it gets skipped, but the working ones are there, as they should.

I have 10 DAI in deposited in the channel and I am transferring 1 DAI. But I am building everything again and trying to run it so that I reliably reproduce this.

After a long time the channel has started showing on the CLI node,
$ curl -i http://localhost:5010/api/v1/channels/0x6B175474E89094C44Da98b954EedeAC495271d0F/0x07d036DbC602F0191a4bC8e217fe48d34cD4a230
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: http://localhost:*/*
Vary: Origin
Content-Type: application/json; charset=utf-8
Content-Length: 337
ETag: W/"151-1H/RcWvDgozLTmm1N0GnQoc8g/0"
Date: Wed, 24 Feb 2021 15:59:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"channel_identifier":"66","token_network_address":"0xEA92bD481e54BBB9Bb6C927970a54E82eE26c6B4","partner_address":"0x07d036DbC602F0191a4bC8e217fe48d34cD4a230","token_address":"0x6B175474E89094C44Da98b954EedeAC495271d0F","balance":"0","total_deposit":"0","total_withdraw":"0","state":"opened","settle_timeout":"500","reveal_timeout":"50"}

I have tested this and satisfied myself again on the latest master it gives the same error on LC browser. if someone wants i could also also upload the state and then the keystore file and they can also try to reproduce this.

source: gharchive/issue

authors: agatsoh andrevmatos

repo: raiden-network/light-client

license: MIT


text:
Licensing for this project

We need to decide how this project is going to be licensed, and then establish some guidelines on how we manage/publish sources.
I think it's important that this effort be true open source and not just publishing STEP and/or STL files.
Personally I would like to avoid the CC license of the Railcore project proper, as that license explicitly mentions it's not well suited for hardware projects.  Left to my own devices I'd just license this MIT since we're not trying to do anything particular groundbreaking, rather just fix make things nicer.  MIT license would allow the upstream railcore to incorporate any of our work as well.
thoughts?

Strong agree that everything should be both reproducible and modifiable. There should be an expectation that original CAD sources are available, IMO.
As far as licensing, I'd also agree that shoehorning software licenses onto hardware is generally a mistake. Less familiar with what options are out there for hardware-specific license options, but it's worth some research.
The only thing I'd really be absolutely against is a bespoke license -- seen too many projects come up with objectively terrible licenses because they insisted on doing their own thing. It should be an off-the-shelf license of some flavor.

Is this the one? https://opensource.org/licenses/MIT

Just a note, we have a registered trademark on the RailCore® name now.
This was done primarily to prevent companies from calling any old printer a RailCore.  It does have some side effects, though.  If your community changes are ever released as a full design, we'll need to discuss naming.  For now, it would be best if on your project's main page you can put  the little ® after RailCore, and note the name is a registered trademark of RailCore Labs, LLC.

Just a note, we have a registered trademark on the RailCore® name now.
This was done primarily to prevent companies from calling any old printer a RailCore. It does have some side effects, though. If your community changes are ever released as a full design, we'll need to discuss naming. For now, it would be best if on your project's main page you can put the little ® after RailCore, and note the name is a registered trademark of RailCore Labs, LLC.

Feel free to submit a PR to have the page say what you want.

authors: bakaufman jslaker kraegar lostapathy

repo: railcore-community/wishlist


text:
cannot load such file -- config/environment

Trying to use lamby in an existing rails app, I am getting this error when access the app in aws lambda url:
Executing 'config/environment.Lamby.cmd' in function directory '/tmp'
Init error when loading handler
{
"errorMessage": "cannot load such file -- config/environment",
"errorType": "Init<LoadError>",
"stackTrace": [
"/usr/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require'",
"/usr/local/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require'",
"/usr/local/bundle/gems/aws_lambda_ric-2.0.0/lib/aws_lambda_ric.rb:41:in `run'",
"/usr/local/bundle/gems/aws_lambda_ric-2.0.0/lib/aws_lambda_ric/bootstrap.rb:35:in `bootstrap_handler'",
"/usr/local/bundle/gems/aws_lambda_ric-2.0.0/lib/aws_lambda_ric/bootstrap.rb:8:in `start'",
"/usr/local/bundle/gems/aws_lambda_ric-2.0.0/bin/aws_lambda_ric:10:in `<top (required)>'",
"/usr/local/bundle/bin/aws_lambda_ric:23:in `load'",
"/usr/local/bundle/bin/aws_lambda_ric:23:in `<main>'"
]
}

FROM ruby:2.7.2

RUN apt-get update

# Install MySQL client and server
RUN apt-get install -y --no-install-recommends default-mysql-client

# Set the working directory to /app
WORKDIR /tmp
COPY Gemfile Gemfile.lock ./

# could not get it from AWS SAM:
ARG BUNDLE_GITHUB__COM
ARG RailsEnv
ENV RAILS_ENV=$RAILS_ENV
ENV BUNDLE_GITHUB__COM

RUN gem install 'aws_lambda_ric'
ENTRYPOINT [ "/usr/local/bundle/bin/aws_lambda_ric" ]

COPY . .

RUN rm -rf /tmp/vendor
RUN bundle install

CMD ["config/environment.Lamby.cmd"]

I do have gem "lamby" in Gemfile, shouldn't it present the entry point for Lambda function ?
Your help is appreciated.

Your WORKDIR is tmp which means you are COPY'ing your app into a directly that the Lambda service will treat as a tmp dir, meaning it deletes everything there. Put your app into an app directory or some other run dir. Here is a Dockerfile for an example.
https://github.com/customink/lamby-cookiecutter/blob/master/{{cookiecutter.project_name}}/Dockerfile

Hey @hopewise, hope you are doing well. Did you get thru this issue alright?

authors: hopewise metaskills

repo: rails-lambda/lamby


text:
Error message: 'github' is undefined

I executed the following command listed in the Quick Start guide:
docker run \
  --rm \
  --interactive \
  --volume "${PWD}:/var/task" \
  ghcr.io/rails-lambda/lamby-cookiecutter \
  "gh:rails-lambda/lamby-cookiecutter"

As a result, the following error was displayed:
project_name [my_awesome_lambda]: foo
Unable to create file '.github/workflows/ci.yml'
Error message: 'github' is undefined
Context: {
    "cookiecutter": {
        "_output_dir": "/var/task",
        "_template": "gh:rails-lambda/lamby-cookiecutter",
        "project_name": "foo"
    }
}

I'm using Windows 11.

Usually things are ment to work on Linux or Mac. This code works on both of those.
Are you able to clone and push to other repos? I haven’t used windows in over 10 years so I won’t be able to help you debug this unfortunately.
I can guarantee that it works on both Linux and Mac however.

I have the same issue on MacOS 13.4.

Can you update to a more recent version of Mac and try?
Also this command is just pulling a docker image nothing to do with the functionality of Lamby. This  issue should probably be in the cookie cutter repo but you can really expect to have the command to pull g the cookie cutter repo for every version of Mac and Linux.

For sanity’s sake I’ll pull the repo again when I get home in a couple hours just to make sure nothing has changed since last time I pulled the repo down ( a month or so ago)

Sorry @es-ki  and  @zvkemp  seems like this is an issue no idea why/when this happened. Ill work on fixing it.

https://github.com/rails-lambda/lamby-cookiecutter/issues/48

@jeremiahlukus
Thank you!
It worked!

authors: es-ki jeremiahlukus zvkemp


text:
directory action does not copy dotfiles

This statement:
directory('common/gem_scaffold', dest_dir, force: true, mode: :preserve)

... recursively copies all the following files and directories, except those with names that start with a period:
$ ls -alF templates/common/gem_scaffold/
total 20
-rw-r--r-- 1 mslinn mslinn 2045 Nov  5 09:54 %gem_name%.gemspec.tt
drwxr-xr-x 1 mslinn mslinn 4096 Nov  5 11:52 ./
drwxr-xr-x 1 mslinn mslinn 4096 Nov  5 11:52 ../
drwxr-xr-x 1 mslinn mslinn 4096 Jun  7 08:14 .bundle/
-rw-r--r-- 1 mslinn mslinn  411 Jul 10 10:10 .gitignore.tt
-rw-r--r-- 1 mslinn mslinn  128 Nov  5 09:53 .markdownlint.json
-rw-r--r-- 1 mslinn mslinn   69 Jun  8 11:10 .rspec
-rw-r--r-- 1 mslinn mslinn 1258 Jun 24 21:07 .rubocop.yml.tt
-rw-r--r-- 1 mslinn mslinn   75 Nov  5 06:53 .shellcheckrc
drwxr-xr-x 1 mslinn mslinn 4096 Jul  8 10:37 .vscode/
-rw-r--r-- 1 mslinn mslinn   43 Nov  5 09:51 CHANGELOG.md.tt
-rw-r--r-- 1 mslinn mslinn 1354 Nov  5 06:55 Gemfile.tt
-rw-r--r-- 1 mslinn mslinn 1405 Jul 29 14:01 README.md.tt
-rw-r--r-- 1 mslinn mslinn 1300 Jun 24 20:57 Rakefile.tt
drwxr-xr-x 1 mslinn mslinn 4096 Nov  5 07:01 bin/
drwxr-xr-x 1 mslinn mslinn 4096 Jun  7 08:14 lib/
drwxr-xr-x 1 mslinn mslinn 4096 Jul 10 10:10 test/

Suggestions for a workaround?

I was wrong, this does not happen

repo: rails/thor


text:
update Google Cloud API client import paths and more

The Google Cloud API client libraries for Go are making some breaking changes:

The import paths are changing from google.golang.org/cloud/... to
cloud.google.com/go/.... For example, if your code imports the BigQuery client
it currently reads
import "google.golang.org/cloud/bigquery"
It should be changed to
import "cloud.google.com/go/bigquery"
Client options are also moving, from google.golang.org/cloud to
google.golang.org/api/option. Two have also been renamed:

WithBaseGRPC is now WithGRPCConn
WithBaseHTTP is now WithHTTPClient

The cloud.WithContext and cloud.NewContext methods are gone, as are the
deprecated pubsub and container functions that required them. Use the Client
methods of these packages instead.

You should make these changes before September 12, 2016, when the packages at
google.golang.org/cloud will go away.

Forgot to close this (thanks for the direct issue headsup btw). Fixed in commit ad7730359144a31c3b6c824bcb6ef1f8d55fa8fd the /bigquery/ looks like it still uses the older API but that app is current deprecated pending a larger refactor.

authors: jba robtuley


text:
(118/phoenix) find: '/mnt/stateful_partition/murkmod/plugins': No such file or directory

find: '/mnt/stateful_partition/murkmod/plugins': No such file or directory is the error I get when I try to install a plugin and the helper says mush is not ready yet (118/grunt treeya/wp disabled/installed with dev mode VT2 command)

Are you on the latest version of murkmod? Have you tried running an update to create the folder for you? Also attach console output from the helper if you're having issues with it.

The cb I had that had murkmod broke but whenever im able to install murkmod on this one I will try, thanks

repo: rainestorme/murkmod


text:
Update cs_CZ locale - add groups, remove locations

Update cs_CZ locale - add groups, remove locations

Thanks!

authors: daftspunk vojtasvoboda

repo: rainlab/user-plugin

license: mit

license_source: bigquery


text:
Flow launcher crash after pressing enter on a clipboard item

Here is the Error:
Flow Launcher version: 1.15.0
OS Version: 22621.2134
IntPtr Length: 8
x64: True
Python Path: C:\Users\Fantasy\scoop\apps\python\current\python.exe
Node Path: C:\Users\Fantasy\AppData\Roaming\FlowLauncher\Environments\Node.js\Node-v16.18.0\node-v16.18.0-win-x64\node.exe
Date: 08/28/2023 03:25:45
Exception:
System.MissingMethodException: Method not found: 'Boolean Flow.Launcher.Plugin.IPublicAPI.IsMainWindowVisible()'.
at ClipboardR.ClipboardR.<>c__DisplayClass23_0.<b__2>d.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
at ClipboardR.ClipboardR.<>c__DisplayClass23_0.b__2(ActionContext )
at Flow.Launcher.Plugin.Result.ExecuteAsync(ActionContext context) in //Flow.Launcher.Plugin/Result.cs:line 219
at Flow.Launcher.ViewModel.MainViewModel.OpenResultAsync(String index) in C:\projects\flow-launcher\Flow.Launcher\ViewModel\MainViewModel.cs:line 277
at CommunityToolkit.Mvvm.Input.AsyncRelayCommand.AwaitAndThrowIfFailed(Task executionTask)
at System.Threading.Tasks.Task.<>c.b__128_0(Object state)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

FYI latest version of Flow is v1.16.1

@Fantasy-programming As deefrawley mentioned, the new API Flow.Launcher.Plugin.IPublicAPI.IsMainWindowVisible() used by latest ClipboardR is added in Flow.Launcher v1.16.0, so please update your Flow to v1.16.0 or newer, if it still crash please attach new logs.

It fixed the problem, thanks for reaching out

authors: Fantasy-programming deefrawley rainyl


text:
[Snyk] Upgrade ace-builds from 1.32.4 to 1.36.3

Snyk has created this PR to upgrade ace-builds from 1.32.4 to 1.36.3.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 22 versions ahead of your current version.

The recommended version was released on a month ago.

Release notes

Package name: ace-builds

1.36.3 - 2024-10-21package 21.10.24

1.36.2 - 2024-08-30package 30.08.24

1.36.1 - 2024-08-29package 29.08.24

1.36.0 - 2024-08-21package 21.08.24

1.35.5 - 2024-08-20package 20.08.24

1.35.4 - 2024-07-22package 22.07.24

1.35.3 - 2024-07-18package 18.07.24

1.35.2 - 2024-07-01package 01.07.24

1.35.1 - 2024-06-27package 27.06.24

1.35.0 - 2024-06-11package 11.06.24

1.34.2 - 2024-05-27

1.34.1 - 2024-05-24

1.34.0 - 2024-05-22

1.33.3 - 2024-05-21

1.33.2 - 2024-05-13

1.33.1 - 2024-04-23

1.33.0 - 2024-04-12

1.32.9 - 2024-03-29

1.32.8 - 2024-03-22

1.32.7 - 2024-03-01

1.32.6 - 2024-02-07

1.32.5 - 2024-01-30

1.32.4 - 2024-01-29

    from ace-builds GitHub release notes

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Updated to 1.36.5 in another commit, must run 'npm install' and run tests to upgrade

repo: rajkowski/cms-platform


text:
cannot install Pod::To::Man on raku version v2023.11

I get the following when I  try to use zef to install Pod::To::Man
zef install Pod::To::Man
===> Searching for: Pod::To::Man
===> Staging Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Staging [OK] for Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Testing: Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
[Pod::To::Man] ===SORRY!=== Error while compiling /tmp/.zef/1701996944.801517/d6657e1f81e282a10e3b1537cdacc243dcca7212.tar.g
[Pod::To::Man] z/Pod-To-Man-0.2.0/t/01-basic.rakutest
[Pod::To::Man] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec (CompUnit::Repository...)
[Pod::To::Man] at /tmp/.zef/1701996944.801517/d6657e1f81e282a10e3b1537cdacc243dcca7212.tar.gz/Pod-To-Man
[Pod::To::Man] -0.2.0/t/01-basic.rakutest:1
===> Testing [FAIL]: Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
Aborting due to test failure: Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules> (use --force-test to override)

can you please look into it

 ✗ zef install Pod::To::Man
===> Searching for: Pod::To::Man
===> Staging Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Staging [OK] for Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Testing: Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Testing [OK] for Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
===> Installing: Pod::To::Man:ver<0.2.0>:auth<zef:raku-community-modules>
✗ raku --version
Welcome to Rakudo™ v2024.05.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.05.

Can you verify if still an issue, and if so, please report out OS and zef version

authors: coke grizzlysmit

repo: raku-community-modules/Pod-To-Man


text:
Upgrading from 0.7.9 to 0.11.1

I'm in the process of upgrading my app from Angular 10 to 11.  While 0.7.9 seems to work just fine with Angular 11, I'd like to upgrade this package as well.  However, when I run npm install ng-mat-carousel@0.11.1 I get the following error:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: xxxxx@0.0.0
npm ERR! Found: @angular/common@11.2.11
npm ERR! node_modules/@angular/common
npm ERR!   @angular/common@"^11.2.11" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/common@"~10.0.4" from ng-mat-carousel@0.11.1
npm ERR! node_modules/ng-mat-carousel
npm ERR!   ng-mat-carousel@"0.11.1" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/xxxxx/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/xxxx/.npm/_logs/2021-04-23T16_44_01_703Z-debug.log

I can't for the life of me figure out where @angular/common@"~10.0.4 is coming from.  My package.json has "@angular/common": "^11.2.11". This project has "@angular/common": "^11.0.2".  Any thoughts on where this could be coming from?

Hi @jeffproe,
I'm facing the same issue with ng-mat-carousel in Angular 16. Encountering a similar dependency conflict as described:
Angular version: 16.2.12
ng-mat-carousel version: 0.11.1
Error:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: xxxxx@0.0.0
npm ERR! Found: @angular/common@16.2.12
npm ERR! node_modules/@angular/common
npm ERR!   @angular/common@"^16.2.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/common@"~10.0.4" from ng-mat-carousel@0.11.1
npm ERR! node_modules/ng-mat-carousel
npm ERR!   ng-mat-carousel@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Did you find any workaround or solution for this? Any help would be greatly appreciated.
Thanks!

authors: Fbossio jeffproe

repo: ralftar/ng-mat-carousel


text:
Can not discover Vizio TV

Hello -
Attempting to deploy on a Windows Server box that has Python installed and running.
When running the discover command
pyvizio --ip=0 discover Nothing is returned.....
I can ping the tv as shown below in the screen grab, any suggestions?

Thanks.
Squid

Hi @KidSquid1 this is likely because mDNS is blocked on your LAN. Is there something in particular you are trying to achieve with discovery given that you already know the IP of the TV?
I just pushed a change that falls back to SSDP if mDNS discovery fails: https://github.com/vkorn/pyvizio/pull/122

I had a similar problem. The first thing I did was run this command:
avahi-browser -all
You should see the device show up. For instance with device_type=tv you should see viziocast entry.  What I found out is that I had my tv on eco mode for the device. You have to set up as quick start. If you don't, the device won't respond.


text:
enabling R.scan to be used as transducer.

It fixes #2816

:herb:
I'm happy with this (as much as I am with anything extending our transducers.)
Anyone else?  @ramda/core?

Cool, @CrossEye !
After self-reviewing my PR I'm going to remove ['scan'] in dispatchable because I think it's out of the scope of this PR.

As with many things around this time, this PR was inadvertently dropped.  This makes sense, and I wonder, @xgbuils, if you want to resolve the conflicts so that we can merge?

No problem. My pleasure. I have to review documentation about transducers again (I had to review my PR accurately to understand what I did 2 years ago). I think that there are another functions that works with lists that can be adapted to work with transducers and I could review it in the future.

Hmm, just coming back to this to see there are conflicts.  Going to bed now, but I hope to look at these soon.

authors: CrossEye xgbuils

repo: ramda/ramda


text:
uncurryN

closes #970

we good here?

:herb:

authors: CrossEye buzzdecafe


text:
Update README.md

first repo

first repo

repo: ramendosanjh/prework-study-guide


text:
nullable strings are set to empty string when null

with the postgres driver I can define *string as type in the structure and get a null-pointer,
if the data is null in the database
with the oracle-driver I get an empty string
but for int and float types I get a null pointer if I define *int or *float64 in the structure
is there a way to change this behavior for null values in varchar2 columns ?

As Oracle DB does not differentiate '' and NULL, we have to decide how to treat the empty string: as an empty string or a NULL. As nil may need a check, returning an empty string seemed forgivable.

authors: tgulacsi volkmarbuehringer

repo: rana/ora


text:
Enhance cloud-init syntax support

Is your feature request related to a problem? Please describe.
Currently we partially support cloud-init syntax, but it is limited to a small subset of the features.
Describe the solution you'd like
To extend the syntax already supported to include:

growpart (which can be provided by the Layout plugin)
uid and  lock_passwd into the users fields

Additional context
So lima can load cOS images cc @ibuildthecloud
#cloud-config
# vim:syntax=yaml

growpart:
  mode: auto
  devices: ['/']

users:
  - name: "darren"
    uid: "1000"
    homedir: "/home/darren.linux"
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock_passwd: true
    ssh-authorized-keys:
    - ...

write_files:
 - content: |
      #!/bin/sh
      set -eux
      LIMA_CIDATA_MNT="/mnt/lima-cidata"
      LIMA_CIDATA_DEV="/dev/disk/by-label/cidata"
      mkdir -p -m 700 "${LIMA_CIDATA_MNT}"
      mount -o ro,mode=0700,dmode=0700,overriderockperm,exec,uid=0 "${LIMA_CIDATA_DEV}" "${LIMA_CIDATA_MNT}"
      export LIMA_CIDATA_MNT
      exec "${LIMA_CIDATA_MNT}"/boot.sh
   owner: root:root
   path: /var/lib/cloud/scripts/per-boot/00-lima.boot.sh
   permissions: '0755'

there was a request for locked_passwd as well on the user fields

there was a request for locked_passwd as well on the user fields

completely missed it! updated the card, thanks!

growpart:
  mode: auto
  devices: ['/']

is a bit unclear to me. In our case / is mounted over an image, so growing partition might have a different meaning, my expectations here is to have COS_PERSISTENT to be enlarged instead of the image file

Support for uid and lockpasswd introduced here: https://github.com/mudler/yip/commit/d5345d29f2c60e7fd4196beb56626804c1048ae3

https://github.com/mudler/yip/releases/tag/0.9.12 has been released and supports also adds growpart support, although if the intention is to grow COS_PERSISTENT should point to /usr/local or at the respective label

authors: Itxaka mudler

repo: rancher-sandbox/cOS-toolkit


text:
Consider using ghw for disks and host information

Just a spare idea , maybe we can replace the udevadm/partprobe calls with something native like https://github.com/jaypipes/ghw#block-storage
cc @davidcassany

Just a spare idea , maybe we can replace the udevadm/partprobe calls with something native like https://github.com/jaypipes/ghw#block-storage
cc @davidcassany

Fine with me, as long as it works. I'd suggest to start with the current implementation and move to something native if possible. The challenging part is reacting to partition table changes, udevadm turned to be a good option to wait until the kernel reports new devices.

I am thinking about if it would make sense to use it to validate partitions when using the --no-format installer option. Gonna check if this is an straight forward exercise, if so it can be a good place to start trying this library. Removing udevadm from partitioner is scary as race conditions like what harvester reported a month ago could pop up again and they were not really popping up consistently in our tests. I'd love to drop partprobe and udevadm, but I am just wondering how to do it in safe way so we do not have to turn back to them again 😅 We need to find some playground to experiment with alternatives.

ghw doesnt seem to be wht we need. It only reads partitions that are mounted, so we cannot use it to find unmounted partitions.

I've used it like so to list all available disks:
	disks := []string{}
	block, err := ghw.Block()
	if err == nil {
		for _, disk := range block.Disks {
			disks = append(disks, fmt.Sprintf("/dev/%s", disk.Name))
		}
	}

each Disk has  Partitions , but I didn't used it so can't tell if it does what we need

it reads from the /proc/mounts to get the info on partitions, https://github.com/jaypipes/ghw/blob/main/pkg/block/block_linux.go#L388 so it wont work for our use case. Which I understand, its the simplest and more straightforward way of getting info on partitions, and the point of the lib is to get info that is available now, not what it could do in the future, so it makes sense they only report that.

it reads from the /proc/mounts to get the info on partitions, https://github.com/jaypipes/ghw/blob/main/pkg/block/block_linux.go#L388 so it wont work for our use case. Which I understand, its the simplest and more straightforward way of getting info on partitions, and the point of the lib is to get info that is available now, not what it could do in the future, so it makes sense they only report that.

but that's just used to read the mountpoint if present, no? https://github.com/jaypipes/ghw/blob/fb0598ce62c8057b6aa65122066c93c2042e5ab3/pkg/block/block_linux.go#L197

And partition type. IIRC ok upgrade we need the partition type of existing FS...not sure why. Maybe we don't need it and can ignore it. Anyway, I tested the lib on my local system and it reported 0 partitions so not sure...

Umm, on upgrade seems like the existing partitions FS is used to mount it but we may get away by just using "auto" .... gonna have a quick look...

umm, layout plugin seems to need that partition FS to expand. I wonder if we could do something in there to avoid that somehow, maybe read it from /proc/partitions directly just for that one case

unfortunately it seems that ghw does not fill the LABEL field for partitions. In fact there is no code in there to do anything with the LABEL so its always empty :/

I sent a patch upstream to get the label info from the udev database: https://github.com/jaypipes/ghw/pull/304

sent another to get the partition fs from unmounted partitions https://github.com/jaypipes/ghw/pull/305
Looks like its already got eyes on it, so this might be feasible to do.

uh...Im gonna guess this is done :D

authors: Itxaka davidcassany mudler

repo: rancher-sandbox/elemental


text:
Apps - rancher-logging app can't be accessed after installation

Rancher version: v2.5-alpha1 (08/28/2020)
The app gets installed but after the app gets listed in the menu, clicking on it gets the user to a different app install.

Rancher version: master-head (08/31/2020) 8d9cedde9
Working on latest master

repo: rancher/dashboard


text:
Changing upstream cluster's name succeeds, but returns error

Setup

Rancher version: 2.6.2
Browser type & version: Google Chrome 89.0.4389.90 (Official Build) (64-bit)

Describe the bug
When modifying or just saving the Rancher cluster configuration, a missing role owner error is displayed.
To Reproduce
Rancher GUI -> Cluster Management -> <rancher_cluster> -> Edit Config -> (make a change or just Save)
Result
Error message:
"There must be at least one member with the Owner role."
Expected Result
No error message.
Screenshots

Additional context

Detailed Description
Should there be an owner (admin user) assigned by default?
Context
It would be better off without an error message.

SUSE Rancher v2.6.3-rc1 has the same behavior.

Edit YAML gives error message, too:

Edit Config saves the changes.
Edit YAML does not save the changes.

There's a bit of a miss-match here

Screenshot one shows the embedded cluster management edit cluster page for what i think an imported cluster
Screenshot two shows the edit yaml page, which we don't provide for imported clusters (maybe we did a year ago)

I've tried to reproduce this and the following works fine

Editing an RKE1 cluster via the embedded cluster management edit cluster page
Editing an imported k3s cluster via the embedded cluster management edit cluster page
Editing an RKE2 cluster via the edit yaml page

@peteingithub Can you provide some additional information regarding steps to reproduce (including cluster type) and if it's still an issue in the latest version of rancher?

Richard,
It is a Rancher cluster. Trying to rename ’local’ to something else.
Richard Cox @.***> kirjoitti 9.11.2022 kello 18.10:

There's a bit of a miss-match here

Screenshot one shows the embedded cluster management edit cluster page for what i think an imported cluster
Screenshot two shows the edit yaml page, which we don't provide for imported clusters (maybe we did a year ago)

I've tried to reproduce this and the following works fine

Editing an RKE1 cluster via the embedded cluster management edit cluster page
Editing an imported k3s cluster via the embedded cluster management edit cluster page
Editing an RKE2 cluster via the edit yaml page

@peteingithubhttps://github.com/peteingithub Can you provide some additional information regarding steps to reproduce (including cluster type) and if it's still an issue in the latest version of rancher?
—
Reply to this email directly, view it on GitHubhttps://github.com/rancher/dashboard/issues/4457#issuecomment-1308995151, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCJ5GGZDKNBUQMTOLWVLWHPEIVANCNFSM5G2BNECA.
You are receiving this because you were mentioned.Message ID: @.***>

Actually rename works, but there is the error message.
Richard Cox @.***> kirjoitti 9.11.2022 kello 18.10:

There's a bit of a miss-match here

Screenshot one shows the embedded cluster management edit cluster page for what i think an imported cluster
Screenshot two shows the edit yaml page, which we don't provide for imported clusters (maybe we did a year ago)

I've tried to reproduce this and the following works fine

Editing an RKE1 cluster via the embedded cluster management edit cluster page
Editing an imported k3s cluster via the embedded cluster management edit cluster page
Editing an RKE2 cluster via the edit yaml page

@peteingithubhttps://github.com/peteingithub Can you provide some additional information regarding steps to reproduce (including cluster type) and if it's still an issue in the latest version of rancher?
—
Reply to this email directly, view it on GitHubhttps://github.com/rancher/dashboard/issues/4457#issuecomment-1308995151, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCJ5GGZDKNBUQMTOLWVLWHPEIVANCNFSM5G2BNECA.
You are receiving this because you were mentioned.Message ID: @.***>

So these are issues after renaming from local? Was the cluster brought up with a different name to start with (https://rancher.com/docs/rke/latest/en/config-options/#cluster-name)?

For me it has always been a ”normal” helm deployment of Rancher, and from 2.6.0 and later  it was not possible to change the default name ’local’ to anything else without the error message, unless manually adding a member.
Still the change takes place, but I’d like to get rid of the error.
Richard Cox @.***> kirjoitti 9.11.2022 kello 19.58:

So these are issues after renaming from local? Was the cluster brought up with a different name to start with (https://rancher.com/docs/rke/latest/en/config-options/#cluster-name)?
—
Reply to this email directly, view it on GitHubhttps://github.com/rancher/dashboard/issues/4457#issuecomment-1309138478, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCJ2CSA43JVCGSPBEDWTWHPQ4LANCNFSM5G2BNECA.
You are receiving this because you were mentioned.Message ID: @.***>

2.7.0-rc9 has the same.
Rancher cluster -> Cluster Management -> Three Dots -> Edit Config ->  -> Save
The name gets changed, but there's error messages.
[cid:8fa74645-f2d5-4f6a-b92f-6e2407981af9]
[cid:32a36d26-c72b-487d-b3ff-ecd9c39b4fbb]
Pete

From: Richard Cox @.>
Sent: Wednesday, November 9, 2022 7:58 PM
To: rancher/dashboard @.>
Cc: Pete Hakkarainen @.>; Mention @.>
Subject: Re: [rancher/dashboard] No Owner for the Rancher cluster Member Roles (Issue #4457)
So these are issues after renaming from local? Was the cluster brought up with a different name to start with (https://rancher.com/docs/rke/latest/en/config-options/#cluster-name)?
—
Reply to this email directly, view it on GitHubhttps://github.com/rancher/dashboard/issues/4457#issuecomment-1309138478, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCJ2CSA43JVCGSPBEDWTWHPQ4LANCNFSM5G2BNECA.
You are receiving this because you were mentioned.Message ID: @.***>

Thanks @peteingithub , think we've got enough to go on now

Awesome! NP.
Pete

From: Richard Cox @.>
Sent: Thursday, November 10, 2022 11:48 AM
To: rancher/dashboard @.>
Cc: Pete Hakkarainen @.>; Mention @.>
Subject: Re: [rancher/dashboard] Changing upstream cluster's name succeeds, but returns error (Issue #4457)
Thanks @peteingithubhttps://github.com/peteingithub , think we've got enough to go on now
—
Reply to this email directly, view it on GitHubhttps://github.com/rancher/dashboard/issues/4457#issuecomment-1310024872, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUWPCJ4YBX52WHVIXKFFM23WHTAFJANCNFSM5G2BNECA.
You are receiving this because you were mentioned.Message ID: @.***>

There's some more detail over at https://github.com/rancher/dashboard/issues/7419

authors: peteingithub richard-cox


text:
Use correct container registry for latest 2.9 head builds

Summary
User correct container registry for latest 2.9 head builds
Occurred changes and/or fixed issues

without this it doesn't look like rancher serves up the correct CNi charts related to the version of kube (1.28 and below are fine, 1.29 and above will fail to fetch charts)

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

Note - this is blocked on eio 2933

https://github.com/rancher/dashboard/pull/12937 should be after this merges


text:
Send full system data on registration

This uses the ghw library to send the full system data during the registration.
This sends, Net, Block, CPU, memory, chassis, etc... data in a nicely structured block which makes it easy to use for the inventory.
This could potentially substitute the smbios data as it overlaps nicely with the same data that smbios provides, and would help us in not having to fully parse the smbios data ourselves like we do.
Signed-off-by: Itxaka igarcia@suse.com

This is an example of the data provided from a qemu instance:
&hostinfo.HostInfo{
  Memory: &memory.Info{
    Area: memory.Area{
      TotalPhysicalBytes: 12616466432,
      TotalUsableBytes: 12226326528,
      SupportedPageSizes: []uint64{
        1073741824,
        2097152,
      },
      Modules: nil,
    },
  },
  Block: &block.Info{
    TotalPhysicalBytes: 43623579648,
    Disks: []*block.Disk{
      &block.Disk{
        Name: "sr0",
        SizeBytes: 673906688,
        PhysicalBlockSizeBytes: 2048,
        DriveType: 3,
        IsRemovable: true,
        StorageController: 2,
        BusPath: "pci-0000:00:1f.2-ata-1.0",
        NUMANodeID: 0,
        Vendor: "QEMU",
        Model: "QEMU_DVD-ROM",
        SerialNumber: "QM00001",
        WWN: "unknown",
        Partitions: []*block.Partition{},
      },
      &block.Disk{ // p0
        Name: "vda",
        SizeBytes: 42949672960,
        PhysicalBlockSizeBytes: 512,
        DriveType: 1,
        IsRemovable: false,
        StorageController: 4,
        BusPath: "pci-0000:04:00.0",
        NUMANodeID: 0,
        Vendor: "0x1af4",
        Model: "unknown",
        SerialNumber: "unknown",
        WWN: "unknown",
        Partitions: []*block.Partition{
          &block.Partition{
            Disk: p0,
            Name: "vda1",
            Label: "COS_GRUB",
            MountPoint: "",
            SizeBytes: 67108864,
            Type: "vfat",
            IsReadOnly: true,
            UUID: "16c4870a-52b8-4802-856b-5adadefef89f",
          },
          &block.Partition{
            Disk: p0,
            Name: "vda2",
            Label: "COS_OEM",
            MountPoint: "",
            SizeBytes: 67108864,
            Type: "ext4",
            IsReadOnly: true,
            UUID: "7bac8569-74cd-4b5a-a963-cd14af3fbaed",
          },
          &block.Partition{
            Disk: p0,
            Name: "vda3",
            Label: "COS_RECOVERY",
            MountPoint: "",
            SizeBytes: 8589934592,
            Type: "ext4",
            IsReadOnly: true,
            UUID: "81b08ac1-2893-406e-aa54-d0dce8e0711d",
          },
          &block.Partition{
            Disk: p0,
            Name: "vda4",
            Label: "COS_STATE",
            MountPoint: "",
            SizeBytes: 16106127360,
            Type: "ext4",
            IsReadOnly: true,
            UUID: "0ee3e931-098c-40ab-a9cf-1b12594745fb",
          },
          &block.Partition{
            Disk: p0,
            Name: "vda5",
            Label: "COS_PERSISTENT",
            MountPoint: "",
            SizeBytes: 18117296128,
            Type: "ext4",
            IsReadOnly: true,
            UUID: "adcf76a9-dce8-42b5-9a4f-f46751c86bb7",
          },
        },
      },
    },
    Partitions: nil,
  },
  CPU: &cpu.Info{
    TotalCores: 2,
    TotalThreads: 2,
    Processors: []*cpu.Processor{
      &cpu.Processor{
        ID: 0,
        NumCores: 1,
        NumThreads: 1,
        Vendor: "GenuineIntel",
        Model: "Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz",
        Capabilities: []string{
          "fpu",
          "vme",
          "de",
          "pse",
          "tsc",
          "msr",
          "pae",
          "mce",
          "cx8",
          "apic",
          "sep",
          "mtrr",
          "pge",
          "mca",
          "cmov",
          "pat",
          "pse36",
          "clflush",
          "mmx",
          "fxsr",
          "sse",
          "sse2",
          "ss",
          "syscall",
          "nx",
          "pdpe1gb",
          "rdtscp",
          "lm",
          "constant_tsc",
          "arch_perfmon",
          "rep_good",
          "nopl",
          "xtopology",
          "cpuid",
          "tsc_known_freq",
          "pni",
          "pclmulqdq",
          "vmx",
          "ssse3",
          "fma",
          "cx16",
          "pdcm",
          "pcid",
          "sse4_1",
          "sse4_2",
          "x2apic",
          "movbe",
          "popcnt",
          "tsc_deadline_timer",
          "aes",
          "xsave",
          "avx",
          "f16c",
          "rdrand",
          "hypervisor",
          "lahf_lm",
          "abm",
          "3dnowprefetch",
          "cpuid_fault",
          "invpcid_single",
          "pti",
          "ssbd",
          "ibrs",
          "ibpb",
          "stibp",
          "tpr_shadow",
          "vnmi",
          "flexpriority",
          "ept",
          "vpid",
          "ept_ad",
          "fsgsbase",
          "tsc_adjust",
          "bmi1",
          "avx2",
          "smep",
          "bmi2",
          "erms",
          "invpcid",
          "mpx",
          "rdseed",
          "adx",
          "smap",
          "clflushopt",
          "xsaveopt",
          "xsavec",
          "xgetbv1",
          "xsaves",
          "arat",
          "umip",
          "md_clear",
          "arch_capabilities",
        },
        Cores: []*cpu.ProcessorCore{
          &cpu.ProcessorCore{
            ID: 0,
            Index: 0,
            NumThreads: 1,
            LogicalProcessors: []int{
              0,
            },
          },
        },
      },
      &cpu.Processor{
        ID: 1,
        NumCores: 1,
        NumThreads: 1,
        Vendor: "GenuineIntel",
        Model: "Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz",
        Capabilities: []string{
          "fpu",
          "vme",
          "de",
          "pse",
          "tsc",
          "msr",
          "pae",
          "mce",
          "cx8",
          "apic",
          "sep",
          "mtrr",
          "pge",
          "mca",
          "cmov",
          "pat",
          "pse36",
          "clflush",
          "mmx",
          "fxsr",
          "sse",
          "sse2",
          "ss",
          "syscall",
          "nx",
          "pdpe1gb",
          "rdtscp",
          "lm",
          "constant_tsc",
          "arch_perfmon",
          "rep_good",
          "nopl",
          "xtopology",
          "cpuid",
          "tsc_known_freq",
          "pni",
          "pclmulqdq",
          "vmx",
          "ssse3",
          "fma",
          "cx16",
          "pdcm",
          "pcid",
          "sse4_1",
          "sse4_2",
          "x2apic",
          "movbe",
          "popcnt",
          "tsc_deadline_timer",
          "aes",
          "xsave",
          "avx",
          "f16c",
          "rdrand",
          "hypervisor",
          "lahf_lm",
          "abm",
          "3dnowprefetch",
          "cpuid_fault",
          "invpcid_single",
          "pti",
          "ssbd",
          "ibrs",
          "ibpb",
          "stibp",
          "tpr_shadow",
          "vnmi",
          "flexpriority",
          "ept",
          "vpid",
          "ept_ad",
          "fsgsbase",
          "tsc_adjust",
          "bmi1",
          "avx2",
          "smep",
          "bmi2",
          "erms",
          "invpcid",
          "mpx",
          "rdseed",
          "adx",
          "smap",
          "clflushopt",
          "xsaveopt",
          "xsavec",
          "xgetbv1",
          "xsaves",
          "arat",
          "umip",
          "md_clear",
          "arch_capabilities",
        },
        Cores: []*cpu.ProcessorCore{
          &cpu.ProcessorCore{
            ID: 0,
            Index: 0,
            NumThreads: 1,
            LogicalProcessors: []int{
              1,
            },
          },
        },
      },
    },
  },
  Topology: &topology.Info{
    Architecture: 0,
    Nodes: []*topology.Node{
      &topology.Node{
        ID: 0,
        Cores: []*cpu.ProcessorCore{
          &cpu.ProcessorCore{
            ID: 0,
            Index: 0,
            NumThreads: 2,
            LogicalProcessors: []int{
              0,
              1,
            },
          },
        },
        Caches: []*memory.Cache{
          &memory.Cache{
            Level: 1,
            Type: 1,
            SizeBytes: 32768,
            LogicalProcessors: []uint32{
              0,
            },
          },
          &memory.Cache{
            Level: 1,
            Type: 1,
            SizeBytes: 32768,
            LogicalProcessors: []uint32{
              1,
            },
          },
          &memory.Cache{
            Level: 1,
            Type: 2,
            SizeBytes: 32768,
            LogicalProcessors: []uint32{
              0,
            },
          },
          &memory.Cache{
            Level: 1,
            Type: 2,
            SizeBytes: 32768,
            LogicalProcessors: []uint32{
              1,
            },
          },
          &memory.Cache{
            Level: 2,
            Type: 0,
            SizeBytes: 4194304,
            LogicalProcessors: []uint32{
              0,
            },
          },
          &memory.Cache{
            Level: 2,
            Type: 0,
            SizeBytes: 4194304,
            LogicalProcessors: []uint32{
              1,
            },
          },
          &memory.Cache{
            Level: 3,
            Type: 0,
            SizeBytes: 16777216,
            LogicalProcessors: []uint32{
              0,
            },
          },
          &memory.Cache{
            Level: 3,
            Type: 0,
            SizeBytes: 16777216,
            LogicalProcessors: []uint32{
              1,
            },
          },
        },
        Distances: []int{
          10,
        },
        Memory: &memory.Area{
          TotalPhysicalBytes: 12616466432,
          TotalUsableBytes: 12226322432,
          SupportedPageSizes: []uint64{
            1073741824,
            2097152,
          },
          Modules: nil,
        },
      },
    },
  },
  Network: &net.Info{
    NICs: []*net.NIC{
      &net.NIC{
        Name: "eth0",
        MacAddress: "52:54:00:e7:48:ac",
        IsVirtual: false,
        Capabilities: []*net.NICCapability{
          &net.NICCapability{
            Name: "rx-checksumming",
            IsEnabled: true,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-checksumming",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-checksum-ipv4",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-checksum-ip-generic",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-checksum-ipv6",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-checksum-fcoe-crc",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-checksum-sctp",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "scatter-gather",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-scatter-gather",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-scatter-gather-fraglist",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tcp-segmentation-offload",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-tcp-segmentation",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-tcp-ecn-segmentation",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-tcp-mangleid-segmentation",
            IsEnabled: false,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tx-tcp6-segmentation",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "generic-segmentation-offload",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "generic-receive-offload",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "large-receive-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-vlan-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-vlan-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "ntuple-filters",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "receive-hashing",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "highdma",
            IsEnabled: true,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-vlan-filter",
            IsEnabled: true,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "vlan-challenged",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-lockless",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "netns-local",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-gso-robust",
            IsEnabled: true,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-fcoe-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-gre-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-gre-csum-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-ipxip4-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-ipxip6-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-udp_tnl-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-udp_tnl-csum-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-gso-partial",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-tunnel-remcsum-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-sctp-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-esp-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-udp-segmentation",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-gso-list",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "fcoe-mtu",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-nocache-copy",
            IsEnabled: false,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "loopback",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-fcs",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-all",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tx-vlan-stag-hw-insert",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-vlan-stag-hw-parse",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-vlan-stag-filter",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "l2-fwd-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "hw-tc-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "esp-hw-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "esp-tx-csum-hw-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-udp_tunnel-port-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tls-hw-tx-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "tls-hw-rx-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-gro-hw",
            IsEnabled: true,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "tls-hw-record",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-gro-list",
            IsEnabled: false,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "macsec-hw-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "rx-udp-gro-forwarding",
            IsEnabled: false,
            CanEnable: true,
          },
          &net.NICCapability{
            Name: "hsr-tag-ins-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "hsr-tag-rm-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "hsr-fwd-offload",
            IsEnabled: false,
            CanEnable: false,
          },
          &net.NICCapability{
            Name: "hsr-dup-offload",
            IsEnabled: false,
            CanEnable: false,
          },
        },
        PCIAddress: nil,
      },
    },
  },
  GPU: &gpu.Info{
    GraphicsCards: []*gpu.GraphicsCard{
      &gpu.GraphicsCard{
        Address: "virtio0",
        Index: 0,
        DeviceInfo: nil,
        Node: nil,
      },
    },
  },
  Chassis: &chassis.Info{
    AssetTag: "",
    SerialNumber: "",
    Type: "1",
    TypeDescription: "Other",
    Vendor: "QEMU",
    Version: "pc-q35-7.1",
  },
  BIOS: &bios.Info{
    Vendor: "EFI Development Kit II / OVMF",
    Version: "0.0.0",
    Date: "02/06/2015",
  },
  Baseboard: &baseboard.Info{
    AssetTag: "unknown",
    SerialNumber: "unknown",
    Vendor: "unknown",
    Version: "unknown",
    Product: "unknown",
  },
  Product: &product.Info{
    Family: "",
    Name: "Standard PC (Q35 + ICH9, 2009)",
    Vendor: "QEMU",
    SerialNumber: "",
    UUID: "79cfdb39-bc36-41d6-a2b2-5726b6bca234",
    SKU: "",
    Version: "pc-q35-7.1",
  },
}

Of special interest IMO is the GPU stuff (You can identify the nodes with GPUs for GPU-related taks) and the NIC capabilities.

This doesnt use the data in any way for now, its only a POC to see if we would like this approach and how we can take advantage of the extra data.
Also to notice if there is something missing that we can contribute back to ghw that would help us here, for example I can see that memory is not reporting the modules...

Visualizing this in the UI will be the hard part ...

Visualizing this in the UI will be the hard part ...

I been wondering how to store this somehow.... Maybe a secret associated with the inventory could be created and the json data stored in there, so its available for the selector AND maybe the labels if we want. So its checked JIT when the selector kicks in?
There is always the possibility of adding a custom resource to save this data....and just have it as another item in the inventory controller, so no need to show it in the UI directly under inventories, it could have its own resource like Plans. But that would be too much IMO, the less resources created the better.
Going with the secret linked to this would be much nicer IMO, we could even start by just exposing this data to the label templating so you can select what data you want to store on nodes (i.e. not sure you need ALL this data, but maybe you want to store only the GPU name or the Network capabilities for example)
Still think its vary valuable data to expose, but not sure of its use, where to store it and so on. Something to discuss in the planning IMO, so we have a clear path for the future of the node data, but its clear we need to do something with it, as the use-cases are clear for more hardware data AND for more selector flexibility.

ros-operator put the whole (well, dmicode) tree into the machineInventory CRD ...

ros-operator put the whole (well, dmicode) tree into the machineInventory CRD ...

yes, and it was terrible and if you described the machineinventory from cli you will get a 2Mb yaml in your cli lol
Its about a better and nicer implementation of the same basic idea :)

I been wondering how to store this somehow.... Maybe a secret associated with the inventory could be created and the json data stored in there, so its available for the selector AND maybe the labels if we want. So its checked JIT when the selector kicks in?

I would consider a ConfigMap that we bind to the MachineInventory !

We should likely keep a way to optionally turn off the storage of the data. I could see it quickly becoming a scaling bottleneck for larger amounts of nodes due to etcd.

I know it's not a popular opinion but maybe an RDBMS would be more appropriate here than putting it all in the k8s api?

I know it's not a popular opinion but maybe an RDBMS would be more appropriate here than putting it all in the k8s api?

That would make us require an extra requirements to deploy. And not a small one, having a db around with all its issues (backup, managing it, permissions, etc...).
Yikes.
We would only need to store this if we expect the selector to be more flexible, i.e. allow selecting with hardware data. Plus we dont really need to store this if we dont have any selector plan. Only a POC to see what kind of data we can get from this, and maybe use it to create extra labels on the node with this data (Network, disks, memory, gpu, etc...?)
I think that the nodes we register should have as much data as possible to identify them, it would be nice to have that, so this is just a first step and a POC so we can discuss this.
I am agaisnt saving all this data anywhere, as it creates more issues that it resolves. HAving it a secret or a configmap its good until you have hundreds of them :/
IMHO the idea here should be to gather as much data as possible on the registration part, as that its basically free, and then decide what we wanna do with it. Labels its the way to go IMHO, but we could always also expand the inventory struct to contains a Hardware struct that includes the most valued data. But still....labels allows for a lot of flexibility across the sholw k8s standard. Search, selectors, etc.. are all compatible with labels out of the box...

That would make us require an extra requirements to deploy. And not a small one, having a db around with all its issues (backup, managing it, permissions, etc...).

Fair. But we just need to recognize the tradeoffs of just shoving anything and everything into the kubeapi/etcd.

IMHO the idea here should be to gather as much data as possible on the registration part, as that its basically free, and then decide what we wanna do with it

That makes sense to me. I wonder if shoving registration data into an event would be interesting. That would allow the admin to consume the data while not having to persistently store it.

$ kubectl describe machineinventory --all-namespaces
Name:         my-machine
Namespace:    fleet-default
Labels:       BlockDevice0-ControllerType=SCSI
              BlockDevice0-DriveType=ODD
              BlockDevice0-Name=sr0
              BlockDevice0-Removable=true
              BlockDevice0-Size=754712576
              BlockDevice1-ControllerType=virtio
              BlockDevice1-DriveType=HDD
              BlockDevice1-Name=vda
              BlockDevice1-Removable=false
              BlockDevice1-Size=32212254720
              BlockTotal=2
              CpuModel=Intel-R--Core-TM--i7-7700K-CPU---4-20GHz
              CpuTotalCores=7
              CpuTotalThreads=7
              CpuVendor=GenuineIntel
              NetIface0-Name=eth0
              NetIface0-Virtual=false
              NetNumberInterfaces=1
              TotalMemory=12616466432
              location=europe
              machineUUID=40227f83-f8c4-49b8-9899-16ba2878498a
              manufacturer=QEMU
              productName=Standard-PC-Q35-ICH9-2009
              serialNumber=Not-Specified
Annotations:  <none>
API Version:  elemental.cattle.io/v1beta1

on latest patch I added the prefix elemental-cattle.io/ to the labels to make sure they are tracked to us.

@fgiudici comments?

@fgiudici comments?

just one: wonderful!!

authors: Itxaka agracey fgiudici kkaempf

repo: rancher/elemental-operator


text:
Download SeedImage's checksum

SURE-8889
Part of https://github.com/rancher/elemental-operator/issues/823
SeedImage.status.checksumURL has been added (gate to elemental-operator >= v1.6.5 ) to provide a checksum of the built image artifact.
It does follow the same rule as downloadURL, so the SeedImage Ready condition has to be true for this field to be usable.
status:
  checksumURL: https://172.18.0.2.sslip.io/elemental/seedimage/wr9xntd96nj6c6rztcfcsfnbtgb7xpz47fxb9dhp4mkjj27cttmxkf/fire-nodes-2024-08-22T07:48:10Z.iso.sha256
  downloadURL: https://172.18.0.2.sslip.io/elemental/seedimage/wr9xntd96nj6c6rztcfcsfnbtgb7xpz47fxb9dhp4mkjj27cttmxkf/fire-nodes-2024-08-22T07:48:10Z.iso

The request is to be able to download this checksum from the UI as well, as it is for the image artifact.

@kwwii we are going to need UX help on this one

@kwwii any feedback in terms of UX?

repo: rancher/elemental-ui


text:
ci: use build-host for build process

This should speedup the build processes.
E2E verification runs:

latest one! https://github.com/rancher/elemental/actions/runs/2629307840
~with standard selfhosted runner conf: https://github.com/rancher/elemental/actions/runs/2529263149/attempts/1~
~with _work on tmpfs and tuned configured for performance: https://github.com/rancher/elemental/actions/runs/2529263149/attempts/2 (it seems that the I/O is degraded, but why?)~
~with tuned configured for performance: https://github.com/rancher/elemental/actions/runs/2529263149/attempts/3~

The build issue is due to the fact that all runs directly on the runner and not on an container image (Ubuntu in that case), on it to fix this.

I still have this error:
Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: End of file while reading data: Input/output error
Even after forcing the build step to use an Ubuntu image...
This PR was to reduce build time by using a self hosted runner but I really don't know how to workaround this error... So better to close it for now I think.

I finally found why tests is failing!
Here a working test:
==> os2: Creating image (snapshot of base box volume).
==> os2: Creating domain with the following settings...
==> os2:  -- Name:              tests_os2
==> os2:  -- Description:       Source: /home/runner/work/elemental/elemental/tests/Vagrantfile
==> os2:  -- Domain type:       qemu
==> os2:  -- Cpus:              4

And here the failing one:
==> os2: Creating image (snapshot of base box volume).
==> os2: Creating domain with the following settings...
==> os2:  -- Name:              tests_os2
==> os2:  -- Description:       Source: /home/runner/work/elemental/elemental/tests/Vagrantfile
==> os2:  -- Domain type:       kvm
==> os2:  -- Cpus:              4

The domain type is kvm when compiled on the self-hosted runner! I think this is because nested virtualization is on. I will try to see if this could be forced during building process.

Ok so I think I understand the process and why KVM accel is set: it's detected when ros-image-build is executed (see here).
Which lead me to ask: why is this so complicated??
I checked a bit and found that the GH workflow execute make ci which execute dapper ci which uses Dockerfile.dapper to generate and run a docker image that execute scripts/ci which itself execute scripts/package which itself execute make build and make iso (and also others make ... commands). This build command generates a docker image that is used in make iso and this command execute ros-image-build that generate docker image and the other artifacts (iso, qcow2, box, etc.) by also using some specific tools like packer (which is useful for some cases I agree).
But this is really difficult to understand TBH...

@mjura @ldevulder - what is this waiting for ?

@mjura @ldevulder - what is this waiting for ?

A verification run that works... I have issue and I'm currently doing manual tests to understand why (could be due to some renaming change). If I can fix in this PR I will do, otherwise I will merge this one and create new to fix.

authors: kkaempf ldevulder

repo: rancher/elemental


text:
1.0.0 image for Raspberry Pi is missing

A 1.0.0 image for Raspberry Pi is missing, the latest is 0.9.0. It seems also not to be possible to build it manually like described here: https://gist.github.com/rgaidot/bc2efc014cccabb926392e353708122a. Error message: "repository rancher/os-debianconsole-base not found: does not exist or no pull access".

@Novanic does https://github.com/rancher/os/releases/download/v1.0.0/rancheros-raspberry-pi.zip not work? (Sorry, I'm at DockerCon atm, so things are hectic)

Oh, it's available, thank you for the link. The link is missing within the release links of https://github.com/rancher/os, that's why I thought it is not available.

I've updated the README, so closing.

authors: Novanic SvenDowideit

repo: rancher/os


text:
Add --insecure-registry flag to daemon arguments

Inspired by https://forums.rancher.com/t/insecure-registry-in-rancheros-v0-7-0/4560.

Docs LGTM

@joshwget is the check failure due to a lack of validation updates?

@SvenDowideit No, just a CI issue. Should be fine now!

authors: SvenDowideit deniseschannon joshwget


text:
Checkboxes are missing for Namespaces but bulk actions still exist

Rancher versions: 2.1 master 9/17
Steps to Reproduce:

Go to Project/Namespaces page

Results:  Checkboxes are missing but bulk actions are still there.

@westlywright I think you missed assigning this to tani

Version - 2.1 master 9/19
Verified fixed

authors: cjellick tfiduccia

repo: rancher/rancher


text:
There is no indication on when external DNS entries are made available.

Rancher server version - Build from master - jan 28
Steps to reproduce the problem:

Create a globalDns entry with fqdn - "test1.test.com" with projectIds set to Cluster1 and project p1.
Create globalDnsProvider with root domain - "test.com"
In user cluster - Cluster1 and project p1, Create Ingress - ingress1 using annotation - rancher.io/globalDNS.hostname=test1.test.com which points to a workload with host name rule pointing to "test1.test.com"
Wait for the ingress to get to "Active" state . Try to access the ingress url - test1.test.com. This is still not accessible at this point since the Route53 entry may not have been created at this point.

After some delay (up to 1 minute) , we see an FQDN entry getting created with ingress1's ip in Route53 after which the ingress url becomes accessible.
It would be good to give some indication on when the external DNS entries are made available and  ingress url becomes accessible.

I don't think we will be able to facilitate this. Since we do not poll the external-dns providers ourselves we do not have a track of what FQDN's are present in the hosted zone. We just provision dummy ingresses with the necessary FQDN and endpoints and offload the rest to kubernetes/external-dns deployment.

Moving out off 2.2 given the comment above

authors: alena1108 prachidamle sangeethah


text:
Rancher server crash with "lost master" error

The same issue as https://github.com/rancher/rancher/issues/18505   in v2.2.2-rc10 and v2.2.2-rc11
setup: single install, 4 vCPU, 8GB memory
It happens after I run the automation in an RKE cluster, and the logs show lost master
I0412 00:40:36.159827       7 trace.go:76] Trace[1294926626]: "Get /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2019-04-12 00:40:26.580904568 +0000 UTC m=+1496.029070405) (total time: 9.578891662s):
Trace[1294926626]: [9.578814204s] [9.57867164s] About to write a response
I0412 00:40:36.580516       7 leaderelection.go:231] failed to renew lease kube-system/kube-scheduler: failed to tryAcquireOrRenew context deadline exceeded
E0412 00:40:36.580567       7 server.go:207] lost master
lost lease
2019/04/12 00:40:51 [INFO] Listening on /tmp/log.sock
2019/04/12 00:40:51 [INFO] Rancher version v2.2.2-rc11 is starting

@deniseschannon are we going to backport whatever our fix for this into v2.2.x?

Seeing this as well on v2.2.2, single master install:
2019-04-29 02:13:43.443529 W | etcdserver: apply entries took too long [2.458767663s for 1 entries]
2019-04-29 02:13:43.443917 W | etcdserver: avoid queries with large range/delete range!
I0429 02:13:47.149286       6 trace.go:76] Trace[1158079405]: "List /apis/management.cattle.io/v3/namespaces/p-28tr9/projectloggings" (started: 2019-04-29 02:13:37.457225975 +0000 UTC m=+3631.790283549) (total time: 9.688945013s):
Trace[1158079405]: [2.612163046s] [2.612163046s] About to List from storage
Trace[1158079405]: [7.486704661s] [4.874541615s] Listing from storage done
Trace[1158079405]: [9.688940071s] [2.201644078s] Writing http response done (0 items)
2019/04/29 02:13:48 [INFO] 2019/04/29 02:13:48 http: response.Write on hijacked connection
2019/04/29 02:13:48 [INFO] 2019/04/29 02:13:48 http: response.Write on hijacked connection
2019/04/29 02:13:47 [INFO] Updating global catalog helm
I0429 02:13:52.161686       6 leaderelection.go:231] failed to renew lease kube-system/kube-scheduler: failed to tryAcquireOrRenew context deadline exceeded
E0429 02:13:52.163380       6 server.go:207] lost master
lost lease

Ditto!
Any way to help you debugging?

I see this while the machine where rancher is running is under IO load (high iowait CPU usage).

I restarted the whole cluster and rancher come up again.

Having the same issue with rancher v2.2.5 single server

This happens when we cannot read/write to etcd fast enough. Can be due to high load or an underpowered box that rancher is running on.

@dramich i just want to discuss this with @ibuildthecloud before we do anything with it

Id like to investigate this as part of our v2.4 performance bucket of work. cc @cloudnautique @deniseschannon

This happens when we cannot read/write to etcd fast enough.

Not sure, if that is the reason. I have the same issue running on a DO managed Kubernetes cluster (4x 4GB RAM).
rancher        | created by github.com/rancher/k3s/pkg/daemons/control.controllerManager
rancher        | 	/go/src/github.com/rancher/k3s/pkg/daemons/control/server.go:119 +0x5cc
rancher        | E1118 14:25:07.331440      31 server.go:252] lost master
rancher        | lost lease
rancher        | E1118 14:25:08.486147       6 reflector.go:280] github.com/rancher/norman/controller/generic_controller.go:175: Failed to watch *v1.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1/watch/rolebindings?allowWatchBookmarks=true&resourceVersion=6641056&timeout=30m0s&timeoutSeconds=386: read tcp 127.0.0.1:45284->127.0.0.1:6443: read: connection reset by peer
rancher        | 2019/11/18 14:25:08 [FATAL] k3s exited with: exit status 1

Actually, that happens on average once a day, here's another example:
rancher        | 2019-11-19 15:41:53.270350 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/projects\" range_end:\"/registry/management.cattle.io/projectt\" count_only:true " with result "range_response_count:0 size:9" took too long (8.361418847s) to execute
rancher        | 2019-11-19 15:41:53.272986 W | etcdserver: read-only range request "key:\"/registry/horizontalpodautoscalers\" range_end:\"/registry/horizontalpodautoscalert\" count_only:true " with result "range_response_count:0 size:7" took too long (9.149485718s) to execute
rancher        | 2019-11-19 15:41:53.273033 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/kontainerdrivers\" range_end:\"/registry/management.cattle.io/kontainerdrivert\" count_only:true " with result "range_response_count:0 size:9" took too long (10.223542632s) to execute
rancher        | 2019-11-19 15:41:53.273133 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/clusterregistrationtokens\" range_end:\"/registry/management.cattle.io/clusterregistrationtokent\" count_only:true " with result "range_response_count:0 size:9" took too long (8.833572345s) to execute
rancher        | E1119 15:41:53.330222      32 server.go:252] lost master
rancher        | lost lease
rancher        | E1119 15:41:53.523336       7 leaderelection.go:365] Failed to update lock: Put https://localhost:6443/api/v1/namespaces/kube-system/configmaps/cattle-controllers?timeout=30s: read tcp 127.0.0.1:45130->127.0.0.1:6443: read: connection reset by peer
rancher        | 2019/11/19 15:41:53 [FATAL] k3s exited with: exit status 1

@b0r1sp are you saying the rancher management plane is running on a DO K8s cluster?

Yes, a managed DO cluster.

Tested with master-head from Dec 23(70452ced53c7)

Created a rancher server with master-head branch.
Set up notifiers and tested alerts.
Tested logging feature using fluentd target.

Observed a panic in the logs and rancher server exited after a couple of hours after setup.
2019-12-24 04:01:23.261085 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/clustertemplaterevisions\" range_end:\"/registry/management.cattle.io/clustertemplaterevisiont\" count_only:true " with result "error:etcdserver: request timed out" took too long (21.161702605s) to execute
2019-12-24 04:01:23.261130 W | etcdserver: read-only range request "key:\"/registry/ingress\" range_end:\"/registry/ingrest\" count_only:true " with result "error:etcdserver: request timed out" took too long (14.085359845s) to execute
2019-12-24 04:01:23.261187 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/multiclusterapprevisions\" range_end:\"/registry/management.cattle.io/multiclusterapprevisiont\" count_only:true " with result "error:etcdserver: request timed out" took too long (21.24195591s) to execute
2019-12-24 04:01:23.261206 W | etcdserver: read-only range request "key:\"/registry/networkpolicies\" range_end:\"/registry/networkpoliciet\" count_only:true " with result "error:etcdserver: request timed out" took too long (14.14726967s) to execute
2019-12-24 04:01:23.261267 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/settings\" range_end:\"/registry/management.cattle.io/settingt\" count_only:true " with result "error:etcdserver: request timed out" took too long (21.492335718s) to execute
2019-12-24 04:01:23.261311 W | etcdserver: read-only range request "key:\"/registry/persistentvolumes\" range_end:\"/registry/persistentvolumet\" count_only:true " with result "error:etcdserver: request timed out" took too long (14.224109866s) to execute
2019-12-24 04:01:23.261344 W | etcdserver: read-only range request "key:\"/registry/cronjobs/\" range_end:\"/registry/cronjobs0\" limit:500 " with result "error:etcdserver: request timed out" took too long (21.723121196s) to execute
2019-12-24 04:01:23.261353 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/clusterloggings\" range_end:\"/registry/management.cattle.io/clusterloggingt\" count_only:true " with result "error:etcdserver: request timed out" took too long (18.13349636s) to execute
2019-12-24 04:01:23.261377 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/rkek8sserviceoptions\" range_end:\"/registry/management.cattle.io/rkek8sserviceoptiont\" count_only:true " with result "error:etcdserver: request timed out" took too long (9.168496616s) to execute
2019-12-24 04:01:23.261420 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/templatecontents\" range_end:\"/registry/management.cattle.io/templatecontentt\" count_only:true " with result "error:etcdserver: request timed out" took too long (13.228917454s) to execute
2019-12-24 04:01:23.261460 W | etcdserver: read-only range request "key:\"/registry/minions/\" range_end:\"/registry/minions0\" " with result "error:etcdserver: request timed out" took too long (14.181283469s) to execute
2019-12-24 04:01:25.295511 W | wal: sync duration of 15.3773633s, expected less than 1s
E1224 04:01:11.533841      33 leaderelection.go:341] Failed to update lock: Put https://localhost:6444/api/v1/namespaces/kube-system/endpoints/kube-scheduler?timeout=10s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
E1224 04:01:11.878352      33 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"context canceled"}
E1224 04:01:11.878364      33 leaderelection.go:306] error retrieving resource lock kube-system/kube-controller-manager: Get https://localhost:6444/api/v1/namespaces/kube-system/endpoints/kube-controller-manager?timeout=10s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
E1224 04:01:25.296197      33 status.go:71] apiserver received an error that is not an metav1.Status: rpctypes.EtcdError{code:0xe, desc:"etcdserver: request timed out"}
E1224 04:01:25.296209      33 server.go:252] lost master
F1224 04:01:25.297060      33 controllermanager.go:248] leaderelection lost
goroutine 2218 [running]:
github.com/rancher/k3s/vendor/k8s.io/klog.stacks(0xc0005fb000, 0xc0000d0dc0, 0x4c, 0x150)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/klog/klog.go:828 +0xb1
github.com/rancher/k3s/vendor/k8s.io/klog.(*loggingT).output(0x6082c40, 0xc000000003, 0xc00eb1e150, 0x5d916fd, 0x14, 0xf8, 0x0)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/klog/klog.go:779 +0x2d9
github.com/rancher/k3s/vendor/k8s.io/klog.(*loggingT).printf(0x6082c40, 0x3, 0x34479ed, 0x13, 0x0, 0x0, 0x0)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/klog/klog.go:678 +0x14e
github.com/rancher/k3s/vendor/k8s.io/klog.Fatalf(...)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/klog/klog.go:1209
github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.Run.func2()
	/go/src/github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:248 +0x5c
github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection.(*LeaderElector).Run.func1(0xc002e99d40)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:175 +0x40
github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection.(*LeaderElector).Run(0xc002e99d40, 0x3c4d4a0, 0xc005779400)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:184 +0x10f
github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection.RunOrDie(0x3c4d4e0, 0xc00005e058, 0x3c74d80, 0xc002fd4c80, 0x37e11d600, 0x2540be400, 0x77359400, 0xc002ff0980, 0x3569778, 0x0, ...)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:196 +0x96
github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.Run(0xc002bb2da8, 0xc0004b0060, 0xc002d72f70, 0xc002aba250)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:240 +0x958
github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.NewControllerManagerCommand.func1(0xc002b80500, 0xc001bf82c0, 0x0, 0xb)
	/go/src/github.com/rancher/k3s/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:101 +0x27c
github.com/rancher/k3s/vendor/github.com/spf13/cobra.(*Command).execute(0xc002b80500, 0xc002b6cf00, 0xb, 0x10, 0xc002b80500, 0xc002b6cf00)
	/go/src/github.com/rancher/k3s/vendor/github.com/spf13/cobra/command.go:760 +0x2ae
github.com/rancher/k3s/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc002b80500, 0x34801d1, 0x22, 0xc00204f7a0)
	/go/src/github.com/rancher/k3s/vendor/github.com/spf13/cobra/command.go:846 +0x2ec
github.com/rancher/k3s/vendor/github.com/spf13/cobra.(*Command).Execute(...)
	/go/src/github.com/rancher/k3s/vendor/github.com/spf13/cobra/command.go:794
github.com/rancher/k3s/pkg/daemons/control.controllerManager.func1(0xc002b6cf00, 0xb, 0x10, 0xc002b80500)
	/go/src/github.com/rancher/k3s/pkg/daemons/control/server.go:121 +0xb2
created by github.com/rancher/k3s/pkg/daemons/control.controllerManager
	/go/src/github.com/rancher/k3s/pkg/daemons/control/server.go:119 +0x5cc
2019-12-24 04:01:25.365424 W | etcdserver: read-only range request "key:\"/registry/management.cattle.io/nodepools\" range_end:\"/registry/management.cattle.io/nodepoolt\" count_only:true " with result "range_response_count:0 size:8" took too long (2.424586974s) to execute
2019-12-24 04:01:25.365786 W | etcdserver: read-only range request "key:\"/registry/controllers\" range_end:\"/registry/controllert\" count_only:true " with result "range_response_count:0 size:6" took too long (2.549781675s) to execute

authors: Oats87 ViceIce b0r1sp chendo cjellick conet jiaqiluo moschlar ribx soumyalj


text:
Menu overlap on small screen

Every now and then i work on rancher from my phone. im having trouble on accessing  menus because it overlaping each other. From the Global menu i can only see Cluster, the project can be search but cannot be selected due to the overlap with another project and the interface below. I hope someone can fix this.

Useful
Info

Versions
Rancher v2.3.5 UI: v2.3.36

Route
global-admin.clusters.index

+1 on this. It's near impossible to access the cluster UI on a phone to view for example workload statuses.

Close in favor of https://github.com/rancher/rancher/issues/27183

authors: ChrML diansaji loganhz


text:
Can not register node

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
You need to have stuck cordoned node in Rancher UI see for example (https://github.com/rancher/rancher/issues/26405)
For me it was I had a problem with nodes (pods not active, and actions from Rancher UI like deleting pods have no effect. A red alert will appear in Rancher UI that displays that the action could not be done)
So you need:

Cordoned node
Drain the node using '30 sec, 60 sec' period and use the 'force option'
Delete the node
Register the node again

Result:
Stuck on setters.go:179] adding overridden hostname of k8s-worker-2 to cloudprovider-reported addresses
See the logs of kubelet

Other details that may be helpful:
I also rebuilt the instance (I started a new fresh instance with the same name), apt update && apt upgrade -y then I installed docker.io and I added the user 'ubuntu' to docker group. Then I registered the node. Also it stuck.
See the logs of kubelet
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):

Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):Hosted
Machine type (cloud/VM/metal) and specifications (CPU/memory):VM, vm with 4 vCPU, 8GB Memory
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:51:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Version:           19.03.6
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        369ce74a3c
 Built:             Fri Feb 28 23:45:43 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.6
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       369ce74a3c
  Built:            Wed Feb 19 01:06:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.3-0ubuntu1~18.04.2
  GitCommit:
 runc:
  Version:          spec: 1.0.1-dev
  GitCommit:
 docker-init:
  Version:          0.18.0
  GitCommit:

Usually I shutdown my cloud in the night (because my cloud is used for dev and it's in my home, not for prod, and it does not have a separate room with an air conditioner).
Today (in the morning), I powered my vms (openstack) and deleted the Node (k8s-worker-2) that is stuck for registering.
Then I tried again to register it, and it worked.
Also the nodes that were marked cordoned (also stuck on this state), and which I could not uncordoned yesterday, I succeeded to uncordoned today (after the power off/on my cloud) by clicking on cordon again from Rancher UI then the button uncordon appeared, and after clicking on it (uncordon), the node changed into the Active state


text:
Monitoring v2 k8s-prometheus-adapter log spam "apiserver was unable to write a JSON response: http2: stream closed"

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Deploy a Rancher v2.5.3 instance and a custom cluster with 3 all role nodes
Deploy the monitoring chart from Apps & Marketplace in the Cluster Explorer UI

Result:
When the monitoring chart has finished installing, observe repeating messages of the following format in the rancher-monitoring-prometheus-adapter Deployment logs in the cattle-monitoring-system namespace.
E0106 15:15:10.658751       1 writers.go:163] apiserver was unable to write a JSON response: http2: stream closed
E0106 15:15:10.658799       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}

Other details that may be helpful:
The upstream k8s-prometheus-adapter issue for these log messages is at https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/292.
When the following is set in the values YAML on installing the monitoring chart (per https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/292#issuecomment-671786467) the log spam does not occur:
prometheus-adapter:
  rules:
    default: false

The upstream issue identifies a potential Kubernetes fix in v1.20 (https://github.com/kubernetes/kubernetes/pull/94589), per https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/292#issuecomment-741777382, and expects the issue resolved once the API machinery dependencies in prometheus-adapter are bumped to v1.20 (https://github.com/DirectXMan12/k8s-prometheus-adapter/issues/292#issuecomment-741870086).
Environment information

Rancher v2.5.3

gz#14188

QA, please test this in the newest version of 2.6.x

Tested in 2.6-head Commit ID 8a31d3c
Error is still present in logs.

install monitoring v2
workload > pods > rancher-monitoring-prometheus-adapter-xxxx
right click 3 dots
view logs

E0518 18:41:29.145364 1 writers.go:130] apiserver was unable to write a fallback JSON response: http2: stream closed
E0518 18:41:29.147069 1 writers.go:117] apiserver was unable to write a JSON response: http: Handler timeout

This needs to be reproduced in 2023-Q1-2.6x and 2023-Q1-2.7x

Reproduced in 2.7-head 9376ad2 in an RKE2 v1.25.6 +rke2r1 downstream cluster (non custom, cluster created through Rancher) with monitoring 102.0.0+up40.1.2 installed.
E0216 23:54:57.688602       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http: Handler timeout"}: http: Handler timeout
E0216 23:54:57.689789       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E0216 23:54:57.692041       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0216 23:54:57.693205       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0216 23:54:57.694298       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0216 23:54:57.695515       1 writers.go:131] apiserver was unable to write a fallback JSON response: http2: stream closed

Also reproduced in 2.6-head 6d1bd94 in an RKE  v1.24.9 downstream cluster (non custom, cluster created through Rancher) with monitoring 100.2.0+up40.1.2 installed.
E0217 00:26:10.139403       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0217 00:26:10.140917       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0217 00:26:10.143083       1 status.go:71] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"http2: stream closed"}: http2: stream closed
E0217 00:26:10.144196       1 writers.go:131] apiserver was unable to write a fallback JSON response: http: Handler timeout
E0217 00:26:10.145433       1 timeout.go:141] post-timeout activity - time-elapsed: 20.250622ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0217 00:26:10.147089       1 timeout.go:141] post-timeout activity - time-elapsed: 23.421925ms, GET "/apis/custom.metrics.k8s.io/v1beta1" result: <nil>
E0217 00:26:10.148219       1 writers.go:131] apiserver was unable to write a fallback JSON response: http2: stream closed

Replaced image rancher/mirrored-prometheus-adapter-prometheus-adapter:v0.10.0 with most recent upstream image gcr.io/k8s-staging-prometheus-adapter/prometheus-adapter:master. Issue still persists. I'm thinking this is because they are using an older version of golang (1.18).
@sanjay920 @MKlimuszka @prachidamle

I have confirmed that this was fixed in v0.11.x.
Unfortunately v0.11.x also deprecated the logtostderr flag, and the chart does not expose the container args as a value, so the only way to run v0.11.x is using kustomize to override the args.

On https://github.com/kubernetes-sigs/prometheus-adapter/issues/292 there are some discussions about this.

Upstream ticket was closed, and we've rebased. Let's test this again after we make our new mirrored images.

Testing shows the behavior still persists after the rebase. The upstream ticket was closed since the originally reported panic has been resolved, but several comments report still having those logs in the prometheus-adapter deployment.

Just added ASML as a customer having this issue on 2.9.2

authors: MKlimuszka PennyScissors axeal cornfeedhobo elektro-wolle jbiers joshmeranda ronhorton thsnielsen


text:
Terraform provider rancher2 missing user/group search filter options

Issue description:
Terraform provider rancher2 missing openldap configuration
Business impact:
blocking infrastructure provisioning using Terraform
Workaround:
manually setting group "group search filter" parameter when setting up an openldap credential configuration.
Actual behavior:
Terraform provider rancher2 missing openldap configuration
Expected behavior:
erraform provider rancher2 should be present in openldap configuration
Files, logs, traces:
not provided
Additional notes:
The Rancher user interface includes this parameter but no way found for setting it in Terraform so we need to set it manually at the moment.

This needs to be reproduced in 2023-Q1-2.6x, 2023-Q1-2.7x, and if it cannot be reproduced in those, 2.6.5
SURE-5493

Both user search filter and group search filter are unavailable in the rancher/rancher2 Terraform provider versions v1.24.0, v1.24.1, v1.24.2, and v1.25.0. This issue is not related to the Rancher version directly, since it refers to missing fields in the rancher2_auth_config_openldap Terraform resource.

missing another value
working on this, i discovered that we're also missing 'start_tls'
we have 'tls'
without the start_tls, getting error ERROR] Unknown error: Error creating ssl connection: LDAP Result Code 200 "Network Error": EOF
source: https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/auth_config_openldap#certificate

@eliyamlevy Merged! Please add a QA test template and list Terraform RC v3.0.2-rc2 as the one to use for testing.

authors: MKlimuszka a-blender ronhorton stormqueen1990