check_move don't check inside

I am using the callback check_move,
it works fine for before and after but it is never called for inside nor last
so when i'm drag&drop'ing my node it appears always false  (i return false for before/after and true for inside) but i can drop my node
bug or i'm doing it wrong ?
"plugins" : ["themes", "ui", "cookies", "hotkeys", "json_data", "types", "dnd", "crrm"],
"crrm" : {
    "move" : {
        "check_move" : myfunction
    }
}

The function is called for [inside]. I've used it today. There is an issue (I do not know whether bug or feature) once a user drops a node the check_move is called multiple times with [after], [before] ... I do not remember certain queue.


Make TLS version and cipher suites configurable

Allow the application to control which TLS versions and cipher suites are used for a particular socket.
TLS version and cipher configuration should be available in all TLS-based XCM transports (TLS, UTLS, BTLS).
TLS version and cipher configuration should be inherited from a server socket to corresponding connection sockets (created with xcm_accept() or xcm_accept_a()).
TLS version configuration
The application may not choose arbitrary SSL or TLS versions; only 1.2 and 1.3 will be available. Enabling/disabling of a TLS protocol version must be done explicitly, with a separate socket attribute. This seems preferable over implicit configuration, by means of just leaving out all TLS 1.2 cipher in case TLS 1.2 are to be disabled. Explicit is better since it's more clear, although arguably a little redundant.
By default, both TLS 1.2 and 1.3 will be enabled (to assure backward compatibility).
Only TLS 1.2 and 1.3, and not any older TLS or SSL protocol version will be supported by XCM. The socket attribute design should allow future XCM version allowing enabling of older TLS or SSL protocol versions or newer, yet-to-be-specified versions of TLS.
TLS cipher configuration
The default TLS 1.3 and 1.3 ciphers currently hard-wired into the XCM TLS transport should continue to be the default.
The application should be able to override the default ciphers for either/both-of TLS 1.2 and 1.3 by means of XCM socket attributes.
The should probably be two separate lists, one for TLS 1.2 and one for TLS 1.3, although technically, you could potentially have one list, given that cipher names seems to be unique. At this point, the "two list" solution seems more clear and not subject to any issues, does not depend on unique crypto suite names. The "two list" solutions also avoid having to explain to the user what happens if the cipher list contains TLS 1.2-only ciphers, but TLS 1.2 is disabled.
Cipher suite names used in the XCM API should be the IANA names (i.e., not IANA hexcodes, and not OpenSSL names).
It's unclear if XCM should only support the ciphers currently hard-coded into the library (i.e., the default will be a superset of all available cipher lists), or if all OpenSSL-supported cipher suites should be available for the application to enable (incuding NUL-crypto), or there should be something in-between.
The should probably be a way for an application to retrieve both the default cipher list, and more importantly, the list of available ciphers (for all supported TLS versions). This information cannot be conveyed as a socket attribute, since it's not related to a socket, but rather a transport, so there would have to be new API calls.
Handshake Result
There should be a way to retrieve both actual ciphers used for a particular connection, and the protocol version (that is already logged today, but not available programmatically), as socket attribute readable after the TLS handshake has completed.

Preferably, the XCM socket attributes structure used should naturally extend to support a future XCM version also supporting older, pre-1.2 versions of TLS, and newer, post-1.3, versions.


mmlspark spark serving startup failed

Describe the bug
when copy the "Spark Serving Hello World",  got nothing but some warns, and spark service startup failed also, because the port (8888) is not unused
To Reproduce
`
import findspark
findspark.init()
from pyspark.sql import SparkSession

if __name__ == '__main__':

  spark = SparkSession.builder.appName('featureEngineering').master("local") \
    .config("spark.jars.packages", "com.microsoft.ml.spark:mmlspark_2.12:1.0.0-rc3-62-25d40cff-SNAPSHOT") \
    .config("spark.jars.repositories", "https://mmlspark.azureedge.net/maven") \
    .getOrCreate()

  from mmlspark.io import *
  from pyspark.sql.functions import udf, col, length
  from pyspark.sql.types import *

  df = spark.readStream.continuousServer() \
    .address("localhost", 8888, "my_api") \
    .load() \
    .parseRequest("my_api", StructType().add("foo", StringType()).add("bar", IntegerType()))

  replies = df.withColumn("fooLength", length(col("foo")))\
    .makeReply("fooLength")

  server = replies\
    .writeStream \
    .continuousServer() \
    .replyTo("my_api") \
    .queryName("my_query") \
    .option("checkpointLocation", "file:///tmp/checkpoints") \
    .start()

`
Info (please complete the following information):

MMLSpark Version: 1.0.0-rc3-62-25d40cff-SNAPSHOT
Spark Version: 3.0.2
Scala Version: 2.12.10
Spark Platform: Linux VM-16-3-centos 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Python 3.7.7
PySpark 3.1.1

** Stacktrace**
[hadoop@VM-16-3-centos service]$ python3 mmlspark_server.py
21/06/08 13:41:34 WARN Utils: Your hostname, VM-16-3-centos resolves to a loopback address: <IP_ADDRESS>; using <IP_ADDRESS> instead (on interface eth0)
21/06/08 13:41:34 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
https://mmlspark.azureedge.net/maven added as a remote repository with the name: repo-1
Ivy Default Cache set to: /home/hadoop/.ivy2/cache
The jars for the packages stored in: /home/hadoop/.ivy2/jars
:: loading settings :: url = jar:file:/usr/local/service/spark/jars/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
com.microsoft.ml.spark#mmlspark_2.12 added as a dependency
:: resolving dependencies :: org.apache.spark#spark-submit-parent-016b38e7-bbea-45e0-9121-bb7e6f27a128;1.0
	confs: [default]
	found com.microsoft.ml.spark#mmlspark_2.12;1.0.0-rc3-62-25d40cff-SNAPSHOT in spark-list
	found org.scalactic#scalactic_2.12;3.0.5 in central
	found org.scala-lang#scala-reflect;2.12.4 in central
	found io.spray#spray-json_2.12;1.3.2 in central
	found com.microsoft.cntk#cntk;2.4 in central
	found org.openpnp#opencv;3.2.0-1 in central
	found com.jcraft#jsch;0.1.54 in local-m2-cache
	found com.microsoft.cognitiveservices.speech#client-sdk;1.14.0 in spark-list
	found org.apache.httpcomponents#httpclient;4.5.6 in local-m2-cache
	found org.apache.httpcomponents#httpcore;4.4.10 in local-m2-cache
	found commons-logging#commons-logging;1.2 in local-m2-cache
	found commons-codec#commons-codec;1.10 in local-m2-cache
	found org.apache.httpcomponents#httpmime;4.5.6 in central
	found com.microsoft.ml.lightgbm#lightgbmlib;3.2.110 in central
	found com.github.vowpalwabbit#vw-jni;8.9.1 in central
	found com.linkedin.isolation-forest#isolation-forest_3.0.0_2.12;1.0.1 in central
	found com.chuusai#shapeless_2.12;2.3.2 in central
	found org.typelevel#macro-compat_2.12;1.1.1 in central
	found org.apache.spark#spark-avro_2.12;3.0.0 in central
	found org.spark-project.spark#unused;1.0.0 in local-m2-cache
	found org.testng#testng;6.8.8 in central
	found org.beanshell#bsh;2.0b4 in local-m2-cache
	found com.beust#jcommander;1.27 in central
:: resolution report :: resolve 565ms :: artifacts dl 15ms
	:: modules in use:
	com.beust#jcommander;1.27 from central in [default]
	com.chuusai#shapeless_2.12;2.3.2 from central in [default]
	com.github.vowpalwabbit#vw-jni;8.9.1 from central in [default]
	com.jcraft#jsch;0.1.54 from local-m2-cache in [default]
	com.linkedin.isolation-forest#isolation-forest_3.0.0_2.12;1.0.1 from central in [default]
	com.microsoft.cntk#cntk;2.4 from central in [default]
	com.microsoft.cognitiveservices.speech#client-sdk;1.14.0 from spark-list in [default]
	com.microsoft.ml.lightgbm#lightgbmlib;3.2.110 from central in [default]
	com.microsoft.ml.spark#mmlspark_2.12;1.0.0-rc3-62-25d40cff-SNAPSHOT from spark-list in [default]
	commons-codec#commons-codec;1.10 from local-m2-cache in [default]
	commons-logging#commons-logging;1.2 from local-m2-cache in [default]
	io.spray#spray-json_2.12;1.3.2 from central in [default]
	org.apache.httpcomponents#httpclient;4.5.6 from local-m2-cache in [default]
	org.apache.httpcomponents#httpcore;4.4.10 from local-m2-cache in [default]
	org.apache.httpcomponents#httpmime;4.5.6 from central in [default]
	org.apache.spark#spark-avro_2.12;3.0.0 from central in [default]
	org.beanshell#bsh;2.0b4 from local-m2-cache in [default]
	org.openpnp#opencv;3.2.0-1 from central in [default]
	org.scala-lang#scala-reflect;2.12.4 from central in [default]
	org.scalactic#scalactic_2.12;3.0.5 from central in [default]
	org.spark-project.spark#unused;1.0.0 from local-m2-cache in [default]
	org.testng#testng;6.8.8 from central in [default]
	org.typelevel#macro-compat_2.12;1.1.1 from central in [default]
	---------------------------------------------------------------------
	|                  |            modules            ||   artifacts   |
	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
	---------------------------------------------------------------------
	|      default     |   23  |   0   |   0   |   0   ||   23  |   0   |
	---------------------------------------------------------------------
:: retrieving :: org.apache.spark#spark-submit-parent-016b38e7-bbea-45e0-9121-bb7e6f27a128
	confs: [default]
	0 artifacts copied, 23 already retrieved (0kB/15ms)
21/06/08 13:41:38 WARN Client: Neither spark.yarn.jars nor spark.yarn.archive is set, falling back to uploading libraries under SPARK_HOME.
21/06/08 13:42:08 WARN HTTPSourceProvider: The socket source should not be used for production applications! It does not support recovery.
21/06/08 13:42:11 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Attempted to request executors before the AM has registered!

