text:
Works for sometime and then can no longer add files from ipfs

Version: 0.9.0 (desktop), 0.4.22 (go-ipfs)
OS: macOS 10.14.6 (18G95)

Adding files from ipfs initially works, but after a nondeterministic amount of time and uses, adding files using the Add button appears to do nothing.
Restarted and reinstalled multiple times, including blowing away ~/.ipfs/ and ~/.ipfs-desktop/  and  ~/Library/Application Support/IPFS Desktop/.
Also, the Files section will periodically refresh and hang forever.

Hey @steakknife,
I'm sorry for hearing you're having some troubles with IPFS Desktop!

Adding files from ipfs initially works, but after a nondeterministic amount of time and uses, adding files using the Add button appears to do nothing.

Hmm... Will try to reproduce.

Restarted and reinstalled multiple times, including blowing away ~/.ipfs/ and ~/.ipfs-desktop/ and ~/Library/Application Support/IPFS Desktop/.

Generally any problem should go away just by restarting the app. Didn't it work?

Also, the Files section will periodically refresh and hang forever.

Will try to reproduce too.

We revamped the way file import works when HTTP API is used (eg. in IPFS Desktop) adding many files, or adding a big file (4GB+) should work much better now.
Please upgrade to v0.13.2.

authors: hacdias lidel steakknife

repo: ipfs-shipyard/ipfs-desktop


text:
Website doesn't seem to be working.

Just checked out peerpad website. But after sharing the link and opening the link in a new window, the windows don't seem to sync?  Also, my status is always offline...what is the status here(tried it with the local ipfs daemon, but it still shows offline)?
Can someone tell me what am I missing here?

I could not reproduce this: I'm able to get online and sync between two browsers.
Is there any error in the console?

Here are the console logs(using the local ipfs daemon):
https://gateway.ipfs.io/ipfs/QmexQFGzCQVAF7mmLBsTHnq6rK6SBAhAfNEY6TjftDFhTz
If you don't mind, can you make a small screen video to show simple steps on how to use it via the website(using it by sharing the link) ...I know it sounds dumb, but I can't figure out what am I missing here.

Just checked out peerpad website. But after sharing the link and opening the link in a new window, the windows don't seem to sync? Also, my status is always offline...what is the status here(tried it with the local ipfs daemon, but it still shows offline)?
i am also facing the same problem can u rectify the problem

Still facing the same problem.

Thanks @vasa-develop for sharing the console.log output, very helpful! @akhil0101 could you do the same so we can see if it's the same issue for you?
Regarding @vasa-develop's issue, seems you're using a browser where AbortController is not defined. According to https://caniuse.com/#search=AbortController, it should be supported in the latest browsers (minus any version of IE). Which browser are you using?
@alanshaw according to the stacktraces, this error comes from AbortController being used in the preload-browser. Is it possible we can either shim it or similar since preloading is kind of an optional feature?
 File ../node_modules/ipfs/src/core/runtime/preload-browser.js line 12 col 1 in e
const controller = new AbortController()

@victorb  Thanks for replying. My browser specifications are as follows:
Chrome: Version 64.0.3282.140 (Official Build) (64-bit)
(This shows the error that I linked above. Seems like it AbortController is not defined in this version)
But it shows no error logs on Mozilla 63.0 (64-bit). The window shows that I am online. But when I tried sharing the document(tried both, read and write), the changes on one window doesn't show up on the other window.
P.S. I am on Ubuntu 16.04 LTS
If you want to know anything more about the logs or what environment using, feel free to ask.

@vasa-develop are you able to upgrade your chrome browser to version 66 or higher and test?

@alanshaw  I will upgrade it and get back to you.

But it shows no error logs on Mozilla 63.0 (64-bit). The window shows that I am online. But when I tried sharing the document(tried both, read and write), the changes on one window doesn't show up on the other window.

