support specify --secret-name for create-remote-secret command

For external Istiod scenario, we will use istio-kubeconfig as secret but now create-remote-secert will use the fixed prefix istio-remote-secret- for the create secret.
Add this flag so this command can be used to support external Istiod as well.

@irisdingbj: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
9af0af72281c3c1fbfdb41ed6c572eea0ee92978
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@irisdingbj: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-multicluster-k8s-tests_istio
5539eaaa1183eb0191454e85e9eabb8866e1dbc5
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@irisdingbj I'm not exactly sure why we need a new naming convention exactly.
For remote clusters, we use istio-remote-secret-<cluster>. This secret already contains an annotation indicating the cluster name, so the fact that we're including the cluster in the name is really just to provide a unique name.  Since we'll likely use a remote cluster as the source of configuration for an external control plane, we don't we just add an additional annotation to the secret that indicates it's a configuration cluster?
@stevenctl WDYT?

I think the what was discussed in the 2 docs about labeling/annotating secrets to identify them as the config cluster would be better than requiring a special name.
This comes along with some refactoring to Pilot bootstrap code to re-use the SecretController logic for the config cluster, so it's a bit of work. In the meantime for testing this command with external control-plane, simply renaming the secret by hand is better than adding this in a user facing place.

@nmittler @stevenctl I need give more background here.
Istiod on external control plane need to use istio-kubeconfig secret  to point its KUBECONFIG to the config cluster.  In the past we are using KUBECONFIG for kubectl directly and it might be short lived. Now we can enhance the create-remote-secret command to generate istio-kubeconfig secret for a specified sa to fullfill this.
So I add the  --secret-name to define the generate secret name instead of the fixed istio-remote-secret-'cluster name"

Users wouldn't edit. We would if we want to experiment. Instead, we need to refactor things so we don't bother with the special mounted secret.

Users wouldn't edit. We would if we want to experiment. Instead, we need to refactor things so we don't bother with the special mounted secret. Rather than a specific secret name, can we watch all files in a directory and mount to that directory, for the initial secret?

I am working on a following up PR which will use the istio-kubeconfig secret generated by this command.  We will also watch this secret.  In case the token in the secret get updated, we will use the updated token automatically in our client.   User can choose to use current mounted secret if they like ( for backward compatibility).

@stevenctl @nmittler  this is the PR which will use the secret generated here. https://github.com/istio/istio/pull/27465

@irisdingbj I agree with @stevenctl here... I'm not sure this is the right approach. I understand that you're just building on what already exists, but the external control plane logic is still WIP and will not be supported for 1.8 anyway. I think now is the right time to discuss what direction we want to go with all of this.
Perhaps we should have a VC to discuss?
FYI @linsun

@stevenctl @nmittler The motivation of this PR was brought up in the env WG last week via this doc
The consensus from the WG is we want to extend create-remote-secret to allow mesh operators to easily create secret for config cluster.
There is only 1 config cluster per external Istiod, and that secret name is not configurable today, which is istio-kubeconfig.  I discussed with @irisdingbj offline to not expose --secret-name but instead allow mesh operators to specify if they are creating remote secrets for config cluster (or remote cluster which is default) via cmd like:
istioctl x create-remote-secret --type=config --service-account istiod-service-account

There is no need to specify secret name in this case, which should help addressing your concerns earlier.  I hope this clarifies things.  Feel free to let us know if a VC is still needed.

@esnible Thanks for the review, PTAL as I have change to --type instead of --secret-name
@nmittler @stevenctl @linsun PTAL

We shouldn't couple the cluster name and whether or not its a config cluster. There are other changes that can be done along with this that enable setting the cluster name for the config cluster without relying on values.global generating flags/env vars to istiod.
The only thing the type flag should do is add the label to the generated secret. We should default to Service type clusters if the --type flag isn't specified in istioctl, or if the label is missing. and spin up k8s service registries for them.

Agreed @stevenctl , cluster name isn't configurable when it is config cluster.  longer term, when we support multiple config clusters, we could make the cluster name configurable.  At the moment, it is not supported.

Just so I understand:

If we have --type has Config, we give the secret a special name
That special name causes us to use the secret the way we do today

We should solidify the design in the doc, I don't feel like I see the long term picture for how this will end up.

your understanding  is correct @stevenctl.
Agree with solidify this in design doc for longer term plan.

@esnible PTAL, Thanks!


Empty multiselect focus issue

This pull request fixes the following issue: when a @aria:MultiSelect widget is empty (i.e. when its items property is an empty array) and when clicking on the dropdown icon to open the popup, the widget gets the focused style and keeps it forever (even when the focus is somewhere else).

This is fine for me, you can merge when you are sure the tests pass on all the platforms!


add architecture diagram

I created a draft architecture diagram, please verify for correctness, our graphics team will clean it up. I also snuck in one or two style fixes.

Looks good, except we will need to include AlphaVantage (for stock prices)

@creitz good call! i'll add something

@creitz see latest revision


Update mm-get-started.md

clarifying some language

@JoanneHendrickson
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Dropdown component render bug in Safari

The dropdown component has a render bug in Safari 9.0.1 on OS X. Check out the arrow in the screenshot below, it has a transparent pixel between the edges...

Thanks for reporting this @jonathanp
Luckily it's limited to retina displays


Mypy: Syntax errors

By mistake, we started using the prerelease version 12.9.0b1 of azure-storage-blob in our CI.
This resulted in these syntax errors from mypy:
/opt/hostedtoolcache/Python/3.8.10/x64/lib/python3.8/site-packages/azure_storage_blob-12.9.0b1-py3.8.egg/azure/storage/blob/_serialize.py:46: error: Type signature has too few arguments [syntax]
/opt/hostedtoolcache/Python/3.8.10/x64/lib/python3.8/site-packages/azure_storage_blob-12.9.0b1-py3.8.egg/azure/storage/blob/_serialize.py:129: error: Type signature has too few arguments [syntax]
/opt/hostedtoolcache/Python/3.8.10/x64/lib/python3.8/site-packages/azure_storage_blob-12.9.0b1-py3.8.egg/azure/storage/blob/_blob_client.py:1408: error: Type signature has too few arguments [syntax]
/opt/hostedtoolcache/Python/3.8.10/x64/lib/python3.8/site-packages/azure_storage_blob-12.9.0b1-py3.8.egg/azure/storage/blob/_blob_client.py:1448: error: Type signature has too few arguments [syntax]

If you check the code at those locations, they are obviously wrong as the number of arguments in the type annotation does not match the number of arguments in the definition.
To avoid these mistakes in future, I'd suggest using the common-practice inline annotations, which would make it impossible to make this mistake:
def get_modify_conditions(kwargs: Dict[str, object]) -> ModifiedAccessConditions:

@Dreamsorcerer, thanks for the suggestion! Directing it to the right people, so they can address this!

Thanks for reporting this @Dreamsorcerer (Sam). We are tracking this work as a part of https://github.com/Azure/azure-sdk-for-python/issues/20083

I fixed some of the type annotations in https://github.com/Azure/azure-sdk-for-python/pull/20084

As another suggestion, it would be a good idea to actually setup mypy as a CI check. I can review PRs or answer questions relating to this if help is needed (I've setup several other projects before).

Broken typing is now released at 12.9.0

Hi all, sorry for the long delay getting these fixed. I believe these have been addressed in #22741 and #23098 and will be part of our next release of 12.10.


Identity operator will be added to my onnx file

Bug description
I had write a multi-input and multi-output network, and I need to export it to onnx file.
When I used load_from_checkpoint(), the app will add identity operator in my onnx file, and the C++ app can't parse the onnx file.
I tried to use torch.load_state_dict, then the onnx file will be clean&clear.
There is unnecessary operator in onnx file.
What version are you seeing the problem on?
v2.0
How to reproduce the bug
No response
Error messages and logs
# Error messages and logs here please

Environment

Current environment
#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0):
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 2.0):
#- Python version (e.g., 3.9):
#- OS (e.g., Linux):
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
#- Running environment of LightningApp (e.g. local, cloud):

More info
No response

@zhuyuanxiang Is there envidence that this is caused by Lightning? Wouldn't it be better to report this to onnx/pytorch?

@zhuyuanxiang Do you have any additional info on this? I'll close the ticket otherwise.


Cursor moves incorrectly when pasting code with service comments

With Flutter 3.3.5 upgrade, the cursor no longer freezes when pasting text with service comments but still is placed incorrectly in some cases.
Moving to backlog due to lesser severity.