If the bug pertains to a specific feature please tag the appropriate CODEOWNER for better visibility
Additional context
when set  spark = SparkSession.builder.appName('featureEngineering').master("yarn") got same issue.  I can run lightGBM sucess, Maybe something occur mmlspark version ?
@mhamilton723   @imatiach-msft  thanks a lot
AB#1214348

it maybe spark version conflict，it work when I downgrade spark3.0 to spark2.4


Support Zip Archive

Hi,
Thx for this contribution.
I would like to know if it's possible tu support Zip archive format ?
Thx,

Hi
I don't think it's possible with the current version. The "tar" usage is hardcoded but it's possible but we can image use a variable to allow zip or tar. Can I know why you need zip?
Thanks

Hi,
Thx for reply, I need Zip, because my artifact/release is generate by Gitlab-CI.
As know as far, Gitlab-CI generate only Zip Format :
https://docs.gitlab.com/ee/user/project/pipelines/job_artifacts.html

Notes: - Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by GitLab Runner are uploaded to GitLab and are downloadable as a single archive (tar.gz) using the GitLab UI. - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format changed to ZIP, and it is now possible to browse its contents, with the added ability of downloading the files separately.

Thx,

no longer need anymore, thx


Variable: Fixes performance issues with variables with many select options

Fixes https://github.com/grafana/support-escalations/issues/9205

Makes selects virtualized to handle many options  (Select get's super slow when option count is > 5000)
Fixes very bad bug in QueryVariable where every query was thought to contain __searchFilter

📦 Published PR as canary version: 2.6.1--canary.569.7796550591.0

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

Virtualisation dupe? https://github.com/grafana/scenes/pull/563


_$X not defined

Using:

squadron: ^6.0.3 in dependencies
squadron_builder: ^6.0.2 in dev_dependencies

Input class:

https://gist.github.com/jpohhhh/230be0266fa7681cac00517fc2e66fc3

Command:

dart run build_runner build

Output for tiktoken_service.worker.g.dart:

https://gist.github.com/jpohhhh/b0d0f578113bc7c582bf6693ee7e8666

Separate issue I ran into while trying to replicate generation in example. TL;DR: Can't get files generated in the example after deleting one.
I saw the example Data marshalling that goes through the generated $X.
I attempted to verify that generation worked on my machine.
I deleted data_service_worker.g.dart.
I read README.md
I ran dart run build_runner build in squadron_builder checkout root.
data_service_worker.g.dart. was not regenerated.
I tried cd example; dart run build_runner build in /example.
The output was Bad state: Unable to generate package graph, no pubspec.yaml found.
I tried cd example/misc, [build runner], same result.
Hewing closer to README.md, I tried doing the Hello World example.
I deleted hello_world.worker.g.dart, then ran dart run build_runner build. No file was generated.
I tried the same commands in example, example/hello_world, and got the same error re: pubspec.yaml not found.

Also tried these, there is no difference in output:

adding base to the service class definition, a la https://github.com/d-markey/squadron_builder/blob/main/README.md
changing return type from Future to FutureOr and implementing marshallers manually a la https://github.com/d-markey/squadron/blob/main/README.md

code for 2: https://gist.github.com/jpohhhh/c455dd06f75f16cb75bebfe8401c8a04

Hello, I can't reproduce your issue :-(
Regarding the test you did with squadron_buildercheckout, you need to try this command line from the root dir of squadron_builder:
dart run build_runner build -d -c example

This is because the build.yaml only contains the default build settings, which build from /lib. The settings to build the examples are found in the build.example.yaml which is activated thanks to -c example.

OK, thanks for the feedback. I've also come across occasional issues when generating / regenerating, that's why I generate examples with my build_example.bat script that starts with dart run build_runner clean...
I actually never got into the WorkerGenerator.generate() is not reentrant! bit, I'm curious as to why this happened. The "shared" type manager was clearly a code smell so I added this check just in case... well, you caught it! And you nailed it too, thanks for that. I'll integrate your change in the next version if you don't mind.

I don't mind at all, please feel free: glad to hear it was sensical, felt a
bit hacky and I didn't know what I was doing, but sometimes, the best fixes
are like that :)
On Fri, Sep 27, 2024 at 1:14 PM David MARKEY @.***>
wrote:

OK, thanks for the feedback. I've also come across occasional issues when
generating / regenerating, that's why I generate examples with my
build_example.bat script that starts with dart run build_runner clean...
I actually never got into the WorkerGenerator.generate() is not reentrant!
bit, I'm curious as to why this happened. The "shared" type manager was
clearly a code smell so I added this check just in case... well, you caught
it! And you nailed it too, thanks for that. I'll integrate your change in
the next version if you don't mind.
—
Reply to this email directly, view it on GitHub
https://github.com/d-markey/squadron_builder/issues/19#issuecomment-2379727330,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APWVASJMPKDGZBZAA3ADQMTZYWG7JAVCNFSM6AAAAABO5YRVO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZZG4ZDOMZTGA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

BTW, I saw the comment "doesn't sound right to me that squadron methods are async".
This is simply because the Worker implements the service as an interface. And since communication with workers is async, the service must expose async methods. FutureOr is merely a trick to enable sync implementation at the service level, while allowing overriding the method to return a Future in the workers :) Another benefit of FutureOr is it silents the linter.

Hah, thanks for noticing: I dropped a word there, should say are not async.
tl;dr Dart Code Metrics flags it as an unnecessary future, but, it's necessary. (DCM is awesome, highly recommended, but there's some false positive.)
Also, I was thinking on the reentrant log. I still believe there was/is some local state issue on my end. But it hit me I might be challenging build_runner's async behavior, I have 12(!) services now with a ton of code/deps involved. Squadron makes it possible for me to run a full AI search engine stack in the browser, among other things.

Update published, thanks again for your contribution.
Your fix doesn't feel like a hack to me, as I'm using the same approach to consolidate multiple outputs from a build event. The solution was right under my nose!

BTW are you using build_runner watch? The concurrency issues might originate from this?


Feature/skeleton

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@af33fae). Click here to learn what that means.
The diff coverage is 41.66%.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   26.31%
=========================================
  Files             ?        9
  Lines             ?       38
  Branches          ?        9
=========================================
  Hits              ?       10
  Misses            ?       20
  Partials          ?        8

Impacted Files
Coverage Δ

src/index.js
0% <0%> (ø)

src/registerServiceWorker.js
0% <0%> (ø)

src/components/Dashboard.jsx
0% <0%> (ø)

src/components/Pipelines.jsx
0% <0%> (ø)

src/App.jsx
100% <100%> (ø)

src/components/Home/Home.jsx
100% <100%> (ø)

src/components/Sidebar/Sidebar.jsx
100% <100%> (ø)

src/components/Footer/Footer.jsx
100% <100%> (ø)

src/components/Navbar.jsx
100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af33fae...0b6ed05. Read the comment docs.


dlib.face_recognition_model_v1() hangs when using multiprocessing with python.

I am using dlib’s face_recogintion module to detect faces in a video. In order to speed up the video processing, I decided to use the python multiprocessing module to process frames in a queue as shown in the code below.

        from multiprocessing import Pool
        from collections import deque

	is_playing = True
        queue = deque()
        number_cores = cv2.getNumberOfCPUs()
        pool = Pool(processes=number_cores)

	while is_playing:

		while queue and queue[0].ready():

			task = queue.popleft()
			frame = task.get()
			cv2.imshow('Frame', frame)

		if len(queue) < number_cores:

			frame, frame_no = read_frame(video_file)

			if frame is not None:
				task = pool.apply_async(process_frame, (frame.copy(), face_input_encodings.copy(), frame_no))
				queue.append(task)
			else:
				is_playing = False

		key = cv2.waitKey(1) & 0xFF
                key == ord('q'):
			break

The process frame function is given here:
def process_frame(frame, face_input_encodings):

	original_frame = frame.copy()
	add_text(original_frame, 'original')
	add_text(frame, 'detect')

	face_locations = get_face_locations(frame)

	for face_location in face_locations:

		face_landmarks = get_landmark_shape(frame, face_location)
		face_encoding = get_face_encoding(frame, face_landmarks) # This lines doesn't work!
		match_found = check_for_match(face_encoding, face_input_encodings)

		if match_found:
			plot_landmarks(frame, face_landmarks)
			plot_rectangle(frame, face_location)
			break

	final_frame = merge_frames(frame, original_frame)
	return final_frame

face_recognizer_model = dlib.face_recognition_model_v1(FACE_MODEL_PATH)
def get_face_encoding(img, face_location):

	face_encoding = face_recognizer_model.compute_face_descriptor(img, face_location) # hangs at this line!
	return np.array(face_encoding)

However, the the program always hangs at the line face_recognizer_model.compute_face_descriptor(img, face_location).. In the main while loop queue[0].ready() is never called, hence no video is shown.
This issue only seems to happen when using multiprocessing module. The code works fine for single process environments. Can anyone shed some light on the issue?
Dlib Version: 19.10.0 , python 3
Platform: Max OS X High Sierra

This is due to an issue a bug in libdispatch for MacOS. Adding these lines fixed the issue.
  context = multiprocessing
   if "forkserver" in multiprocessing.get_all_start_methods():
       context = multiprocessing.get_context("forkserver")


fix: error with disposing notification

Fixes exceptions caused by faulty disposal method
════════ Exception caught by widgets library ═══════════════════════════════════
_ElegantNotificationState#512a0(ticker active) was disposed with an active Ticker.
════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by animation library ═════════════════════════════════
Looking up a deactivated widget's ancestor is unsafe.
════════════════════════════════════════════════════════════════════════════════

@koukibadr This one should be enough to warrant an update of the plugin in my opinion! ⚡

Thanks for enhancing the project quality @Xazin


Save bandwidth costs due to byte transfer out for mysql queries

At present there is one mysql EC2 instance which is consumed by the cron machine by public IP directly. AWS charges for data transfer. web2py creates a hash from the mysql connection i.e. mysql://username:password@publicIP.
Quick PoC:
There is an option to pass a table_hash option to the DAL initiation here which is consumed here.
This will help in changing the IP of the mysql instance to <IP_ADDRESS> and the other machines to the public IP reducing the bytes out cost for the mysql instance.