This might be a issue where the same Peer ID is being used, because it's essentially the same browser session but another tab, and I think PeerPad is reusing the same Peer ID, leading to pubsub not working correctly. @pgte correct me if I'm wrong about this.
@vasa-develop could you try to open the same pad but in two different browsers where PeerPad shows the status as online? For example, try opening it up in Firefox and Chrome with both windows being side-by-side (Chrome throttles the JS if it's in the background)

@victorb Just checked it out. It works when I use 2 different browsers.

@vasa-develop great! Renamed the title so it'll be easier to find in the future, and let's close this one.
@akhil0101 if it turns out you have a different issue than "AbortController is not defined", please open a new issue with more details of the problem, including javascript console logs if possible.

source: gharchive/issue

authors: akhil0101 alanshaw pgte vasa-develop victorb

repo: ipfs-shipyard/peer-pad

license: MIT

license_type: permissive

license_source: github-api


text:
Add Skiff files and image

What kind of PR is this?
Select only one to speed up review/approval; i.e., don't lump an addition and a removal into a single PR.

[x] Adding something new to awesome-ipfs
[ ] Editing something already listed on awesome-ipfs
[ ] Removing something from awesome-ipfs
[ ] Something else (if so, please explain in the "Additional details" section below)

Pre-submit checklist
Please confirm ALL of the following before submitting your PR.

[x] This PR includes only one addition, removal, or edit.
[x] I edited the /data directory instead of the README.md.
[x] I reviewed the content policy and the and the IPFS Community Code of Conduct to ensure my submission meets the requirements.
[x] I have followed the CONTRIBUTING.md guidelines.

Additional details
Is there anything else we should know about this PR?

Skiff has a long history of collaboration with Protocol Labs, including IPFS blog and this article.
For new additions: What is your project's current size/reach?

Over 100,000 users.
For new additions: What is your project's potential size/reach?

Everyone who uses email, collaboration, or file storage!
For new additions: How critical is IPFS to your project?

[x] Essential
[ ] Somewhat critical
[ ] Useful, but not critical

For new additions: What core goal(s) does your project address?

[ ] Big-data solutions
[x] Freedom from corporate/government interference
[ ] Data integrity
[ ] Dev tools or other ways to enable developers
[ ] Disaster resilience/recovery
[x] File storage/retrieval
[ ] File streaming
[ ] Permanent archiving
[ ] Self-sovereign identity
[ ] Platforms that utilize consensus, reputation, or incentivization
[ ] Other (please list)

Is anything about IPFS blocking your project?

Hey all! Just checking in to see who could be a gooed reviewer.

source: gharchive/pull-request

repo: ipfs/awesome-ipfs


text:
SEO: Add default canonical links to pages

Context
After discoving that the plugin we're using isn't working and that we don't have any canonical tags on the blog, I fixed it by building a small plugin.
What's in the PR

Remove non functioning canonical plugin
Add custom plugin to add the canonical tag to blog posts

How to test
One of the quick ways to test/check canonical tags is https://seominion.com/ a browser plugin that you can run on any page.
If you run it on https://blog.ipfs.tech/ currently, you will see there's none.

This PR fixes it for every blog post while still allowing to override via the frontmatter.canonicalUrl

This makes sense but I'm not as familiar with specifics, so looping in @johnnymatthews as a reviewer instead of me. It might be good to include him as a reviewer for all platform-related changes generally.
Also tagging @jennijuju for visibility.

Hey @2color, thanks for flagging this and kicking off a solution - really appreciate that! I've refactored the plugin/config and tested with each scenario and believe this to be resolved now.
Please double check and let me know, then I can deploy to production 😎

Thanks for cleaning it up @cwaring. Looks much cleaner now.
One thing I noticed is that all pages without a trailing slash get 302ed to the version with a trailing slash.
I've added a trailing slash to ensure that pages with a [permalink that doesn't have a trailing slash have it added.

Oh nice @2color, which page did you notice that on? I checked the output log and it seems that they all had trailing slashes here, however an extra safety net doesn't hurt to catch any errors in the user defined permaLink

Everything looks good here, shipping! 🛳

Oh nice @2color, which page did you notice that on?

This was the one: https://bafybeiahz36qlmb43qi6azd72iopbslj2lecfat6ytnkhg2ymawhueplmy.on.fleek.co/17-distributions/
(See that the canonical link in the preview of your last commit is without the trailing slash)
https://github.com/ipfs/ipfs-blog/blob/2b60628e82f5c5819bbfb9bfc04372c381e99c36/src/_blog/006-distributions.md?plain=1#L3

authors: 2color cwaring mishmosh

repo: ipfs/ipfs-blog


text:
Use Flit for packaging?

@alexander255 Just discovered a package/util for making uploading to PyPI easier. Might simplify our process. It's called Flit, and it is configured through an ini file instead of a setup.py file. I believe that it is cross-platform too, which is nice. Thoughts?

I've looked at back when you opened the issue, but didn't write a response yet. Sorry.
I really like what flit is trying to achieve, but I'm really worried about compatibility with existing implementations of pip (see https://github.com/takluyver/flit/issues/74). Also flite apparently hard-codes the useage of README.rst for the package description (which we converted to MarkDown when switching to the standardized-README), but I think this would probably be something that can be worked around easily enough.
I'm also not sure how/if this would interact with testing?
My current verdict: Maybe, but it needs some thorough investigation first. Maybe we should wishlist this?

So I looked at flit again the last couple of days and I'm very happy with what I see: 😁

[X] flit can now create sdist files (by generating a tiny setuptools-style package)
[X] Flit has a hidden feature for reading the decription from MarkDown files and converting it on-the-fly to ReST by call pandoc through pypandoc, see: https://github.com/takluyver/flit/issues/127

This is very similar to our current hack, but less ugly (for us at least)
The author has also “[doesn't] see any reason to get rid of the hidden pandoc feature, and if I ever do, I'll do so with a deprecation cycle unless there's a really good reason that's not practical.” – So this feature shouldn't just disappear overnight
The latest PyPA specs actually specify a new Description-Content-Type field, that can be used by packages to signal that their description isn't in reStructuredText, but in MarkDown or plain text (but Python Warehose and Legacy-PyPI don't support it yet). So there is a clear migration path into the future here.

[X] Testing works after applying a small tweak to tox' configuration

I've uploaded a demo of the flit-converted package here: https://test.pypi.org/project/ipfsapi/
Unless any grave issues are discovered we should totally do this! :+1:

We now use flit! \o/

repo: ipfs/py-ipfs-api

license: mit

license_source: bigquery


text:
Order masks by cracked password per time unit

By running statgen on my sample, I get the following rules:
...
?s?d?d?d?d?d?d?d,1611
?s?s,1450
?s?s?s?s?s?s?s?s?s?s?s,1267
...

The second one would yield much more passwords per time unit than the two others so it would be preferable to try this one first. A way to do that would be to sort using the number of passwords cracked per time unit. It can be abstract, it doesn't have to be in seconds. One ten bits password is cracked as fast as two eleven or four twelve bit passwords, so the unit could be related to bit strength of the mask - log2(number of passwords for this mask). Any thoughts?

Oops, sorry, didn't pay attention to the others scripts.
Awesome repo BTW !

Oh nice! Glad you find it useful.

On Jun 4, 2018, at 8:38 AM, mfr-itr notifications@github.com wrote:
Oops, sorry, didn't pay attention to the others scripts.
Awesome repo BTW !
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: iphelix mfr-itr

repo: iphelix/pack


text:
🛑 NowBoarding (tokyo) is down

In 406cbf5, NowBoarding (tokyo) (https://tokyo.nowboarding.club/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NowBoarding (tokyo) is back up in 1795960 after 10 minutes.

repo: iplanwebsites/up


text:
🛑 Invitation (og.invt.co - v1) is down

In 8efe6ce, Invitation (og.invt.co - v1) (https://og.invt.co/felix.png?fontSize=%40felix&theme=light&md=1&images=https%3A%2F%2Flh3.googleusercontent.com%2Fa-%2FAOh14GjUk2VKmkWxpgWZgY0CXWRFi_k6t7f2MBSsfSxR%3Ds96-c) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Invitation (og.invt.co - v1) is back up in a8f6047.


text:
Add: GIS-TV

Channel Name
GIS-TV
Alternative Names (optional)
Government Information Service of Grenada
Network (optional)
No response
Owners (optional)
No response
Country
GD
Subdivision (optional)
No response
City (optional)
St. George's
Broadcast Area
c/GD
Languages
eng
Categories (optional)
general
NSFW
FALSE
Launched (optional)
No response
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://gistvgrenada.org/
Logo
https://yt3.googleusercontent.com/DSIM-hb08pZ8i21FS4U1maT2IL5B2aGvLRlUSqiPwPFHGoLfkAy4QCE9riwptGwmX2PdIbeNPg=s900-c-k-c0x00ffffff-no-rj
Notes
https://media.streambrothers.com:1936/8474/8474/playlist.m3u8
[Geo-blocked]

Fixed

Please update your request:

the size of the logo should not exceed 512x512px

https://github.com/iptv-org/database/blob/master/CONTRIBUTING.md#channels

Fixed?

authors: AntiPontifex freearhey

repo: iptv-org/database

license: Unlicense


text:
The site should be better arranged

It would look cleaner to arranged as that each task (one or more versions) will have only one row in the table.

The idea is to take advantage of taxonomy function (one type of Kind which is disabled recently).

repo: iquizoo/pages


text:
How to use a develop branch of IREE with iree-jax

I built IREE from the source code in this feature branch https://github.com/antiagainst/iree/tree/apple-metal-hal. Then, I want to install and run models/gpt2.
I following the step here https://github.com/antiagainst/iree/tree/apple-metal-hal, and run the dependency installation commands in a fresh new Conda enviromnet with Python 3.9.  I didn't use --use-pinned because I am using a feature branch. And I have PYTHONPATH set by ~/w/iree/build/.env.
cd ~/w/iree-jax
python3 -m pip install absl-py future h5py numpy optax transformers # This works
python build_tools/configure.py # This updates version_info.json
python build_tools/pip_install.py # This failed

The last command failed with the following error message
10:59 $ python3 build_tools/pip_install.py
20230331.475
python3 -m pip install . -f https://openxla.github.io/iree/pip-release-links.html --force-reinstall .[xla,cpu,test]
Looking in indexes: https://pypi.apple.com/simple
Looking in links: https://openxla.github.io/iree/pip-release-links.html
Processing /Users/y/w/iree-jax
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting numpy (from iree-jax==0.1.dev1)
  Using cached https://pypi.apple.com/packages/packages/54/41/fb17c1d48a574c50422ff3f1b17ed979b755adc6ed291c4a44a76e226c67/numpy-1.24.3-cp39-cp39-macosx_11_0_arm64.whl (13.9 MB)
Collecting jax>=0.4.8 (from iree-jax==0.1.dev1)
  Using cached jax-0.4.8-py3-none-any.whl
INFO: pip is looking at multiple versions of iree-jax to determine which version is compatible with other requirements. This could take a while.
ERROR: Could not find a version that satisfies the requirement iree-compiler>=20230331.475 (from iree-jax) (from versions: 20220420.113, 20220421.114, 20220422.115, 20220423.116, 20220424.117, 20220425.118, 20220426.119, 20220427.120, 20220428.121, 20220429.122, 20220430.123, 20220501.124, 20220502.125, 20220503.126, 20220504.127, 20220505.128, 20220506.129, 20220507.130, 20220508.131, 20220509.132, 20220513.137, 20220514.138, 20220515.139, 20220516.140, 20220517.141, 20220518.142, 20220519.143, 20220520.144, 20220522.146, 20220523.147, 20220525.149, 20220526.150, 20220527.151, 20220601.156, 20220602.157, 20220603.158, 20220604.159, 20220605.160, 20220606.161, 20220607.162, 20220608.163, 20220609.164, 20220611.166, 20220612.167, 20220614.169, 20220615.172, 20220616.173, 20220616.174, 20220617.175, 20220618.176, 20220619.177, 20220620.178, 20220621.179, 20220622.180, 20220623.181, 20220624.182, 20220625.183, 20220626.184, 20220627.185, 20220629.188, 20220630.189, 20220701.191, 20220702.192, 20220703.193, 20220704.194, 20220705.195, 20220706.196, 20220707.197, 20220708.198, 20220709.199, 20220710.200, 20220712.202, 20220713.203, 20220714.204, 20220715.205, 20220716.206, 20220717.207, 20220718.208, 20220720.210, 20220721.211, 20220730.220, 20220731.221, 20220801.222, 20220803.224, 20220809.230, 20220810.231, 20220811.232, 20220812.233, 20220813.234, 20220814.235, 20220816.237, 20220817.238, 20220819.240, 20220820.241, 20220821.242, 20220823.244, 20220825.246, 20220826.247, 20220828.249, 20220830.251, 20220831.252, 20220901.253, 20220902.254, 20220903.255, 20220904.256, 20220905.257, 20220906.258, 20220907.259, 20220908.260, 20220909.261, 20220910.262, 20220911.263, 20220912.264, 20220913.265, 20220914.266, 20220915.267, 20220917.269, 20220918.270, 20220919.5, 20220919.6, 20220919.271, 20220920.272, 20220921.273, 20220922.274, 20220923.275, 20220924.276, 20220925.277, 20220926.278, 20220928.280, 20220929.7, 20220929.281, 20220930.282, 20221001.283, 20221002.284, 20221003.285, 20221004.286, 20221006.288, 20221007.289, 20221008.290, 20221009.291, 20221010.292, 20221011.293, 20221012.294, 20221019.301, 20221020.302, 20221021.303, 20221022.304, 20221023.305, 20221024.306, 20221025.307, 20221026.308, 20221027.309, 20221028.310, 20221029.311, 20221030.312, 20221031.313, 20221101.314, 20221102.315, 20221103.316, 20221104.317, 20221105.318, 20221106.319, 20221107.320, 20221108.321, 20221109.322, 20221110.323, 20221111.324, 20221112.325, 20221113.326, 20221114.327, 20221115.328, 20221116.329, 20221117.330, 20221118.331, 20221119.332, 20221120.333, 20221121.334, 20221122.335, 20221123.336, 20221124.337, 20221126.10, 20221127.340, 20221129.342, 20221201.344, 20221202.345, 20221203.346, 20221204.347, 20221205.348, 20221207.350, 20221208.11, 20221208.351, 20221209.353, 20221210.354, 20221211.355, 20221212.356, 20221213.357, 20221214.358, 20221215.359, 20221216.360, 20221217.361, 20221218.362, 20221219.363, 20221223.368, 20221224.369, 20221225.370, 20221226.371, 20221227.372, 20221231.376, 20230101.377, 20230102.378, 20230104.386, 20230105.387, 20230106.389, 20230107.390, 20230108.391, 20230110.393, 20230111.394, 20230112.395, 20230114.397, 20230115.398, 20230117.400, 20230119.402, 20230120.403, 20230121.404, 20230122.405, 20230123.406, 20230125.408, 20230126.409, 20230127.410, 20230128.411, 20230129.412, 20230130.413, 20230131.414, 20230201.415, 20230202.416, 20230203.417, 20230204.418, 20230205.420, 20230205.421, 20230206.422, 20230207.423, 20230208.424, 20230209.425, 20230210.426, 20230211.427, 20230212.428)
ERROR: No matching distribution found for iree-compiler>=20230331.475
None

Despite the above errors, python3 -c import iree.jax works. However, running the script models/gpt2/export.py complains no module named iree.jax.
(iree-jax) ✔ ~/w/iree-jax [main|✚ 2]
11:12 $ python3 models/gpt2/export.py
Traceback (most recent call last):
  File "/Users/y/w/iree-jax/models/gpt2/export.py", line 16, in <module>
    import iree.jax
ModuleNotFoundError: No module named 'iree.jax'

Sorry for this false alarm - I did't set PYTHONPATH correctly to point to iree.runtime, which I built from source code.

repo: iree-org/iree-jax


text:
Add strided and dynamic offset to memref type

When the static shape information is available,
we use a strided memref type with a dynamic offset for integration with iree.

The code looks great! Although I am not completely sure how are we planning to use the the stride and offset info on our stack. :)

So when I was first trying to integrate the tk kernels, I ran into issues with the iree integration. What happens is that one of the stream passes tries to optimize the bindings (use the same buffer for multiple input arguments) and so in order to enable that we need to have a dynamic offset, (not a fixed offset of 0).

Makes sense, thanks for the explanation :)

authors: harsh-nod raikonenfnu

repo: iree-org/iree-turbine


text:
Preserve input/output signatures from the TensorFlow frontend

Currently the TensorFlow frontend implicitly folds empty tuples, lists and dicts out of compiled functions' input and output signatures. In the case of empty arguments and return values, this changes the arity of the function or the number of values it returns. This produces surprising errors, and limits the ease with which IREE can be incorporated into an already existing pipeline.
I created a test below which should cover a small number of the relevant signatures.
import iree.compiler.tf
import iree.runtime
from iree.tf.support import tf_test_utils
import tensorflow as tf

class InputOutputModule(tf_test_utils.TestModule):

  @tf_test_utils.tf_function_unit_test(input_signature=[[]])
  def empty_list_arg(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      [tf.TensorSpec([4]), []],
  ])
  def empty_list_nested(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      [[]],
      tf.TensorSpec([4]),
      [],
  ])
  def empty_list_multi(self, a, b, c):
    return a, b, c

  @tf_test_utils.tf_function_unit_test(input_signature=[tuple()])
  def empty_tuple_arg(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      (tf.TensorSpec([4]), tuple()),
  ])
  def empty_tuple_nested(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      tuple(tuple()),
      tf.TensorSpec([4]),
      tuple(),
  ])
  def empty_tuple_multi(self, a, b, c):
    return a, b, c

  @tf_test_utils.tf_function_unit_test(input_signature=[{}])
  def empty_dict_arg(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      {
          'tensor': tf.TensorSpec([4]),
          'maybe_empty_state': {},
      },
  ])
  def empty_dict_nested(self, a):
    return a

  @tf_test_utils.tf_function_unit_test(input_signature=[
      {
          'empty': {}
      },
      tf.TensorSpec([4]),
      {},
  ])
  def empty_dict_multi(self, a, b, c):
    return a, b, c

