大体やった

Summary (GitHub Copilot)
This pull request introduces several new components and functionalities to the application, focusing on improving the user interface and adding CRUD operations for orders, products, and details. The most important changes include the addition of new UI components for different parts of the application, the implementation of CRUD operations using Prisma, and updates to the application's root and index files to enhance the overall structure and functionality.
New UI Components:

app/components/atoms/button/MenuIconButton.tsx: Added a new MenuIconButton component using Chakra UI's IconButton and HamburgerIcon for the menu button.
app/components/molecules/MenueDrawer.tsx: Introduced the MenueDrawer component, which includes buttons for navigating to different sections of the application.
app/components/organisms/kitchen/OrderCard.tsx: Created the OrderCard component to display order details and manage order status transitions.
app/components/organisms/reception/ReceptionCard.tsx: Added the ReceptionCard component to handle product orders and cancellations.
app/components/organisms/register/ProductCard.tsx: Implemented the ProductCard component for managing product details, including deletion and modification.

CRUD Operations:

app/crud/crud_details.ts: Added CRUD operations for order_details, including creation, reading, and deletion of details.
app/crud/crud_orders.ts: Implemented CRUD operations for orders, including creation, reading by ID and status, updating status, and deleting orders.
app/crud/crud_products.ts: Introduced CRUD operations for products, including creation, reading, updating stock, modifying product details, and deletion.

Application Structure Enhancements:

app/root.tsx: Updated the root component to include a ChakraProvider, Header, and Sidebar, and structured the layout using Chakra UI's Grid component.
app/routes/_index.tsx: Refactored the home page component to use Chakra UI's Box, HStack, and VStack for displaying total sales.
app/routes/header.tsx: Added a new Header component that includes navigation buttons and integrates the MenuIconButton and MenueDrawer components.

Additional Changes:

app/hooks/useMessage.ts: Added a custom hook useMessage to display toast notifications using Chakra UI's useToast.
app/routes/$.tsx: Added a 404 error page component to handle non-existent routes.

@BruCandy
#4 にてPrettierを導入して自動フォーマットをかけた関係で、一部コンフリクトが発生しているので、コンフリクト解消お願いします！
競合している箇所は、mainブランチの内容を無視して、このブランチの内容で上書きすると良いと思います！
bun.lockbに関しては、package.jsonのコンフリクトを解決した後に、bun installを実行してbun.lockbを再生成すると良いと思います

vscode上でgitignoreにprisma/dev.dbを追加し、MenuIconButton.tsxの内容も簡潔に直したのですが、コンフリクトについてがよくわからないです。本来はコンフリクトが起きていたら、vscode上で以下のようになりますか？
<<<<<<< HEAD
=======


Incorrect code created for global verbs

Describe the bug
When creating a simple random maths and check a global verb the wrong code is created and errors saying there is something
wrong with your code when there isn't anything the end user did.
This was on a food item when eaten
1.16.4 version as you can see grabs the verbs and sets everything up the 1.12.2 version does not.
To Reproduce
Create this

Screenshots
Image above creates the code below
Code
public class ProcedureBeerFoodEaten extends ElementsMorefwoodsMod.ModElement {
	public ProcedureBeerFoodEaten (ElementsMorefwoodsMod instance) {
		super(instance, 10);
	}

	public static void executeProcedure(Map<String, Object> dependencies){
		if(dependencies.get("entity")==null){
			System.err.println("Failed to load dependency entity for procedure BeerEaten!");
			return;
		}
            Entity entity =(Entity)dependencies.get("entity" );
		if ((Math.random()<0.5)) {if ((<3)) {}}
	}
}

Details

OS: Windows
MCreator version 2020.4/2020.5
Generator type: forge-1.12.2

Demo workspace
Unable to at this stage
Additional context
The code in 1.16.4
public classBeerFoodEatenProcedure extends ElementsMorefwoodsMod.ModElement {
	public classBeerFoodEatenProcedure (ElementsMorefwoodsModElements instance) {
		super(instance, 83);
	}

	public static void executeProcedure(Map<String, Object> dependencies) {
		if (dependencies.get("entity") == null) {
			if (!dependencies.containsKey("entity"))
				ElementsMorefwoodsMod.LOGGER.warn("Failed to load dependency entity for procedureBeerEaten!");
			return;
		}
		Entity entity = (Entity) dependencies.get("entity");
		if ((Math.random() < 0.5)) {
			if ((((entity.getCapability(ElementsMorefwoodsModVariables.PLAYER_VARIABLES_CAPABILITY, null)
					.orElse(new ElementsMorefwoodsModVariables.PlayerVariables())).wetcount) < 3)) {
				{
					double _setval = (double) (((entity.getCapability(ElementsMorefwoodsModVariables.PLAYER_VARIABLES_CAPABILITY, null)
							.orElse(new ElementsMorefwoodsModVariables.PlayerVariables())).wetcount) + 1);
					entity.getCapability(ElementsMorefwoodsModVariables.PLAYER_VARIABLES_CAPABILITY, null).ifPresent(capability -> {
						capability.wetcount = _setval;
						capability.syncPlayerVariables(entity);
					});
				}
			}
		}
	}
}

Player variables are not supported on 1.12.2 generator.

Player variables are not supported on 1.12.2 generator.

What should I change that to then?

What should I change that to then?


Update Readme file

Fix issue about content of the readme file
Add Build status

Merge into master with Pull Request #9


Compile the lucille with Visual Studio

Hi,
Thanks for sharing your work.
I noticed that the lucille can be run on Windows, is that the corresponding sln project on VS is available or can you give me some suggestion on how to make the sln project file for lucille？
Thanks again.

lucille is not maintained anymore.
You can take a look at https://github.com/mmp/pbrt-v3 , appleseed renderer https://appleseedhq.net/ or other OSS renderer as an alternative.


[Bug] [File Manage] The file path in the resource center file management is inconsistent with that saved in the database

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
The file path in the resource center file management is inconsistent with that saved in the database.
When I use the uploaded resource, a message is displayed indicating that the corresponding resource and directory do not exist and the program cannot be executed normally. An error message is displayed indicating that the execution fails
What you expected to happen
I checked the t.d.resources table in mysql database and found that the path of saving files is different from the actual path of file management in resource center, whether the directory level is greater than or equal to 3 levels will appear
How to reproduce
Create folder path test/test1/testa Upload the corresponding file testa.hql
Create folder path test/test1/testb Upload the corresponding file testb.hql
Create folder path test/test1/testc Upload the corresponding file testc.hql
When using the file to the following conditions, such as the test/test1/testb/testc.hql
Anything else
No response
Version
2.0.0
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Uploading File-Manager-Bug.docx…

The file testa.hql,testb.hql.testc.hql is uploaded to the corresponding directory
Query t_ds_resources from the DolphinScheduler database in MySQL
The query statement is select * from dolphinscheduler.t_ds_resources where user_id=3;
The result is shown below


fix: typo spelling grammar

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

[ ] Please open PR in Draft mode if it is:

Work in progress or not intended to be merged.
Encountering multiple pipeline failures and working on fixes.

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code. (Track 2 only)
[x] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK. Please double check nuget.org current release version.

Additional management plane SDK specific contribution checklist:
Note: Only applies to Microsoft.Azure.Management.[RP] or Azure.ResourceManager.[RP]

[ ] Include updated management metadata.
[ ] Update AzureRP.props to add/remove version info to maintain up to date API versions.

Management plane SDK Troubleshooting

If this is very first SDK for a services and you are adding new service folders directly under /SDK, please add new service label and/or contact assigned reviewer.

If the check fails at the Verify Code Generation step, please ensure:

Do not modify any code in generated folders.
Do not selectively include/remove generated files in the PR.
Do use generate.ps1/cmd to generate this PR instead of calling autorest directly.
Please pay attention to the @microsoft.csharp version output after running generate.ps1. If it is lower than current released version (2.3.82), please run it again as it should pull down the latest version.

Note: We have recently updated the PSH module called by generate.ps1 to emit additional data. This would help reduce/eliminate the Code Verification check error. Please run following command:
  `dotnet msbuild eng/mgmt.proj /t:Util /p:UtilityName=InstallPsModules`

Old outstanding PR cleanup
Please note:
If PRs (including draft) has been out for more than 60 days and there are no responses from our query or followups, they will be closed to maintain a concise list for our reviewers.

thanks sir @jsquire !!

thank your sir @LarryOsterman @heaths !!

@allenjzhang, @m-nash:  Would either of you be so kind as to offer your thoughts and, potentially, assist with resolving the management pipeline build error?