This is deployed 🤘


DOH UAT - Clicking "Device Settings" to Enable EN Does Not Bring You to Appropriate Settings Screen (HIGH)

iOS 13.6
Build: 1.0.0 (13)
If you click on "Device Settings" to enable Exposure Notifications, it just brings you to the main iOS settings page. It should bring you directly to the settings screen to enable EN (Settings > Privacy > Health). If the user tries to enable or re-enable EN after the onboarding process, they will not know how to get to the screen to enable if it just brings them to the main iOS settings page.

This is not possible, Apple don't allow deep linking into particular settings area.

This will be solved in https://github.com/project-vagabond/covid-green-app/issues/67. On iOS we can only goto either "app settings" (for enabling ENS & Notification) or "device settings" and we need to explain the users what they need to access and what to do.

@floridemai just noticed small typo on new instructions.
Please fix "Privacy > Health Settigs" to "Privacy > Health Settings"

Typos fixed


[Bug]: The Public app link is broken

Is there an existing issue for this?

[X] I have searched the existing issues

Description
The Public app link is broken

https://rbac-release.appsmith.com/app/rbac-ce-copy/postgre-62ecc040ff270560daab30e4
Steps To Reproduce

Go to home page
Open an app
click on share button
Make a app as public in share modal
Copy the app link
Open it in the new private window
the view mode of the application should be displayed but here the user is navigate to login page

Public Sample App
No response
Version
https://rbac-release.appsmith.com/app/rbac-ce-copy/postgre-62ecc040ff270560daab30e4

Miss from my side this is not an issue


DOMStringMap

Error when importing a hxd package:
C:\SDK\Haxe\haxe\std/js/html/DOMElement.hx:39: characters 29-41 : Type not found : DOMStringMap
Project-Libraries:
heaps
Additional Compiler Options:
-D resourcePath="res"
Environment:
HaxeDevelop <IP_ADDRESS> ( master#167008dca57)
Win7 :: 32bit :: Microsoft Windows [Version 6.1.7601]
cmd>haxelib list
actuate: [1.8.7]
box2d: [1.2.3]
flixel: [4.1.1]
format: [3.2.1]
halk: [git]
heaps: [git]
hscript: [2.0.7]
hxcpp: [3.3.49]
kha: [16.1.2] git
layout: [1.2.1]
lime-samples: [2.6.0]
lime: 2.9.1 3.1.0 [3.2.0]
moon-ai: [0.1.0]
moon-core: [1.1.1]
msignal: [1.2.4]
nme: [5.6.4]
openfl-samples: [4.0.0]
openfl: 3.6.1 4.1.0 [4.2.0]
starling: [0.5.7]
swf: [2.2.4]

Seems like something is broken with you haxe install since the error is inside a Haxe std file and is not related to Heaps.


.hu WHOIS server

Description
.hu WHOIS lookups became really bad over the past years, you can no longer lookup the data from whois.nic.hu, you must
use  https://www.domain.hu/domain-kereses to make a lookup with captcha involved.
 Looks like this might not work anymore?

Well, considering the WHOIS client for Linux gives just about the same amount of information, I'd say .hu is "broken".
whois orhalom.hu
% Whois server 3.0 serving the hu ccTLD

domain:         orhalom.hu
record created: 2009-07-08 23:00:52
Tovabbi adatokert ld.:
https://www.domain.hu/domain-kereses/
For further data see:
https://www.domain.hu/domain-search/
You'd think there were rules for how data must be available and served at the various country levels.
If you, however, use the -I parameter for WHOIS, you do get correct information.
-I      First  query whois.iana.org and then follow its referral to the whois server
authoritative for that request. This works for IP addresses, AS numbers and domains.
BEWARE: this implies that the IANA server will receive your complete query.

The biggest problem with whois servers is that they format the response differently and not all of them give the same information.
The library already reads only the main ones (and not all), for the TLDs that do not return them it is sufficient to check them first to avoid having errors.
Look at this simple example:
use Iodev\Whois\Factory;

$whois = Factory::get()->createWhois();

if (!$whois->isDomainAvailable("google.hu")) {
    print 'Domain is NOT available!';
}
print "\n\n";

$response = $whois->lookupDomain("google.hu");
print $response->text;
print "\n\n";

$info = $whois->loadDomainInfo("google.hu");

if ($info->creationDate) {
  print 'Domain created ' . date("Y-m-d", $info->creationDate);
}
else {
  print 'Creation not available.';
}

print "\n\n";

if ($info->expirationDate) {
  print 'Domain expires ' . date("Y-m-d", $info->expirationDate);
}
else {
  print 'Expiration not available.';
}
print "\n\n";
if ($whois->isDomainAvailable("domainnotregistered.hu")) {
    print 'Domain is available!';
}

Domain is NOT available!

% Whois server 3.0 serving the hu ccTLD

domain:         google.hu
record created: 2000-03-25 23:20:39
Tovabbi adatokert ld.:
https://www.domain.hu/domain-kereses/
For further data see:
https://www.domain.hu/domain-search/

Domain created 2000-03-25

Expiration not available.

Domain is available!

It is enough to understand if a domain is registered or not, to obtain the complete text of the whois and the other only data provided, that is the registration date.
Obviously you could do more, manage all the exceptions of each TLD and improve the parsing of all the answers, I thought about it every now and then but I think it would take a refactoring of the entire library and resources to do it, but seeing the number of contributors I think there just aren't enough.
NOTE
Then another note on the .hu, the registration is manual, when it started but they haven't completed all the work yet, the whois server gives a still different answer, i.e .:
% Whois server 3.0 serving the hu ccTLD

domain:         pendingdomain.hu

Tovabbi adatokert ld.:
https://www.domain.hu/domain-kereses/
For further data see:
https://www.domain.hu/domain-search/

The difference is that the registration date is not yet available (as it is pending) and the library, not finding the date, considers the domain free.
At that moment it is neither free nor registered, it is pending, but in fact it cannot be registered.
This is obviously not handled by the library.

I gave up already on .hu, it's crap in every way to make a normal system for either WHOIS or for the registration itself. Thanks anyways! :)


Incorrect order of interfaces that start with numbers

Environment

Python version:  3.6.7
NetBox version:  2.5.13

Huawei CE switches can have interface names start with numbers, for example: 10GE1/0/1 or 40GE1/0/5. Such names have incorrect order in the list of interfaces.
Steps to Reproduce

Add interfaces with names 10GE1/0/[1-48] to device

Expected Behavior
list of interfaces with ascending order

Observed Behavior
Natural ordering doesn't work correctly

NetBox employs custom logic to naturally order interfaces as best we can. Unfortunately, it is not feasible to accommodate every naming scheme.
I'm going to close this as non-actionable. However, if you'd like to propose a specific modification to the existing logic that will address your use case without impacting any of the existing test cases, I'm happy to re-open it.


Default targets don't work correctly when element-path is "."

See original issue on GitLab
In GitLab by [Gitlab user @cs-shadow] on Apr 10, 2019, 14:37
Summary
When element-path of a project is configured to ., i.e. the project directory, our logic for finding default elements breaks down. Since we stage junctions in .bst directory, the current logic tries to find all .bst files inside the junction, which is not expected. It's worse than that because it mangles the path and then tries to look for those elements in bst directory instead of .bst, and fails subsequently.
Steps to reproduce

Create a project with element-path: ..
Create a junction on some other project.
Run bst show, everything should be fine this time as we won't have .bst directory to begin with.
Run bst show again, watch it fail, as this time bst tries to find elements in the staged junctions.

What is the current bug behavior?
bst show or any other commands fail on all subsequent runs when no target is specified.
What is the expected correct behavior?
bst show and other commands should not attempt to find elements from staged junctions, and not error out in either case.
Relevant logs and/or screenshots

In GitLab by [Gitlab user @cs-shadow] on Apr 10, 2019, 14:37
changed the description

In GitLab by [Gitlab user @cs-shadow] on Apr 10, 2019, 14:46
mentioned in commit 3c0f540dd620de30445ac2351821c9a395aa750f

In GitLab by [Gitlab user @cs-shadow] on Apr 10, 2019, 14:47
mentioned in merge request !1284

In GitLab by [Gitlab user @marge-bot123] on Apr 10, 2019, 17:44
closed via merge request !1284

In GitLab by [Gitlab user @marge-bot123] on Apr 10, 2019, 17:44
mentioned in commit b9cdf82c6c33d18ae08d17dce5fa041486893ec0


chore: include internal hops into workshop test config

Bors merge bot cheat sheet
We are using bors-ng to automate merging of our pull requests. The following table provides a summary of commands that are available to reviewers (members of this repository with push access) and delegates (in case of bors delegate+ or bors delegate=[list]).

Syntax
Description

bors merge
Run the test suite and push to master if it passes. Short for "reviewed: looks good."

bors merge-
Cancel an r+, r=, merge, or merge=

bors try
Run the test suite without pushing to master.

bors try-
Cancel a try

bors delegate+
Allow the pull request author to merge their changes.

bors delegate=[list]
Allow the listed users to r+ this pull request's changes.

bors retry
Run the previous command a second time.

This is a short collection of opinionated commands. For a full list of the commands read the bors reference.

I can as well edit the commit on the release PR branch. 🤷♂

bors merge


It is not clear that a kernel is running. It should be.

Whether you run all the cells in a notebook, or "this cell and down" or just run a single cell, it is extremely difficult to tell that a kernel is running. The only indication comes through scrolling through the notebook looking for timers in the cell status bars or if you happen to see that the "interrupt kernel" toolbar icon is no longer grayed out. Since it's gray to begin with, the difference is really subtle.
Ideas:

Disable the run xxx commands when a kernel is running.
Make the interrupt kernel button red so that it's more noticeable.
Provide some hint on the VS Code status bar
Provide a widget in a location similar to what Jupyter Lab and Classic uses (a green "busy" circle)

Any or all of the above.

@greazer I believe that the "goto running cell" button that has the spinner icon handles this pretty well. Closing, but reactivate if you disagree :).


Give better error when security update not possible due to "lockfile_only" strategy