class InputOutputTest(tf_test_utils.TracedModuleTestCase):

  def __init__(self, *args, **kwargs):
    super().__init__(*args, **kwargs)
    self._modules = tf_test_utils.compile_tf_module(InputOutputModule)

def main(argv):
  del argv  # Unused
  if hasattr(tf, 'enable_v2_behavior'):
    tf.enable_v2_behavior()
  InputOutputTest.generate_unit_tests(InputOutputModule)
  tf.test.main()

Routing to @jpienaar to asses and add priority if needed.

@not-jenni Can you help review and prioritize this on frontend rotation this week?

Prioritzed as P3 as TensorFlow is lower priority to other frontends.

repo: iree-org/iree


text:
#include unistd.h on GNU/Hurd and kFreeBSD

In libmseed.h, unistd.h needs to be included on GNU/Hurd systems (__GNU__) and GNU/kFreeBSD systems (__FreeBSD_kernel__ && __GLIBC__). Relevant issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890571

Fixed in d32d8326cbf2f8adf4585aeb866a4041ad998234.
unistd.h is included for everything not Windows.

authors: chad-iris paride

repo: iris-edu/libmseed


text:
[7,8,irods/irods_4650] Get project building again (master)

Addresses 7 and irods/irods_4650.
Addresses 8 with the quick-n-dirty solution. Proper fix for 8 will come with irods/irods_5250.