Add a siteConfig.markdown.onUnusedDirective: 'throw' option

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Description
The siteConfig.markdown.onUnusedDirective: 'throw' option will throw unused markdown directives.
Has this been requested on Canny?
No response
Motivation
In https://github.com/facebook/docusaurus/pull/9394 we have introduced the ability to warn unused markdown directives. This feature is very useful and helps Babel website nailed quite a few markdown directive bugs: https://github.com/babel/website/pull/3013.
Since the warning messages do not fail the build, it would be great to introduce a siteConfig.markdown.onUnusedDirective: 'throw' option so that it can be checked by the website CI.
API design
// docusaurus.config.js
{
  siteConfig: {
    markdown: {
      onUnusedDirective: 'throw'
    }
}

Have you tried building it?
No response
Self-service

[ ] I'd be willing to contribute this feature to Docusaurus myself.

Hello! This issue sounds very interesting to me. Can someone assign it to me so that I can start working on it?


not a member of trait Error

Hello,
When I'm packaging my code (cargo package), I get this issue:
   Compiling utf-8 v0.7.5
error[E0407]: method `source` is not a member of trait `Error`
  --> /Users/damiencuenot/.cargo/registry/src/github.com-1ecc6299db9ec823/utf-8-0.7.5/src/read.rs:48:5
   |
48 | /     fn source(&self) -> Option<&(dyn Error + 'static)> {
49 | |         match *self {
50 | |             BufReadDecoderError::InvalidByteSequence(_) => None,
51 | |             BufReadDecoderError::Io(ref err) => Some(err),
52 | |         }
53 | |     }
   | |_____^ not a member of trait `Error`

And I'm using the last version of your code:
[package]
name = "utf-8"
version = "0.7.5"
authors = ["Simon Sapin<EMAIL_ADDRESS>description = "Incremental, zero-copy UTF-8 decoding with error handling"
license = "MIT OR Apache-2.0"
repository = "https://github.com/SimonSapin/rust-utf8"
[profile.test]

Do you have an idea about what is happening?
Thanks for your help.
Damien

This method was added in Rust 1.30. You likely need to update your compiler, or downgrade this crate to an older version.
https://doc.rust-lang.org/std/error/trait.Error.html#method.source

You are right!
I wasn't up to date on this VM.
Thanks for the feedback. Issue closed


Uvx does not support @latest when using --from

I was expecting the following to work but it doesnt.
> uvx --from Babel pybabel@latest
The executable `pybabel@latest` was not found.
warning: An executable named `pybabel@latest` is not provided by package `babel`.
The following executables are provided by `babel`:
- pybabel

The other option I thought of doesn´t work either:
> uvx --from Babel@latest pybabel
error: Distribution not found at: XXX

I din't find any helpful information in the documentation

Fair enough :) Thanks for the report.


Updated Direction For Table Placement

Short description of what this resolves:
Changes proposed in this pull request:

Ionic Version: 1.x / 2.x
Fixes: #
The table is actually below not above.

thanks!


Widen support to Symfony 5 and Symfony 6

Add support for Symfony 6 components

symfony/console
symfony/process
symfony/yaml

Update lock file for symfony/console, symfony/process and
symfony/yaml

Duplicate of #2918, #2891 and #2864.
But I'm still in favor of doing this. If there is no extra work required to support symfony 5 and 6, then there is also no reason to forbid it.


Thoughts

Continuing discussion from this long thread :
https://github.com/zouloux/prehook-proof-of-concept/issues/1
Answering @xdev1 :

@xdev1 : It would be really helpful, if the demos in reflex's README.md were written in TypeScript or at least a bunch of non-trivial examples.

True ! In fact, if this lib is used someday, I'll create a cleaner doc with categories, Readme.md will become a classic lib homepage with basic facts and pointing to the doc. For now, I'll keep it this way because it's still in beta and only used by me 🥸 I'll just create some code sandboxes so new users could play with it in plain TSX without having to setup an env.

@xdev1 : Also, using prettier would be very nice. Every syntax that is used with the reflex patterns should work fine with prettier, as a majority of developers (including me 😉) use prettier wherever possible.

Using prettier in the reflex/src ? Why not ! Again this is beta but I may accept to use prettier if I got others maintainers helping me. I'm not a huge fan on prettier on those kind of algorithmes, I often need manual formatting for better understanding. Also very opinionated but clearly not closed to prettier !

@xdev1 : I would consider, not to use the name hooks anymore if it's not "react-like" hooks. Folks will get confused otherwise (especially those who do not like react-like hooks, I know this from own bad experience in other discussions 😄). Maybe extensions could be a good name instead, as those functions are conceptionally extension functions where the first argument (= object) will just be passed implicitly.

Yep, I totally agree ! I was roaming into your https://github.com/js-works/preactive codebase recently and found the naming very interesting, I'll re-use this idea if you are OK 🙌 You are right about how things are named, this is very important for global understanding.

@xdev1 : One major goal for that factory-pattern based components should be to increase conciseness wherever possible and reasonable. In the old days we used stuff like this.props.label which was extremely cumbersome, React now uses just label which is awesome, while reflex uses props.label, which may look okayish first, but if you love React as I do and then you use reflex (or something similar), then even props.label seems way to noisy. I personally really prefer using the variable name p instead of props which reduces noise at a good amount especially in larger components. I know, normally we try to prevent single-character variables (except for maybe i, j, x, y etc.) but here this shortcut makes perfectly sense, IMHO. By the way, I'd also use s for a state object (i.e. s.count instead of state.count) and ctx for the used context values (i.e. ctx.theme).

I agree about how concise is React but I do not find this too much of a drawback. Solid has the same way of dealing with reactive values and props (as in a, object, not destructurable), and it feel fine when you know it. Will keep plain props in source code and examples because not everybody knows that p means props, and by extensions componentProperties. Also always destructuring objects into vars can be sometime noisy, a lot of curly braces to understand, which is fine for a lot of people but can be messy if done wrong. I'll maybe find a way to make defaultProps work with destructuring somehow (in stateless), if it's possible it will be implemented but I feel that stateful and stateless components should not work too differently. If any stateless component you are writing is becoming stateful for any reason, you should not be forced to refacto too much the code, it can be source of errors and frustration.

@xdev1 : Regarding stateless components: I would not provide some special API for those stateless components as it is not really necessary.

Stateless components are / will be very much the same as React functional components, but with the defaultProps and shouldUpdate functions, working like factory components. Maybe it will be through the preset and shouldUpdate extensions, which will work both in factory and stateless components. This can be easily explained in the doc + by raising errors in dev mode if misused.

@xdev1 : Frankly, I do not know, why count.set(count.value + 1) shall be better than setCount(getCount() + 1) or setCount(count() + 1) or count(count() + 1)

Yep that's pretty much the same BUT : Now states are usable both ways :

const myState = state( 0 )
state.value ++ // will trigger component update
// dom is not updated yet
await state.set( newValue )
// or
await state.set( v => v + 1 )
// dom is now updated and ready because of the await

Also, having state.value as a getter, will allow us to implement atomic rendering (diff only nodes that use this getter). It will have better perfs than React in a lot of cases and useState cannot do it because of value as a variable (not possible to track usages)
See @developit twitter thread on this : https://twitter.com/_developit/status/1549001036802625536

@zouloux : I'll search for a solution but the preset hook is maybe the only way to have this working in strict mode.

@xdev1 : The only type-safe solutions that I know are the following ...

@zouloux : I'm starting to like the preset version ! The HOC (curried) version feels more wrong to me because there is a lot of curly / destructuring / generic noise which can be avoided. It is less chars but it feels more to me ^^

}>({
  initialCount: 0
})((p) => {

As always, thanks for your time and your feedbacks ! You rock ! I'll try to re-read everything later because I'll get more subtleties. Also, I'm starting to use the lib on a personal project so I'll surely have some changes to do, will do better docs after this "alpha" phase is finished.

My question was more about, why this
// 98 chars
const count = state(0);
count.set(newValue);
count.set(count.value + 1);
count.set(v => v + 1);

shall be better than that?
// 82 chars
// "atomic rendering" is equally possible
const count = state(0);
count(newValue);
count(count() + 1);
count(v => v + 1);

I personally would use neither of them, but anyway...
And why does count.set(...) return a promise (instead of void)?
Are there any use-cases where this is really necessary?

Stateless components are / will be very much the same as React functional components, but with the defaultProps and shouldUpdate functions, working like factory components. Maybe it will be through the preset and shouldUpdate extensions, which will work both in factory and stateless components.

What's wrong with just using a memo function like React.memo?
If the component functions for stateless components are not pure any longer, like in React, that would be extremely odd and IMHO a really big anti-pattern.
Is it because shouldComponentUpdate is more powerful than React.memo, as you have also access to the component's internal state, and you need that additional power for whatever reasons?

@zouloux Please find here a little demo that uses "default props" and "should component update": » Demo
Counter1 uses the factory pattern with extensions, while Counter2 uses react-like hooks (I have not implemented a hook for "should component update" yet, but the extension version is called optimizeUpdates).
I think it does not make sense that the extensions preset and optimizeUpdates would also be allowed in non-factory component functions. I personally would just never (!) use props deconstructuring for components in the reflex style (only for components in the react style). So if you need "default props" or "should component update" you can very easily add this for any component.


when clicking send, check first if all used addresses are authorized

Enable this feature only when account.chain_type == "goldchain"

When clicking send, use the functionality provided in #206 to check if the used addresses (destination) as well as source addresses are authorised, if not, show that as an error without trying to submit.

Closing this as wontfix, as you won't be able to do this through our cached API for destination addresses not yours. Just make sure @DylanVerstraete, that errors are correctly shown on the form, in case the send action failed due to for example an unauthorised address.


Remove link to awesome-python PR (merged)

The PR was merged, we don't need to ask people to upvote it anymore, right?

I removed this on 3296b4ccc0caa6470e60a6fb4d63274ff44a6eea.


Team problem

Can you reproduce the bug at https://try.gitea.io:

[x] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

Description
I can't leave the team I created because it must have at least 1 member.
I cannot delete the team because there are users in it.
I cannot delete my account because I am in a team.

What version of Gitea is this?
That should only be true of the owners team, and the solution would be to delete the org or add someone else as an owner before removing yourself.


stream has to be disposed always otherwise the file is lock and cannot be replaced

Hi @GioviQ,
Thanks, but... you didn't actually test this change, did you?
The stream needs to stay open while the animator is in use, because it will keep reading from it during the animation. The stream will be disposed when the animator is disposed. If you dispose it right after creating the animator, it will just throw an error as soon as it starts playing...

@thomaslevesque I am testing now and it works as expected. I used CacheFramesInMemory="True" too.
While the animation is running, I can update the gif file with a new version.

oops After a while it does not see anymore the gif, I will change File.Open instead

I used CacheFramesInMemory="True"

In this case, yes, it might work. But by default this is false, and your change throws immediately when the GIF starts playing (I tried).
Anyway, not locking the file during playback was never a goal for this library. The original goal was to reduce memory usage, and for that I need to read for the file instead of holding the whole GIF in memory.


Replace hover events with click on map

Description of PR
The behaviour is now consistent with touch screens. Single click to select, and double click to expand map.
Also removed back button. Double clicking outside map will now go back to country view.
PS: This PR is subject to scrutiny if this behaviour does not seem fit for PC.
Type of PR

[ ] Bugfix
[x] New feature

Relevant Issues
Fixes #717, fixes #1243
Checklist

[x] Compiles and passes lint tests
[x] Properly formatted
[x] Tested on desktop
[x] Tested on phone

Looks good, I think we'll also have to edit the "Hover over a state/UT for more details" text.

I think it'd be good to add the "double click/tap to view districts" below the state name.
Also do you think it would be possible to have said selected state row highlighted (hovered style) too?

@jeremyphilemon Don't make me do this

@shuklaayush 😂


Update Website home page to be a landing page

I recently realized while looking at documentation for another package that: if you go directly to pages (montepy.org) from a web search it's very unclear what MontePy does without leaving the website.
The homepage should include a quick README style introduction (or the actual readme) to provide this context.
Also including the current version on the website might be helpful for users.

NVM. there's a 3 sentence headline at the top.


Update the dependency to core-java 0.10.82-SNAPSHOT.

Auto-generated PR to update core library dependency to the latest version.

Closing as the version has already been updated in https://github.com/SpineEventEngine/jdbc-storage/pull/114.


Added arch to cache path to prevent race conditions with concurrent runs

This PR adds the architecture being built for to the cache path. I was running into an issue running AutoPkg recipes with concurrency where the x86 and arm64 builds for Docker would read/write from/to the same cache path, resulting in some weird behaviour. This fix would mean that those recipe runs are granted different folders for assembling the pkg.

Closing in favour of the updated PR #47


feat: push benefit method

:tada: This PR is included in version 5.0.0-beta.33 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 5.0.0-alpha.18 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


When pubkey is aggregated, the input set contains 0 pubkey

When pubkey is aggregated and the input set contains 0 pubkey, the aggregated public key can be generated and used for signature verification. The example is as follows:
test_case: PubkeyAggrVerifyTestCase { input: PubkeyAggrVerifyTestInput { pubkeys: ["0xa491d1b0ecd9bb917989f0e74f0dea0422eac4a873e5e2644f368dffb9a6e20fd6e10c1b77654d067c0618f6e5a7f79a", "0xb301803f8b5ac4a1133581fc676dfedc60d891dd5fa99028805e5ea5b08d3491af75d0707adab3b70c6a6a580217bf81", "0xb53d21a4cfd562c469cc81514d4ce5a6b577d8403d32a394dc265dd190b47fa9f829fdd7963afdf972e5e77854051f6f", "0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"], message: "0x1212121212121212121212121212121212121212121212121212121212121212", signature: "0xafcb4d980f079265caa61aee3e26bf48bebc5dc3e7f2d7346834d76cbc812f636c937b6b44a9323d8bc4b1cdf71d6811035ddc2634017faab2845308f568f2b9a0356140727356eae9eded8b87fd8cb8024b440c57aee06076128bb32921f584" }, output: false }, deser_rst: true

In current implementation， we don't detect all "0x000" pubic key. In real,  all "0x0" public is not allowed.


Unify error message language for failed allocations

Difficulty: Easy to Medium
I noticed that the error messages for when calloc returns NULL use different strings in different parts of the codebase.
To see an example of what I'm talking about, try this against the root of the repo:
for s in "Unable" "Failed" "Allocation"; do grep -rn -A3 calloc | grep $s; done
There are probably other contexts where a similar thing happens. I think the most thorough fix for this would probably look like enumerating those contexts and perhaps adding some standards to the coding style guide.

CNDP_Team2 working on this


Unable to download docker image (has it been removed ?)

Hi,
following the documentation, I tried the following:
docker run --rm -t -i -p 9000:9000 essembeh/depthy
But I had an error "The system cannot find the file specified."
I'm not sure if it is due to my firewall at work so I need to try it at home.
HOWEVER I noticed on the docker hub that the image is not present when I search for 'essembeh'
https://hub.docker.com/search?q=essembeh&type=image
From what I understand of issue #18 it has been put online in 2014 by @essembeh but now it seems removed.
Please note that I'm a true beginner with docker so I may have missed something, in that case juste tell me where to look for the docker image.

Hi @Celeborn2BeAlive
I'm really sorry, I didn't receive any notfication when you created the ticket.
I sent a PR to @panrafal to integrate a docker file but if the git repository is not linked via webhook to the docker repository, the docker image is not rebuilt every time the git repository is updated.
As I'm not a depthy developper, I couldn't setup the docker and git repositories together to automate the docker image builds.
I only published a demo docker image which became totally outdated because I didn't rebuild it that often.
Recently, I cleaned up some outdated docker images which I did not maintain, that is why you cannot pull essembeh/depthy.
But, you might be able to build the docker image yourself (but it is based on a ubuntu which is EOL).
$ docker build --tag depthy:latest https://github.com/panrafal/depthy.git
$ docker run --rm -t -i -p 9000:9000 depthy:latest

Have fun

I've uploaded a new Docker image here:
docker run --rm -t -i -p 9000:9000 ndahlquist/depthy

(I've also made a PR to update the readme here: #48)

@ndahlquist could you share the Dockerfile you have used to create that image?
I tried with this one: depthy/docker/Dockerfile
but it gives me errors.

Here it is! https://github.com/LeiaInc/depthy/blob/master/Dockerfile
(Not sure if this will work; haven't touched this in years)

Thank you very much


[SMALLFIX] Fix .gitignore to include userlog directory

removes annoying untracked user directory
pr-link: Alluxio/alluxio#8899
change-id: cid-8b7086a0cd8b521b1c5b8545d7436d3bf0ea5810

@aaudiber PTAL

alluxio-bot, merge this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3157/
Test PASSed.


Issue #135: Fix MegaLinter Markdown 403 Error

Closes #135
Note, this is a recreation of Pull Request: https://github.com/Nautilus-Cyberneering/git-queue/pull/140

ACK 60b75dcc849a0ae0249c4185f7868a12c56b26c9

Will merge using the github-merge.py script.


docs: remove downloads; add pix and contact badges

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.


2024.05.2 breaks my camera

Checklist

[X] I have updated the integration to the latest version available
[X] I have checked if the problem is already reported

The problem
2024.05.2 breaks my camera. Everything works again after rolling back to 2024.05.1.
The cards just say "valetudo invalid calibration, please check your configuration". Two browsers, cleared cache.
I set this up a while ago and barely remember how anything works, much less how to troubleshoot. If anything sticks out, let me know. Otherwise I guess I will just keep this version until the heatdeath of the universe.
What version of an integration has described problem?
2024.05.2
What was the last working version of an integration?
2024.05.1
What vacuum model do you have problems with?
Dreame L10 Pro
Please firmware installed on your Vacuum.
1138
What type of platform you use?
VEMLinux (Virtual Machine) such as Proxmox, VMWare, etc.
What version of Home Assistant do you use?
latest as of today
What type of installation are you running?
Home Assistant OS
Camera's settings.
- type: custom:xiaomi-vacuum-map-card
        map_source:
          camera: camera.dreame_l10_2_camera
        calibration_source:
          camera: true
        entity: vacuum.valetudo_l10_2
        vacuum_platform: Hypfer/Valetudo
        tiles:
          - tile_id: battery_level
            entity: vacuum.valetudo_l10_2
            label: Battery
            attribute: battery_level
            icon_source: vacuum.valetudo_l10_2.attributes.battery_icon
            unit: '%'
          - tile_id: fan_speed
            entity: vacuum.valetudo_l10_2
            label: Fan speed
            attribute: fan_speed
            icon: mdi:fan
            translations:
              silent: Silent
              standard: Standard
              medium: Medium
              turbo: Turbo
              auto: Auto
              gentle: Gentle
          - tile_id: filter_left
            label: Filter left
            icon: mdi:air-filter
            unit: h
            multiplier: 0.016666666666666666
            entity: sensor.valetudo_l10_2_main_filter
            precision: 0
            translations: {}
          - tile_id: main_brush_left
            label: Main brush left
            icon: mdi:brush
            unit: h
            multiplier: 0.016666666666666666
            entity: sensor.valetudo_l10_2_main_brush
            precision: 0
            translations: {}
          - tile_id: side_brush_left
            label: Side brush left
            icon: mdi:brush
            unit: h
            multiplier: 0.016666666666666666
            entity: sensor.valetudo_l10_2_right_brush
            precision: 0
            translations: {}
          - tile_id: cleaned_area
            label: Cleaned area
            icon: mdi:texture-box
            unit: m²
            multiplier: 0.0001
            entity: sensor.valetudo_l10_2_current_statistics_area
            precision: 0
            translations: {}
          - tile_id: cleaning_time
            label: Cleaning time
            icon: mdi:timer-sand
            unit: min
            multiplier: 0.016666666666666666
            entity: sensor.valetudo_l10_2_current_statistics_time
            precision: 0
            translations: {}
        icons: []
        map_locked: true
        two_finger_pan: true
        map_modes:
          - template: vacuum_clean_segment
            service_call_schema:
              service: mqtt.publish
              evaluate_data_as_template: false
              service_data:
                topic: valetudo/L10-2/MapSegmentationCapability/clean/set
                payload: >-
                  {"segment_ids": [[selection]], "iterations": [[repeats]],
                  "customOrder": false}
            predefined_selections:
              - id: '1'
                icon:
                  name: mdi:shower-head
                  x: 3102
                  'y': 2962
                label:
                  text: Office bath
                  x: 3102
                  'y': 2962
                  offset_y: 35
                outline:
                  - - 2980
                    - 2875
                  - - 3225
                    - 2875
                  - - 3225
                    - 3050
                  - - 2980
                    - 3050
              - id: '2'
                icon:
                  name: mdi:shower-head
                  x: 2735
                  'y': 2985
                label:
                  text: Master bath
                  x: 2735
                  'y': 2985
                  offset_y: 35
                outline:
                  - - 2485
                    - 2885
                  - - 2985
                    - 2885
                  - - 2985
                    - 3085
                  - - 2485
                    - 3085
              - id: '4'
                icon:
                  name: mdi:chair-rolling
                  x: 3142
                  'y': 3305
                label:
                  text: Office
                  x: 3142
                  'y': 3305
                  offset_y: 35
                outline:
                  - - 2985
                    - 3055
                  - - 3300
                    - 3055
                  - - 3300
                    - 3555
                  - - 2985
                    - 3555
              - id: '5'
                icon:
                  name: mdi:numeric-3-box
                  x: 2255
                  'y': 3465
                label:
                  text: Hall
                  x: 2255
                  'y': 3465
                  offset_y: 35
                outline:
                  - - 1830
                    - 3335
                  - - 2680
                    - 3335
                  - - 2680
                    - 3595
                  - - 1830
                    - 3595
              - id: '3'
                icon:
                  name: mdi:bed-queen
                  x: 2200
                  'y': 3117
                label:
                  text: Master bed
                  x: 2200
                  'y': 3117
                  offset_y: 35
                outline:
                  - - 2020
                    - 2885
                  - - 2380
                    - 2885
                  - - 2380
                    - 3350
                  - - 2020
                    - 3350
          - name: Zone cleanup
            icon: mdi:select-drag
            run_immediately: false
            coordinates_rounding: true
            coordinates_to_meters_divider: 100
            selection_type: MANUAL_RECTANGLE
            max_selections: 5
            repeats_type: EXTERNAL
            max_repeats: 3
            service_call_schema:
              service: mqtt.publish
              evaluate_data_as_template: true
              service_data:
                topic: valetudo/L10-2/ZoneCleaningCapability/start/set
                payload: >-
                  {"zones": [{%for s in ('[[selection]]')|from_json %}{
                  "points": {"pA": { "x": {{s[0]}}, "y": {{s[1]}} }, "pB": {
                  "x": {{s[2]}}, "y": {{s[1]}} }, "pC": { "x": {{s[2]}}, "y":
                  {{s[3]}} }, "pD": { "x": {{s[0]}}, "y": {{s[3]}} } },
                  "iterations": [[repeats]]}{%if not
                  loop.last%},{%endif%}{%endfor%}]}
            predefined_selections: []
            variables: {}

Logs or Errors shown in the HA snapshots (please enable the Debug Mode)
No response
Additional information
No response

@nomonkeynodeal is there a warning that the vacuum is not connected?
I would need the logs of the camera not the configuration of the card.

Update for camera.fuffy_camera fails Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 950, in async_update_ha_state     await self.async_device_update()   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1293, in async_device_update     await self.async_update()   File "/config/custom_components/valetudo_vacuum_camera/camera.py", line 425, in async_update     pil_img = await self.hass.async_create_task(               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   File "/config/custom_components/valetudo_vacuum_camera/camera_processing.py", line 191, in run_async_process_valetudo_data     images = await gather(*tasks)              ^^^^^^^^^^^^^^^^^^^^   File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run     result = self.fn(*self.args, **self.kwargs)              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   File "/config/custom_components/valetudo_vacuum_camera/camera_processing.py", line 169, in process_valetudo_data     result = loop.run_until_complete(              ^^^^^^^^^^^^^^^^^^^^^^^^   File "/usr/local/lib/python3.12/asyncio/base_events.py", line 685, in run_until_complete     return future.result()            ^^^^^^^^^^^^^^^   File "/config/custom_components/valetudo_vacuum_camera/camera_processing.py", line 48, in async_process_valetudo_data     pil_img = await self._map_handler.async_get_image_from_json(               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   File "/config/custom_components/valetudo_vacuum_camera/valetudo/hypfer/image_handler.py", line 268, in async_get_image_from_json     room_id, img_np_array = await self.imd.async_draw_base_layer(                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   File "/config/custom_components/valetudo_vacuum_camera/valetudo/hypfer/image_draw.py", line 68, in async_draw_base_layer     and self.img_h.active_zones[room_id + 1] == 1         ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ IndexError: list index out of range
Mine too, is enough this log?

@brusarp Will have a look on this as soon. It was somehow expected as I did modify the Image_handler.py thanks a lot for the report ;)

@nomonkeynodeal I noticed that when the vacuum get disconnected this is going to happen, is your problem as this?

If yes I will try to fix it within the next version. Thanks also for you report.

@nomonkeynodeal  I did check and probably found the issue in the connector.py that was causing the camera to stop.
The correction for this issue, if it is the same you are facing (as I didn't yet got the logs of the camera) this was a quick easy and easy fix. Dreame are having some issue with MQTT (firmware wise) and also.. 1138 isn't actually a firmware I'm familiar with. I mean what Valetudo version are you using?

If I can be helpful...
Mine is Valetudo 2024.02.0

If I can be helpful... Mine is Valetudo 2024.02.0 Dreame D9

Yep this help thanks @brusarp .. @nomonkeynodeal can you please confirm it is the same for you?

@sca075 can confirm. Seeing the same error after updating.

@nomonkeynodeal I did check and probably found the issue in the connector.py that was causing the camera to stop. The correction for this issue, if it is the same you are facing (as I didn't yet got the logs of the camera) this was a quick easy and easy fix. Dreame are having some issue with MQTT (firmware wise) and also.. 1138 isn't actually a firmware I'm familiar with. I mean what Valetudo version are you using?

Sorry, that is the manufacturer firmware version. I was using Valetudo version 2023.12.0, but I upgraded to 2024.2.0 just now.
I looked for anything in the HA logs before rolling back to 2024.5.1, but I couldn't find any errors. Maybe I needed to look harder. I'd happy to test out whatever you changed.

All, thanks a lot for sharing your experience and feedback.
I'm working on it and probably will release a fix as soon.
I will test the camera with a Drame JSON and come back to you as soon I'm done with it 😉

Okay I was able to reproduce the issue #142 by loading the test json of a D9Pro I had, the condition failing was changed to:
if layer_type == "segment":
                    # Check if the room is active and set a modified color
                    if (
                        self.img_h.active_zones
                        and room_id < (len(self.img_h.active_zones) - 1)
                    ):
                        if self.img_h.active_zones[room_id + 1] == 1:
                            room_color = (
                                ((2 * room_color[0]) + color_zone_clean[0]) // 3,
                                ((2 * room_color[1]) + color_zone_clean[1]) // 3,
                                ((2 * room_color[2]) + color_zone_clean[2]) // 3,
                                ((2 * room_color[3]) + color_zone_clean[3]) // 3,
                            )

The original code lines are: https://github.com/sca075/valetudo_vacuum_camera/blob/ae25662dce40e0f85d12540e506652c29f535187/custom_components/valetudo_vacuum_camera/valetudo/hypfer/image_draw.py#L62-L74
I need some additional test to confirm it works as we expect and as soon I'm done with it I will release the fixes for both connector.py and image_draw.py, once again thanks for your kind understanding and cooperation guys.
If you would consider to star the project this would help :)

All just released the 2024.05.3 that will fix the issues you are facing. At your complete disposal for any clarification's or other requests. Thanks once again for your contributions :)
If you would consider to star the project it would be really appreciated.

Okay I was able to reproduce the issue #142 by loading the test json of a D9Pro I had, the condition failing was changed to:
if layer_type == "segment":
                    # Check if the room is active and set a modified color
                    if (
                        self.img_h.active_zones
                        and room_id < (len(self.img_h.active_zones) - 1)
                    ):
                        if self.img_h.active_zones[room_id + 1] == 1:
                            room_color = (
                                ((2 * room_color[0]) + color_zone_clean[0]) // 3,
                                ((2 * room_color[1]) + color_zone_clean[1]) // 3,
                                ((2 * room_color[2]) + color_zone_clean[2]) // 3,
                                ((2 * room_color[3]) + color_zone_clean[3]) // 3,
                            )

The original code lines are:
https://github.com/sca075/valetudo_vacuum_camera/blob/ae25662dce40e0f85d12540e506652c29f535187/custom_components/valetudo_vacuum_camera/valetudo/hypfer/image_draw.py#L62-L74
I need some additional test to confirm it works as we expect and as soon I'm done with it I will release the fixes for both connector.py and image_draw.py, once again thanks for your kind understanding and cooperation guys. If you would consider to star the project this would help :)

Thanks, I can confirm it's working!


fix: Deactivate Sentry when developing

The type of this PR is: Bugfix

This PR resolves CX-1765
Description
Deactivates sentry when developing by checking for __DEV__ when initializing Sentry.
PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Deactivate sentry when developing - ole

This PR contains the following changes:

Dev changes (Deactivate sentry when developing - ole)

  Generated by :no_entry_sign: dangerJS against 6ae499bbac55ae46653dc36cc0d03aaac3db2052


Forwarding setup to config entry platforms

Calling hass.config_entries.async_forward_entry_setup is deprecated and will be removed in Home Assistant 2025.6. Instead, await hass.config_entries.async_forward_entry_setups as it can load multiple platforms at once and is more efficient since it does not require a separate import executor job for each platform.

https://developers.home-assistant.io/blog/2024/06/12/async_forward_entry_setups/
closes #131

Hi, thank you very much for your PR!
I am quite busy for the moment, so I have no time to test your changes. I'll will look into this as soon as possible. This will probably be next week.
Best regards

Thanks for your feedback!


Update core addon lists

Superseded by #25, which was generated using the latest mk_core_addons which generates de PR and new fragment automatically.


InterestingPatterns-Tuinboon

Write a short description about your art piece, such as what your artwork represents and your experience drawing it!
Its generated different patterns each time using circles and lines.

[x] I have read the steps to getting a blot
[x] I have read all the submission requirements and follow them
[x] I am submitting art that...

[x] is algorithmically generated (will meaningfully change each time the program is run)
[x] is your own work that is not copied from somewhere else
[x] is drawable through the editor(does not use outside tools)
[x] doesn't call Math.random() (See the documentation on randomness)
[x] is drawable on Blot itself (doesn't have lines overlap more than 5 times)

[ ] Doesn't overlap lines more than 5 times     ( im not really sure if this counts or not )
[x] Fits in the working area of 125x125mm
[x] Doesn't rely on colour to look good

If you used based your art on something else, used a tutorial, or remixed it from something else, please link it here:
Lastly, link a picture of your art piece here:
https://github.com/TuinboonDev/blot/blob/main/art/InterestingPatterns-Tuinboon/snapshots/snapshot1.png?raw=true

Hello!
I saw you posted in the slack and I think you got some good feedback over there, but I also just wanted to give you a couple hints over here.
Overall, while I think you do have some cool stuff going on here, you have some work to do before it's a 'blot-worthy' project. Generally, blot worthy projects take ~15-20hrs, and I took closer to 25-30hrs. Also, I would take a look at the submission requirements, and especially this section:

If you want to keep working toward a blot, I would advise finding some more specific artistic inspiration, as this is a good way to get going with a project that will have more complexity and artistry. Maybe you can find a hobby or other interest you have to represent?
I'm excited to see what you make!


Test flake in k8s-multi-node-tests

Seen at https://jenkins.cilium.io/job/cilium/job/cilium/job/PR-1406/1/execution/node/29/log/
00:09:51.470 ==> k8s2-build-PR-1406-1: [csr] Received signed certificate from the API server, generating KubeConfig...
00:09:51.470 ==> k8s2-build-PR-1406-1: [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
00:09:51.470 ==> k8s2-build-PR-1406-1:
00:09:51.470 ==> k8s2-build-PR-1406-1: Node join complete:
00:09:51.470 ==> k8s2-build-PR-1406-1: * Certificate signing request sent to master and response
00:09:51.470 ==> k8s2-build-PR-1406-1:   received.
00:09:51.470 ==> k8s2-build-PR-1406-1: * Kubelet informed of new secure connection details.
00:09:51.470 ==> k8s2-build-PR-1406-1:
00:09:51.470 ==> k8s2-build-PR-1406-1: Run 'kubectl get nodes' on the master to see this machine join.
00:09:51.470 ==> k8s2-build-PR-1406-1: node "k8s-1" tainted
00:09:51.470 ==> k8s2-build-PR-1406-1: ---
00:09:51.470 ==> k8s2-build-PR-1406-1: endpoints:
00:09:51.470 ==> k8s2-build-PR-1406-1: - https://<IP_ADDRESS>:2379
00:09:51.470 ==> k8s2-build-PR-1406-1: ca-file: '/var/lib/cilium/etcd-ca.pem'
00:09:51.470 ==> k8s2-build-PR-1406-1: Running provisioner: ssh_accept_env (shell)...
00:09:51.878     k8s2-build-PR-1406-1: Running: inline script
00:09:51.878 ==> k8s2-build-PR-1406-1: Running provisioner: shell...
00:09:52.261     k8s2-build-PR-1406-1: Running: inline script
00:09:52.644 ==> k8s2-build-PR-1406-1: Running provisioner: shell...
00:09:53.027     k8s2-build-PR-1406-1: Running: inline script
00:09:53.027 ==> k8s2-build-PR-1406-1: Running provisioner: cilium-slave-netconfig (shell)...
00:09:53.410     k8s2-build-PR-1406-1: Running: inline script
00:09:53.411 ==> k8s2-build-PR-1406-1: Running provisioner: load-docker-image (shell)...
00:09:54.228     k8s2-build-PR-1406-1: Running: inline script
00:09:54.229 ==> k8s2-build-PR-1406-1: local_build: Pulling from cilium
00:09:54.229 ==> k8s2-build-PR-1406-1: f71841908c6f: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 88594daaf43f: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: b420183319a4: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 1903e8bcc8d4: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: f25897afa1a0: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 0e03000c5613: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 574f0a83ce63: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: e38569fec443: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 2c542472f849: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 7f414530bf73: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 2eda520e4abc: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 841f1e75791b: Pulling fs layer
00:09:54.229 ==> k8s2-build-PR-1406-1: 1903e8bcc8d4: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: f25897afa1a0: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 0e03000c5613: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 574f0a83ce63: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: e38569fec443: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 2c542472f849: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 7f414530bf73: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 2eda520e4abc: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 841f1e75791b: Waiting
00:09:54.229 ==> k8s2-build-PR-1406-1: 88594daaf43f: Verifying Checksum
00:09:54.229 ==> k8s2-build-PR-1406-1: 88594daaf43f: Download complete
00:09:54.229 ==> k8s2-build-PR-1406-1: b420183319a4: Verifying Checksum
00:09:54.229 ==> k8s2-build-PR-1406-1: b420183319a4: Download complete
00:09:54.611 ==> k8s2-build-PR-1406-1: 1903e8bcc8d4: Verifying Checksum
00:09:54.611 ==> k8s2-build-PR-1406-1: 1903e8bcc8d4: Download complete
00:09:54.995 ==> k8s2-build-PR-1406-1: f25897afa1a0:
00:09:54.995 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:09:54.995 ==> k8s2-build-PR-1406-1: f25897afa1a0:
00:09:54.995 ==> k8s2-build-PR-1406-1: Download complete
00:09:54.995 ==> k8s2-build-PR-1406-1: f71841908c6f:
00:09:54.995 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:09:54.995 ==> k8s2-build-PR-1406-1: f71841908c6f:
00:09:54.995 ==> k8s2-build-PR-1406-1: Download complete
00:09:55.378 ==> k8s2-build-PR-1406-1: 0e03000c5613:
00:09:55.378 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:09:55.378 ==> k8s2-build-PR-1406-1: 0e03000c5613:
00:09:55.378 ==> k8s2-build-PR-1406-1: Download complete
00:09:55.378 ==> k8s2-build-PR-1406-1: 574f0a83ce63:
00:09:55.378 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:09:55.378 ==> k8s2-build-PR-1406-1: 574f0a83ce63:
00:09:55.378 ==> k8s2-build-PR-1406-1: Download complete
00:10:00.567 ==> k8s2-build-PR-1406-1: 2c542472f849: Verifying Checksum
00:10:00.568 ==> k8s2-build-PR-1406-1: 2c542472f849: Download complete
00:10:04.055 ==> k8s2-build-PR-1406-1: 7f414530bf73:
00:10:04.055 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:10:04.055 ==> k8s2-build-PR-1406-1: 7f414530bf73:
00:10:04.055 ==> k8s2-build-PR-1406-1: Download complete
00:10:04.055 ==> k8s2-build-PR-1406-1: 2eda520e4abc:
00:10:04.055 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:10:04.055 ==> k8s2-build-PR-1406-1: 2eda520e4abc:
00:10:04.055 ==> k8s2-build-PR-1406-1: Download complete
00:10:06.027 ==> k8s2-build-PR-1406-1: 841f1e75791b:
00:10:06.027 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:10:06.027 ==> k8s2-build-PR-1406-1: 841f1e75791b:
00:10:06.027 ==> k8s2-build-PR-1406-1: Download complete
00:10:06.842 ==> k8s2-build-PR-1406-1: e38569fec443:
00:10:06.842 ==> k8s2-build-PR-1406-1: Verifying Checksum
00:10:06.842 ==> k8s2-build-PR-1406-1: e38569fec443:
00:10:06.842 ==> k8s2-build-PR-1406-1: Download complete
00:10:08.720 ==> k8s2-build-PR-1406-1: f71841908c6f:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: 88594daaf43f:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: b420183319a4:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: 1903e8bcc8d4:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: f25897afa1a0:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: 0e03000c5613:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:08.720 ==> k8s2-build-PR-1406-1: 574f0a83ce63:
00:10:08.720 ==> k8s2-build-PR-1406-1: Pull complete
00:10:32.868 ==> k8s2-build-PR-1406-1: e38569fec443:
00:10:32.868 ==> k8s2-build-PR-1406-1: Pull complete
00:10:32.868 ==> k8s2-build-PR-1406-1: 2c542472f849:
00:10:32.868 ==> k8s2-build-PR-1406-1: Pull complete
00:10:42.370 ==> k8s2-build-PR-1406-1: 7f414530bf73:
00:10:42.371 ==> k8s2-build-PR-1406-1: Pull complete
00:10:42.371 ==> k8s2-build-PR-1406-1: 2eda520e4abc:
00:10:42.371 ==> k8s2-build-PR-1406-1: Pull complete
00:10:42.371 ==> k8s2-build-PR-1406-1: 841f1e75791b:
00:10:42.371 ==> k8s2-build-PR-1406-1: Pull complete
00:10:42.371 ==> k8s2-build-PR-1406-1: Digest: sha256:b8b02b687974b7ba10c7c352759811654f5ca71291b0aa530d7e7dc5ceec0aab
00:10:42.371 ==> k8s2-build-PR-1406-1: Status: Downloaded newer image for <IP_ADDRESS>:5000/cilium:local_build
00:10:42.371 make k8s-multi-node-tests
00:10:42.371 + make k8s-multi-node-tests
00:10:42.371 ./run-tests.bash
00:10:42.371 +++ dirname ./run-tests.bash
00:10:42.371 ++ cd .
00:10:42.371 ++ pwd
00:10:42.371 + dir=/root/jenkins/workspace/cilium_cilium_PR-1406-WUNYE6H7D7ABYE6OBLMHTPCLTKXJBWR4TP3FN6FNDMPTOFWAA4LQ/tests/k8s
00:10:42.371 + source /root/jenkins/workspace/cilium_cilium_PR-1406-WUNYE6H7D7ABYE6OBLMHTPCLTKXJBWR4TP3FN6FNDMPTOFWAA4LQ/tests/k8s/../helpers.bash
00:10:42.371 ++ CILIUM_FILES=cilium-files
00:10:42.371 +++ mktemp
00:10:42.371 ++ DUMP_FILE=/tmp/tmp.irPHVctS1x
00:10:42.371 ++ MONITOR_PID=
00:10:42.371 ++ LAST_LOG_DATE=
00:10:42.371 ++ TEST_NET=cilium
00:10:42.371 ++ BUILD_NUM=1
00:10:42.371 ++ JOB_BASE=PR-1406
00:10:42.371 ++ BUILD_ID=PR-1406-1
00:10:42.371 ++ AGENT_SOCK_PATH=/var/run/cilium/cilium.sock
00:10:42.371 ++ for bin in '"../cilium/cilium"' '"../daemon/cilium-agent"' '"../plugins/cilium-docker/cilium-docker"'
00:10:42.371 ++ '[' -f ../cilium/cilium ']'
00:10:42.371 ++ for bin in '"../cilium/cilium"' '"../daemon/cilium-agent"' '"../plugins/cilium-docker/cilium-docker"'
00:10:42.371 ++ '[' -f ../daemon/cilium-agent ']'
00:10:42.371 ++ for bin in '"../cilium/cilium"' '"../daemon/cilium-agent"' '"../plugins/cilium-docker/cilium-docker"'
00:10:42.371 ++ '[' -f ../plugins/cilium-docker/cilium-docker ']'
00:10:42.371 +++ dirname ./run-tests.bash
00:10:42.371 ++ cd .
00:10:42.371 ++ pwd
00:10:42.371 + dir=/root/jenkins/workspace/cilium_cilium_PR-1406-WUNYE6H7D7ABYE6OBLMHTPCLTKXJBWR4TP3FN6FNDMPTOFWAA4LQ/tests/k8s
00:10:42.371 ++ get_k8s_vm_name k8s1
00:10:42.371 ++ check_num_params 1 1
00:10:42.371 ++ local NUM_PARAMS=1
00:10:42.371 ++ local NUM_EXPECTED_PARAMS=1
00:10:42.371 ++ '[' 1 -ne 1 ']'
00:10:42.371 ++ local VM_PREFIX=k8s1
00:10:42.371 ++ '[' '!' -z 1 ']'
00:10:42.371 ++ local BUILD_ID_NAME=-build-PR-1406-1
00:10:42.371 ++ echo k8s1-build-PR-1406-1
00:10:42.371 + node1=k8s1-build-PR-1406-1
00:10:42.371 ++ get_k8s_vm_name k8s2
00:10:42.371 ++ check_num_params 1 1
00:10:42.371 ++ local NUM_PARAMS=1
00:10:42.371 ++ local NUM_EXPECTED_PARAMS=1
00:10:42.371 ++ '[' 1 -ne 1 ']'
00:10:42.371 ++ local VM_PREFIX=k8s2
00:10:42.371 ++ '[' '!' -z 1 ']'
00:10:42.371 ++ local BUILD_ID_NAME=-build-PR-1406-1
00:10:42.371 ++ echo k8s2-build-PR-1406-1
00:10:42.371 + node2=k8s2-build-PR-1406-1
00:10:42.371 + run_tests 1.6.6-00
00:10:42.371 + k8s_version=1.6.6-00
00:10:42.371 + echo '====================== K8S VERSION ======================'
00:10:42.371 ====================== K8S VERSION ======================
00:10:42.371 + echo 'Node 1'
00:10:42.371 Node 1
00:10:42.371 + vagrant ssh k8s1-build-PR-1406-1 -- -t 'kubectl version'
00:10:43.808 Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:34:20Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
00:10:43.808 Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
00:10:43.808 + echo 'Node 2'
00:10:43.808 Node 2
00:10:43.808 + vagrant ssh k8s2-build-PR-1406-1 -- -t 'kubectl version'
00:10:46.332 Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:34:20Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
00:10:46.332 Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
00:10:46.332 + echo '================== Running in IPv4 mode =================='
00:10:46.332 ================== Running in IPv4 mode ==================
00:10:46.332 + reinstall_ipv4 k8s1-build-PR-1406-1 1.6.6-00
00:10:46.332 + vm=k8s1-build-PR-1406-1
00:10:46.332 + k8s_version=1.6.6-00
00:10:46.332 + vmssh k8s1-build-PR-1406-1 '/home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash reinstall --yes-delete-all-data'
00:10:46.332 + k8s_version=1.6.6-00
00:10:46.332 + vagrant ssh k8s1-build-PR-1406-1 -- -o SendEnv=k8s_version -t /home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash reinstall --yes-delete-all-data
00:10:48.337 [preflight] Running pre-flight checks
00:10:48.337 [reset] Stopping the kubelet service
00:10:48.337 [reset] Unmounting mounted directories in "/var/lib/kubelet"
00:10:48.337 [reset] Removing kubernetes-managed containers
00:10:48.719 [reset] No etcd manifest found in "/etc/kubernetes/manifests/etcd.yaml", assuming external etcd.
00:10:48.719 [reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d /var/lib/dockershim]
00:10:48.719 [reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
00:10:48.719 [reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]
00:10:48.719 6c9889dcadd6
00:10:48.719 [Unit]
00:10:48.719 Description=etcd
00:10:48.719 Documentation=https://github.com/coreos
00:10:48.719
00:10:48.719 [Service]
00:10:48.719 ExecStart=/usr/bin/etcd --name master \
00:10:48.719   --cert-file=/etc/etcd/kubernetes.pem \
00:10:48.719   --key-file=/etc/etcd/kubernetes-key.pem \
00:10:48.719   --peer-cert-file=/etc/etcd/kubernetes.pem \
00:10:48.719   --peer-key-file=/etc/etcd/kubernetes-key.pem \
00:10:48.719   --trusted-ca-file=/etc/etcd/ca.pem \
00:10:48.719   --peer-trusted-ca-file=/etc/etcd/ca.pem \
00:10:48.719   --peer-client-cert-auth \
00:10:48.719   --initial-advertise-peer-urls https://<IP_ADDRESS>:2380 \
00:10:48.719   --listen-peer-urls https://<IP_ADDRESS>:2380 \
00:10:48.719   --listen-client-urls https://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:2379 \
00:10:48.719   --advertise-client-urls https://<IP_ADDRESS>:2379 \
00:10:48.719   --initial-cluster-token etcd-cluster-0 \
00:10:48.719   --initial-cluster master=https://<IP_ADDRESS>:2380 \
00:10:48.719   --initial-cluster-state new \
00:10:48.719   --data-dir=/var/lib/etcd
00:10:48.719 Restart=on-failure
00:10:48.719 RestartSec=5
00:10:48.719
00:10:48.719 [Install]
00:10:48.719 WantedBy=multi-user.target
00:10:48.719 * etcd.service - etcd
00:10:48.719    Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: enabled)
00:10:48.719    Active: active (running) since Mon 2017-08-28 10:56:38 UTC; 19ms ago
00:10:48.719      Docs: https://github.com/coreos
00:10:48.719  Main PID: 18005 (etcd)
00:10:48.719     Tasks: 1 (limit: 4915)
00:10:48.719    Memory: 848.0K
00:10:48.719       CPU: 906us
00:10:48.719    CGroup: /system.slice/etcd.service
00:10:48.719            `-18005 /usr/bin/etcd --name master --cert-file=/etc/etcd/kubernetes.pem --key-file=/etc/etcd/kubernetes-key.pem --peer-cert-file=/etc/etcd/kubernetes.pem --peer-key-file=/etc/etcd/kubernetes-key.pem --trusted-ca-file=/etc/etcd/ca.pem --peer-trusted-ca-file=/etc/etcd/ca.pem --peer-client-cert-auth --initial-advertise-peer-urls https://<IP_ADDRESS>:2380 --listen-peer-urls https://<IP_ADDRESS>:2380 --listen-client-urls https://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:2379 --advertise-client-urls https://<IP_ADDRESS>:2379 --initial-cluster-token etcd-cluster-0 --initial-cluster master=https://<IP_ADDRESS>:2380 --initial-cluster-state new --data-dir=/var/lib/etcd
00:10:48.719
00:10:48.719 Aug 28 10:56:38 k8s-1 systemd[1]: Started etcd.
00:10:49.104 [kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
00:10:49.104 [init] Using Kubernetes version: v1.6.6
00:10:49.104 [init] Using Authorization mode: RBAC
00:10:49.104 [preflight] Running pre-flight checks
00:10:49.922 [preflight] Starting the kubelet service
00:10:49.922 [certificates] Generated CA certificate and key.
00:10:50.303 [certificates] Generated API server certificate and key.
00:10:50.304 [certificates] API Server serving cert is signed for DNS names [k8s-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cilium-k8s-tests.local] and IPs [<IP_ADDRESS> <IP_ADDRESS>]
00:10:50.304 [certificates] Generated API server kubelet client certificate and key.
00:10:50.775 [certificates] Generated service account token signing key and public key.
00:10:50.775 [certificates] Generated front-proxy CA certificate and key.
00:10:51.156 [certificates] Generated front-proxy client certificate and key.
00:10:51.156 [certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
00:10:51.156 [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
00:10:51.553 [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
00:10:51.553 [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
00:10:51.937 [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
00:10:51.938 [apiclient] Created API client, waiting for the control plane to become ready
00:11:08.972 [apiclient] All control plane components are healthy after 15.515880 seconds
00:11:08.972 [apiclient] Waiting for at least one node to register
00:11:14.482 [apiclient] First node has registered after 6.505494 seconds
00:11:14.482 [token] Using token: 123456.abcdefghijklmnop
00:11:14.482 [apiconfig] Created RBAC rules
00:11:14.482 [addons] Created essential addon: kube-proxy
00:11:14.482 [addons] Created essential addon: kube-dns
00:11:14.482
00:11:14.482 Your Kubernetes master has initialized successfully!
00:11:14.482
00:11:14.482 To start using your cluster, you need to run (as a regular user):
00:11:14.482
00:11:14.482   sudo cp /etc/kubernetes/admin.conf $HOME/
00:11:14.482   sudo chown $(id -u):$(id -g) $HOME/admin.conf
00:11:14.482   export KUBECONFIG=$HOME/admin.conf
00:11:14.482
00:11:14.482 You should now deploy a pod network to the cluster.
00:11:14.482 Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
00:11:14.482   http://kubernetes.io/docs/admin/addons/
00:11:14.482
00:11:14.482 You can now join any number of machines by running the following on each node
00:11:14.482 as root:
00:11:14.482
00:11:14.482   kubeadm join --token 123456.abcdefghijklmnop <IP_ADDRESS>:6443
00:11:14.482
00:11:14.482 ---
00:11:14.482 endpoints:
00:11:14.482 - https://<IP_ADDRESS>:2379
00:11:14.482 ca-file: '/var/lib/cilium/etcd-ca.pem'
00:11:14.482 + vmssh k8s1-build-PR-1406-1 'sudo cp -R /root/.kube /home/vagrant'
00:11:14.482 + k8s_version=1.6.6-00
00:11:14.482 + vagrant ssh k8s1-build-PR-1406-1 -- -o SendEnv=k8s_version -t sudo cp -R /root/.kube /home/vagrant
00:11:15.950 + vmssh k8s1-build-PR-1406-1 'sudo chown vagrant.vagrant -R /home/vagrant/.kube'
00:11:15.950 + k8s_version=1.6.6-00
00:11:15.950 + vagrant ssh k8s1-build-PR-1406-1 -- -o SendEnv=k8s_version -t sudo chown vagrant.vagrant -R /home/vagrant/.kube
00:11:17.257 + reinstall_ipv4 k8s2-build-PR-1406-1 1.6.6-00
00:11:17.258 + vm=k8s2-build-PR-1406-1
00:11:17.258 + k8s_version=1.6.6-00
00:11:17.258 + vmssh k8s2-build-PR-1406-1 '/home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash reinstall --yes-delete-all-data'
00:11:17.258 + k8s_version=1.6.6-00
00:11:17.258 + vagrant ssh k8s2-build-PR-1406-1 -- -o SendEnv=k8s_version -t /home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash reinstall --yes-delete-all-data
00:11:19.132 Failed to stop etcd.service: Unit etcd.service not loaded.
00:11:19.514 [preflight] Running pre-flight checks
00:11:19.514 [reset] Stopping the kubelet service
00:11:19.514 [reset] Unmounting mounted directories in "/var/lib/kubelet"
00:11:19.514 [reset] Removing kubernetes-managed containers
00:11:19.514 [reset] No etcd manifest found in "/etc/kubernetes/manifests/etcd.yaml", assuming external etcd.
00:11:19.514 [reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d /var/lib/dockershim]
00:11:19.514 [reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
00:11:19.514 [reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]
00:11:19.514 [kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
00:11:19.514 [preflight] Running pre-flight checks
00:11:19.514 [preflight] Starting the kubelet service
00:11:19.514 [discovery] Trying to connect to API Server "<IP_ADDRESS>:6443"
00:11:19.514 [discovery] Created cluster-info discovery client, requesting info from "https://<IP_ADDRESS>:6443"
00:11:24.836 [discovery] Cluster info signature and contents are valid, will use API Server "https://<IP_ADDRESS>:6443"
00:11:24.837 [discovery] Successfully established connection with API Server "<IP_ADDRESS>:6443"
00:11:24.837 [bootstrap] Detected server version: v1.6.6
00:11:24.837 [bootstrap] The server supports the Certificates API (certificates.k8s.io/v1beta1)
00:11:24.837 [csr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request
00:11:24.837 [csr] Received signed certificate from the API server, generating KubeConfig...
00:11:24.837 [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
00:11:24.837
00:11:24.837 Node join complete:
00:11:24.837 * Certificate signing request sent to master and response
00:11:24.837   received.
00:11:24.837 * Kubelet informed of new secure connection details.
00:11:24.837
00:11:24.837 Run 'kubectl get nodes' on the master to see this machine join.
00:11:24.837 node "k8s-1" tainted
00:11:24.837 ---
00:11:24.837 endpoints:
00:11:24.837 - https://<IP_ADDRESS>:2379
00:11:24.837 ca-file: '/var/lib/cilium/etcd-ca.pem'
00:11:24.837 + vmssh k8s2-build-PR-1406-1 'sudo cp -R /root/.kube /home/vagrant'
00:11:24.837 + k8s_version=1.6.6-00
00:11:24.837 + vagrant ssh k8s2-build-PR-1406-1 -- -o SendEnv=k8s_version -t sudo cp -R /root/.kube /home/vagrant
00:11:26.710 + vmssh k8s2-build-PR-1406-1 'sudo chown vagrant.vagrant -R /home/vagrant/.kube'
00:11:26.710 + k8s_version=1.6.6-00
00:11:26.710 + vagrant ssh k8s2-build-PR-1406-1 -- -o SendEnv=k8s_version -t sudo chown vagrant.vagrant -R /home/vagrant/.kube
00:11:28.583 + deploy_cilium 1.6.6-00
00:11:28.583 + k8s_version=1.6.6-00
00:11:28.583 + vmssh k8s2-build-PR-1406-1 '/home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash deploy_cilium'
00:11:28.583 + k8s_version=1.6.6-00
00:11:28.583 + vagrant ssh k8s2-build-PR-1406-1 -- -o SendEnv=k8s_version -t /home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/cluster/cluster-manager.bash deploy_cilium
00:11:30.452 clusterrole "cilium" created
00:11:30.452 serviceaccount "cilium" created
00:11:30.452 clusterrolebinding "cilium" created
00:11:30.452 daemonset "cilium" created
00:11:30.452 Waiting for 2 instances of Cilium daemon cilium in namespace kube-system to become ready
00:11:30.835 NAME         DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE-SELECTOR   AGE
00:11:30.835 cilium       2         2         0         2            0           <none>          0s
00:11:30.835 kube-proxy   2         2         1         2            1           <none>          17s
00:11:30.835 NAME                            READY     STATUS              RESTARTS   AGE       IP              NODE
00:11:30.835 cilium-0chdj                    0/1       Pending             0          0s        <none>          k8s-2
00:11:30.835 cilium-dv0mc                    0/1       ContainerCreating   0          0s        <IP_ADDRESS>   k8s-1
00:11:30.835 kube-controller-manager-k8s-1   1/1       Running             0          23s       <IP_ADDRESS>   k8s-1
00:11:30.835 kube-dns-1930225767-lkjpq       0/3       Pending             0          6s        <none>
00:11:30.835 kube-proxy-pl7bx                0/1       Pending             0          0s        <none>          k8s-2
00:11:30.835 kube-proxy-rh419                1/1       Running             0          6s        <IP_ADDRESS>   k8s-1
00:11:30.835 kube-scheduler-k8s-1            1/1       Running             0          22s       <IP_ADDRESS>   k8s-1
00:11:33.425  [0/2]NAME         DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE-SELECTOR   AGE
00:11:33.426 cilium       2         2         1         2            1           <none>          2s
00:11:33.426 kube-proxy   2         2         1         2            1           <none>          19s
00:11:33.426 NAME                            READY     STATUS    RESTARTS   AGE       IP              NODE
00:11:33.426 cilium-0chdj                    0/1       Pending   0          2s        <none>          k8s-2
00:11:33.426 cilium-dv0mc                    1/1       Running   0          2s        <IP_ADDRESS>   k8s-1
00:11:33.426 kube-controller-manager-k8s-1   1/1       Running   0          25s       <IP_ADDRESS>   k8s-1
00:11:33.426 kube-dns-1930225767-lkjpq       0/3       Pending   0          8s        <none>
00:11:33.426 kube-proxy-pl7bx                0/1       Pending   0          2s        <none>          k8s-2
00:11:33.426 kube-proxy-rh419                1/1       Running   0          8s        <IP_ADDRESS>   k8s-1
00:11:33.426 kube-scheduler-k8s-1            1/1       Running   0          24s       <IP_ADDRESS>   k8s-1
00:11:35.510  [1/2]NAME         DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE-SELECTOR   AGE
00:11:35.510 cilium       2         2         1         2            1           <none>          5s
00:11:35.510 kube-proxy   2         2         1         2            1           <none>          22s
00:11:35.510 NAME                            READY     STATUS              RESTARTS   AGE       IP              NODE
00:11:35.510 cilium-0chdj                    0/1       ContainerCreating   0          5s        <IP_ADDRESS>   k8s-2
00:11:35.510 cilium-dv0mc                    1/1       Running             0          5s        <IP_ADDRESS>   k8s-1
00:11:35.510 kube-controller-manager-k8s-1   1/1       Running             0          28s       <IP_ADDRESS>   k8s-1
00:11:35.510 kube-dns-1930225767-lkjpq       0/3       Pending             0          11s       <none>
00:11:35.510 kube-proxy-pl7bx                0/1       ContainerCreating   0          5s        <IP_ADDRESS>   k8s-2
00:11:35.510 kube-proxy-rh419                1/1       Running             0          11s       <IP_ADDRESS>   k8s-1
00:11:35.510 kube-scheduler-k8s-1            1/1       Running             0          27s       <IP_ADDRESS>   k8s-1
00:11:38.033  [1/2]+ kubectl -n kube-system get pods -o wide
00:11:38.033 NAME                            READY     STATUS    RESTARTS   AGE       IP              NODE
00:11:38.033 cilium-0chdj                    1/1       Running   0          7s        <IP_ADDRESS>   k8s-2
00:11:38.033 cilium-dv0mc                    1/1       Running   0          7s        <IP_ADDRESS>   k8s-1
00:11:38.033 kube-controller-manager-k8s-1   1/1       Running   0          30s       <IP_ADDRESS>   k8s-1
00:11:38.033 kube-dns-1930225767-lkjpq       0/3       Pending   0          13s       <none>
00:11:38.033 kube-proxy-pl7bx                1/1       Running   0          7s        <IP_ADDRESS>   k8s-2
00:11:38.033 kube-proxy-rh419                1/1       Running   0          13s       <IP_ADDRESS>   k8s-1
00:11:38.033 kube-scheduler-k8s-1            1/1       Running   0          29s       <IP_ADDRESS>   k8s-1
00:11:38.033 + echo 'lb='\'''\'''
00:11:38.033 + vmssh k8s2-build-PR-1406-1 'set -e; for test in /home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/tests/*.sh; do $test; done'
00:11:38.033 + k8s_version=1.6.6-00
00:11:38.033 + vagrant ssh k8s2-build-PR-1406-1 -- -o SendEnv=k8s_version -t set '-e;' for test in '/home/vagrant/go/src/github.com/cilium/cilium/tests/k8s/tests/*.sh;' do '$test;' done
00:13:02.735 ssh_exchange_identification: read: Connection reset by peer
00:13:02.735 Makefile:4: recipe for target 'k8s-multi-node-tests' failed
00:13:02.735 make: *** [k8s-multi-node-tests] Error 255

build-artifacts.zip

Also happened in second build https://jenkins.cilium.io/job/cilium/job/cilium/job/PR-1406/2/execution/node/29/log/

Looks similar in fourth build https://jenkins.cilium.io/job/cilium/job/cilium/job/PR-1406/4/execution/node/29/log/

This is blocking every build - I'm hitting it in PR #1352 now too.

Master builds that are blocked:

https://jenkins.cilium.io/job/cilium/job/cilium/job/master/577/execution/node/29/log/
https://jenkins.cilium.io/job/cilium/job/cilium/job/master/576/execution/node/29/log/

The commits from master build 575 vs. 576 should not be causing this change.
Diff of the two commits:
$ git diff 9a412b975f88fb6cbff328ee5c3f2a1c5bcb0801 c3832e3b8eb94a497dd62c3491deb3dc51fc2691
diff --git a/bpf/bpf_netdev.c b/bpf/bpf_netdev.c
index d28448ee..a19178d5 100644
--- a/bpf/bpf_netdev.c
+++ b/bpf/bpf_netdev.c
@@ -64,7 +64,7 @@ static inline int __inline__ handle_redirect(struct __sk_buff *skb, int ret)
        }
 #endif

-       return ret;
+       return TC_ACT_OK;
 }

 static inline __u32 derive_sec_ctx(struct __sk_buff *skb, const union v6addr *node_ip,
diff --git a/daemon/bpf.sha b/daemon/bpf.sha
index 1f741239..bf88d563 100644
--- a/daemon/bpf.sha
+++ b/daemon/bpf.sha
@@ -1,2 +1,2 @@
-GO_BINDATA_SHA1SUM=27b2080465b3d33869f797ed1750fb69e49f0f34
+GO_BINDATA_SHA1SUM=3dce2b60285bf3ebd1edff0a57e00c31e1617a9e
 GO_VERSION_USED=go1.8.3

The commits from master build 575 vs. 576 should not be causing this change.
Diff of the two commits:
Maybe it does. It causes the redirect to be overwritten. I'll investigate.

Closing this as the commit causing this issue has been reverted by PR #1417


Add a higher-level setPersistentTimer

The goal of a persistent timer would be to survive crashes or application restarts, the only use I can think of right now is runtime-initialized cronjobs and services for tasks.
It would require:

an expiration date for each timer to allow one-shot timers to be skipped (e.g. birthday emails)
a router to register the callbacks & names
an abstract serialization feature for the callback name and parameters, ideally json
an abstract storage like the session store to save/load the timers, ideally using redis

Since this is probably independent of the HTTP module, I guess it would belong in vibe.core directly.

I actually have some code lying around for that, but never could really decide where to put it inside vibe.d: https://github.com/D-Programming-Language/dub-registry/blob/master/source/dubregistry/scheduler.d
Maybe I should just put it into a little separate package first...
Ironically, it's still unused for the DUB registry itself.

Cool, all it's missing is some event parameters in json.

Just a note: Don't put it in core please :)

Maybe in vibe.db.redis.timers

I won't do that, so much is certain (even though it would work out in terms of dependencies, but it's just a too high level concept for core). I'd also like to keep it DB independent. Probably it'll just be a separate package, because currently vibe.d doesn't have a high-level utility module and it would be nice to keep it that way.


Make setup page theme-aware

The setup page is currently best viewed in Light theme. It should dynamically and gracefully adjust to a Dark theme.

@SachinS10-lab I fixed the button styles with #37 but the .install-options style still need some love

Fixed with #62


Requesting UUID/GUID v4 validator (regex inside)

Version 4 UUIDs have the form xxxxxxxx-xxxx-4xxx-Yxxx-xxxxxxxxxxxx where x is any hexadecimal digit and y is one of 8, 9, a, or b.
Regex equiv /^[0-9A-F]{8}-[0-9A-F]{4}-4[0-9A-F]{3}-[89AB][0-9A-F]{3}-[0-9A-F]{12}$/i

Alternatively you can use validator's function. They have a lot of string validations.


test: merge waitToDelete* functions

Follow up of https://github.com/cilium/cilium/pull/10520#discussion_r391665734

This change is

test-me-please

Coverage increased (+0.02%) to 45.641% when pulling<PHONE_NUMBER>cab9907e164d2ea619eef78f4d33c7 on pr/fix-operator-read-config-ci-follow-up into a734d81edc5aafd2d58532fa2c71f2984c9c080a on master.

test-me-please

test-me-please

test-me-please


About Producing Manifest File

Hello, thank you for providing a wonderful repository.
I would like to ask a question about how to obtain information in order to produce manifest file.
{
    "LJ001-0051.wav": {
      "text": "and paying great attention to the press work or actual process of printing,",
      "raw-text": "and paying great attention to the press work or actual process of printing,",
      "duration": 4.860090702947846,
      "phoneme": "æ|n|d|_|p|eɪ|ɪ|ŋ|_|ɡ|ɹ|eɪ|t|_|ɐ|t|ɛ|n|ʃ|ə|n|_|t|ə|_|ð|ə|_|\"|p|ɹ|ɛ|s|_|w|ɜː|k|\"|_|ɔː|ɹ|_|æ|k|tʃ|uː|əl|_|p|ɹ|ɑː|s|ɛ|s|_|ʌ|v|_|p|ɹ|ɪ|n|t|ɪ|ŋ|,"
    },
    "LJ001-0120.wav": {
    ...
    },
    ...
}

In the format of manifest file above, although there is a transcribed data of the audio file, getting duration and phoneme from the following data should need extra pre-processing, and the method nor code to create these information doesn't seem to presented in the repository.
Thus, I would like to ask: what libraries did you use for producing those information?
Also, if you used codes to produce the manifest file in your experiments, I would like to carefully ask if you could provide the code.
Thank you.

Hi @nonmetal thank you for the interest in our work!
We added necessary scripts in the repository to generate manifests for both model training and evaluation.
Please consult the updated readme section


Bcubed problem

With increasing clusters, B-cubed measure accuracy decreases, while the purity measure and rand-index measure increase in the same data, What is the cause? Does B-cubed measure have a decreasing trend with increasing number of clusters?

I was playing with their ground-truth and output example, and I saw that if the output has just one item we got Pr, Re and Fs equal to 1. For example:
#ground-truth data (also called gold-standard data) ldict = {     "item1": set(["gray", "black"]),     "item2": set(["gray", "black"]),     "item3": set(["gray"]),     "item4": set(["black"]),     "item5": set(["black"]),     "item6": set(["dashed"]),     "item7": set(["dashed"]),     "item8": set(["fk"]),     "item9": set(["dk"]),     "item10": set(["dk"]),     "item11": set(["dk"]), }
and
`cdict = {
"item1": set(["A", "B"]),
"item2": set(["A", "B"]),
"item3": set(["A"]),
"item4": set(["B"]),
"item5": set(["B"]),
"item6": set(["C"]),
"item7": set(["C"]),
}`
I read the paper, but I didn't understand the reason for it. So, I expected that it considers the number of items in the ground-truth.


Apply a consistent naming system to klasa

Description of the PR
Changed arguments to longer versions, msg => message, mes => response, start => runTime, and changed the commandLogging section to use the lengthened version; cmdLogging => commandLogging
Changes Proposed in this Pull Request (List new items in CHANGELOG.MD)

See description

Semver Classification

[x] This PR only includes documentation or non-code changes.
[ ] This PR fixes a bug and does not change the (intended) framework interface.
[ ] This PR adds methods or properties to the framework interface.
[x] This PR removes or renames methods or properties in the framework interface.

Could we get a changelog before this gets merged into master?

@bdistin any more requested changes on this?

Still requesting a changelog due to the fact this is Semver: Major and breaking even tho this is a development branch most users do use master so a changelog would be deeply appreciated.


Groups App not Loading for Mainnet

The groups application does not work for mainnet. After ~30 seconds load time, a screen pops up telling me I need to enable Keplr to run the app. Clicking the button, however does nothing.
If I switch to redwood the application loads fine. See image below.

RND full node was temporarily unavailable and is now back online.


Add critical hits when rolling damage

Changes:

When a DAMAGE button is Control-clicked, the roll should be treated as a critical hit
The toast message should be changed to: "$character rolled critical $weapon damage!"
The emote should be changed to: "/em : $character rolls critical $weapon damage"
All damage dice (not modifiers) should be doubled. Example: 1d4 + 2 becomes 2d4 + 2
A tooltip should be added to the buttons, which says: ctrl+click for critical hit

Notes;

Extract the dice using the following regex: [0-9]+d[0-9]+, split on the d, double, then recombine
We need to wait for #88 to avoid redoing work

#88 is still blocked, but we can start this regardless


[Bug] Failed to detect source code with declaring multiple variables

---------------------------------------------------
 File    = D:\working-folder\xxx\buspdo.c
 Config  = D:\working-folder\xxx\CppNameLint\cppnamelint.toml
 Inc[ 1] = -ID:\working-folder\xxx\CppNameLint
 Checked =  1095  [Func:224 | Param:332 | Var:539]
 Error   =   743  [Func: 48 | Param:695 | Var:  0]
---------------------------------------------------
<347, 5> Variable :    nNext (int nCur,)

int nCur, nNext = QS_ERROR;  // Line: 272

This issue was fixed in version v0.1.3.


pull request for e2e test at 12/13/2016 02:56:03

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Store samples anywhere

Implies this works in Soda Core as well as in Soda Cloud
Depends on #1243

Custom sampler via API and HTTP Sampler are now available


TypeScript strange working with " and ' quotes in import

TypeScript Version:
1.7.5
Code
import {HTTP_PROVIDERS} from 'angular2/http'; // <-- one quotes !
import {Component} from "angular2/core";
import {Http} from "angular2/http"; // <-- two quotes !

@Component({
    templateUrl: 'tst.html',
    viewProviders: [HTTP_PROVIDERS]
})

export class tst {
    constructor(private http1:Http) {
        http1.get('tst');
    }
}

Expected behavior:
After compilation (js file):
System.register(['angular2/http', "angular2/core"] ...
Actual behavior:
After compilation (js file):
System.register(['angular2/http', "angular2/core", "angular2/http"] ...
I have a many problems with this bug
bug example (with demo): http://stackoverflow.com/q/36134033/2051938

Silly question, why are you not destructuring all your desired objects from a module with a single import statement?

duplicate of #6681, already fixed in master

inattention
WebStorm editor automatically generates imports


[Feature] Badge/Chip Component in Docs

Problem description
I'd like to be able to define Badge/Chip UI elements as part of Markdown content within Fern Docs.
Why would it be useful?
We'd like to create a Changelog and with each change, tag it with the product area that its related to.
Describe the solution (optional)
They would look similar to the Availability component except I could customize:

The text/copy
The color
Optionally specify a start icon (to be positioned to the left of the text, within the Badge/Chip) from fontawesome

Additional context

Awesome feature request. Will get back to you when we get this live.
We're increasingly getting asked for Changelogs in Docs, so this is timely!

Here's another changelog where this could be relevant: https://primer.buildwithfern.com/changelog/api-v-2-1

Here's the badge component: https://github.com/fern-api/fern-platform/blob/main/packages/ui/components/src/badges/badge.tsx
Action would be allowing the user to specify properties, define this in MDX, and then for us to document that.


CPP highlighting with const array declaration

Checklist

[x] This problem exists even with the setting "C_Cpp.enhancedColorization": "Disabled"

If Disabling that^ makes the problem go away, then follow this to make an issue on the C++ extension:
https://github.com/microsoft/vscode-cpptools/issues/new/choose
The code with a problem is:
static const std::string led_paths[] {
    [RED] = LED_PATH("red"),
    [GREEN] = LED_PATH("green"),
    [BLUE] = LED_PATH("blue"),
    [WHITE] = LED_PATH("white"),
};

It looks like:

Originally from @vware in https://github.com/microsoft/vscode/issues/170177.

not even a response after a month?

¯\_(ツ)_/¯ I have +200 repositories. This is a free time project. If something bothers me I fix it.
If this bothers you @vware fix it. If you've got a question or need help, and I'll usually help.
This issue didn't ask for a response, so no I'm not going to respond until a question is asked or I feel like doing something about it.

yeah, thanks, but no thanks. i'd rather switch vscode to a better highlighter. loving the attitude. hfgl


Use total events to calculate drop_pct

What type of PR is this?

/kind cleanup

Any specific area of the project related to this PR?

/area engine

What this PR does / why we need it:
My expectation for drop_pct was that it showed the percent of total events dropped by the Falco engine. While investigating some misbehaving Falco processes, I found that many were reporting more than 100% of events being dropped:
log: {"sample": 15, "cur": {"events":<PHONE_NUMBER>, "drops":<PHONE_NUMBER>2, "preemptions": 0}, "delta": {"events": 488585741, "drops": 904962208, "preemptions": 0}, "drop_pct": 185.221},

I think that Falco is counting only the successfully processed events in the total when calculating drop_pct.

Fixes #2111
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

use total events to calculate drop_pct

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

a453232 Use total events to calculate drop_pct.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: shane-lawrence
To complete the pull request process, please assign leodido after the PR has been reviewed.
You can assign the PR to them by writing /assign @leodido 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

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

a453232 Use total events to calculate drop_pct.
1d0c458 Move drop_pct into delta subfield of stats output.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/cc @jasondellaluce

Hi, @shane-lawrence thanks for this PR. The situation here is a little bit complicated, let's proceed step by step:

first of all I have seen in the issue that you are using Falco 0.31.0 and Cloud provider or hardware configuration: GKE so I guess the eBPF probe.
Falco 0.31.0 was affected by an issue, in a nutshell, we counted twice the number of drops, one-time kernel-side, and another userspace-side. You can find more info about it in this PR.  This explains the strange data you have faced "events":<PHONE_NUMBER>, "drops":<PHONE_NUMBER>2 as you can see the number of drops is greater than the number of events and this is impossible since the events seen by the drivers should contain also drops. From this point, we can understand also the strange drpo_pct value.
Please note that our n_evts fields, both in kmod and in bpf should be intended as "events seen by the drivers" so they should contain also the number of drops. This is for example what we do in our bpf probe after this variable increment we will increment also the drops number in case the event cannot be pushed into the buffer for example.
In the end we can say that probably the way in which we compute the percentage is good, the problem is that Falco 0.31.0 with the bpf probe was affected by a bug, as I said before.

BTW we probably need to double-check all the cases in which we manage these numbers in order to avoid inconsistencies  in the computation

Thanks for the info @Andreagit97. Is it possible that the drops are counted more than twice? I have also seen drop_pct values greater than 200, as in this sample:
log: {"sample": 45, "cur": {"events":<PHONE_NUMBER>, "drops":<PHONE_NUMBER>, "preemptions": 0}, "delta": {"events": 36712191, "drops": 109353131, "preemptions": 0}, "drop_pct": 297.866},

IMHO drop_pct there should be computed using cstats instead of delta.
We can also add a delta_drop_pct that explicitly expresses the drop_pct between 2 consecutive points in time.
Moreover, together with @jasondellaluce , we discovered this: https://github.com/falcosecurity/falco/blob/120027dc2e3a638ef5dda7be9241bad549e2e4e1/userspace/falco/event_drops.cpp#L94
@Andreagit97

IMHO drop_pct there should be computed using cstats instead of delta. We can also add a delta_drop_pct that explicitly expresses the drop_pct between 2 consecutive points in time.
Moreover, together with @jasondellaluce , we discovered this:
https://github.com/falcosecurity/falco/blob/120027dc2e3a638ef5dda7be9241bad549e2e4e1/userspace/falco/event_drops.cpp#L94

Yeah, these are the inconsistencies I was talking about

@Andreagit97

@shane-lawrence more than twice seems strange probably there are also some errors in the percentage computation, I will take a deeper look into it. Anyway thank you for all these data, they surely help us in finding bugs :eye:

/milestone 0.33.0

Thanks! I dug into the code a bit more. I see that the definition of n_evts describes it as the total number of events received by the driver so I don't think my approach of summing n_drops + n_evts is correct. The count must not obey this in some places though or we could never get n_drops > n_evts.
I'm not very familiar with the codebase so it's possible that I just missed parts where each is counted, but it looks like the eBPF probe is dropping events before they are counted in the total in bpf/plumbing_helpers.h.
If this sounds accurate to you, I can update this PR to increment n_evts before dropping the event in that file. If not, I will summarize our conversation in #2111 and close this PR.
Please let me know what you think.

Thanks! I dug into the code a bit more. I see that the definition of n_evts describes it as the total number of events received by the driver so I don't think my approach of summing n_drops + n_evts is correct. The count must not obey this in some places though or we could never get n_drops > n_evts.

Yeah. completely agree with you. Thanks to your issue we have already found an inconsistent logic here, and we are still searching for other possible problems. More precisely we are focusing our attention on this strange drop_pct: 297.866! Looking at the actual code we have not found anything strange since you are using an old Falco version there is the possibility that different issues (2-times BPF drops + something wrong in the percentage computation) mixed together could cause this strange number. It would be amazing if you could test the last Falco release (0.32.1) to see if the issue is still there, this would mean that there is something wrong in the actual logic for sure!

I'm not very familiar with the codebase so it's possible that I just missed parts where each is counted, but it looks like the eBPF probe is dropping events before they are counted in the total in bpf/plumbing_helpers.h.

Oh yes, that's a good point, this logic is a little bit confusing because these events are not counted at all, nor in the n_evts nor in the drops, for this reason, we are thinking to re-implement it in some other ways so right now I wouldn't change it if it's ok for you.

If this sounds accurate to you, I can open a PR in falcosecurity/libs to increment n_evts before dropping the event in that file. If not, I will summarize our conversation in #2111 and close this PR.
Please let me know what you think.

It would be amazing if you could summarize the conversation on the issue and maybe test the latest Falco just to be sure that the problem is still here. For what concern this PR I think you can close it, thank you very much for all your effort, you helped us in finding some bugs!