What are you trying to accomplish?
I receive the following error when Dependabot tries to create a security update for an advisory:

Anything you want to highlight for special attention from reviewers?
This PR tries to change the above error to instead read:

Dependabot cannot update activeadmin to a non-vulnerable version
The latest possible version of activeadmin that can be installed is 4.0.0.beta6.
The earliest fixed version is 4.0.0.beta7.

Which makes more sense.
How will you know you've accomplished your goal?

Checklist

[x] I have run the complete test suite to ensure all tests and linters pass.
[x] I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
[x] I have written clear and descriptive commit messages.
[x] I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
[x] I have ensured that the code is well-documented and easy to understand.

This should be ready now!


project status

hi, is this git repo the official project replacement for http://alcinoe.svn.sourceforge.net/viewvc/alcinoe/ ?
or just a copy?

Both are synchronized so you can choose with you prefer ! github offer Git for people who like git and sourceforge offer svn for people who prefer svn.


Proposal: add files field in config file.

The proposal allows user specify which files should be checked when use command line. And for IDE to determining the current opening fie if should be checked or not. For example, the WebStorm will check any *.ts files opening in edit tab, even if it is not in the current project.

WebStorm does not use the CLI, therefore it has to include and exclude files on its own behalf.
That part of you feature request is better suggested in their issue tracker.

Re: files in tslint.json

would only work if you use tslint -c tslint.json
once you specify a file as CLI argument, it should override the ones specified in the config
how should tslint-c tslint.json -p tsconfig.json work? Take all files specified in tsconfig.json or tslint.json?

Related: https://github.com/palantir/tslint/issues/858

--project path/to/tsconfig.json should be sufficient for most use cases like this.


Disable BigQueryStorageStreamSource.splitAtFraction when read api v2 used

Follow up of #28778, stay in alignment with #25392 where the streams returned by the server won't be splited further
Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @ahmedabu98 @vachan-shetty

Ping for reviewers

👍🏽


Report total watering time as part of the water use summary

Report total watering time as part of the water use summary. Right now, we only report remaining watering time during an active watering cycle.
Refactored the code to allow fetching the water use summary even in the absence of a flow sensor. In this case, we only report the total watering time. The total water use will be zero. The allows us to expose the daily total watering time in HA even for folks that don't own a flow sensor.

@dknowles2 is there still anything needed before merging?


Android 12 Keyboard in Card Payment is not opening

Describe the bug
Android 12 Keyboard in CardPayment is not opening
To Reproduce
Run Android 12 ,
Open payment by Card,
Focus Card Input.
See the keyboard
Expected behavior
To open the keyboard
Screenshots
If applicable, add screenshots to help explain your problem.
Android 12
(on 11 and 13 work fine)
if you guys need Video or Image of the issue I can provide in Monday.

Hey @YankovWeb

Run Android 12

Physical device or emulator?

Please provide a video :)

Thank you for the fast respond.
https://github.com/Adyen/adyen-react-native/assets/109748669/1e89d0ca-eb77-44a7-8323-c795c062bb03

Hey @YankovWeb
What version of Adyen React Native SDK you are using?
I wasn't able to reproduce it on latest one.

Is something wrong with a keyboard? Do you have similar behaviour on other apps?
Can you reproduce this behaviour on other Android 12 devices/emulator?

Have you modify your app's AndroidManifest.xml ?

Version 1.2.1v.
Unfortunately, I am currently on sick leave. My colleagues will provide the answers and continue the conversation.
Thank you!

Take care @YankovWeb
I did local tests with 1.2.1 on Motorola G51 Android 12 and I am not able to reproduce the bug.
IMHO this issue could be device-specific.
Do you have any other plugins effecting keyboard?

Redmi Note 10 ,  oppo A96 was the reported devices.

Hey @YankovWeb
So you are able to reproduce this issue on 2 devices?
Can you reproduce it on a blank project?

Do you have any other plugins that may effecting keyboard?

The QA reproduce it in browserStack,
I will try with black project.
I don't think so.

Okay, in BrowserStack, on the same devices (11 and 13), the Android keyboard is working, but on Android 12, it looks like it is behind the drop-in. After we close the drop-in, the keyboard opens.
this is in the manifest
`

<activity android:name=".MainActivity" android:label="@string/app_name" android:screenOrientation="portrait" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode" android:launchMode="singleTask" android:windowSoftInputMode="adjustResize" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
  <intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="consumer" />
  </intent-filter>
  <intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="http" />
    <data android:scheme="https" />
    <data android:host="www.deeplinkdemo.com" />
  </intent-filter>
</activity>
<service android:name="com.adyenreactnativesdk.component.dropin.AdyenCheckoutService" android:exported="false"/>

`
Is it possible to test it on browserStack ?

Hey @YankovWeb, does the issue still persist?


[FEATURE REQUEST] Natively support envelopes, e.g., CloudEvents

It's a common practice to use message envelopes in event-driven architectures. Most of the time, these envelopes contain information about the company, the domain context, or other application-specific data. Envelopes are also a great way to standardize messages structure across the whole organization, making it easier to build code around it.
The most common case I've found so far —aside from custom formats— is the usage of CloudEvents. Especially, when used together with Kafka and Avro. Trying to define such a system, comes with confusing decisions:

What's should schemaFormat look like? Should it be JSON Schema, Avro, or CloudEvents? Everything could be defined using JSON Schema or Avro, but since the "data" of the envelope is Avro, things get confusing here. Is CloudEvents a schema format at all? I don't think so.
Should we define the message on the AsyncAPI file as if the envelope wasn't there? Or should we include it somehow? If we include it on every message payload, we'll then have to maintain a lot of repeated information across messages, making it harder to update the envelope on every single message.
Should we put this information as a protocol binding? If so, is CloudEvents really a protocol? I don't think so.
Should we just use an extension? Probably yes as a starting point but this case is very frequent and would love to have AsyncAPI recognize it as a first-class citizen.

For these reasons, I think it would be interesting to come up with a first-class solution for envelopes in AsyncAPI. This would make people feel everything is integrated better instead of hacking the spec here and there.
Example
Please, take this example as an illustration of what I'm trying to accomplish here. By no means, it's a final solution.
asyncapi: 2.0.0
channels:
  test:
    message:
      schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
      envelope:
        format: application/cloudevents # This would tell parsers that it's a CloudEvents envelope. Can be optional.
        schema:
          type: object
          properties:
            specversion:
              type: string
              enum: ['1.0', '1.1'] # In case we want to restrict to specific versions of the CloudEvents spec
            myCustomField: # Define custom fields here. Those that are not defined on the CE spec.
              type: string
      payload:
        type: record
        # ... more Avro stuff

Open Questions/Thoughts

What if we could define that CloudEvents (CE) message fields must be placed in the headers or in the payload? CE has its own bindings and, in some of them, they allow you to map the fields to headers or to the payload/body. It would be great to have a way to define that.
Use envelope + bindings. For instance, in the case of CE, we could use a binding called cloudevents that will allow us to define how it's used (not used, binary, structured, both). I don't think we want to define that the envelope fields are going to be placed on the headers section because then they would not be an envelope anymore, right? Food for thought tho.
Should we support in-house envelopes at all? Or should these people be "penalized" for not using a standard format? In any case, we must consider that even CE allows you to define custom fields and their support is a must.

That's a very interesting point and a super valid usecase. In the next community call I wanted to suggest something similar called event metadata. In the past months I found a lot of useful usecase based on generalised metadata.

In the next community call I wanted to suggest something similar called event metadata.

I usually recommend putting metadata in headers but agree it's not always possible. For instance, when using WebSockets, there are no headers. Let's discuss it on the next call (I've added it).

I am wondering whether the envelope concept is too related to cloudevents or it can be easily generalised. From what I remember about cloudevents, their envelope has a very specific schema.

In my example, I'm trying to make it generic enough, that's why it has an optional format field and an optional schema field. If your envelope doesn't follow any standards (i.e., it's built in-house) you can leverage schema. That should be enough for custom envelopes, I think.

do we really need a new envelope section? CloudEvents is not a protocol, but the definition of bindings in AsyncAPI is AsyncAPI offers a mechanism called “bindings” that aims to help with more specific information about the protocol and/or the topology so isn't it part fo the topology? and, even if I'm super wrong here, wouldn't it be better to just extend the scope of bindings and have cloudevents binding instead of having envelope that so far would only work for Cloud Events?

That would work for CloudEvents but not for custom envelope formats, which are even more common than CloudEvents, especially in the enterprise. Also, I have the feeling that if we start putting too much stuff in the bindings it's gonna become a black box nobody wants to open.

So I guess something to consider, as I understand CloudEvents when working with HTTP as an example, the 'Envelope' can be wrapping the message body, which of course fits nicely into the proposal or it could be with the message headers, with unchanged body or it can be a wrapper and also in the headers. That for me at least gets a little confusing if defined as an Envelope block.
Of course not all protocols support these options. So I guess you could place a configuration flag in the envelope specifying where the envelope is to be placed but this is surely protocol dependent.
My 2 cents on how could this be handled,

Use the Envelope section and then with in the binding specific how the CloudEvent is used (not used, binary, structured, both)
Define CloudEvents within the binding as required for that implement of the protocol

IMHO I think [1] might be a good option as the protocol different handling can be restricted to the binding.

Let me recap and clarify what this proposal is and isn't about, just to make sure we're all aligned here:
✅ Add a way to specify that a message's payload is wrapped in an envelope.
✅ Make it easy and obvious for people to define their messages in CloudEvents + Avro/JSON Schema/etc.
✅ Make it easy and obvious for people to define any envelope format, including those built in-house that have no specific name or the name is internal to the organization.
✅ Place this information in the spec in a semantic way. To clarify, envelope has a clear meaning while using a binding for an envelope doesn't really make it clear if it's an envelope or it's a protocol (MQTT, AMQP, Kafka, etc.).
❌ Create something specific to CloudEvents.
❌ Create something specific to any format because we might not know the name in advance, so it can't be placed at bindings. The envelope format might not even have a name at all and it's just known inside the organization as "the envelope" or "the wrapper", etc.
❌ Have a way to define envelopes for headers or any other section that isn't payload.