some sweet sweet minus - # it when ready.

#'d

authors: SwooshyCueb trel


text:
(refactor) bump version of num_cpus to 1.0

In the process of updating the dependencies of another far upstream package that eventually includes iron, I noticed that num_cpus had finally stabilized and made a 1.0 release. There were no code changes in the 1.0 release from 0.2.13 (https://github.com/seanmonstar/num_cpus/commit/7aab1fbc30b9bf39e74b0624dc037af694ce4da3)
The tests for iron pass on my machine, with one ignored test??: test itry!_0 ... ignored.

Thanks! :)

authors: Hoverbear YetAnotherMinion

repo: iron/iron


text:
It would be amazing if dead space 1, 2 along with the DLC's /Severed had KAMI support!!!

I don't mind using the controller but with mouse and keyboard feels so much better.

I was about to post it, it would be amazing!

repo: isJuhn/KAMI


text:
[Question] Failing test since v11.0.0

Hi,
We recently came across an issue which seems to be related to the latest release of next-i18next.
Everything works fine with v10.5.0 and the issue occurs in a test file ONLY (PROD code is not affected). So it seems that we have to change something in the test setup but we do not really know what.
This is the associated file: https://gitlab.com/biomedit/portal/-/blob/dev/frontend/pages/_app.tsx. In the test basically, we expect the token:

  common:unsupportedBrowser