hi @HarveyLink could you help to look at the mgmt CI task failure? thanks

/azp run net - mgmt - ci

revert specific file on commit cd9cf62 and 2704071

LGTM

CI and sign-offs look good;  merging this in.    @slowy07:  Thank you, again, for your contribution.

thank you sir @jsquire for teach me more !


install failed

I did composer install and get this error:

php artisan clear-compiled

[TeamSpeak3_Transport_Exception]
Failed to parse address ":"
Script php artisan clear-compiled handling the post-install-cmd event returned with an error
[RuntimeException]
Error Output:
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-plugins] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--ignore-platform-reqs] [--] []...

Can you try follow the next step. (fill your .env file with the correct values) and after that run composer install.
If that works you can continue with the other steps. Please let me know. 😄

I feel the same, I did what you said and I get the same error


Error when combined with gql schema

I'm trying to use EasyGraphQLTester with apollo and the gql template literals. I'm new to the GraphQL-world so combining apollo with EasyGraphQLTester might not even be valid use-case. But if it should be possible it would be nice to have an example of a correct setup in the readme.
I'm getting the following error:
    TypeError: Cannot read property 'types' of undefined

      14 |
      15 |   beforeEach(() => {
    > 16 |     tester = new EasyGraphQLTester(typeDefs);
         |              ^
      17 |   });
      18 |
      19 |   test("validate schema", () => {

      at buildClientSchema (node_modules/graphql/utilities/buildClientSchema.js:57:61)
      at buildGraphQLSchema (node_modules/easygraphql-tester/utils/buildGraphQLSchema.js:15:28)
      at new Tester (node_modules/easygraphql-tester/lib/tester.js:27:22)
      at Object.beforeEach (src/schema.test.js:16:14)

And this is the code:
const EasyGraphQLTester = require("easygraphql-tester");
const { gql } = require("apollo-server-express");

const typeDefs = gql`
  type Query {
    name: String!
  }
`;

describe("schema validation", () => {
  let tester;

  beforeEach(() => {
    tester = new EasyGraphQLTester(typeDefs);
  });

  test("validate schema", () => {
    const validQuery = `
          {
            name
          }
        `;

    tester.test(true, validQuery);
  });
});

Thank you for creating this issue, I'm going to work to support gql, but in the meantime, you can try:
const typeDefs = `
  type Query {
    name: String!
  }
`;

And it'll work

This is fixed on v5.1.5. If it's not working as expected we can open this issue again 🙂


lodash: signatures of the method _.indexOf changed

https://lodash.com/docs#indexOf
https://lodash.com/docs#_ (description of the chainable wrapper)

thanks mate!


Use search for network policies instead of walks (#6079)

Description
Cherry-picking #6079.

/retest

/retest

@tommartensen Not sure what we can do about those two failing stages

@connorgorman @tommartensen I've asked about this in https://redhat-internal.slack.com/archives/CBN38N3MW/p1684864225577309
It does not seem at all related to changes we made to the CI config lately so hopefully we'll get a resolution there or I will escalate.

/retest
The fix is in.

Whoa. All green.

Whoa. All green.

Never seen all green on this branch before 😱


How to press once shortcut key to automatically jump class or function？

Is there a way to automatically determine whether the current context is a function or a class, and then set the same shortcut key to jump?
There will be problems if set the same settings directly
      goto_previous_start = {
        ["[m"] =<EMAIL_ADDRESS>        ["[m"] =<EMAIL_ADDRESS>      },

When using the treesitter-context plugin, it can get the corresponding line number like this. I want to automatically jump to the corresponding place.

For example, in go, when I am in a function or structure, I can jump to the definition by pressing [m

It doesn't work the same way as you described but you can pass multiple queries.
        ["]o"] = { query = {<EMAIL_ADDRESS><EMAIL_ADDRESS>} }


[QUESTION] Getting error 5001 after pushing frames. How to debug?

I put together an app using the Linux sample code, which was working fine until last week. This week it started to consistently fail with a log as follows:
Jan 25 09:00:02.136 Info: 100-continue^M
Jan 25 09:00:02.234 Info: Fragment buffering, timecode:18446744071867076041^M
Jan 25 09:00:02.555 Info: Fragment received, timecode:18446744071867076041^M
Jan 25 09:00:02.565 Info: Fragment buffering, timecode:18446744071867078043^M
Jan 25 09:00:02.732 Error: Time:Tue Jan 25 09:00:02 2022 File:amazon-kinesis-video-streams-producer-embedded-c/src/source/restful/kvs/restapi_kvs.c Func:prvLogFragmentAck Line:512 PutMedia session error id:5001^M

From the documentation error 5001 is:
5001 - ARCHIVAL_ERROR - Kinesis Video Streams failed to persist fragments to the data store.
For reference, I have a similar app using this SDK: https://github.com/awslabs/amazon-kinesis-video-streams-producer-c which is pushing the same media, and it doesn't fail.
How can I debug this issue?

@gtapizquent It seems somehow S3 is unable to store this fragment. Which region do you use? Do both apps use the same KVS stream name? Is data protection enabled in C SDK? Could you try to change to another KVS stream or change the region in the app that uses this embedded producer library so we can see if this issue relates to the server-side?

@weichihl I am using the same KVS stream (not at the same time). Region is us-west-2
As I mentioned, using the exact same stream information works for the c producer. And it was working with the embedded c SDK until last week. Nothing changed from the app side.
Would this require opening a ticket via the IoT Console so they can help me look at the backend logs?

@gtapizquent  I think it helps by opening a ticket because this error is reported from S3 to KVS.

I figured out this issue. It was caused by bad timestamps being sent from the device. Thanks.


update: fix blog post slugs

Signed-off-by: Lorenzo Fontana<EMAIL_ADDRESS>What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area blog
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fix an issue reported by @Issif on the slack channel where our new website blog urls are not matching the old website ones.
I had to add a specific slug for every old blog post to reflect what it had in the old blog because we already have the 0.27.0 release blog post out on social and because of that we now had two different schemes deployed.
I think this is also a good opportunity to remember that the slug:  tag exists in Hugo and that we can use that to create more friendly URLs instead of using what hugo gives.
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

/lgtm

LGTM label has been added.  Git tree hash: 368896106c391e72bf5799fe5a7da4624e977cae

LGTM label has been added.  Git tree hash: 368896106c391e72bf5799fe5a7da4624e977cae

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: danpopSD
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: danpopSD
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: danpopSD, Issif
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: danpopSD, Issif
To complete the pull request process, please assign fntlnz after the PR has been reviewed.
You can assign the PR to them by writing /assign @fntlnz in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danpopSD, Issif, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danpopSD, Issif, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danpopSD, Issif, leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danpopSD, Issif, leodido, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


feat: Deactivate beacon mutation.

fixes: #78

@aadibajpai i have tested this locally, and its working as expected.

why can't we just use the duration changing mutation?

I had the same thing in mind, but thought having separate mutation would be better.

You may close this pr if the change doesnt seem necessary.

I had the same thing in mind, but thought having separate mutation would be better.

I think it's smart to not add redundant code when you can just reuse the mutation for it

Sure thanks.


[feature #156577841] Create dashboard for failed checks

What does this PR do?
Have dashboard for viewing failed checks working.
Description of Tasks to be complete
Have the following files running and functioning;
hc-rogue-one/hc/front/views.py
hc-rogue-one/templates/front/my_checks.html
How should this be tested manually?
RUN; python manage.py runserver
Background context;
Installed more dependencies such requests.
Created a local_settings.py file
Any pivotal tracker user stories?
#156577841

Hello Team, please review my code and let me know what you guys think.


ha.UnitOfFrequency.HERTZ error

after updating to the latest HomeAssistant stable version 2024.5.3, OCPP integration is failing due to unknown unit in const.py file.
I need to delete the ha.UnitOfFrequency.HERTZ due to it caused and error. Seem like Home Assistant is deleting the HERTZ unit.

Same issue here

As interim, you can delete the ha.UnitOfFrequency.HERTZ in const.py file and restart HA. Not sure if it will impact others functionalities but mine worked good. After restart, the integration successfully loaded.

Seems strange as UnitOfFrequency.HERTZ still exists in HA. Can you revert and post the error logs?

@drc38 I'm having the same issue.
The full error is as follows:

Logger: homeassistant.loader
Source: loader.py:1041
First occurred: 21:41:15 (2 occurrences)
Last logged: 21:41:15
Unexpected exception importing component custom_components.ocpp
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/loader.py", line 1041, in _get_component
    ComponentProtocol, importlib.import_module(self.pkg_path)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/loop.py", line 144, in protected_loop_func
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 995, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/config/custom_components/ocpp/__init__.py", line 13, in <module>
    from .api import CentralSystem
  File "/config/custom_components/ocpp/api.py", line 52, in <module>
    from .const import (
  File "/config/custom_components/ocpp/const.py", line 121, in <module>
    UnitOfMeasure.hertz: ha.UnitOfFrequency.HERTZ,
    ^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'UnitOfMeasure' has no attribute 'hertz'

Thanks, the issue is with the ocpp latest release see https://github.com/mobilityhouse/ocpp/issues/207 rather than HA 2025.3


Enable testing for all branches/PRs

It seems like - maybe I am mistaken - that we only check master in Travis. Would it be possible to also test other branches, or at least PRs?

PRs are tested automatically. For example, if you scroll down in #107, you will see something like "All checks have passed". If you click on "Show all checks", you'll find the Travis report there. I disabled automatic testing of other branches, since this usually means that they are tested twice (since they will usually correspond to a PR).

OK, thanks for letting me know!


Simulation Rendering doesn't clear after stop

When stopping a simulation the active objects of the simulation don't remove themselves from the 'UniversePanel'.  This can lead to a cluttered panel as all previous run simulations ghost images persist.
Implementing a gfx.clearRect() on the panel results in a large white rectangle covering everything.  This may be the proper solution, and then just requesting the Background panel redraws.

Solved by refreshing on stop signal through the render frame.  UniversePanel removes all objects from the panel and the object list then redraws.  Seems to have solved the issue.  There are still some artifacts from the previous simulation, but those correct themselves when a new simulation is started.  But it would be beneficial to look into those, given time...


git maintenance start doesn't use launchctl on Darwin

Describe the bug
The git package provided by Nixpkgs doesn't handle git maintenance start on Darwin properly.
The git maintenance start command attempts to modify the user's crontab to schedule regular maintenance tasks, but this doesn't work on Darwin:

While macOS technically supports cron, using crontab -e requires elevated privileges and the executed process does not have a full user context. Without a full user context, Git and its credential helpers cannot access stored credentials, so some maintenance tasks are not functional.
Instead, git maintenance start interacts with the launchctl tool, which is the recommended way to schedule timed jobs in macOS. Scheduling maintenance through git maintenance (start|stop) requires some launchctl features available only in macOS 10.11 or later.
...

From https://git-scm.com/docs/git-maintenance
To Reproduce
Steps to reproduce the behavior:

Install pkgs.git from a recent revision of Nixpkgs on a Darwin machine
Go into a random Git repository
Run git maintenance start

Expected behavior
Git exits without any error, indicating it started/scheduled the tasks successfully.
Actual behavior
λ git maintenance start
crontab: no crontab for evan

Additional context
After running into the error above, I installed Git from Homebrew via brew install git, and was able to successfully start/schedule the maintenance tasks.
After running git maintenance start with Git provided by Homebrew, the Git I got from Nixpkgs started working (stop and start both execute without any errors, in all the repositories I tried).
Notify maintainers
@primeos @peti @wmertens @globin
Metadata
 - system: `"x86_64-darwin"`
 - host os: `Darwin 19.6.0, macOS 10.15.7`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.10`
 - channels(root): `"nixpkgs-21.03pre264882.92c884dfd71"`
 - nixpkgs: `/Users/evan/.nix-profile/channels/default`

# Nixpkgs
λ ~/.nix-profile/bin/git --version
git version 2.30.0

# Homebrew
λ /usr/local/bin/git --version
git version 2.30.1

Maintainer information:
attribute:
  - "git"
  - "gitAndTools.gitFull"

Seems to work now, @evanrelf do you think this can be closed?
$ sw_vers
ProductName:            macOS
ProductVersion:         14.3.1
BuildVersion:           23D60
$ nix-info -m
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.3.0, macOS 14.3.1`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.19.3`
 - channels(n8henrie): `""`
 - channels(root): `""`
 - nixpkgs: `/nix/store/64npyyxn3bb6cxciz12yigldfc2p9fh1-source`

Yup, seems to work now! 🎉 Thanks to whoever fixed it.


Dependabot/other deps manager automation?

Just an issue to remind us to setup dependency management automation

💯 for Dependabot.
I was thinking that we could also use Pull Panda.

@mkalish reports in the slack that Dependabot is set up


backup: continue to seek regions if one range has no located leader region

What is changed and how it works?

Issue Number: Close #17168

What's Changed:
backup: continue to seek regions if one range has no located leader region

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[x] Unit test
[ ] Integration test
[x] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

/approve

/retest


Make magic_map a global constant to avoid creating temporary instances on every call

Fixes #65

Are there any changes that need to be made or is this fine?

The change looks good to me. Thanks for the answer to my question, I see why you structured it that way.

@SamVanheer Could you resolve the conflict -- then I'll be happy to merge!

@ddiakopoulos Should be good now.


Class 'Subject' incorrectly extends base class 'Observable' with TypeScript 2.4

RxJS version:
5.4.1
Code to reproduce:
Save this line this to a TypeScript file (test.ts):
import {Subject} from 'rxjs/Subject';
Then compile:
tsc  test.ts
Expected behavior:
No errors
Actual behavior:
Compilation error:
node_modules/rxjs/Subject.d.ts(16,22): error TS2415: Class 'Subject<T>' incorrectly extends base class 'Observable<T>'.
  Types of property 'lift' are incompatible.
    Type '<R>(operator: Operator<T, R>) => Observable<T>' is not assignable to type '<R>(operator: Operator<T, R>) => Observable<R>'.
      Type 'Observable<T>' is not assignable to type 'Observable<R>'.
        Type 'T' is not assignable to type 'R'.

Additional information:
TypeScript version: 2.4.1
TypeScript 2.4 introduced stricter checks for generics (see this blog post)
(Looks like this could be a typo in Observable#lift)

dupe of #2699 , #2539, #2700 . #2701 #2702 #2703 https://github.com/ReactiveX/rxjs/issues/2704

update TS. That's it

upgrade ts won't help. according to ts webpage, I added --noStrictGenericChecks to suppress the error message.
tsc --noStrictGenericChecks

Got this error WHEN i updated to TS 2.4.2

Fixed by updating RxJS to 5.4.2

@Argon2000
It Work for me, Thank You

Didn't worked for me with typescript 2.4.2 & RxJS 5.4.2
Started to work after the downgrading the typescript to 5.4.0

@andrewmur  what you have downgraded TypeScript  or RxJS??

TypeScript to 5.4.0

I've deleted Rxjs node_module folder, and ran again npm install. That made the magic.

@andrewmur I don't believe there is a Typescript version 5.4.0, latest version (as of right now) is 2.4.2 - perhaps you got it confused with the latest version of RxJS which is currently 5.4.3?

@theBull srry for typo & confuse. Yeap I meant downgrade to typescript 2.4.0

Anyone installing from a package.json file, try changing your typescript devDependency from:
"typescript": "^2.0.3" to "typescript": "2.4.0" specifically.
Then delete the typescript package from your node_modules folder and then retry npm install.

I am seeing incorrect information's shared in this issue's comment - anyone still experiences compilation issue with LATEST RxJS, please confirm

if there are any other copy of RxJS v5 stays under node_modules which isn't latest, should be checked by physical lookup
if above is not case and compilation fail occurred with strict generic check, confirm any user code inherits have correct type definition of base classes.

(check detail at https://github.com/ReactiveX/rxjs/issues/2726#issuecomment-313713212)
RxJS itself has fixed its own issue of library regarding this type definition issue and remaining failure mostly shoud be those cases listed above. If you're certain library has still failing, please don't hesitate to create new issue with repo have smallest code can reproduce issue.
I'm locking this issue itself to avoid further confusions.


Fix traffic_via problem with string length

I think we have a problem with traffic_via since commit 925cbb40ea132bcbf9a68303d4833f73f0d7e22b
We should be removing 2 characters instead of 1.

Yes, I think so.

Cherry picked to 8.1.0


Update documentation for get_theme_stylebox

Updated documentation for the get_theme_stylebox to make it clearer how the 'name' parameter is supposed to be used.
Resolves #1431

I'm not 100% certain that the changes fully explain how the method works. Also not sure if it captures how the second parameter behaves. Let me know if any changes are needed.

Not sure if you understood this method correctly. get_theme_stylebox("panel") will return the stylebox named "panel" in the current Control. If you call it on PanelContainer, it will return the style for PanelContainer:

Compare with button for example, which has multiple styles:

Did a quick rebase and touched up the description. Let me know if there's anything else needed.

@zak-grumbles Is there still an interest to update this PR?

By the way, the new description is factually incorrect, and the older description was closer to the truth. get_theme_item() methods work in steps.

The local overrides are checked for the name of the item; type is not used as overrides are directly attached to the node in question.
If type is omitted, the class name of the control is used (e.g. Button).

Additionally, if this control has the new theme_custom_type property set, it is used as a default value instead of the class name.

Then the lookup begins where we go up the tree to find control nodes with the theme property defined and look through it looking for an item by its name and its type.

If there is no match for the name and the type and if the type is from theme_custom_type, then we repeat the search using the class name of the control as a type;
If there is no match and if the type is a registered class name, we look up the name of the parent class (e.g. Button -> BaseButton), and repeat this until we reach the end of the inheritance chain.

If we've looked through all the control nodes in the branch and didn't find anything, we check the project level theme in the same way.
Lastly, we check the default theme in the same way.

While it is probably an overkill to describe this process in such detail, the short description of each get_theme_item() method should suggest this behavior in some form. So because of that I think that the following change is misleading:

on the current [Control] of the given [code]type[/code]

Something along those lines should be used:

Returns a [StyleBox] from the first matching [Theme] in the tree if this [Theme] has a [StyleBox] with the specified [code]name[/code] and [code]type[/code]. If [code]type[/code] is omitted, the class name of the current [Control] is used, or [member theme_custom_type] is it is defined. If no matching [Theme] is found, a custom project [Theme] (see [member ProjectSettings.gui/theme/custom]) and the default [Theme] are used.

And then an example, maybe for both with and without a type.

Let's close this PR then if the proposed changes make the description incorrect. Maybe you could make a PR to improve the description(s) - if still needed - based on your understanding @pycbouh?

Sure, I'll add it to my TODO list 🙂


Refactor RefreshMode enum and related classes

Is your feature request related to a problem?
The refreshMode in FlintSparkIndexRefresh makes use of the same enum as the code manipulates index option. This actually should be a separate enum that describes the refresh execution mode instead.
What solution would you like?
Refactor the RefreshMode enum and related classes to clearly distinguish between the Spark side physical trigger setup and the logical Flint index option.
Do you have any additional context?
Follow-up of https://github.com/opensearch-project/opensearch-spark/pull/415

[Catch All Triage - 1, 2, 3]


HSEARCH-2103 Fix Checkstyle for Java 8 syntax

This pr bumps the maven-checkstyle-plugin to 2.17 and puppycrawl checkstyle to 6.15.

Seems like jenkins is broken for this PR

Looks good to me so far, but what you said in the isssue itself should be discussed:

I am using Java 8 for some classes in my async backend pull request

Did we already agree on requiring Java 8?
It'd be fine for me, provided we actually have a good benefit from it, making potential exclusion of users stick to older versions worthwile. If it's just to benefit from some syntactical sugar, I'd rather stick to 7.

@gunnarmorling :
Hmm, I think I use some Java 8 classes, we can discuss whether that's a good idea on that PR I guess. Java 8 is also only required in my new modules.
Anyhow, the Checkstyle upgrade brings some improvements in code-style checking as well, which I think is great.

Let's keep in mind that many getters were written in the "one line" style intentionally,
I'm not a big fan of enforcing otherwise.
I generally like Checkstyle as having some basic ground rules allows us to

quickly understand larger blocks of code
avoid people introducing many style related changes in PR

But we've also seen that making rules too strict backfires: a pedantic build tool is quite annoying. We need to find a good balance, and I'm actually having the impression that we should be relaxing some rules rather than introducing more checks?

I did not include any new style checks, the default behaviour just changed and I figured since the 1 line getters were only present in tests that this would not be a big deal to keep.

@Sanne: i reverted the 1 line property access checks.

i reverted the 1 line property access checks.

Thanks!

Also, I think that the checkstyle.xml needs some more intensive care in general and needs to be updated to our needs. Why not keep a list of suggestions open?

I'm not sure I understand. What do you have in mind?
BTW the long term plan was to see how this checkstyle.xml and the one living in Hibernate OGM would "stabilize" and mature, and hopefully also converge to extract them in their own repository to be used across Hibernate projects but maintained "out of the way".
i.e. There's no benefit for Search to rebuild that module every time it's being built.

It seems like the checkstyle documentation lacks at some points and that the actual code behaves quite differently. Therefore the settings used in checkstyle.xml might not be optimal 100% at all times and I would propose that we keep enhancing it more in the future.
For this some kind of TODO list would be a good idea where people can list their complaints with the current setting.

For this some kind of TODO list would be a good idea where people can list their complaints with the current setting.

Sure. I'm not aware of any though; maybe you have some as Windows user?

Sure. I'm not aware of any though; maybe you have some as Windows user?

Not related to Windows, but as I already said I don't think that checking whether an empty line contains whitespace is beneficial to the build process. As I cannot just auto-format all the code this is quite the issue for me sometimes. I remember some spending my fair share deleting whitespace where it didn't help the readability.

consistency with whitespaces are actually important to avoid conflicts with git, and warnings with git when it's at EOF. But it's the conflicts part which is more important.
Any sensible IDE and editor has options around how to deal with whitespaces, so being strict on that isn't a significant coding burden but rather to check that you've configured your editors correctly.

Hmm, sounds reasonable?
I am using the hibernate-style.xml for IntelliJ. Isn't that enough configuration to prevent that?

I am using the hibernate-style.xml for IntelliJ. Isn't that enough configuration to prevent that?

I'm not sure. I would assume the IntelliJ styles are not aligned with our checkstyle rules, but my guess is that the IntelliJ styles need more work rather than the checkstyle files.
N.B. those IntelliJ styles are mostly used by Steve Ebersole on Hibernate ORM, while most people use Eclipse when working on Hibernate Search.

If I use autoformat with the IntelliJ xml file everything works great. But sometimes during normal editing it seems to slip up. I will keep watching out for these issues, maybe they have gone away in the meantime (or at least the big ones).

But sometimes during normal editing it seems to slip up. I will keep watching out for these issues, maybe they have gone away in the meantime (or at least the big ones).

I am not sure what that is, since I mostly use Eclipse. My guess is that beyond "formatting rules" it might have separate options about adding default whitepace for indentation.

Hi @s4ke
thanks for this, there are some nice improvements in here but I'd prefer you could do one more polishing step: I know git doesn't scare you (as it does to some occasional contributors) so I'd love it if you could do one more step when preparing pull request: to actually squash "reverting changes" in their original commit so that it looks like they never happened.
It's quite easier to review if you can keep the changes to the minimum;
to that end, commits like "1453adf" could also use some love as you state "updated version for checkstyle" but for that I expect a single line to change.. reformatting the whole file is a no-go ;)
In this case I see that indeed there was a need to fix some indentation, but that really should be in a separate commit.
Also you changed many XML elements which end with " />" to remove the separating space.. the space is intentional in our style.
For sake of HSEARCH-2103 could you revert most of the non-related cosmetic changes?
For example in the checkstyle.xml file, I'd really like to be able to open the diff and have it point out what you did change.. it's hard to point fingers since it's significantly reformatted.
In such a case I'd avoid reformatting altogether (generally), but if formatting really needs some love, make sure you format it once w/o any other change, commit with a clear message and then apply your changes so that one can "trust" that the first commit isn't changing anything and read the second commit with more care.
N.B. this is more important in the long term than just for the one -off review. Sometimes one needs to dig in history and see when something was changed.. it's very time consuming when there are changes which aren't relevant so we need to keep those out of the main history.

all nice now :+1:

@s4ke when I run mvn -DskipTests checkstyle:check, I have the following errors:
[INFO] ------------------------------------------------------------------------
[INFO] Building Hibernate Search ORM 5.6.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-checkstyle-plugin:2.17:check (default-cli) @ hibernate-search-orm ---
[INFO] Starting audit...
[ERROR] /data/home/gsmet/git/gsmet/hibernate-search/orm/src/test/resources/META-INF/persistence.xml:2: Line does not match expected header line of '<!--'. [Header]
[ERROR] /data/home/gsmet/git/gsmet/hibernate-search/orm/src/test/resources/META-INF/persistence.xml:22: White spaces at the end of line [RegexpSingleline]
[ERROR] /data/home/gsmet/git/gsmet/hibernate-search/orm/src/test/resources/META-INF/persistence.xml:27: White spaces at the end of line [RegexpSingleline]
[ERROR] /data/home/gsmet/git/gsmet/hibernate-search/orm/src/test/resources/org/hibernate/search/test/spatial/hibernate.cfg.xml:1: Line does not match expected header line of '<?xml version="1.0" encoding="UTF-8"?>'. [Header]
[ERROR] /data/home/gsmet/git/gsmet/hibernate-search/orm/src/test/resources/org/hibernate/search/test/spatial/hibernate.cfg.xml:35: White spaces at the end of line [RegexpSingleline]

Could you take a look at it?
Thanks!

@gsmet:
Huh that's weird. It seems like the error only occurs when used with the direct checkstyle:check goal. I will fix this and provide a PR.

Yup. That  surprised me but it looks like it comes up with things we should really fix.

see https://github.com/hibernate/hibernate-search/pull/1008


glm-10b-chinese build_inputs_for_generation missing targets argument

Hi, thanks for the great work!
build_inputs_for_generation for glm-10b-chinese does not take in targets argument. Link here.
This is inconsistent with glm-large-chinese, which supports targets argument. Link here
Can glm-10b-chinese support the targets argument please? Thank you!

Thank you for pointing that out. Already fixed.


2.0.3 Integrate with Gaia node Qdrant Vector Store

Integrate the output connector with the Qdrant vector store. This involves configuring the connector to communicate with Qdrant's API, ensuring seamless data ingestion and storage. Proper integration is essential for enabling efficient retrieval and querying of the knowledge base within Qdrant, enhancing the performance and usability of the AI agents.

Solved in #14

Output connector is working as expected. Just need to make sure in #30 we use qdrant/qdrant:v1.10.1 image (the gaia node uses this version. Got errors when trying to import a snapshot generated with a newer version) so it maintains version compatibility between dev end production environments


Update README

Since initVM is present just for compatibility reasons, I suppose the README could be updated to point this out.
It would also be nice to have an actual Tika Class which on init accepts the ENV_VARs as arguments, as it's impractical to work with them when remote workers are in place. (eg. Google Dataflow) That however is a discussion for another issue.

Yeah I think I would be open to having a class with properties and so forth for Tika but it would require a bit of refactoring and is a separate issue. Thank you for your comment @ktoulgaridis If you get a chance to update the README go ahead and propose a PR and I'll take a look. Thanks.


Not all Players Showing Up in Permissions

I am experiencing an exceptionally strange bug. I have several merchants and loot actors and five players. Every single one of them has the same sheet type, they all have accounts linked to said sheets as owners, and they show up in permissions in all manner, save for the sidebar menu in your loot sheet. One of them is missing. I can set the settings to all and I see their color dot but the gold doesn't split properly. Session is coming up. Do you know what the problem is and how I can fix it?
I tried removing their ownership of their character and re-adding it, see if that fixed things. It did not.

For a character to show up in the loot list, it needs to be claimed by a player. Open your player list in the lower left and make sure every player has been assigned a character.


fix broken-links for app-types document

Responding to a user comment on
https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-wi
th-xplat-cli

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/migrating-from-dnx?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli?branch=pr-en-us-1203

Status: SucceededWithWarning. Message: Warning occurred: Invalid file link:(~/docs/core/deployment/index.md.md)...
Open Publishing Report.

I also noticed that this problem is caused by the redirection metadata I've applied to the app-types topic. It's not doing what I've expected so we should fix that too.

@mairaw should be fixed now.  I'll verify once the build finishes and staging is available.

I think that the redirect metadata should be changed from
redirect_url: /deploying/index

to
redirect_url: /dotnet/articles/core/deploying/index

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/migrating-from-dnx?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli?branch=pr-en-us-1203

Status: SucceededWithWarning. Message: Warning occurred: Invalid file link:(~/docs/core/deployment/index.md)...
Open Publishing Report.

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/app-types?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/migrating-from-dnx?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli?branch=pr-en-us-1203

Status: SucceededWithWarning. Message: Warning occurred: Invalid file link:(~/docs/core/deploying/)...
Open Publishing Report.

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/app-types?branch=pr-en-us-1203
https://review.docs.microsoft.com/en-us/dotnet/articles/core/migrating-from-dnx?branch=pr-en-us-1203

Status: Succeeded.
Open Publishing Report.

I just checked all the links on staging, and it's all good.


Add 020 to cellphone_codes.txt

020 is still used for pocket bells.
http://www.soumu.go.jp/main_sosiki/joho_tsusin/top/tel_number/number_shitei.html

Coverage remained the same at 100.0% when pulling 1cc6e8cdcf53871c98e859399eb9b2cfe6c8f38b on maisumakun:add_pocket_bell into 5025ab3f0c1830649e9155cea62ca960e90c478f on iTakeshi:master.

Thanks for your contribution :)


After completing the test node autonomy, the edge node status still keep ready

Situation description

I installed the kubernetes cluster using kubeadm. The version of the cluster is 1.16. The cluster has a master and three nodes.

After I finished installing open-yurt manually, I started trying to test whether the result of my installation was successful

I used the Test node autonomy chapter in https://github.com/alibaba/openyurt/blob/master/docs/tutorial/yurtctl.md to test

After I completed the actions in the Test node autonomy chapter, the edge node status still keep reday

Operation steps

I created a sample pod

kubectl apply -f-<<EOF
apiVersion: v1
kind: Pod
metadata:
  name: bbox
spec:
  nodeName: node3
  containers:
  - image: busybox
    command:
    - top
    name: bbox
EOF

node3 is the edge node. I chose the simplest way to schedule the sample pod to the edge node, although this method is not recommended in the kubernetes documentation

I modified yurt-hub.yaml. make the value of --server-addr= a non-existent ip and port
- --server-addr=https://<IP_ADDRESS>:6448

Then I used the curl -s http://<IP_ADDRESS>:10261 command to test and verify whether the edge node can work normally in offline mode. the result of the command is as expected
{
  "kind": "Status",
  "metadata": {

  },
  "status": "Failure",
  "message": "request( get : /) is not supported when cluster is unhealthy",
  "reason": "BadRequest",
  "code": 400
}

But node3 status still keep ready. and yurt-hub enters pending state
kubectl get nodes
NAME     STATUS   ROLES    AGE   VERSION
master   Ready    master   23h   v1.16.6
node1    Ready    <none>   23h   v1.16.6
node2    Ready    <none>   23h   v1.16.6
node3    Ready    <none>   23h   v1.16.6

# kubectl get pods -n kube-system | grep yurt
yurt-controller-manager-59544577cc-t948z   1/1     Running   0          5h42m
yurt-hub-node3                             0/1     Pending   0          5h32m

Some configuration items and logs that may be used as reference

Label information of each node
root@master:~# kubectl describe nodes master | grep Labels
Labels:             alibabacloud.com/is-edge-worker=false
root@master:~# kubectl describe nodes node1 | grep Labels
Labels:             alibabacloud.com/is-edge-worker=false
root@master:~# kubectl describe nodes node2 | grep Labels
Labels:             alibabacloud.com/is-edge-worker=false
root@master:~# kubectl describe nodes node3 | grep Labels
Labels:             alibabacloud.com/is-edge-worker=true

Configuration of kube-controller-manager
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle
    - --kubeconfig=/etc/kubernetes/controller-manager.conf

/etc/kubernetes/manifests/yurthub.yml
# cat yurthub.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    k8s-app: yurt-hub
  name: yurt-hub
  namespace: kube-system
spec:
  volumes:
  - name: pki
    hostPath:
      path: /etc/kubernetes/pki
      type: Directory
  - name: kubernetes
    hostPath:
      path: /etc/kubernetes
      type: Directory
  - name: pem-dir
    hostPath:
      path: /var/lib/kubelet/pki
      type: Directory
  containers:
  - name: yurt-hub
    image: openyurt/yurthub:latest
    imagePullPolicy: Always
    volumeMounts:
    - name: kubernetes
      mountPath: /etc/kubernetes
    - name: pki
      mountPath: /etc/kubernetes/pki
    - name: pem-dir
      mountPath: /var/lib/kubelet/pki
    command:
    - yurthub
    - --v=2
    - --server-addr=https://<IP_ADDRESS>:6448
    - --node-name=$(NODE_NAME)
    livenessProbe:
      httpGet:
        host: <IP_ADDRESS>
        path: /v1/healthz
        port: 10261
      initialDelaySeconds: 300
      periodSeconds: 5
      failureThreshold: 3
    resources:
      requests:
        cpu: 150m
        memory: 150Mi
      limits:
        memory: 300Mi
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "NET_RAW"]
    env:
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
  hostNetwork: true
  priorityClassName: system-node-critical
  priority:<PHONE_NUMBER>

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# cat  /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
#Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/var/lib/openyurt/kubelet.conf"
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/var/lib/openyurt/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

/var/lib/openyurt/kubelet.conf
# cat /var/lib/openyurt/kubelet.conf
apiVersion: v1
clusters:
- cluster:
    server: http://<IP_ADDRESS>:10261
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    namespace: default
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users:
- name: default-auth

Use kubectl describe to view yurt-hub pod information
# kubectl describe pods yurt-hub-node3 -n kube-system
Name:                 yurt-hub-node3
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Node:                 node3/
Labels:               k8s-app=yurt-hub
Annotations:          kubernetes.io/config.hash: 7be1318d63088969eafcd2fa5887f2ef
                      kubernetes.io/config.mirror: 7be1318d63088969eafcd2fa5887f2ef
                      kubernetes.io/config.seen: 2020-08-18T08:41:27.431580091Z
                      kubernetes.io/config.source: file
Status:               Pending
IP:
IPs:                  <none>
Containers:
  yurt-hub:
    Image:      openyurt/yurthub:latest
    Port:       <none>
    Host Port:  <none>
    Command:
      yurthub
      --v=2
      --server-addr=https://<IP_ADDRESS>:6448
      --node-name=$(NODE_NAME)
    Limits:
      memory:  300Mi
    Requests:
      cpu:     150m
      memory:  150Mi
    Liveness:  http-get http://<IP_ADDRESS>:10261/v1/healthz delay=300s timeout=1s period=5s #success=1 #failure=3
    Environment:
      NODE_NAME:   (v1:spec.nodeName)
    Mounts:
      /etc/kubernetes from kubernetes (rw)
      /etc/kubernetes/pki from pki (rw)
      /var/lib/kubelet/pki from pem-dir (rw)
Volumes:
  pki:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/kubernetes/pki
    HostPathType:  Directory
  kubernetes:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/kubernetes
    HostPathType:  Directory
  pem-dir:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/kubelet/pki
    HostPathType:  Directory
QoS Class:         Burstable
Node-Selectors:    <none>
Tolerations:       :NoExecute
Events:            <none>

Use docker ps on the edge node to view the log of the yurt-hub container. Intercept the last 20 lines
# docker logs 0c89efbe949b --tail 20
I0818 13:54:13.293068       1 health_checker.go:151] ping cluster healthz with result, Get https://<IP_ADDRESS>:6448/healthz: dial tcp <IP_ADDRESS>:6448: connect: connection refused
I0818 13:54:13.561262       1 util.go:177] kubelet get nodes: /api/v1/nodes/node3?resourceVersion=0&timeout=10s with status code 200, spent 331.836µs, left 10 requests in flight
I0818 13:54:15.746576       1 util.go:177] kubelet update leases: /apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/node3?timeout=10s with status code 200, spent 83.127µs, left 10 requests in flight
I0818 13:54:15.828560       1 util.go:177] kubelet get pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3 with status code 200, spent 436.489µs, left 10 requests in flight
I0818 13:54:15.829628       1 util.go:177] kubelet patch pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3/status with status code 200, spent 307.187µs, left 10 requests in flight
I0818 13:54:17.831366       1 util.go:177] kubelet delete pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3 with status code 200, spent 147.492µs, left 10 requests in flight
I0818 13:54:17.833762       1 util.go:177] kubelet create pods: /api/v1/namespaces/kube-system/pods with status code 201, spent 111.762µs, left 10 requests in flight
I0818 13:54:22.273899       1 health_checker.go:151] ping cluster healthz with result, Get https://<IP_ADDRESS>:6448/healthz: dial tcp <IP_ADDRESS>:6448: connect: connection refused
I0818 13:54:23.486523       1 util.go:177] kubelet watch configmaps: /api/v1/namespaces/kube-system/configmaps?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dkube-flannel-cfg&resourceVersion=2161&timeout=7m54s&timeoutSeconds=474&watch=true with status code 200, spent 7m54.000780359s, left 9 requests in flight
I0818 13:54:23.648871       1 util.go:177] kubelet get nodes: /api/v1/nodes/node3?resourceVersion=0&timeout=10s with status code 200, spent 266.182µs, left 10 requests in flight
I0818 13:54:25.748497       1 util.go:177] kubelet update leases: /apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/node3?timeout=10s with status code 200, spent 189.694µs, left 10 requests in flight
I0818 13:54:25.830919       1 util.go:177] kubelet get pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3 with status code 200, spent 1.375535ms, left 10 requests in flight
I0818 13:54:25.835015       1 util.go:177] kubelet patch pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3/status with status code 200, spent 1.363765ms, left 10 requests in flight
I0818 13:54:33.733913       1 util.go:177] kubelet get nodes: /api/v1/nodes/node3?resourceVersion=0&timeout=10s with status code 200, spent 303.499µs, left 10 requests in flight
I0818 13:54:34.261504       1 health_checker.go:151] ping cluster healthz with result, Get https://<IP_ADDRESS>:6448/healthz: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
I0818 13:54:35.751002       1 util.go:177] kubelet update leases: /apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/node3?timeout=10s with status code 200, spent 144.723µs, left 10 requests in flight
I0818 13:54:35.830895       1 util.go:177] kubelet get pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3 with status code 200, spent 1.146812ms, left 10 requests in flight
I0818 13:54:35.834366       1 util.go:177] kubelet patch pods: /api/v1/namespaces/kube-system/pods/yurt-hub-node3/status with status code 200, spent 744.857µs, left 10 requests in flight
I0818 13:54:42.274049       1 health_checker.go:151] ping cluster healthz with result, Get https://<IP_ADDRESS>:6448/healthz: dial tcp <IP_ADDRESS>:6448: connect: connection refused
I0818 13:54:43.818381       1 util.go:177] kubelet get nodes: /api/v1/nodes/node3?resourceVersion=0&timeout=10s with status code 200, spent 248.672µs, left 10 requests in flight

Use kubectl logs to view the logs of yurt-controller-manager. Intercept the last 20 lines
# kubectl logs yurt-controller-manager-59544577cc-t948z -n kube-system --tail 20
E0818 13:56:07.239721       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:10.560864       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:13.288544       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:16.726605       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:19.623694       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:23.572803       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:26.809117       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:29.021205       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:31.271086       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:34.083918       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:37.493386       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:40.222869       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:44.149011       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:47.699211       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:50.177053       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:52.553163       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:55.573328       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:56:58.677034       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:57:02.844152       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0818 13:57:05.044990       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"

At last
	I very much hope that you can help me solve the problem or point out my mistakes. If there is any other information that needs to be provided, please communicate with me in time

Hello, @HirazawaUi
In your steps，Configuration of kube-controller-manager
Please cancel append -nodelifecycle to - --controllers=*,bootstrapsigner,tokencleaner，
In my opinion, Work node sends its health status to master, if send overtime, Master node will change node status;
After install yurt on work node, edge work node sends its health status to yurthub, Master node should change the node status
like descriptions in yurtctl.md;
but if you set kube-controller-manager config -nodelifecycle, Master node will not change status when receive health status overtime.
I don't know if my opinion is right, I will find introduction in Kubernetes.

您好，@HirazawaUi
在您的步骤中，kube-controller-manager的配置
请取消将-nodelifecycle附加到---controllers = *，bootstrapsigner，tokencleaner，
我认为，工作节点会将其运行状况发送给主节点，如果超时发送，则主节点将更改其节点状态。
在工作节点上安装yurt之后，边缘工作节点会将其运行状况发送给yurthub，主节点应
像yurtctl.md中的描述那样更改节点状态；
但是，如果您设置kube-controller-manager config -nodelifecycle，则当超时收到运行状况时，主节点将不会更改状态。
我不知道我的观点是否正确，我会在Kubernetes中找到介绍。

thank you very much for your answers, which solved my problem and now openyurt is running normally. I am not sure if anyone else has encountered this problem, I think this parameter should be described in more detail in the document

Isn't this an expected behavior? With the yurt-controller-manager which re-implements the node lifecycle controller, if an edge node stops sending the heartbeats, the yurt-controller-manager will not mark node NotReady.

这不是预期的行为吗？使用yurt-controller-manager重新实现节点生命周期控制器，如果边缘节点停止发送心跳，则yurt-controller-manager不会将节点标记为NotReady。

In the Test node autonomy chapter of https://github.com/alibaba/openyurt/blob/master/docs/tutorial/yurtctl.md, I see that the expected result is that after modifying yurthub's --server-addr= , The edge node will enter the notready state, and the pod will always be in the running state

Hello, @HirazawaUi
In your steps，Configuration of kube-controller-manager
Please cancel append -nodelifecycle to - --controllers=*,bootstrapsigner,tokencleaner，
In my opinion, Work node sends its health status to master, if send overtime, Master node will change node status;
After install yurt on work node, edge work node sends its health status to yurthub, Master node should change the node status
like descriptions in yurtctl.md;
but if you set kube-controller-manager config -nodelifecycle, Master node will not change status when receive health status overtime.
I don't know if my opinion is right, I will find introduction in Kubernetes.

thank you very much for your answers, which solved my problem and now openyurt is running normally. I am not sure if anyone else has encountered this problem, I think this parameter should be described in more detail in the document

Isn't this an expected behavior? With the yurt-controller-manager which re-implements the node lifecycle controller, if an edge node stops sending the heartbeats, the yurt-controller-manager will not mark node NotReady.

In the Test node autonomy chapter of https://github.com/alibaba/openyurt/blob/master/docs/tutorial/yurtctl.md, I see that the expected result is that after modifying yurthub's --server-addr= , The edge node will enter the notready state, and the pod will always be in the running state

You are right. I take it back. The yurt-controller-manager just does not evict Pods and Node status is still updated to NotReady.

Show nodes status after Convert a multi-nodes Kubernetes cluster in yurtctl.md may be better. Thanks

It is recommended that the default nodelifecycle controller should not be installed, otherwise it will conflict with yurt-controller-manager. In yurtctl tool, to ease the workflow, we delete the nodelifecycle sa from kube-system assuming that
the default nodecontroller will not work without the sa.  Is this possible that in your setup, the default nodelifecycle controller still works (using other SAs)?

I observed that my simple pod entered the Terminating state about five minutes after the edge node stopped sending heartbeats. I don't know if this is normal and meets expectations. There is no similar description in the document

Information output using kubectl get pods
# kubectl get pods
NAME   READY   STATUS        RESTARTS   AGE
bbox   1/1     Terminating   0          59m

Information output using kubectl describe pods bbox
# kubectl describe pods bbox
Name:                      bbox
Namespace:                 default
Priority:                  0
Node:                      node3/<IP_ADDRESS>
Start Time:                Thu, 20 Aug 2020 06:01:18 +0000
Labels:                    <none>
Annotations:               Status:  Terminating (lasts 54m)
Termination Grace Period:  30s
IP:                        <IP_ADDRESS>
IPs:
  IP:  <IP_ADDRESS>
Containers:
  bbox:
    Container ID:  docker://1d7e95fe71f632363f7e811813ce1fd7778cfa53258cc66b5eb5aae39babca68
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:4f47c01fa91355af2865ac10fef5bf6ec9c7f42ad2321377c21e844427972977
    Port:          <none>
    Host Port:     <none>
    Command:
      top
    State:          Running
      Started:      Thu, 20 Aug 2020 06:01:37 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-ccjzj (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-ccjzj:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-ccjzj
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason   Age   From            Message
  ----    ------   ----  ----            -------
  Normal  Pulled   60m   kubelet, node3  Successfully pulled image "busybox"
  Normal  Created  60m   kubelet, node3  Created container bbox
  Normal  Started  60m   kubelet, node3  Started container bbox

It is recommended that the default nodelifecycle controller should not be installed, otherwise it will conflict with yurt-controller-manager. In yurtctl tool, to ease the workflow, we delete the nodelifecycle sa from kube-system assuming that
the default nodecontroller will not work without the sa. Is this possible that in your setup, the default nodelifecycle controller still works (using other SAs)?

I did not find the relevant instructions in the kubernetes documentation, about using other SAs make the default nodelifecycle controller still works. In fact, this is to test the brand new kubernetes cluster installed by openyurt using kubeadm, I haven't made any changes to it

I observed that my simple pod entered the Terminating state about five minutes after the edge node stopped sending heartbeats. I don't know if this is normal and meets expectations. There is no similar description in the document

This looks like the default node controller behavior.  Can you do kubectl get sa -n kube-system | grep node and see if the node controller sa is still there?

I observed that my simple pod entered the Terminating state about five minutes after the edge node stopped sending heartbeats. I don't know if this is normal and meets expectations. There is no similar description in the document

This looks like the default node controller behavior. Can you do kubectl get sa -n kube-system | grep node and see if the node controller sa is still there?

Yes, it exists in the kubernetes cluster，Do I need to delete it?

I observed that my simple pod entered the Terminating state about five minutes after the edge node stopped sending heartbeats. I don't know if this is normal and meets expectations. There is no similar description in the document

This looks like the default node controller behavior. Can you do kubectl get sa -n kube-system | grep node and see if the node controller sa is still there?

Yes, it exists in the kubernetes cluster，Do I need to delete it?

Yes, the Yurtctl supposes to delete this SA (https://github.com/alibaba/openyurt/blob/ea19a211e43324f71a318a2236799b18291df4d8/pkg/yurtctl/cmd/convert/convert.go#L215). You can manually delete it for now. We should figure out why this deletion fails.

@xujunjie-cover your understand is correct. If nodelifecycle controller is disabled, then the node status will never change. However, to my knowledge, the yurt-controller-manager will be responsible for managing the nodelifecycle, therefore the default nodelifecycle should still be disabled. @rambohe-ch would you verify this?
@HirazawaUi I just tried the manually setup process (disable the nodelifecycle controller by applying option --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle), and everything works as expected (node become NotReady after disconnected from the apiserver). Could you check if the edge node is marked as autonomous?  (edgenode has the label node.beta.alibabacloud.com/autonomy=true )

Ah, I realized that you are doing the conversion manually instead of using yurtctl. Then you should use  --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle option to disable the default nodelifecylce controller.
Basically, follow the step mentioned in https://github.com/alibaba/openyurt/blob/master/docs/tutorial/manually-setup.md#disable-the-default-nodelifecycle-controller
Can you please do it and repeat the test? We will go from there and the see what does not meet the expectation.

@xujunjie-cover your understand is correct. If nodelifecycle controller is disabled, then the node status will never change. However, to my knowledge, the yurt-controller-manager will be responsible for managing the nodelifecycle, therefore the default nodelifecycle should still be disabled. @rambohe-ch would you verify this?
@HirazawaUi I just tried the manually setup process (disable the nodelifecycle controller by applying option --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle), and everything works as expected (node become NotReady after disconnected from the apiserver). Could you check if the edge node is marked as autonomous? (edgenode has the label node.beta.alibabacloud.com/autonomy=true )

this is the label and Annotations information of the edge node, alibabacloud.com/is-edge-worker=true label and node.beta.alibabacloud.com/autonomy: true annotation exist
Name:               node3
Roles:              <none>
Labels:             alibabacloud.com/is-edge-worker=true
                    beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=node3
                    kubernetes.io/os=linux
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"fe:5d:79:c2:90:e5"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: <IP_ADDRESS>
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    node.beta.alibabacloud.com/autonomy: true
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Mon, 17 Aug 2020 13:55:19 +0000
Taints:             <none>
Unschedulable:      false
Lease:
  HolderIdentity:  node3
  AcquireTime:     <unset>
  RenewTime:       Fri, 21 Aug 2020 02:29:27 +0000
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Tue, 18 Aug 2020 08:38:30 +0000   Tue, 18 Aug 2020 08:38:30 +0000   FlannelIsUp                  Flannel is running on this node
  MemoryPressure       False   Fri, 21 Aug 2020 02:28:53 +0000   Fri, 21 Aug 2020 02:24:51 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Fri, 21 Aug 2020 02:28:53 +0000   Fri, 21 Aug 2020 02:24:51 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Fri, 21 Aug 2020 02:28:53 +0000   Fri, 21 Aug 2020 02:24:51 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Fri, 21 Aug 2020 02:28:53 +0000   Fri, 21 Aug 2020 02:24:51 +0000   KubeletReady                 kubelet is posting ready status. AppArmor enabled
Addresses:
  InternalIP:  <IP_ADDRESS>
  Hostname:    node3
Capacity:
  cpu:                4
  ephemeral-storage:  102684600Ki
  hugepages-2Mi:      0
  memory:             8168092Ki
  pods:               110
Allocatable:
  cpu:                4
  ephemeral-storage:<PHONE_NUMBER>4
  hugepages-2Mi:      0
  memory:             8065692Ki
  pods:               110
System Info:
  Machine ID:                 0500c02d85d74055b90a973b0bd7a4cc
  System UUID:                6A2B2942-28F3-C25F-F60C-2D14B7B068F2
  Boot ID:                    92c16623-c1be-4064-aa23-4f372029c12b
  Kernel Version:             4.15.0-99-generic
  OS Image:                   Ubuntu 18.04.4 LTS
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://19.3.12
  Kubelet Version:            v1.16.6
  Kube-Proxy Version:         v1.16.6
PodCIDR:                      <IP_ADDRESS>/24
PodCIDRs:                     <IP_ADDRESS>/24
Non-terminated Pods:          (2 in total)
  Namespace                   Name                           CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                   ----                           ------------  ----------  ---------------  -------------  ---
  kube-system                 kube-flannel-ds-amd64-nj6q8    100m (2%)     100m (2%)   50Mi (0%)        50Mi (0%)      3d12h
  kube-system                 kube-proxy-n9nxr               0 (0%)        0 (0%)      0 (0%)           0 (0%)         3d12h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests   Limits
  --------           --------   ------
  cpu                100m (2%)  100m (2%)
  memory             50Mi (0%)  50Mi (0%)
  ephemeral-storage  0 (0%)     0 (0%)
  hugepages-2Mi      0 (0%)     0 (0%)
Events:
  Type    Reason                   Age                 From            Message
  ----    ------                   ----                ----            -------
  Normal  NodeHasSufficientMemory  12m (x21 over 20h)  kubelet, node3  Node node3 status is now: NodeHasSufficientMemory
  Normal  NodeHasNoDiskPressure    12m (x21 over 20h)  kubelet, node3  Node node3 status is now: NodeHasNoDiskPressure
  Normal  NodeHasSufficientPID     12m (x21 over 20h)  kubelet, node3  Node node3 status is now: NodeHasSufficientPID
  Normal  NodeReady                12m (x3 over 20h)   kubelet, node3  Node node3 status is now: NodeReady

Ah, I realized that you are doing the conversion manually instead of using yurtctl. Then you should use --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle option to disable the default nodelifecylce controller.
Basically, follow the step mentioned in https://github.com/alibaba/openyurt/blob/master/docs/tutorial/manually-setup.md#disable-the-default-nodelifecycle-controller
Can you please do it and repeat the test? We will go from there and see what does not meet the expectation.

I have executed kubectl delete -f yurt-controller-manager.yaml to delete the deployment controller and rebuild, but the result is still the same as above, the edge node state is still keep ready, should I try other versions of kubernetes or try to follow the document example only A kubernetes cluster with one master and one pod

I have executed kubectl delete -f yurt-controller-manager.yaml to delete the deployment controller and rebuild, but the result is still the same as above, the edge node state is still keep ready, should I try other versions of kubernetes or try to follow the document example only A kubernetes cluster with one master and one pod

Please note that you should restart the default Kubernetes controller-manager kube-controller-manager in kube-system with the correct option, not the yurt-controller-manager.

I observed that my simple pod entered the Terminating state about five minutes after the edge node stopped sending heartbeats. I don't know if this is normal and meets expectations. There is no similar description in the document

This looks like the default node controller behavior. Can you do kubectl get sa -n kube-system | grep node and see if the node controller sa is still there?

before this. I have modified the --controllers of kube-controller-manager. It has restarted automatically

Ah, I realized that you are doing the conversion manually instead of using yurtctl. Then you should use --controllers=*,bootstrapsigner,tokencleaner,-nodelifecycle option to disable the default nodelifecylce controller.
Basically, follow the step mentioned in https://github.com/alibaba/openyurt/blob/master/docs/tutorial/manually-setup.md#disable-the-default-nodelifecycle-controller
Can you please do it and repeat the test? We will go from there and see what does not meet the expectation.

I have executed kubectl delete -f yurt-controller-manager.yaml to delete the deployment controller and rebuild, but the result is still the same as above, the edge node state is still keep ready, should I try other versions of kubernetes or try to follow the document example only A kubernetes cluster with one master and one node

@HirazawaUi Thanks for the detailed log output. I will verify the manual setup process on a multi-nodes 1.16 Kubernetes, and let you know if the problem can be reproduced.

@charleszheng44 @Fei-Guo
I think I know where the problem is. I fell into a misunderstanding of thinking. I rechecked the log of yurt-controller-manager and found that the problem is simply because the default serviceaccount in kube-system has insufficient permissions.
Then,I use The serviceaccount was created on the command line, and the manifest of yurt-controller-manager was modified to bind it with yurt-controller-manager. Now all the results are in line with expectations
Show the log of yurt-controller-manager again
E0905 07:02:52.347282       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0905 07:02:55.841780       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0905 07:03:00.146093       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0905 07:03:04.198585       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0905 07:03:08.111697       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"
E0905 07:03:12.270039       1 leaderelection.go:330] error retrieving resource lock kube-system/yurt-controller-manager: leases.coordination.k8s.io "yurt-controller-manager" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"

Create serviceaccount
# kubectl -n kube-system create sa yurt-cm
serviceaccount/yurt-cm created
# kubectl create clusterrolebinding yurt-cm --clusterrole=cluster-admin --serviceaccount=kube-system:yurt-cm
clusterrolebinding.rbac.authorization.k8s.io/yurt-cm created

Modify the deploy of yurt-controller-manager
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: yurt-cm
      serviceAccountName: yurt-cm
      terminationGracePeriodSeconds: 30

@charleszheng44
I hit the issue again today, seems we do not resolve it: https://github.com/alibaba/openyurt/issues/52

@charleszheng44
I hit the issue again today, seems we do not resolve it: #52

Thanks for reporting the issue, I forgot to fix it :sweat_smile:. #123 should resolve the problem.


Add etag linting rule

Develop a linter rule that says that “if you have a property named etag, it should have format etag”. And probably that you shouldn’t have “etag” if the property name isn’t etag. And if you are a header named etag, I’d argue that we don’t need to specify format. But we could.

Related issue: https://github.com/Azure/autorest/issues/4536


[extractor/nitter] Update Nitter instance list

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information

Updated the Nitter instance list slightly
Nitter.ca has been dead for months now, added my preferred instance n.l5.ca.
Fixes #
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

Here's the story behind my adding n.l5.ca to yt-dlp:
I used to use nitter.mint.lgbt (already in the list) but that has been getting slower recently so I went to this list to find a faster one. I ended up settling on n.l5.ca. The only issue is that it isn't on this list so I need to replace the name with twitter or some other nitter host before I download.

so I went to this list

Is our list in sync with this now?


Webdriver policyAttributes multi map

The variable policyAttributes that allow users to declare a List of attributes to identify and close policy popups is a Map that does not support the declaration of multiple attributes using the same Map.Key.
https://github.com/TESTARtool/TESTAR_dev/blob/3db158a5aba4ea21c4154c76909f2e1beba5b70e/testar/src/org/testar/protocols/WebdriverProtocol.java#L104
For example, declaring two policy buttons using the same key (class) will only enable the usage of the last value (btn-accept):
policyAttributes.put("class", "btn-cancel");
policyAttributes.put("class", "btn-accept");

A possible solution for this improvement is to allow multiple declarations of values for the same key is to use a MultiMap:
Multimap<String, String> policyAttributes = ArrayListMultimap.create();

Solved with #332


add a note hit-1163710220

I added some notes to your project.

I added some notes to your project.

Thank you very much for your contribution to my project, but I think you need to make more changes.Such as add some entity classes.


Issue report or feature request

Please fill out this template to help us diagnose and address your issue effectively.
Type: (Select one)

[ ] Bug Report

Summary:
While doing deploy on server and getting below error
> `src/utils/loginInfo.ts(117,31): error TS2345: Argument of type '{ storeHash: string; channel_id: number; expires_at: number; allowed_cors_origins: Location[]; }' is not assignable to parameter of type 'Partial<ApiTokenConfig>'.
> 10:44:52 AM: storefront:build:   Types of property 'allowed_cors_origins' are incompatible.
> 10:44:52 AM: storefront:build:     Type 'Location[]' is not assignable to type 'string[]'.
> 10:44:52 AM: storefront:build:       Type 'Location' is not assignable to type 'string'.`

Can you please help to me solve it;?

@BrianJiang2021 - seems like the type introduced in #128 is too restrictive
https://github.com/bigcommerce/b2b-buyer-portal/blob/58d1daa4735b64b37273f9e327443029531a7883/apps/storefront/src/shared/service/b2b/graphql/login.ts#L9
Can we check on this?

@SunilP-WassDigital
A related pr has been created
cc: @bc-micah

hey @BrianJiang2021 has this issue been solved now by that PR?

Hi, @bc-victor
PR: https://github.com/bigcommerce/b2b-buyer-portal/pull/159
production has not yet been deployed