Now, IMO, there are a couple of interesting points that were raised during the last call and on the last comment from @Paul-T-AU:

What if we could define that CloudEvents (CE) message fields must be placed in the headers or in the payload? CE has its own bindings and, in some of them, they allow you to map the fields to headers or to the payload/body. It would be great to have a way to define that.
Use envelope + bindings. For instance, in the case of CE, we could use a binding called cloudevents that will allow us to define how it's used (not used, binary, structured, both). I don't think we want to define that the envelope fields are going to be placed on the headers section because then they would not be an envelope anymore, right? Food for thought tho.
Should we support in-house envelopes at all? Or should these people be "penalized" for not using a standard format? In any case, we must consider that even CE allows you to define custom fields and their support is a must.

I'm adding these questions/thoughts to the original comment. Anything else I should be adding in your opinion?

@fmvilas A point of clarification, when we say CloudEvents, is the proposal to be CloudEvents compliant or CloudEvents like/inspired?

CloudEvents compliant. The idea is to allow users of CloudEvents reuse their existing messages.

I am interested in the envelope feature for built in-house case. Our current set up is done over Kafka with json format and it looks to something like this with current capabilities:
asyncapi: 2.0.0
info:
  title: Some application
  version: '0.1.0'
servers:
  kafka-rest-proxy:
    url: http://{kafkadomain}:{port}
    protocol: kafka
    variables:
      kafkadomain:
        default: kafka-rest-proxy
      port:
        default: '8082'
channels:
  item-created:
    publish:
      message:
        $ref: '#/components/messages/MessageWithEnvelopeExample'
components:
  messages:
    MessageWithEnvelopeExample:
      payload:
        type: object
        properties:
          timestamp:
            type: string
          uuid:
            type: string
          payload:
            type: object
            properties:
              pk:
                type: integer
                minimum: 1
                description: Primary key of the related object
              value:
                $ref: '#/components/schemas/Item'
              extra:
                type: object
  schemas:
    Item:
      type: object
      properties:
        amount:
          type: number
          format: float
          description: Some number

Does this match with the intended feature scope?

Following previous comment, firstly say that we have come with an alternative for not having to repeat envelope in each message by using composition with allOf.
asyncapi: 2.0.0
info:
  title: Some application
  version: '0.1.0'
servers:
  kafka-rest-proxy:
    url: http://{kafkadomain}:{port}
    protocol: kafka
    variables:
      kafkadomain:
        default: kafka-rest-proxy
      port:
        default: '8082'

channels:
  item1-created:
    publish:
      message:
        $ref: '#/components/messages/MessageWithEnvelopeExample1'
  item2-created:
    publish:
      message:
        $ref: '#/components/messages/MessageWithEnvelopeExample2'

components:
  messages:
    MessageWithEnvelopeExample1:
      payload:
        allOf:
          - $ref: '#/components/schemas/Envelope'
          - $ref: '#/components/schemas/PayloadItem1'

    MessageWithEnvelopeExample2:
      payload:
        allOf:
          - $ref: '#/components/schemas/Envelope'
          - $ref: '#/components/schemas/PayloadItem2'

  schemas:
    Envelope:
      type: object
      additionalProperties: false
      properties:
        fired_at:
          type: string
          format: date-time
          description: Represents the moment the message was fired.
        uuid:
          type: string
          description: Uniquely identifies the event and allow for detecting duplicates.

    PayloadItem1:
      type: object
      additionalProperties: false
      properties:
        payload:
          type: object
          properties:
            pk:
              type: integer
              minimum: 1
              description: Primary key of the related object
            value:
              $ref: '#/components/schemas/Item1'
            extra:
              type: object

    PayloadItem2:
      type: object
      additionalProperties: false
      properties:
        payload:
          type: object
          properties:
            pk:
              type: integer
              minimum: 1
              description: Primary key of the related object
            value:
              $ref: '#/components/schemas/Item2'
            extra:
              type: object

    Item1:
      type: object
      properties:
        amount:
          type: number
          format: float
          description: Some number

    Item2:
      type: object
      properties:
        name:
          type: string
          description: Some name

I guess this must have other cons besides than not declaring explicitely that an envelope may have different concerns for the clients, but the result looks quite similar with what would be expected with the proposal.
This said, following the proposal for being CloudEvents friendly, what I would need for being also friendly with my case, is being able to define which one in the key containing "the payload data". In the case of CloudEvents, it is contained under "data", in my case it is under "payload".
So, if I take the proposal to convert it into my example, it could be looking to something like this:
components:
  messages:
    MessageWithEnvelopeExample1:
      envelope:
        $ref: '#/components/schemas/Envelope'
      payload:
        $ref: '#/components/schemas/PayloadItem1'

    MessageWithEnvelopeExample2:
      payload:
        envelope:
          $ref: '#/components/schemas/Envelope'
        payload:
          $ref: '#/components/schemas/PayloadItem1'

  schemas:
    Envelope:
      type: object
      additionalProperties: false
      properties:
        fired_at:
          type: string
          format: date-time
          description: Represents the moment the message was fired.
        uuid:
          type: string
          description: Uniquely identifies the event and allow for detecting duplicates.
      payload-ref: payload  # optional, when not present it will set 'data' as in the case of CloudEvents.

    PayloadItem1:
      type: object
      properties:  # now I wouldn't need to double-nest payload thanks to payload-ref
        pk:
          type: integer
          minimum: 1
          description: Primary key of the related object
        value:
          $ref: '#/components/schemas/Item1'
        extra:
          type: object

    PayloadItem2:
      type: object
      properties: # now I wouldn't need to double-nest payload thanks to payload-ref
        pk:
          type: integer
          minimum: 1
          description: Primary key of the related object
        value:
          $ref: '#/components/schemas/Item2'
        extra:
          type: object

payload-ref (or a better name), would act somehow like discriminator do to define polymorphism.

Hi. I read your related article.
You say in there a short definition for CloudEvent:
schemaFormat: 'application/cloudevents+json; version=0.2; charset=utf-8'.
Can you clarify please this definition? Do I have to create a file named: cloudevents.json and put their the CloudEvent fields at json format? Or is this definition is parsed and magically understandable by the AsyncApi parser?

Any updates on this? seems like a critical feature that an async API schema natively documents the message envelope

I'm gonna work on this for v3.0.0, that's all I can say so far. No plans to have it for v2.x.

that's all I can say so far

Just for the record, I meant "I haven't really looked at it in detail yet so don't know". Hope it didn't look like I'm hiding information or something 😅

It would be nice if there was a way to describe the CE metadata/context without having to also understand the way that information is encoded into the payload (structured mode) or transport headers (binary mode). Also note that when using structured JSON (application/cloudevents+json) the business data may appear in either 'data' or 'data_base64'.
Also note that CE's allow for events that only contain metadata, ie no business data.

This feels like "HTTP header fields for events", i.e. a way how there's some agreement on syntax and semantics of how events work. It feels very powerful and relevant, but also rather tricky because unlike HTTP, we don't have a shared foundation that's designed for openness and extensibility. I sincerely hope that this will come to fruition at some point!

I am also stumbling upon this.
In case the payload for the message MyMessage is:
{
  "field1": "value1",
  "field2": "value1"
}

This envelope can be used:
{
  "type:": "MyMessage",
  "data" :  {
     "field1": "value1",
     "field2": "value1"
  }
}