for some unsupported navigators. With v11.0.0, we are now always getting:

instead.
I hope, my question is complete and understandable. Feel free to ask me if you have any questions. Any hint would be greatly appreciated.
Best regards,
christian

Did you upgrade other i18next dependencies along with next-i18next@11.0.0? I highly doubt this is an issue with next-i18next source code, as it does not deal with browser support at all.

Hi. Which dependencies are you talking about? Here is the package.json file (we rolled back the library upgrade).

Your package.json file is irrelevant. Your lockfile is where you should look.

But if I install the latest version of next-i18next, related dependencies will be installed automatically, won't they? I do not control my lockfile, npm does Or did I misunderstand something?
We implemented the browser check, and output a message translated by next-i18next (https://gitlab.com/biomedit/portal/-/blob/dev/frontend/pages/_app.tsx#L83):
  if (isSupportedBrowser === false) {
    log.warn({ message: unsupportedBrowserLogMessage });
    return (
      <Trans
        i18nKey={`${I18nNamespace.COMMON}:unsupportedBrowser`}
        values={{ contactEmail }}
        components={{
          email: <EmailLink email={contactEmail ?? ''} />,
          ulist:
,
          litem:
,
          break:
,
        }}
      />
    );
  }

The test is exactly checking that part, which does no longer work with v11.0.0. Stop, this is not true. As I said, it works. The problem is just the test...

As I said, I highly doubt this is related to next-i18next source code. Please do update us if you resolve the problem.

Looks like, I have to mock next-i18next.config.js in my test (should become null/undefined). I think, the relevant change for me is here: UserConfig overrides changes.
Up to me the release notes are too sparse and the commit message did not help neither. I had to analyse the code changes to understand what has changed for me in the latest version.

authors: isaachinman ribeaud


text:
Can you provide a PHP version?

Can you provide a PHP version?

no sorry, piping events over a websocket is my suggestion

authors: isaackogan siqinglin

repo: isaackogan/TikTokLive


text:
Render numbers blocked

It blocked when render such numbers, it seems that the more continual numbers rendered,the more longer it blocked
like this:

0123456789012345678901234567

or this:

0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

see example:
http://sandbox.runjs.cn/show/nszkiaec
screenshot:

Thanks for reporting this. It's fixed in current master code.

authors: bluishoul isagalaev


text:
Changed the colors of navbar buttons in accordance with the page

Committed in a new branch with some additional changes

@MonalikaKapoor Please create an issue for the same.


text:
🛑 Sulicor.isolucion.co is down

In 6568790, Sulicor.isolucion.co (https://Sulicor.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sulicor.isolucion.co is back up in 348c000 after 1 hour, 32 minutes.

Resolved: Sulicor.isolucion.co is back up in 6a0c9e2 after 1 hour, 32 minutes.

repo: isolucionco/EstadoIsolucionHosting


text:
🛑 sstbancodeoccidente.isolucion.co is down

In 4f812bb, sstbancodeoccidente.isolucion.co (https://sstbancodeoccidente.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

ok


text:
Add RosWalk state

This is a state in which the robot walks toward a pose received via ROS topic. It is assumed that the pose obtained from visual recognition is taken by the ROS topic.
https://github.com/isri-aist/BaselineWalkingController/assets/6636600/82589ca2-4436-49e8-b444-1138932c321f

The frame_id of the PoseStamped message can be a world or a robot frame name that can be resolved by mc_rtc.

repo: isri-aist/BaselineWalkingController


text:
map size change does not trigger onChange?

just put together a dumb demo.
if you click the marker, the map is resized.
the onChange does not seem to triger.
I should console.log the size.
(I wndow resize resizes the map it seems to work)
Is this expected behaviour?
https://jsbin.com/zaxemotiwu/edit?js,console,output

https://github.com/istarkov/google-map-react/issues/147

authors: geritol istarkov

repo: istarkov/google-map-react


text:
Google Maps API warning: NoApiKeys

Hiya,
I'm using this for a React / Typescript project. My map works totally fine -- but I keep getting this warning when the page loads. I'm very sure that I have the bootstrapURLKeys property set up correctly: bootstrapURLKeys={{ key:this.util.getKey() }}. This is a valid Google Maps JS API key as well. This also occurs when the key itself is hardcoded into the pair. Is there a simple fix for this that I am missing?
Thanks for the help in advance!
Stack trace of the error (but it doesn't seem very helpful):
util.js:220 Google Maps API warning: SensorNotRequired https://developers.google.com/maps/documentation/javascript/error-messages#sensor-not-required
rB.j @ util.js:220
(anonymous) @ js?libraries=places&sensor=false:136
(anonymous) @ js?libraries=places&sensor=false:53
(anonymous) @ js?libraries=places&sensor=false:50
(anonymous) @ js?libraries=places&sensor=false:53
_.G @ js?libraries=places&sensor=false:52
(anonymous) @ js?libraries=places&sensor=false:53
_.v @ js?libraries=places&sensor=false:32
Yc @ js?libraries=places&sensor=false:53
(anonymous) @ js?libraries=places&sensor=false:136

Having that there is no word sensor in this library, I don't know what to say, somehow it's added to gmap script tag in your case. Search you codebase to find where.

Hi, I'm sorry it seems I copy pasted the wrong stack trace:
util.js:220 Google Maps API warning: NpApiKeys https://developers.google.com/maps/documentation/javascript/error-messages#sensor-not-required
rB.j @ util.js:220
(anonymous) @ js?libraries=places&sensor=false:136
(anonymous) @ js?libraries=places&sensor=false:53
(anonymous) @ js?libraries=places&sensor=false:50
(anonymous) @ js?libraries=places&sensor=false:53
_.G @ js?libraries=places&sensor=false:52
(anonymous) @ js?libraries=places&sensor=false:53
_.v @ js?libraries=places&sensor=false:32
Yc @ js?libraries=places&sensor=false:53
(anonymous) @ js?libraries=places&sensor=false:136

For reference, I got this snippet of code from the API Docs found in the README. I was trying to add a SearchBox (which works), and the docs instructed that I add a script tag in the HTML (specifically under Adding a searchbox). I found a way to get rid of the warning, by including the API key in:
<script type="text/javascript" src="https://maps.google.com/maps/api/js?libraries=places&key={YOUR_API_KEY}"></script>, but I really dislike having to directly bake my API key into a script tag.
In regards to the sensor, it was also part of the <script> in the API docs.
Do you happen to know of any other fixes to adding a searchbox to the page that won't result in these warning or adding a <script> tag to the HTML?

Docs were written not by me only, I don't even know what searchbox is. Seems like bug in docs.
Just don't use script tag, or use it after reading a google api, everything can be added via bootstrapURLKeys.

Okay, thanks for the help, I'll update here if I have a solution

I'm having the same issue, it does work, but my cod kicks in with warnings ;)

I am using the place with searchBox by simply using libraries: 'places' in bootstrapURLKeys, No other script tags on page
import React from 'react';
import GoogleMap from 'google-map-react';

const GoogleMapConfig = {
	key: YOUR_KEY,
	libraries: 'places',
};

export default class Map extends React.Component {
	render() {
		return (
			<GoogleMap
				bootstrapURLKeys={GoogleMapConfig}
	                        // ALL YOUR OTHER OPTIONS
			/>
		);
	}
}

authors: axe-z evanfrawley istarkov sergop321


text:
Fix the "docker" target in the Makefile to use Dockerfile.builder

The "docker" target in the Makefile was using an outdated approach and referenced a Dockerfile that does not exist anymore

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

@googlebot I signed it!

/LGTM

authors: cfryanr istio-testing tylerschultz

repo: istio-ecosystem/authservice


text:
Rename install.sh to ci-install.sh or test-install.sh

For people who want a one step install of istio, we are going to recommend "kubectl apply -k" and kustomize.
For people who want advanced install - iop ( and istioctl once this is integrated ).
I want to avoid confusion, install.sh is not intended for neither prod or demo installations.

I think we should rename the install.sh to "test-install.sh" - it is mainly used in the test pipeline.

Would this really make sense? I do not see a benefit having a script "just" for test purposes. What are we testing then at all? I would argue that if we really only want to use it for tests, we should remove it all together and use make.
But why make? IMHO, a dedicated shell script for installing is easier (to use, maintain and understand) than using make for that. Is there a benefit for the user?

...we are going to recommend "kubectl apply -k" and kustomize.

Where can I see how these calls look like? I guess this is used somewhere.

Issue moved to istio/istio #14117 via ZenHub

authors: c0d1ngm0nk3y costinm fpesce

repo: istio/installer


text:
Copy edit for Control Ingress Traffic.

Signed-off-by: Stephen Gilson gilsonsm@google.com

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: sgilsonapigee
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: sdake
Assign the PR to them by writing /assign @sdake in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content/OWNERS

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

Hi @sgilsonapigee. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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.

authors: istio-testing sgilsonapigee


text:
SidecarInjection should use one common label

Describe the feature request
There are two different labels to control the sidecar injection:

sidecar.istio.io/inject on pod level.
istio-injection on namespace level.

Describe alternatives you've considered
I would prefer only sidecar.istio.io/inject.
For backward compatibility I would check both labels for a transitional period.

See also https://github.com/istio/istio.io/issues/3191

authors: esnible thomschke

repo: istio/istio


text:
TestLeaderElectionNoPermission test flake due to k8s bug

https://prow.istio.io/view/gcs/istio-prow/pr-logs/pull/istio_istio/21931/unit-tests_istio/9928
I will skip this for now. Should be re-enabled when we upgrade to k8s 1.18

still valid, waiting for k8s
On Sun, Mar 15, 2020, 2:00 AM Istio Policy Bot notifications@github.com
wrote:

🤔 ❄ Hey there's been no update for this test flakes for 3 days.
Courtesy of your friendly test flake nag.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/22038#issuecomment-599184354, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXP5CDWS6HFIGKSPBV3RHSKKXANCNFSM4LFA274A
.


text:
Error adding/updating listener(s) 0.0.0.0_80: error adding listener '0.0.0.0:80': multiple filter chains with the same matching rules are defined

Bug description
When I upgraded to istio 1.6.0, istio proxy stopped working. No pods can be started because istio-proxy sidecar fails with:
2020-05-25T18:13:13.365524Z	warning	envoy filter	[src/envoy/http/authn/http_filter_factory.cc:83] mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS, and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode for more secure configuration that only allows TLS connection with client cert. See https://istio.io/docs/tasks/security/mtls-migration/
2020-05-25T18:13:13.366997Z	warning	envoy filter	[src/envoy/http/authn/http_filter_factory.cc:83] mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS, and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode for more secure configuration that only allows TLS connection with client cert. See https://istio.io/docs/tasks/security/mtls-migration/
2020-05-25T18:13:13.368143Z	warning	envoy config	[external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_80: error adding listener '0.0.0.0:80': multiple filter chains with the same matching rules are defined

2020-05-25T18:13:14.930471Z	warn	Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected

Steps to reproduce the bug
Install istio 1.6.0 on top of 1.5.4.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client version: 1.6.0
control plane version: 1.6.0
data plane version: 1.6.0 (4 proxies)

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.1", GitCommit:"d224476cd0730baca2b6e357d144171ed74192d6", GitTreeState:"clean", BuildDate:"2020-01-15T15:50:25Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.11", GitCommit:"d94a81c724ea8e1ccc9002d89b7fe81d58f89ede", GitTreeState:"clean", BuildDate:"2020-03-12T21:00:06Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}

version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

How was Istio installed?
istioctl install -f manifest.yaml (IstioOperator spec extending on default profile)
Environment where bug was observed (cloud vendor, OS, etc)
ubuntu 18.04 lts (bare-metal)
Config dump was huge, so I put it here: https://gist.github.com/rauanmayemir/65e737ea6eca8d6a0f0ec2fa156fdfdd
Cc: @howardjohn

I think it was the wrong config dump, here's the dump from istio-proxy: https://gist.github.com/rauanmayemir/7001c7de839e919d2f0ff90cfde7c533.

@rauanmayemir Can you show all your services with 80 port? I am not sure whether this related to tcp fail through feature

@hzxuzhonghu Here it is:
apiVersion: v1
kind: Service
metadata:
  name: echo
  labels:
    app: echo
spec:
  ports:
    - port: 80
      targetPort: 5678
      name: http
  selector:
    app: echo

(I can also see that istio tracing svc binds to port 80)

I deleted tracing component and switched echo to a different port, still seeing same issues.

I tried to create multi services with 80 on istio 1.6.0, but can not reproduce.  Not sure why the passthrough filter chain match with application protocol set.

@hzxuzhonghu I deleted everything that were bound to 80, but still seeing the error.

click-s5-russia.esv2.com service entry is the problem. Reproducer:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: break-80
spec:
  hosts:
  - httpbin.org
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: tcp
    protocol: TCP
  resolution: NONE

We end up with FCMs:
tcp match all SE
1.0/1.1/h2c -> 80
1.0/1.1/h2c -> passthrough

We should have
tcp match all SE
1.0/1.1/h2c -> 80

@howardjohn Wow, that was something I couldn't make work and forgot it even existed (the idea was to proxy incoming https request to insecure external endpoint).
Is that a bug, or did I do something I wasn't supposed to?

@rauanmayemir its a bit of both. We shouldn't send invalid config to envoy like we are today as it gets rejected like you saw, but the config is pretty abnormal

@howardjohn 👍 great finding

We're running into the same error when applying this ServiceEntry:
---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  annotations:
  name: proxyserver
  namespace: istio-system
spec:
  hosts:
  - proxyserver.internal.company.com
  location: MESH_EXTERNAL
  ports:
  - name: https-8080
    number: 8080
    protocol: HTTPS
  resolution: DNS

Workloads need to reach a proxy outside the mesh that runs on port 8080 and requires https.
Because every proxy in the mesh has by default an entry for outbound|8080||istio-pilot.istio-system.svc.cluster.local , adding this service entry causes this error for each service and in addition results in no ready envoys after a restart.

@rolandkool what version? I am surprised this is failing at all but a quick test on 1.6 shows this behaving properly

This is on 1.6

Can you post the config dump?
On Thu, May 28, 2020, 9:13 AM Roland Kool notifications@github.com wrote:

This is on 1.6
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/24084#issuecomment-635445972, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNXUJB4KU6P2QZZ5RTRT2ESPANCNFSM4NJWQLNA
.

Created one: https://gist.github.com/rolandkool/febcbbe5e41fdccd1eb070c956a3aaf4

When changing the SE to http, the error disappears.

I wonder if it's related, but I also couldn't expose a tcp port on istio ingress. Here's my config:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: amqp-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "rabbitmq.redacted.tld"
      port:
        number: 5672
        name: tcp-amqp-5672
        protocol: TCP
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: tcp-amqp
spec:
  hosts:
    - rabbitmq.redacted.tld
  gateways:
    - istio-system/amqp-gateway
  tcp:
    - match:
        - port: 5672
      route:
        - destination:
            host: rabbitmq-headless.default.svc.cluster.local
            port:
              number: 5672

And here's how it looks in service/istio-ingressgateway:
spec:
  ports:
  # ...
  - name: tcp-amqp
    # auto-set by k8s, not me:
    nodePort: 30769
    port: 5672
    protocol: TCP
    targetPort: 5672

This config seemed to work on 1.5.4, but telnetting on 1.6.0 gives me this:
$ telnet rabbitmq.redacted.tld 5672
Trying ip...
Connected to rabbitmq.redacted.tld.
Escape character is '^]'.
Connection closed by foreign host.

I.e connection is being closed immediately.

Please disregard my previous comment, should have looked into istiod logs.

@rolandkool I forgot the order the service is created matters, thanks for the config dump, I can reproduce now.

https://github.com/istio/istio/pull/24131/files fixes your issue as well @rolandkool (in my testing, at least)

@rolandkool I forgot the order the service is created matters, thanks for the config dump, I can reproduce now.

Hi I am facing the similar issue, what does "the order the service is created matters" mean?
Do I have to create services in a specific order?
I am using istio-1.4.6 and TCP 0.0.0.0_80 is not being listened in the ingress gateway.

Istio 1.4 is EOL. Please upgrade.
On Mon, Jan 10, 2022 at 9:50 PM Dominic Kim @.***>
wrote:

@rolandkool https://github.com/rolandkool I forgot the order the
service is created matters, thanks for the config dump, I can reproduce now.
Hi I am facing the similar issue, what does "the order the service is
created matters" mean?
Do I have to create services in a specific order?
I am using istio-1.4.6 and TCP 0.0.0.0_80 is not being listened in the
ingress gateway.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/24084#issuecomment-1009620501, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXISQSTMZSX5J542XHLUVPAJVANCNFSM4NJWQLNA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@howardjohn
Yes, but our legacy is sticking to the version for some reason..
Could you give me some information about the issue or at least about the order please?

authors: howardjohn hzxuzhonghu rauanmayemir rolandkool style95


text:
[Istio Sidecar] Reset by peer when connecting to external service

Bug description
When deploying a service whitch connects to external service in this case is a grafana service and connects to postgresql RDS. Gives an error.
grafana-f9f4447c4-xd4xp istio-proxy [2021-03-28T14:28:33.373Z] "- - -" 0 UH - - "-" 0 0 0 - "-" "-" "-" "-" "-" - - 10.11.30.83:5432 10.11.10.97:54384 - -

I have added an external service also to try if with this works:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: postgresql-external-devops
  namespace: istio-system
spec:
  hosts:
    - postgresql.devops.example.com
  location: MESH_EXTERNAL
  ports:
    - number: 5432
      name: tcp-postgresql-devops
      protocol: TCP
  resolution: DNS

And fails. If I disable the sidecar, it works.
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
Permit connection
Steps to reproduce the bug
Version
istio:
client version: 1.9.2
control plane version: 1.9.2
data plane version: 1.9.2 (4 proxies), 1.9.1 (56 proxies)

Kubectl
Client Version: v1.20.2
Server Version: v1.19.6-eks-49a6c0

How was Istio installed?
with istioctl

My fault, I had another service entry deployed and I think it was failing.


text:
curl helloword service error：Recv failure: Connection reset by peer

when create app helloword in local cluster
root@SZX1000353068:~/istio-0.2.1/samples/apps/helloworld# kubectl get svc helloworld
NAME         TYPE       CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
helloworld   NodePort   10.0.0.111   <none>        5000:31858/TCP   16m

and I visit helloword
root@SZX1000353068:~/istio-0.2.1/samples/apps/helloworld# curl 127.0.0.1:5000/helloword
curl: (7) Failed to connect to 127.0.0.1 port 5000: Connection refused

I curl pod ip, the same error,
then I enter container, and curl 127.0.0.1:5000/helloword it works ok. But curl podIP:5000, still recv  Connection refused.
I do not know what's the matter

By the way, I use istio-0.2.1, kubernetes
root@SZX1000353068:~/istio-0.2.1# kubectl version
Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.2.2994+3cf7000b3b5947", GitCommit:"3cf7000b3b5947e957f1f54faa75680bc51a987c", GitTreeState:"clean", BuildDate:"2017-09-02T08:52:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

does curl http://helloworld:5000/ work ?
why do you expect localhost to work (unless you use kubectl port-forward ?)

because it is nodeport service.

Issue moved to istio/pilot #1370 via ZenHub

authors: hzxuzhonghu ldemailly


text:
remove unneeded ClusterRole and ClusteRroleBinding in gateway

/cc @linsun @rshriram

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: yangminzhu
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: gyliu513
If they are not already assigned, you can assign the PR to them by writing /assign @gyliu513 in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

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

lgtm pending tests passing

@yangminzhu: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
de579873309201ea29776790ca3caffdf649052d
link
/test istio-integ-k8s-tests

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.

/test istio-integ-k8s-tests

@linsun @rshriram All required tests pass, PTAL. thanks!

@yangminzhu: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
de579873309201ea29776790ca3caffdf649052d
link
/test istio-integ-k8s-tests

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.

authors: istio-testing linsun yangminzhu


text:
Log a warning when we ingest an Ingress resource containing a rule without a body

What this PR does / why we need it: Fix our handling of Ingress resources, which may specify rules without HTTP bodies.
Which issue this PR fixes: fixes #2226
Special notes for your reviewer:
Release note:

NONE

@ZackButcher: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
19748b6d565beaa78d105b5e018f0a911d0256a9
link
/test e2e-smoke

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.

/test e2e-smoke

authors: ZackButcher istio-testing


text:
Remove istioctl manifest migrate command

fixes https://github.com/istio/istio/issues/22716

@richardwxn if a user wants to translate they can use the old 1.6 istioctl. There will be no users migrating from 1.6 helm -> 1.7 iop, as 1.6 helm does not exist. We cannot feasibly maintain a helm -> iop migration path anymore, the entire architecture has changed. well over 50% of the values no longer have a logical equivalent anymore

yes for master only
On Thu, Apr 30, 2020, 5:07 AM Steven Dake notifications@github.com wrote:

@sdake approved this pull request.
this should not be backported to 1.6 AFIACT based upon @ostromart
https://github.com/ostromart 's comments in the linked issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/23353#pullrequestreview-403456412,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXLZAMMGZTGRD36UIJ3RPFSYDANCNFSM4MTGDVTQ
.