or this envelope:
{
  "MyMessage": {
     "field1": "value1",
     "field2": "value1"
}

And these are only 2 examples.
It would be nice not to specify the wrapping as part of the payload, but as a separate concern.
In this case there should be some way to reference the type of the message.  This could be de messageId.
Does anyone have any (new) thoughts on this?

I haven't touched this issue in a while because we're working on the v3 release but this is one of my favorites for v3.1. The way I'd do it is similar to what we already have in the spec regarding correlationId. You pass whatever you want as the envelope and specify the path in which the data is contained. For instance, roughly something like this:
messages:
  MyMessage:
    envelopes:
      payload: # <- This is the payload definition (could be extracted from current message payload definition)
        type: object
        properties:
          type:
            type: string
          data:
            type: object
      dataPath: '#/data' # <- This is to indicate where the "data" field is

We can then also have headers inside envelopes. Not perfect but simple enough I think. What do you think?


Skip tests if not root

This should allow running locally without requiring capabilities flags
or root. Note that I'm not actually checking for capabilities and just
for uid = 0 to determine if I should skip or not.

+1


Couldn't fetch parent branch

warning: Some Tfs branches could not have been initialized or entirely fetched due to errors:

$/Collection/DW 2.0/Release
=>error:error: Couldn't fetch parent branch

Please report this case to the git-tfs developers! (report here : https://github.com/git-tfs/git-tfs/issues )

Hi @janissimsons , Were you able to workout a solution for this issue? I get the same error while trying to clone the master branch. Not just that if I try to clone some other branch, only the first change set is copied and the remaining changes are all ignored.

Hi @GauravRawat01, I don't remember what was the exact command I ran to get this error, I did a lot of experimentation, and in the end, I used this one:
git-tfs clone http://server.address.here/tfs/TFS2008Collection "$/ProjectNameHere/RepositoryNameHere/Development" . --branches=all --changeset=865153
I used a specific changeset (which was from around year 2017), to limit how much history we get, but you can also remove the changeset option, if you want all of the history.
Another important thing, after the clone was complete, I ran:
git tfs branch –init --all
so it recreates branches that failed to clone properly.
I essentially, followed this guide:
https://blog.cellenza.com/devops/migrating-from-tfvc-to-git/

Thanks for the response @janissimsons but in the meanwhile I tried a different tool (git-tf) and got the entire history and branching data without much fuss.

@GauravRawat01 which git-tf tool are you talking about? I thought git-tf didn't support branching?


allow user to pass in regex for resource lookup

dhcp networks are given a name at create-time by the dhcp service, so we won't know network name -OR- ID until after it's created. we'll have to settle for this, which will create a one-DHCP-nw-per-cloud-instance restriction until we can get a feature request accepted and implemented by powervs
Signed-off-by: Christy Norman<EMAIL_ADDRESS>

If this has to be done then we may need to remove this check in mapio webhook https://github.com/openshift/machine-api-operator/pull/998/files#r831762016

I avoid such logic into the controller code because there may be good chance in the future where they may change the naming pattern itself.
Instead I'm wondering if we can add one more field called regex here so that the calling code can specify whatever regex they want.
wdys @Karthik-K-N @clnperez

Yeah, I think this approach looks good to me, By this way we can add validation as well for Network.

ah yah, that's a good idea to have the regex not be hardcoded in the controller itself. i can resubmit with that today

No matter what I do for that import statement, these tests fail. I changed it to what the generate outputs but then it complains with the opposite reason.

added that json line, rebased, and re-pushed 🤞🏻

this is stuck. github is being odd lately
/retest

/lgtm


Adding a random joke generator

I will be be adding a random joke generator in the website which will work on a public REST API. @lovishprabhakar kindly assign this issue and label it with hacktoberfest so that I can work on it. Thanks

Go ahead @cyberbuddy-manas!

@cyberbuddy-manas updates?

@lovishprabhakar Done


Only security updates feature is not working now

I have a very simple question, I did a lot of Google but could not find the answer anywhere. Sorry I have to seek for this answer here.
Earlier, there was an option in https://app.dependabot.com for "Only security updates" which were creating the PRs with the label security and [Security] in the commit message.

I see no option to achieve this now. I am sure there is a filter something like this only-security-updates: true which can be defined in dependabot.yml file i.e.:
version: 2
updates:
- package-ecosystem: pip
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 10
  only-security-updates: true

Either it does not exist or I am unable to locate it. Kindly help.

I am getting this error:
The property '#/updates/0/' contains additional properties ["only-security-updates"] outside of the schema when none are allowed

I have the same problem and this started happening this week only. Earlier this option was working fine from UI but no idea how can be achieved in yml file.

Security updates are not handled via the yml file, instead you have to use a repo setting.  See Configuring Dependabot security updates for more details.

Hi @calix2 - the reply above from @ocean90 is correct, in Dependabot native we provide security updates as a repository setting. The config file is only required to manage Version updates, so you no longer need the file if you just want security patches.

Based on @brrygrdn's comment above, I think that answers the question and we can close this issue now.
If there's more to do here, please let us know and we can reopen. :bow:

Understood, thanks for the clarifications @jasonrudolph @ocean90 @brrygrdn
Last question: Since we would like to have PRs only for security updates, there is no way to limit the PRs and schedule interval?

Since we would like to have PRs only for security updates, there is no way to limit the PRs and schedule interval?

Correct. At the moment, Dependabot aims to open a security update PR in response to each vulnerability that is published, and Dependabot optimizes for getting those updates to you as soon as possible (as opposed to waiting for a specific time or day or day of the week).


add talk-pacific

Community Resource Name
talk-pacific
What is it?
mailing list
URL link to the resource
https://lists.openstreetmap.org/listinfo/talk-pacific
Location
Peoples of the
Moana/Oceania/Pacific.
Description (optional)
example:  "Join our group here: {url}"
Languages spoken (optional)
example: "en"
Points of contact (optional)
List of people who moderate or manage the community.
Each should include both a name and email:
example:  "Ian Dees<EMAIL_ADDRESS>

@mapmakerdavid @ViolaineDo I think we should try to get talk-pacific included in the community index here, so it pops up for mappers making edits in the region, what do you think?. Any particular country codes and language codes to use?

Thanks, I'd like to help get this resource added!
You can browse https://ideditor.codes/ to see what country and region codes we currently have "built-in" support for.
These include ISO 3166-1 2 or 3 letter country codes, UN M.49 numeric codes, and supported Wikidata QIDs.
For example, "Oceania", code 009 includes this:
https://ideditor.codes/?code=Q538
BUT - please don't feel that you're limited to using country and region codes.
The software can support any custom geojson area, so we could just draw a big polygon around everything you want included and use that as the "location" for talk-pacific.

I added this resource today with a broad geojson that covers the Pacific and coastal areas, and the common indigenous languages too (see below).  It will start showing up soon for mappers editing in the Pacific.  I'm happy to revise it if you want..
Hoping everyone in the Pacific OSM community is safe and well following last week's eruption and tsunami near Tonga.
Let me know how and if we can support you!
{
  "id": "talk-pacific",
  "type": "mailinglist",
  "account": "talk-pacific",
  "locationSet": {"include": ["pacific.geojson"]},
  "languageCodes": ["en", "fr", "haw", "mi", "sm", "to", "ty"],
  "strings": {
    "description": "The regional OSM mailing list for and by the peoples of the Moana/Oceania/Pacific",
    "extendedDescription": "We would like this mailing list to support all peoples of the Pacific, in all of our diversity and aspirations, to share thoughts, questions, projects, and everything related to OpenStreetMap in our sea of islands."
  }
}

I'd rather leave it to @mapmakerdavid and @ViolaineDo to make a call on the area, but I would assume because we already have dedicated mailing lists for AU, NZ, JP that those are excluded. I'd also move the border in from the Americas so coastal regions of the Americas don't fall within the area.

Hi,
Sounds ok for the language part/description, and i would remove Australia and New zealand borders who have their own mailing lists. Thats list was made for Pacific islands, to have their own space. Which is the reason why we didn't name it oceania mailing list. Is thats enough informations ?
Best regards
Le 18 janvier 2022 12:02:15 GMT-10:00, Andrew Harvey @.***> a écrit :

I'd rather leave it to @mapmakerdavid and @ViolaineDo to make a call on the area, but I would assume because we already have dedicated mailing lists for AU, NZ, JP that those are excluded. I'd also move the border in from the Americas so coastal regions of the Americas don't fall within the area.
--
Reply to this email directly or view it on GitHub:
https://github.com/osmlab/osm-community-index/issues/498#issuecomment-1015874063
You are receiving this because you were mentioned.
Message ID: @.***>


Unify ValueExpression instance naming and update JavaDoc

Implemented the naming scheme as proposed in #274.
Additionally, when updating the JavaDoc to reflect the new names, also updated it. Most important change there is that in places where constructor arguments/fields are referred to as operand(s), this has been changed to field()s since that word is more accurate in the context of the Java code it describes.

To be honest, this does not look like an improvement to me.
Let's take a look at the first class in the diff:
public abstract class BinaryValueExpression implements ValueExpression {

    public final ValueExpression left;
    public final ValueExpression right;

    public BinaryValueExpression(final ValueExpression left, final ValueExpression right) {
        this.left = checkNotNull(left, "left");
        this.right = checkNotNull(right, "right");
    }

Now turns into:
public abstract class BinaryValueExpression implements ValueExpression {
    public final ValueExpression lefts;
    public final ValueExpression rights;

    public BinaryValueExpression(final ValueExpression lefts, final ValueExpression rights) {
        this.lefts = checkNotNull(lefts, "lefts");
        this.rights = checkNotNull(rights, "rights");
    }

The fact that a single ValueExpression results in a collection of values, multiple "lefts", does not warrant the field name change. We have a single ValueExpression, so the singular left make total sense to me.
If we continue with this, we will end up with Gollum-ish variable names, like leftses for ValueExpression[] or List<ValueExpression>.

The Precious will be ours once the hobbitses are dead.

Isn't the problem mostly with the variable names we use for the result of these expressions, instead of the names of the fields?

Maybe it would make more sense to give the resulting variables more meaningful names.
From Bytes:
final ImmutableList<Optional<Value>> evaluatedOperands = operands.eval(parseState, encoding);

evaluatedOperands says nothing about what we are actually dealing with here.
In this case, using a more meaningful name could be:
final ImmutableList<Optional<Value>> bytes = operand.eval(parseState, encoding);

(Note the singular operand here.)

In this case, using a more meaningful name could be:
final ImmutableList<Optional<Value>> bytes = operand.eval(parseState, encoding);

Unfortunately this is a good example of why evaluatedOperands is a better name: this line you are quoting in no way represents anything that could accurately be described by the name bytes. It's just a completely unknown result of evaluating a ValueExpression that we will transform into a representation of byte values. But at this point in the processing, bytes completely misrepresents what it is, because it's a list of Optional<Value> instances without any additional meaning attached to it.

To respond to your first comment, I totally agree that lefts, rights and even operands looks horrible. I was trying to apply the scheme without thinking in order to find some edge situations that would be unclear or strange. The lefts-case is the most glaring one, but there are some others.
For example, when extracting a value from a list of evaluatedBases we would refer to it as a baseValue, but once we convert that from a Value to a BigInteger (or something else) we still use baseValue? It's a little difficult to determine a good scheme there.

Unfortunately this is a good example of why evaluatedOperand (with or without the s) is a better name: this line you are quoting in no way represents anything that could accurately be described by the name bytes.

I agree that the name bytes in this case is also not ideal. But evaluatedOperand is also rather confusing to me. In many (if not all) cases we should be able to come up with a more meaningful name. Concatenating the variable name (operand) with the method we invoked on it (eval) does not improve our code much, IMHO.
As we know, naming things is hard :grin:

This makes sense on some level: in the case of left or operand, the name describes what it itself is, a left operand or the operand. In the case of bases or offsets, the name describes what it represents, which can be singular or plurar. It just bugs me that in many cases we don't have a real description (Unless we want to give the operands specific names like divisor for the right operand of Div?)

I feel your pain. But I guess that's the problem with all the very generic code inside a parser combinator implementation.
Using the name divisor in Div makes a lot of sense to me, and I think we should do things like that wherever we can (left would become dividend). But within classes like BinaryValueExpression, we have no choice but to use those very generic names.

Ok this is it. I totally agree that stuff like methodedVariable are not really nice names. But I do think that this PR moves things a little bit in the right direction, so I hope you'll agree @rdvdijk @mvanaken @ccreeten :)

I'm going to incorporate the best stuff from this branch/PR into a single commit on the other PR (#273). Thanks for the feedback!


metrics suggestion: backup jobs, replication jobs, and IO delay

hey @znerol, thank you for creating this helpful exporter :raised_hands:
i'd like to track and set up alerts for failed or absent backups, replications, and on high IO delay (the one that's displayed in the webui for each node).
cheers :wave:

This exporter is using the PVE REST API. Looking through the API docs I have found the following interesting routes possibly covering your requirements (at least partly):
absent backups:
cluster/backup-info/not-backet-up lists all guests (qemu and lxc) which are not covered by any backup plan.
failed backups:
Maybe this is extractable from /cluster/backup.
failed replications:
Maybe this is extractable from /cluster/replication
Regarding high IO delay I recommend to take a look at node_exporter. For node level metrics, this is usually the better option.

thanks @znerol

cluster/backup-info/not-backet-up lists all guests (qemu and lxc) which are not covered by any backup plan.

while i originally meant backup jobs who for some reason didn't execute, i also like the idea of alerting when a VM doesn't have a backup job at all.
for the rest i'll also have a look at the API to see which items would be useful to add.

Regarding high IO delay I recommend to take a look at node_exporter. For node level metrics, this is usually the better option.

indeed, thanks! i thought PVE was doing something special but according to the frontend code it evaluates the system's wait load, which can be gathered otherwise.

Hello everyone, is there any progress? I faced a similar problem. I need to know which machines were left without backup, or there was an error.

IO wait would be a very useful metric to have, IMO, if possible -- especially for those using ZFS for backing storage.

Please use node_exporter for the iowait metric. Take a look at this blog post for a start.

Thenks to @svengerber and @themoriarti, replication metrics are available as of release v3.3.0.


Brazilian Portuguese Localization update

Here is the JSON file with updated localization strings
pt-BR.zip

https://github.com/mclemente/healthEstimate/commit/09b9f8b4ac8949b8cacaec5bf11a9bb2914b2e27


NEXT-36108 NewsletterSubscribe add salesChannelId filter

[NEXT-0000] Update getNewsletterRecipient to search for specific recipient from salesChannelId

1. Why is this change necessary?
Once a newsletter recipient exists on one salesChannel it possible that the wrong recipient is selected, and dispatched along with NewsletterConfirmEvent and NewsletterRegisterEvent in NewsletterSubscribeRoute
2. What does this change do, exactly?
Add salesChannelId filter to select newsletter recipient for the correct salesChannel
3. Describe each step to reproduce the issue or behaviour.
Add event listender for NewsletterConfirmEvent (dd) or something else to show salesChannelId.
Sign up for newsletter on one salesChannel then on another.
4. Please link to the relevant issues (if any).
5. Checklist

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

Hey @wexoag, thanks for your contribution! We've just merged it 💙


Fix typo in run-number.md

Correct token is $(Build.DefinitionName).

@juliakm
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@ru-sh Thank you! This will be live today.
#sign-off


Add Object Pooling

Currently, the combat text is the only thing that is pooled.
This means all objects that are instantiated at run-time are not re-used.  They are created, and permanently destroyed.
This leads to a lot of garbage collection which causes spikes in CPU usage, and dropping frame rates or input and graphic lag.
An object pooling system should be used for instantiation of all objects in the engine.  This will involve a bit of work to ensure that all pooled objects can have their properties reset properly on re-use.
For example, a re-used arrow object should not begin immediately heading toward its last target etc.

This framework looks pretty comprehensive and provides interfaces, hooks for creation/destruction, and general configuration parameters.  In other words, it looks like they have thought out the problem.  MIT license.
https://github.com/GalvanicGames/unity-pooler
If you agree, a plan of attack might be to drop this in, and then change the combat message text implementation as a first step.  Regression test. Then, identify good candidates for pooling.  Then apply the interface to those candidates one at a time.

Nice find.  I was just going to use this code from Unity Learn, but the one you found looks like it has more configuration options.
https://learn.unity.com/tutorial/introduction-to-object-pooling
https://www.raywenderlich.com/847-object-pooling-in-unity

Yeah it would kinda suck to have to add that component to every prefab

I used a simpler one from  https://github.com/ertanturan/Unity-Object-Pooling
To integrate, one tags and adds their prefab to an enum  :/   and then adds a game object to the root specifying that tag.
Here's a diff to see a basic implementation for CombatText pooling.   I took out his dependency injection drek:
https://github.com/michaelday008/AnyRPGCore/compare/master...grannypron:18-objectpooling
If you like it, lmk and I can polish it up.

Simple setup of the pooler

Simple setup of the pooler

Thanks for looking into this.  After further review, the two poolers I linked were far too basic for what I need.
That one you found has some good features, but in some respects I think it's over-engineered, and in some, missing the flexibility I'm looking for in this update. I may use some of the code, but decided to just write a custom object pooler.  You can see the types of features that are needed for it to just work out of the box for everyone without adding enums or tags.

Released with 0.11a


[easy] Hypen as a valid part of model names

Detectron model names contains-. Tutorial on https://github.com/caffe2/models/tree/master/detectron/e2e_faster_rcnn_R-50-C4_1x won't work if - is not recognized as a valid character.

@onnxbot retest this please


SOLR-16707: Avoid "Recursive update" ISE in non-async cache computeIfAbsent()

an alternative to #1480
See: SOLR-16707

I'm thinking this warrants a "bugfix" CHANGES.txt entry?

This fell through the cracks; circling back now, I plan to merge this within the next couple of days, pending any objections/feedback. cc @dsmiley , @mkhludnev.

Looking back at this, the problem is that the cache implementation can't recursively compute new cache entries.  Given this situation, couldn't we use a ThreadLocal boolean to indicate if we're recursively being invoked and make different decisions based on this?  If recursive invocation, need to compute the query prior to the computeIfAbsent call.  The vast majority of invocations will not be recursive though.

You could even modify the logic so we optimistically assume non-recursion (the fast path).  if the lambda in compute-if-absent sees we aren't so lucky, it could throw an exception to bail out of the computeIfAbsent call.  Catch it outside, and do the fallback logic.

This sounds good; I had been thinking to not optimize the async=false case, and to instead move toward deprecating it. But I like this; it's straightforward, and will also provide a template for a simple way for plugin SolrCache impl's to handle this situation without requiring them to implement full-blown async support.

@dsmiley thanks again for your suggestion; it's implemented in 3fb684f0291b508e7cbca3ad964dbe779211ff8d if you care to take a look!

@magibney you seemed so close to this nice change being merged

Ah, thanks for not letting this slip through the cracks; I'll follow up on this shortly


Make an autocomplete library for the terminal

To help autocomplete commands. Not sure if this can be done in a generic way or has to be done for bash and for zsh separately.

This would be handled more by inquirer actually. Closing.


Bump k8s v1.8.0

I'll wait on bumping vendor libs to v1.8 until client-go has a more unified v1.8 targeted release.
cc @rphillips @dghubble

Also, running conformance tests separately - will hold off on merging until those pass too

lgtm

Tested PXE booted bare-metal setups with both flannel and with calico. Bootstrapping succeeds and control plane seems ok (nothing too atypical in logs). This didn't cover controller reboot survival (i.e. checkpointing).

Conformance has 2 failures need to check out:
[1061461.011458] golang[5]: [14168.336421] golang[5]: Summarizing 2 Failures:
[1061461.011722] golang[5]: [14168.336603] golang[5]: [Fail] [k8s.io] Pods [It] should be submitted and removed [Conformance]
[1061461.012043] golang[5]: [14168.336787] golang[5]: /go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/common/pods.go:252
[1061461.012319] golang[5]: [14168.336972] golang[5]: [Fail] [k8s.io] Pods Extended [k8s.io] Delete Grace Period [It] should be submitted and removed [Conformance] [Flaky]

@dghubble I think we might have to bump the vendoring after all (or update the tests). Not super clear about the interaction of using "extensions/v1beta1" in the tests, vs creating the objects with v1.8 "apps/v1beta2"

Any idea if my suggestion will unblock the e2e tests, might be worth a shot. I hadn't looked at conformance tests yet.

I believe the intention there is to remove the nodeSelector altogether (so the daemonset ends up on all nodes) - we're not using node affinity in this case. I have a feeling the actual failure is due to some versioning interplay (e.g. using ExtensionsV1beta1() when it's been switched to apps/v1beta2.

coreosbot run e2e

@dghubble do you know how to re-trigger the e2e-calico test?

coreosbot run e2e calico

Happy to change it, its just the first phrase I defined.

@dghubble that's fine. Mind adding it to https://github.com/kubernetes-incubator/bootkube/blob/master/Documentation/development.md#running-pr-tests

coreosbot run e2e calico

e2e-calico failed bc Terraform is waiting for an EC2 instance to create, retry.

Both failures are related to the checkpointer. Any relation to the (not-yet-included) improvements made in #733 @thorfour?

@aaronlevy I see e2e and self-hosted etcd e2e are using "coreosbot run e2e", so I've changed calico-e2e to use the same. Docs are already correct.

My changes wouldn't be a fix for those failures. I believe I've seen those failures before, seems like a timing failure

I don't think it's related to checkpointer itself, but rather behavior that touches the checkpointer tests. It seems like there's something related to removing pods that has changed (similarly got same conformance test failures twice now - so not outright flakes).

Looking at the tests, we're rebooting masters, starting workers, verifying "pod-checkpointer" is present on a worker (verifyPod with docker ps), and starting masters, and then verifying "pod-checkpointer" is NOT present on a worker (step that fails).
https://github.com/kubernetes-incubator/bootkube/blame/master/e2e/checkpointer_test.go#L277
https://github.com/kubernetes-incubator/bootkube/blame/master/e2e/checkpointer_test.go#L89
I'm guessing this is done to test the idea that once an apiserver can be contacted, the checkpointer doesn't need to be running on that worker per doc, but I'm not 100%. cc @yifan-gu

Added a sleep and the tests pass. I have a feeling removing a pod might have got slower? One option might just be to increase the retry window on verifyPod

Increasing the retries allowed does seem nicer than a fixed sleep.

Looks like that cluster apiserver failed to come back and subsequent tests failed. Hm, known or new?

The self-hosted etcd is actually still occasionally flaky - and not really maintained. I'll re-run for now (last test with the sleep passed, and this is functionally the same change).

coreosbot run e2e

I'm going to try and see if I can reproduce locally. Even if this does pass - having to run e2e test 3 times is too flaky

Same flake waiting for checkpointer to restore apiserver in the calico variant, so it appears independent of just self-hosted etcd.

I feel like something about deleting pods has slowed way down

I recall a discussion about pod deletion slowdowns. cc @ericchiang similar or something else? Perhaps initial test assumptions for delete and wait times no longer hold true.

There is an issue fixed in 1.8.1 (not released yet) that was specifically for deleting pods #51899

Hm, the description of large clusters doesn't seem to match our much smaller test clusters.

True... The fix states the periodic garbage collector would need to run and instead they have changed the code to actively remove the pods.

But waiting up to 30 seconds to delete a pod might add to this flakiness...
We could add longer retry timeouts until v1.8.1 then back them out again.

@dghubble @rphillips - passing at this point. Seem reasonable to merge?
I have a strong suspicion that the two conformance tests failures are also timing related. I manually tested deleting pods (those tests are essentially checking the grace period) and didn't see any problems. We should still did into those errors and get them resolved, but I feel like it's relatively low risk here.

lgtm, 1.8.1 released today fwiw

I think https://github.com/kubernetes/kubernetes/issues/53396 (hyperkube v1.8.0 breaks pods talking to services on the same node) still impacts us.

@aaronlevy I haven't reproduced bootstrapping flakes testing this manually. Can we aim to bump to 1.8.1 and patch the hyperkube before a bootkube release? I'm ok with merging or if you want to wait for that followup.

Hmm https://github.com/kubernetes/kubernetes/issues/53396 is bad enough that we should just bump the image.
@dghubble is anyone working on bumping the hyperkube?

@aaronlevy the patch for #53396 hasn't been merged yet, but it should be shortly (probably today)

The fix for that issue was submitted too late to get into 1.8.1
https://github.com/kubernetes/kubernetes/pull/53642
@rphillips opened a cherry pick which can be used to track the fix for the
branch
https://github.com/kubernetes/kubernetes/pull/53744
If we're going to release another hyperkube, we'll probably want to cherry
pick those changes once the original fix is merged into master.
On Thu, Oct 12, 2017 at 11:54 AM Aaron Levy<EMAIL_ADDRESS>wrote:

Hmm kubernetes/kubernetes#53396
https://github.com/kubernetes/kubernetes/issues/53396 is bad enough
that we should just bump the image.
@dghubble https://github.com/dghubble is anyone working on bumping the
hyperkube?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/bootkube/pull/729#issuecomment-336232388,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACO_XTYWxKFMX7iHSmt8Q6m-Cw_IAR0Pks5srmBggaJpZM4Pt9Fv
.

Ok if we want to wait until all the pieces are ready to go at once.

@aaronlevy I started building v1.8.1 this morning, tag is cut. Waiting for build to finish and image push to finish.

Heh, whoops. I'll revert the v1.8.1 bump then

Per some tests by @rphillips - the networking issue has to do with kubenet - so I think we can move forward with merging this now. hyperkube v1.8.1 is also available, so I bumped that. If someone gets a chance please do another review and I'll merge on green tests

coreosbot run e2e

@dghubble any chance you could do a quick manual sanity check of calico + the reboot test that it says failed?

Yeah, I'm working on testing this on some clusters.

On bare-metal with bootkube render at this commit and --network-provider=experimental-calico, controller and full cluster reboots were tolerated as usual.
NAMESPACE     NAME                                       READY     STATUS    RESTARTS   AGE
kube-system   calico-node-c6596                          2/2       Running   0          8m
kube-system   calico-node-j2kdj                          2/2       Running   2          8m
kube-system   calico-node-w65hg                          2/2       Running   0          8m
kube-system   kube-apiserver-55ctg                       1/1       Running   1          8m
kube-system   kube-controller-manager-5dbc5d8c6b-bd2v5   1/1       Running   1          8m
kube-system   kube-controller-manager-5dbc5d8c6b-cmbh9   1/1       Running   1          8m
kube-system   kube-dns-598c789574-9vgnd                  3/3       Running   3          7m
kube-system   kube-proxy-8nwbt                           1/1       Running   1          7m
kube-system   kube-proxy-c8x54                           1/1       Running   0          7m
kube-system   kube-proxy-jgfg8                           1/1       Running   0          7m
kube-system   kube-scheduler-bdb68cdc-4tqzp              1/1       Running   1          7m
kube-system   kube-scheduler-bdb68cdc-5qhp5              1/1       Running   1          7m
kube-system   pod-checkpointer-85p29                     1/1       Running   1          7m
kube-system   pod-checkpointer-85p29-node1.example.com   1/1       Running   1          7m

rel: https://github.com/coreos/matchbox/pull/657

On CI, TestReboot failed once and TestCheckpointerUnscheduleCheckpointer failed once on separate runs. So its a flaking issue rather than being broken outright.
I'll point out, the reboot seems to fail sometimes at the testing code's call to node.Reboot, not from a cluster behavior itself. reboot_test.go:30: failed to reboot node: Process exited with status 1

Tested on a cloud provider as well

coreosbot run e2e

e2e-selfetcd failed on Terraform creation of AWS resources. aws_instance.master_node.0: Error waiting for instance (i-0c6b293b70086d5fa) to become ready: Failed to reach target state. Reason: Server.InternalError: Internal error on launch

coreosbot run e2e

Any thoughts on how we might make this less flaky?

TestReboot failures sometimes occur simply because the reboot logic is literally try to ssh once and run "reboot". No retries.
Most recent nginx workload failure comes from https://github.com/coreos/ktestutil. Hasn't been touched in a while, old client-go? It hardcodes its own retry intervals and counts, so they're unaffected by your bumps. https://github.com/coreos/ktestutil/tree/master/testworkload

At a higher level and longer term level, I'd like to strip out functionality we don't intend to go forward with such as self-hosted kubelet (#735, but not an issue here) and self-hosted etcd. Most of these issues boil down to crash loops being a normal part of self-hosted control planes, our control plane growing more complex, and there being no precise definition of when setup is complete and conformance testing should begin. It'd also be valuable if we had some better way to show how long a step normally takes, we kinda go by instinct and maybe these values need re-tuning.

coreosbot run e2e

I'm really hesitant to merge this even if tests finally pass (without addressing some of the underlying issues). Otherwise every subsequent PR will have to run tests 5 times to pass (which isn't the case prior to this PR). So that might mean that we need to increase timeouts.

Agreed. At this point its mainly useful to see where we're hitting failures. It'd be different if it were the same error every time.

I'd like to strip out functionality we don't intend to go forward with such as self-hosted kubelet (#735, but not an issue here) and self-hosted etcd

Sorry for hijacking this issue, but why do you want to drop self-hosted etcd? Isn't it working? Too unstable? I can see it was just removed from the tectonic UI.

This isn't the place for that discussion, it would hijack this. I'll open an issue later to communicate the plan more broadly.

Summarizing here, in the 5 builds on v1.8.1 (rather than v1.8.0)

e2e - 5/5 passes
e2e-calico - 4/5 passes

One failure on TestReboot due to ssh'ing once and not retrying (known test issue)

e2e-selfetcd - 2/5 passes

One failure due to Terraform AWS failing to create instance (known flaky)
One failure on TestSmoke waiting for nginx creation (unknown)
One failure on TestDeleteAPI and subsequent tests "non-checkpoint apiserver did not come back". (unknown)

All conformance tests passed once bumped to v1.8.1

Added some fixes which should address the TestReboot and TestSmoke flakes. I don't have anything for the Terraform or occassional self-hosted etcd TestDeleteAPI failures. I haven't been able to reproduce them on my clusters running v1.8.1 with self-hosted etcd.

Ok, so we've seen flaky failures in TestDeleteAPI "non-checkpoint apiserver did not come back" on both e2e-calico and e2e-selfetcd

Looks like all passed. Good to merge @dghubble ?

I'll keep trying to repro the flakes in experimental features.
Yes, good to merge.


DOS closing message

Message on homepage to let suppliers know they can no longer apply for Digital Outcomes and Services.

:+1:


Modules with duplicate imports cannot be componentized

This is only known to be a problem for Grain where a Hello World wasi preview1 module produces duplicate fd_write imports.
Duplicate imports are permitted in modules by the Wasm core spec but forbidden by the component model, which prevents these modules from being componentized.
Two plausible paths to fix this:

Get Grain to deduplicate imports in the compiler: https://github.com/grain-lang/grain/issues/2152
Build tooling to deduplicate imports

While fixing Grain is probably independently a good idea, we don't necessarily control that timing and it wouldn't help for existing modules. A discussion of how to build dedupe tooling can be found in BA Zulip.

It turns out this is only an issue for debug builds. Compiling with --release solves the problem.

@lann now that the grain template and language page have been updated to use --release, do we still want to keep this open?  Untether from Spin 3.0 if so?

No my understanding is that this is working as intended on the wasmtime side.


SendBTC

-On clicking SendBTC, it should not land on the first screen of Send as we already know the recipient. -It should go to the second screen with the recipient filled in.

Remaining default account selection and balance of that account from contact details page


Items at store gives walkie-talkie

i dont know why but, in game scraps work fine but when you buy new item from store it gives walkie-talkies.

@MuratMG If you have Terminalformatter mod that might be the cause. Disable the mod then try again.


Enhance subprocess error handling and path redirection in Blender add-on execution

Background

When terminating execution in PyCharm, a KeyboardInterrupt exception may occur, leaving the subprocess running. This requires an additional termination to fully exit the process.

Error messages containing file paths may point to non-project directories, which can cause confusion during debugging.

Solution Implemented
This pull request addresses these issues by:

Using subprocess.Popen to launch the subprocess, with an added listener for KeyboardInterrupt to ensure graceful termination of the subprocess when an interrupt is detected.
Redirecting error messages containing file paths to point to the project root directory, enhancing clarity and relevance for users navigating error logs.

Testing
This solution has been tested locally, and the results are as expected: the subprocess now terminates cleanly upon interruption, and error messages display project-relative paths.

Please let me know if there are any further improvements or modifications required!

I have merged this pull request and added path normalization to the main branch.