ClaimIdentity cannot be mapped to legacy format

Currently, when Authenticator establishes ClaimsIdentity, it does so in the format of "user@REALM". For dealing with legacy scenarios, it would be useful to have access to principal in "DOMAIN\user" format. I propose either: a) an option for authenticator on how to establish the primary Name claim. b) adding additional claim into ClaimIdentity in the legacy format. c) a+b

The intent was to try and align it with what .NET does natively, which I don't think has this behavior. Domain\user is not really a correct format for Kerberos either, so I'm wondering how this could be exposed correctly. I do see the issue you have though.
One thing you can do in the meantime is override the method AddUser on the KerberosAuthenticator class to change how the claim is generated.

From: Andrew Stakhov<EMAIL_ADDRESS>Sent: Tuesday, May 7, 2019 1:23:13 PM
To: SteveSyfuhs/Kerberos.NET
Cc: Subscribed
Subject: [SteveSyfuhs/Kerberos.NET] Identity format (#36)
Currently, when Authenticator establishes ClaimsIdentity, it does so in the format of "user@REALM". For dealing with legacy scenarios, it would be useful to have access to principal in "DOMAIN\user" format. I propose either: a) an option for authenticator on how to establish the primary Name claim. b) adding additional claim into ClaimIdentity in the legacy format. c) a+b
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/SteveSyfuhs/Kerberos.NET/issues/36, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJHTYP7PTMGIDCBBLRHFO3PUHQLDANCNFSM4HLMGEZA.

Actually, the default behavior for WindowsIdentity.Name property is the
DOMAIN\user format.
https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.name?view=netframework-4.8
I'm specifically dealing with this compatibility issue when using your
library right now as the existing legacy code we're putting on the platform
expects it in the old school format when using IWA.
On Tue, May 7, 2019 at 7:20 PM Steve Syfuhs<EMAIL_ADDRESS>wrote:

The intent was to try and align it with what .NET does natively, which I
don't think has this behavior. Domain\user is not really a correct format
for Kerberos either, so I'm wondering how this could be exposed correctly.
I do see the issue you have though.
One thing you can do in the meantime is override the method AddUser on
the KerberosAuthenticator class to change how the claim is generated.

From: Andrew Stakhov<EMAIL_ADDRESS>Sent: Tuesday, May 7, 2019 1:23:13 PM
To: SteveSyfuhs/Kerberos.NET
Cc: Subscribed
Subject: [SteveSyfuhs/Kerberos.NET] Identity format (#36)
Currently, when Authenticator establishes ClaimsIdentity, it does so in
the format of "user@REALM". For dealing with legacy scenarios, it would
be useful to have access to principal in "DOMAIN\user" format. I propose
either: a) an option for authenticator on how to establish the primary Name
claim. b) adding additional claim into ClaimIdentity in the legacy format.
c) a+b
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://github.com/SteveSyfuhs/Kerberos.NET/issues/36>, or mute the
thread<
https://github.com/notifications/unsubscribe-auth/AAJHTYP7PTMGIDCBBLRHFO3PUHQLDANCNFSM4HLMGEZA

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/SteveSyfuhs/Kerberos.NET/issues/36#issuecomment-490289165,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAINFWFXHKJ4HC3AYJMLU2TPUIFFFANCNFSM4HLMGEZA
.

Gotcha. The old NetBIOS components should be available in the PAC so it should be easy enough to build up that value. Will need to work through how to handle this so it's compatible both ways, but I have some ideas.

From: Andrew Stakhov<EMAIL_ADDRESS>Sent: Tuesday, May 7, 2019 7:13:36 PM
To: SteveSyfuhs/Kerberos.NET
Cc: Steve Syfuhs; Comment
Subject: Re: [SteveSyfuhs/Kerberos.NET] ClaimIdentity cannot be mapped to legacy format (#36)
Actually, the default behavior for WindowsIdentity.Name property is the
DOMAIN\user format.
https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.name?view=netframework-4.8
I'm specifically dealing with this compatibility issue when using your
library right now as the existing legacy code we're putting on the platform
expects it in the old school format when using IWA.
On Tue, May 7, 2019 at 7:20 PM Steve Syfuhs<EMAIL_ADDRESS>wrote:

The intent was to try and align it with what .NET does natively, which I
don't think has this behavior. Domain\user is not really a correct format
for Kerberos either, so I'm wondering how this could be exposed correctly.
I do see the issue you have though.
One thing you can do in the meantime is override the method AddUser on
the KerberosAuthenticator class to change how the claim is generated.

From: Andrew Stakhov<EMAIL_ADDRESS>Sent: Tuesday, May 7, 2019 1:23:13 PM
To: SteveSyfuhs/Kerberos.NET
Cc: Subscribed
Subject: [SteveSyfuhs/Kerberos.NET] Identity format (#36)
Currently, when Authenticator establishes ClaimsIdentity, it does so in
the format of "user@REALM". For dealing with legacy scenarios, it would
be useful to have access to principal in "DOMAIN\user" format. I propose
either: a) an option for authenticator on how to establish the primary Name
claim. b) adding additional claim into ClaimIdentity in the legacy format.
c) a+b
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://github.com/SteveSyfuhs/Kerberos.NET/issues/36>, or mute the
thread<
https://github.com/notifications/unsubscribe-auth/AAJHTYP7PTMGIDCBBLRHFO3PUHQLDANCNFSM4HLMGEZA

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/SteveSyfuhs/Kerberos.NET/issues/36#issuecomment-490289165,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAINFWFXHKJ4HC3AYJMLU2TPUIFFFANCNFSM4HLMGEZA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/SteveSyfuhs/Kerberos.NET/issues/36#issuecomment-490320384, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJHTYOPHA36Q6O5OSKEE3TPUIZNBANCNFSM4HLMGEZA.

Thanks for providing the change. You rock! I've approved, merged, built, and it's in the process of uploading to nuget as we speak. Expect a nuget version of v2.7.0508.1.
https://github.com/SteveSyfuhs/Kerberos.NET/pull/37


Fix path ordering

Fixes #71
The implementations of summarise() and the Skeleton class have diverged significantly. The way that paths are traversed are totally different. Rather than reconciling, I decided to move towards "soft" deprecation of summarise and preferring the Skeleton class as an API for the future.
As a result of #71, I've implemented csr.Skeleton.summarize as a method, which replicates (and improves upon) the functionality fo summarise.
This PR also fixes a number of deprecations in dependencies like NumPy, SciPy, and Matplotlib.

Coverage increased (+0.02%) to 99.415% when pulling 9dc4b01a51fde226b34fbaeb4afb65ae799bb2c1 on fix-path-ordering into 5c0d23e5b1eab2fb06b25ff599e98eaa11d621e6 on master.


Implement the 'prefix' as a passable argument when during conversion.

A code below
 var f = "Field1".AsParameter("@");

Would return "@Field1"

Will be a part of build > v1.9.0-beta1


PDF build says failed when it has actually succeeded

For example, for the Astropy PDF build:
https://readthedocs.org/builds/astropy/2483122/
the final lines of output are:
Output written on Astropy.pdf (1407 pages, 7211162 bytes).
Transcript written on Astropy.log.

and the PDF file works, so not sure why it is being marked as failed.

Ah but somehow the PDF for that version doesn't exist:
https://media.readthedocs.org/pdf/astropy/v1.0.1/astropy.pdf
so there must be some error I am missing. @ericholscher - any ideas?

It seems that PDF build for your latest version (1.0.3) was reported as success and the PDF is available. @astrofrog is this still an issue for you?

This is fixed in #1524


Issues with fixed angles for calculating Fajr & Isha in places at high latitudes

What do you think of this article that says fixed degree around the year is not correct in places with high latitudes and low latitudes.
see the link below:
https://www.moonsighting.com/how-we.html

This is why we offer the "moonsighting committee" calculation method. It is up to the developer to use this method for the appropriate location.

Thanks for the clarification. but I have two question please:

Does this code adjust the degree of Fajr and Isha when the high latitude is use? if not, then how can it be done ?
Also Can you add recommend high latitude rule function?

@moosalim the high latitude rule puts in a limiting factor so that during the extremes of summer there is a max time for isha and minimum time for fajr. This is to provide reasonable prayer times that are not a burden. For adjusting the degrees specifically thats not something that is done, however the "moonsighting committee" method has seasonal adjustment values that effectively change how fajr and isha are calculated in summer vs winter.
For your second point, yes we can. We added one to the swift library so we should add one here too.

@z3bi Thanks for the clarifications.
That means, if I wanted to follow moonsighting committee, i need to do seasonal adjustments progromaticaly by my self. Do you have these values of seasonal adjustments? do you know where form I get them?

@moosalim you do not need to provide them yourself, that method automatically makes adjustments based on the season. All you need to do is calculate times using that method.

@z3bi , my app is live which has been using your Java library for 7 months. Recently, at my place (latitude 51.0 degrees), I am facing a couple of issues with the setup below

Salat calculation method selected : - anyone supported, except for Moon Sighting Committee
High Latitude methods selected : None, and Middle of the night

Issues:

I find fajr of next day starts one minute earlier than start of Isha time tonight. So, e.g. today, Isha started at 12:59am, and Fajr tomorrow is at 12:58am, which is a minute earlier than Isha started.
This is slightly unrelated; but it appears to me that Qiyaam method with 'Middle of the night' is actually taking a mid point between sunset and start of next Fajr, however, while calculating the Isha & fajr using High Latitude Middle of the night method, library is picking up mid point between sunset and next sunrise. Is this correct?
Last is just a query; if I have to enable 'High Latitude' at app first launch by default, could you please suggest which latitude shall I start doing it at - some sites have said anything above 46 but less than 66 degrees. Could you advise also if that must be done for southern hemisphere too - i.e. negative latitudes?

Thanks in advance , and sorry if questions above are too lengthy.
2)


org rename in 2.4 branch

The related issue: https://github.com/stolostron/backlog/issues/18746
Signed-off-by: Yang Le<EMAIL_ADDRESS>

/approve

/lgtm


Changes to TestPackage Constructor

TestPackage has two constructors, TestPackage(string) and TestPackage(IList<string>), with entirely different semantics. The string constructor is intended for use with subpackages only but nothing prevents the caller for using it for the top-level constructor. This is confusing for the caller and requires our code to make provision for either constructor being used. It also doubles the effort of maintaining tests that make use of TestPackage. The string constructor will be removed and a method added to create subpackages under the top-level package.
This duplicates a change I made to the NUnit V4 Api.

:tada: This issue has been resolved in version 2.0.0-beta4 :tada:
The release is available on:

GitHub Release
NuGet Package


CoreOs cluster restarted all containers due to etcd errors

Hello
We just saw a pretty server issue on our production CoreOs setup. Details are:

3 CoreOs nodes running in AWS EC2 Us East1
m3.2xlarge instance types
CoreOS nodes - 2 are DISTRIB_RELEASE=1068.2.0 and 1 is at DISTRIB_RELEASE=1081.5.0
etcd version 0.4.9
we have auto update disabled on CoreOs
Around 21:56 UTC on Jan 17 we saw all our containers go down and the logs seemed to suggest an issue with etcd

Jan 17 21:56:22 ip-10-26-31-100.ec2.internal fleetd[999]: ERROR server.go:189: Server monitor triggered: Monitor timed out before successful heartbeat
Jan 17 21:56:22 ip-10-26-31-100.ec2.internal fleetd[999]: INFO server.go:157: Establishing etcd connectivity
Jan 17 21:56:22 ip-10-26-31-100.ec2.internal fleetd[999]: ERROR engine.go:179: Engine leadership acquisition failed: context deadline exceeded
Jan 17 21:59:41 ip-10-26-31-100.ec2.internal fleetd[999]: INFO server.go:168: Starting server components
Jan 17 21:59:42 ip-10-26-31-100.ec2.internal fleetd[999]: INFO engine.go:185: Engine leadership acquired
Jan 17 21:59:43 ip-10-26-31-100.ec2.internal fleetd[999]: ERROR engine.go:254: Failed unscheduling Unit(kafka-broker-1.service) from Machine(6ca65ead2f164b2682c0d941c8a75d9b): context deadline exceeded
Jan 17 21:59:43 ip-10-26-31-100.ec2.internal fleetd[999]: ERROR reconciler.go:62: Failed resolving task: task={Type: UnscheduleUnit, JobName: kafka-broker-1.service, MachineID: 6ca65ead2f164b2682c0d941c
Jan 17 21:59:44 ip-10-26-31-100.ec2.internal fleetd[999]: ERROR engine.go:254: Failed unscheduling Unit(newNewApps.service) from Machine(6ca65ead2f164b2682c0d941c8a75d9b): context deadline exceeded

We checked the CPU and disk IO for all 3 instances, there is NO indication of any CPU spike per AWS Cloudwatch
ETCD config is as below
core@ip-10-26-33-251 ~ $ sudo systemctl cat etcd

/usr/lib64/systemd/system/etcd.service
[Unit]
Description=etcd
Conflicts=etcd2.service
[Service]
User=etcd
PermissionsStartOnly=true
Environment=ETCD_DATA_DIR=/var/lib/etcd
Environment=ETCD_NAME=%m
ExecStart=/usr/bin/etcd
Restart=always
RestartSec=10s
LimitNOFILE=40000
/run/systemd/system/etcd.service.d/10-oem.conf
[Service]
Environment=ETCD_PEER_ELECTION_TIMEOUT=1200
/run/systemd/system/etcd.service.d/20-cloudinit.conf
[Service]
Environment="ETCD_ADDR=<IP_ADDRESS>:4001"
Environment="ETCD_CERT_FILE=/home/etcd/certs/cert.crt"
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/"
Environment="ETCD_KEY_FILE=/home/etcd/certs/key.pem"
Environment="ETCD_PEER_ADDR=<IP_ADDRESS>:7001"

Attached the fleet & etcd logs from all nodes

etcd-10-26-31-100.txt
etcd-10-26-32-94.txt
etcd-10-26-33-251.txt
fleet-10-26-31-100.txt
fleet-10-26-32-94.txt
fleet-10-26-33-251.txt

AWS status dashboard does not show any errors or issues on their end

Appreciate if someone can take a look at the above and give us any pointers on what to look at and what we can do to mitigate this.
Thx
Maulik

A few things:

Some clients are trying to access etcd either through an http endpoint or with the wrong certs:

http: TLS handshake error from <IP_ADDRESS>:19866: EOF
...
http: TLS handshake error from <IP_ADDRESS>:59032: tls: first record does not look like a TLS handshake

The etcd cluster is still accepting writes; it appears healthy:

etcd] Jan 17 19:50:59.580 INFO      | 561f7d156ce24a5196696cc1c466fcea: snapshot of 10003 events at index 493628340 completed

fleet appears to be spinning on very out-of-date revisions:

Jan 17 20:14:52 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282006 != 377975623]) [377975623]
Jan 17 20:14:56 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282050 != 377975657]) [377975657]
Jan 17 20:15:00 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282083 != 377975695]) [377975712]
Jan 17 20:15:04 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282137 != 377975733]) [377975753]
Jan 17 20:15:08 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282177 != 377975778]) [377975778]
Jan 17 20:15:12 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282201 != 377975812]) [377975812]
Jan 17 20:15:16 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282234 != 377975867]) [377975867]
Jan 17 20:15:20 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282288 != 377975926]) [377975931]

0.4.9 is ancient and is officially slated to be EOL'd: https://coreos.com/blog/toward-etcd-v3-in-container-linux.html

Is there any evidence the etcd cluster is broken? Looks like a fleet bug.

@heyitsanthony thanks for the quick response:

Some clients are trying to access etcd either through an http endpoint

That is an AWS ELB we have and is mostly just healthchecks from the ELB

When you say fleet is spinning on old revisions - can you provide some more insight here? Would we need to restart fleet daemon to recover? Sorry if these are dumb questions

Point take on etcd update - will schedule that on our end (am guessing its a CoreOS upgrade in general)

there is no evidence that etcd is broken other than the errors we see in fleet pointing to a leadership failure which I thought (perhaps incorrectly) was with etcd

Also should or can I move this issue to Fleet from etcd?

@mshahpalerra yes, probably file under http://github.com/coreos/fleet/issues
fleet is using a compare and swap on based on key revision to safely renew leadership:
Jan 17 20:14:52 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282006 != 377975623]) [377975623]
Jan 17 20:14:56 ip-10-26-32-94.ec2.internal fleetd[985]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378282050 != 377975657]) [377975657]

Here, it's using a key that's behind by about 300k revisions. It's unclear to me why it's drifted by that much and why it's staying so far behind. It's possible etcd is returning bad indexes. @xiang90 might know whether something like that has ever been observed in the past.
From the logs, it looks like the etcd cluster is ingesting about 600--1000 writes per minute:
etcd-10-26-32-94.txt:Jan 17 18:56:29 ip-10-26-32-94.ec2.internal etcd[976]: [etcd] Jan 17 18:56:29.773 INFO      | 6ca65ead2f164b2682c0d941c8a75d9b: snapshot of 10046 events at index 493587348 completed
etcd-10-26-32-94.txt:Jan 17 19:09:50 ip-10-26-32-94.ec2.internal etcd[976]: [etcd] Jan 17 19:09:50.996 INFO      | 6ca65ead2f164b2682c0d941c8a75d9b: snapshot of 10005 events at index 493597353 completed

So the fleet member is behind by about five hours somehow.
I'm not a fleet expert so I don't know what the correct course of action would be. Resetting the fleet the daemon probably can't make things any worse, at least.

@heyitsanthony  thanks - we did restart fleet - however we are still seeing:
Jan 18 00:50:34 ip-10-26-31-100.ec2.internal fleetd[20619]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378128986 != 378128996]) [378129072]
Jan 18 00:50:37 ip-10-26-31-100.ec2.internal fleetd[20619]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378128996 != 378129075]) [378129075]
Jan 18 00:50:39 ip-10-26-31-100.ec2.internal fleetd[20619]: INFO engine.go:79: Engine leader is<PHONE_NUMBER>914769b7f29e3bc5ea3c1b
Jan 18 00:55:21 ip-10-26-31-100.ec2.internal fleetd[20619]: ERROR server.go:189: Server monitor triggered: Monitor timed out before successful heartbeat
Jan 18 00:55:21 ip-10-26-31-100.ec2.internal fleetd[20619]: INFO server.go:157: Establishing etcd connectivity
Jan 18 00:55:24 ip-10-26-31-100.ec2.internal fleetd[20619]: INFO server.go:168: Starting server components
Jan 18 00:55:24 ip-10-26-31-100.ec2.internal fleetd[20619]: INFO engine.go:185: Engine leadership acquired
Jan 18 00:55:24 ip-10-26-31-100.ec2.internal fleetd[20619]: INFO engine.go:81: Engine leadership changed from<PHONE_NUMBER>914769b7f29e3bc5ea3c1b to 561f7
where fleet leadership continues to move around. We can restart etcd if that helps (am not sure if the keys are ephemeral) - any comments?
Is there a way to move this issue in Github to fleet or I have to a file a new one with all the details?

@mshahpalerra just file a new one. This can stay open in case it's an etcd bug.
The fleet keys for leader election have a ttl, which is effectively ephemeral.

@heyitsanthony  thanks - opened another issue - however we are seeing the below errors:
<IP_ADDRESS> shows
ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378459038 != 378157064]) [378157073]
<IP_ADDRESS> shows
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO reconcile.go:330: AgentReconciler completed task: type=ReloadUnitFiles job=N/A reason="always reload unit files"
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO manager.go:246: Writing systemd unit apprity-home-data-3-unit-1.service (1924b)
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO manager.go:182: Instructing systemd to reload units
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO manager.go:127: Triggered systemd unit apprity-home-data-3-unit-1.service start: job=3981
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO reconcile.go:330: AgentReconciler completed task: type=LoadUnit job=apprity-home-data-3-unit-1.service reason="unit scheduled here but not loaded"
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO reconcile.go:330: AgentReconciler completed task: type=ReloadUnitFiles job=N/A reason="always reload unit files"
Jan 18 02:10:53 ip-10-26-33-251.ec2.internal fleetd[924]: INFO reconcile.go:330: AgentReconciler completed task: type=StartUnit job=apprity-home-data-3-unit-1.service reason="unit currently loaded but desired state is launched"
Jan 18 02:10:54 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166410 != 378166604]) [378166604]
Jan 18 02:10:58 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166417 != 378166610]) [378166610]
Jan 18 02:11:02 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166422 != 378166612]) [378166612]
Jan 18 02:11:06 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166423 != 378166752]) [378166752]
Jan 18 02:11:10 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166562 != 378166754]) [378166754]
Jan 18 02:11:14 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166563 != 378166756]) [378166756]
Jan 18 02:11:17 ip-10-26-33-251.ec2.internal fleetd[924]: WARN job.go:268: No Unit found in Registry for Job(feed_syslog.service)
Jan 18 02:11:17 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR job.go:108: Failed to parse Unit from etcd: unable to parse Unit in Registry at key /_coreos.com/fleet/job/feed_syslog.service/object
Jan 18 02:11:17 ip-10-26-33-251.ec2.internal fleetd[924]: WARN job.go:268: No Unit found in Registry for Job(feed_syslog.service)
Jan 18 02:11:17 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR job.go:108: Failed to parse Unit from etcd: unable to parse Unit in Registry at key /_coreos.com/fleet/job/feed_syslog.service/object
Jan 18 02:11:18 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166564 != 378166758]) [378166804]
Jan 18 02:11:22 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166611 != 378166898]) [378166898]
Jan 18 02:11:26 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166704 != 378166900]) [378166900]
Jan 18 02:11:31 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:149: Unable to determine cluster engine version
Jan 18 02:11:31 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR state.go:71: Failed fetching page of UnitStates: context deadline exceeded
Jan 18 02:11:32 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:217: Engine leadership lost, renewal failed: 101: Compare failed ([378166705 != 378166903]) [378166903]
Jan 18 02:11:35 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:149: Unable to determine cluster engine version
Jan 18 02:11:36 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR state.go:71: Failed fetching page of UnitStates: context deadline exceeded
Jan 18 02:11:37 ip-10-26-33-251.ec2.internal fleetd[924]: ERROR engine.go:149: Unable to determine cluster engine version
We are not seeing anything wrong on the nodes - rebooted <IP_ADDRESS> for kicks but no luck

This is probably a fleet issue, not an etcd one. As an issue already created in fleet repo, I am closing the one here. Thanks for reporting.


[HDInsight]Remove NetworkSettings property

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

As identified in the automated checks there are breaking changes, Please follow Azure Breaking changes approval request form as defined @ Breaking Change Process

@changlong-liu pls help check python SDK breaking changes.

@changlong-liu pls help check python SDK breaking changes.

@changlong-liu I think that the next version of python SDK should be breaking change version, but please don't release python sdk immediately. We still need to continue to update swagger after this PR.

Hi, @leni-msft  , yes, this PR bring breaking change in SDK, I'm OK for this if @aim-for-better think it's necessary for service side.
Hi @aim-for-better, we will only release SDK per request.

Hi, @leni-msft , yes, this PR bring breaking change in SDK, I'm OK for this if @aim-for-better think it's necessary for service side.
Hi @aim-for-better, we will only release SDK per request.

Hi @changlong-liu  Thanks for your confirmation and clarification. Thank you very much~. I think breaking change in python side is ok from service side. There is not customer is using this property

/azp run automation - sdk

Breaking change approved: https://msazure.visualstudio.com/One/_workitems/edit/8351076


Support for file infos (CreationTime,LastWriteTime, Length, e…

I omitted WinRT and hence Windows Phone since I'm on VS2012 which doesnt support it. I guess it would be not too hard to implement on those platforms.
Let me know what you think.

:+1:

Since the owner of this repo seems to have abandoned this project I'm going to maintain a fork on https://github.com/floolean/PCLStorageEx

Thanks for forking. Any chance of it going onto NuGet?

@floolean  I'm a little late to the party.... I checked your PCLStorageEX and it too appears (according to the graphs) abandoned. Did you add anything worth getting, features, bug fixes...etc?
thanks

Please, merge and update NuGet packs


Methods that take cirq.Duration should also take datetime.timedelta

We still need duration, because timedelta only goes to microseconds.

I would like to give this a shot.
Is there additional context I should be aware of?

Probably just watch out for cases where you somehow end up doing a conversion from Duration to timedelta, since we don't want hidden loss of precision.


(GH-141) Modify the Puppet Function loading to use all of the new Puppet 4 API features

Builds on #140
Fixes #141

[x] Remove all TODOs
[x] What about puppet language functions?

Previously the Sidecar Protocol had the serialisation methods on the
BasePuppetObject however this meant anything that wanted to use the
serialisation methods also inherited the parameters like key and calling_source.
This commit:

Moves the serialisation methods (to_json, from_json!) to BaseClass which
BasePuppetObject now inherits from
Adds equality methods on the BaseClass to make it possible to compare
Sidecar objects correctly.  This is mainly required in spec tests to test for
equality (either == or eql?)
Adds a hash method to generate the hash number required when Sidecar objects
are put into hashtables

Previously the Puppet Function information retrieved over the Sidecar Protocol
only supported the older V3 Function API.  This commit updates the Protocol to
now be able to transmit V4 function information.  V3 information is expected to
be adapted into its equivalent in V4.
This commit:

Removes the deprecated arity and type methods and adds function_version and
signatures.  Where signatures are the function method signatures expressed as
a PuppetFunctionSignatureList object
Adds a PuppetFunctionSignature and PuppetFunctionSignatureList object which
captures all of the properties of Puppet Function V4 API method signature.
The PuppetFunctionSignatureList object is a "typed" array of
PuppetFunctionSignature objects
Adds a PuppetFunctionSignatureParameter and
PuppetFunctionSignatureParameterList object which captures all of the
properties of Puppet Function V4 API method signature parameter. The
PuppetFunctionSignatureParameterList object is a "typed" array of
PuppetFunctionSignatureParameter objects
Updates the spec_helper to be able to create mock objects for functions,
function signatures and function signature parameters
Updates the sidecar protocol tests for the modified parameters and newly added
classes
Updates the in-memory cache object tests for the modified parameters of a
Function.

Previously a Puppet Strings Helper was added however there no tests for the
metadata extraction.  This commit:

Adds tests to ensure that YARD/Puppet Strings extracts the metadata correctly
Converts the Strings Helper module into a class to make it easier to test
Updates the Puppet 4 function fixture to be a more complete example

When Puppet Strings extracts the parameter name it differs from how it appears
in the signature key. This makes it hard for clients to determine where in the
signature, the parameter actually is. This commit:

Updates the Sidecar Protocol and adds two new methods for the
PuppetFunctionSignatureParameter class; signature_key_offset and
signature_key_length.  These values will store where in the signature key
a parameter exists
Updates the protocol tests and spec helper for the new methods
Updates the Puppet Strings Helper to detect and populate the offset and length
values for each parameter in a signature
Updates the Puppet Strings Helper tests to assert these values are correct for
bare parameter names, blocks and splattable arguments.

Previously the Sidecar could only emit information in function V3 API format.
Now that the Sidecar Protocol has been changed to emit V4 information, this
commit updates the Sidecar to extact the V4 information.
This commit:

Updates the sidecar_protocol_extensions for the Puppet Function object to
adapt the V3 function information into the V4 version
Updates the tests for the sidecar_protocol_extensions for the new parameters
for the V4 API functions
Updates the Puppet Strings Helper to extract the required information from
YARN in order to populate the V4 API function metadata.  In particular the
concepts of function type and arity no longer apply, and have been replaced
using Function Signatures.

Now that the Sidecar and the Sidecar Protocol have been modified to emit V4
API function metadata the completion and hover providers need to be modified
to use it.  This commit:

Because the concept of Function Type no longer exists (rvalue vs statement)
all functions need to be returned when in the root of a document.  Therefore
the all_statement_functions method is changed into all_functions
The completion resolver is modified to only emit completion information if the
function actually has a signature (all functions should have at least one
sig). The resulting resolution now returns the function documentation and
function signatures in separate fields in the response
The insertion text for the completion item now just emits the function with
empty parentheses. This should trigger the Signature Helper, which will be
implemented in later commits
The hover provider is modified to remove a todo item because arity no longer
exists

Found some bugs.  Back to WIP

I'm good to merge this, but feel like I haven't really 'used' it as I don't have examples of these advanced functions and stuff you've exposed. Do you have some examples to use?

Stdlib is my goto module as it basically has everything and it's used a lot
4.x
https://github.com/puppetlabs/puppetlabs-stdlib/tree/master/lib/puppet/functions
3.x
https://github.com/puppetlabs/puppetlabs-stdlib/tree/master/lib/puppet/parser/functions


Elasticsearch pod stuck in CrashLoopBackOff

Chart version:
Kubernetes version:
1.16.0
Kubernetes provider: E.g. GKE (Google Kubernetes Engine)
PKS (Pivotal Container Service)
Helm Version:
helm get release output
RELEASED: Wed Nov  6 15:29:20 2019
CHART: elasticsearch-7.4.1
USER-SUPPLIED VALUES:
antiAffinity: hard
antiAffinityTopologyKey: kubernetes.io/hostname
clusterHealthCheckParams: wait_for_status=green&timeout=1s
clusterName: elasticsearch
esConfig: {}
esJavaOpts: -Xmx1g -Xms1g
esMajorVersion: ""
extraEnvs: []
extraInitContainers: ""
extraVolumeMounts: ""
extraVolumes: ""
fsGroup: ""
fullnameOverride: ""
httpPort: 9200
image: docker.elastic.co/elasticsearch/elasticsearch
imagePullPolicy: IfNotPresent
imagePullSecrets: []
imageTag: 7.4.1
ingress:
  annotations: {}
  enabled: false
  hosts:
  - chart-example.local
  path: /
  tls: []
initResources: {}
keystore: []
labels: {}
lifecycle: {}
masterService: ""
masterTerminationFix: false
maxUnavailable: 1
minimumMasterNodes: 2
nameOverride: ""
networkHost: <IP_ADDRESS>
nodeAffinity: {}
nodeGroup: master
nodeSelector: {}
persistence:
  annotations: {}
  enabled: true
podAnnotations: {}
podManagementPolicy: Parallel
podSecurityContext:
  fsGroup: null
  runAsUser: null
podSecurityPolicy:
  create: false
  name: ""
  spec:
    fsGroup:
      rule: RunAsAny
    privileged: true
    runAsUser:
      rule: RunAsAny
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    volumes:
    - secret
    - configMap
    - persistentVolumeClaim
priorityClassName: ""
protocol: http
rbac:
  create: false
  serviceAccountName: ""
readinessProbe:
  failureThreshold: 3
  initialDelaySeconds: 10
  periodSeconds: 10
  successThreshold: 3
  timeoutSeconds: 5
replicas: 3
resources:
  limits:
    cpu: 1000m
    memory: 2Gi
  requests:
    cpu: 100m
    memory: 2Gi
roles:
  data: "true"
  ingest: "true"
  master: "true"
schedulerName: ""
secretMounts: []
securityContext:
  capabilities:
    drop:
    - ALL
  runAsNonRoot: false
  runAsUser: null
service:
  annotations: {}
  httpPortName: http
  labels: {}
  labelsHeadless: {}
  nodePort: ""
  transportPortName: transport
  type: ClusterIP
sidecarResources: {}
sysctlInitContainer:
  enabled: false
sysctlVmMaxMapCount: 262144
terminationGracePeriod: 120
tolerations: []
transportPort: 9300
updateStrategy: RollingUpdate
volumeClaimTemplate:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

COMPUTED VALUES:
antiAffinity: hard
antiAffinityTopologyKey: kubernetes.io/hostname
clusterHealthCheckParams: wait_for_status=green&timeout=1s
clusterName: elasticsearch
esConfig: {}
esJavaOpts: -Xmx1g -Xms1g
esMajorVersion: ""
extraEnvs: []
extraInitContainers: ""
extraVolumeMounts: ""
extraVolumes: ""
fsGroup: ""
fullnameOverride: ""
httpPort: 9200
image: docker.elastic.co/elasticsearch/elasticsearch
imagePullPolicy: IfNotPresent
imagePullSecrets: []
imageTag: 7.4.1
ingress:
  annotations: {}
  enabled: false
  hosts:
  - chart-example.local
  path: /
  tls: []
initResources: {}
keystore: []
labels: {}
lifecycle: {}
masterService: ""
masterTerminationFix: false
maxUnavailable: 1
minimumMasterNodes: 2
nameOverride: ""
networkHost: <IP_ADDRESS>
nodeAffinity: {}
nodeGroup: master
nodeSelector: {}
persistence:
  annotations: {}
  enabled: true
podAnnotations: {}
podManagementPolicy: Parallel
podSecurityContext: {}
podSecurityPolicy:
  create: false
  name: ""
  spec:
    fsGroup:
      rule: RunAsAny
    privileged: true
    runAsUser:
      rule: RunAsAny
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    volumes:
    - secret
    - configMap
    - persistentVolumeClaim
priorityClassName: ""
protocol: http
rbac:
  create: false
  serviceAccountName: ""
readinessProbe:
  failureThreshold: 3
  initialDelaySeconds: 10
  periodSeconds: 10
  successThreshold: 3
  timeoutSeconds: 5
replicas: 3
resources:
  limits:
    cpu: 1000m
    memory: 2Gi
  requests:
    cpu: 100m
    memory: 2Gi
roles:
  data: "true"
  ingest: "true"
  master: "true"
schedulerName: ""
secretMounts: []
securityContext:
  capabilities:
    drop:
    - ALL
  runAsNonRoot: false
service:
  annotations: {}
  httpPortName: http
  labels: {}
  labelsHeadless: {}
  nodePort: ""
  transportPortName: transport
  type: ClusterIP
sidecarResources: {}
sysctlInitContainer:
  enabled: false
sysctlVmMaxMapCount: 262144
terminationGracePeriod: 120
tolerations: []
transportPort: 9300
updateStrategy: RollingUpdate
volumeClaimTemplate:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

HOOKS:
---
# elasticsearch-ghxrk-test
apiVersion: v1
kind: Pod
metadata:
  name: "elasticsearch-ghxrk-test"
  annotations:
    "helm.sh/hook": test-success
spec:
  containers:
  - name: "elasticsearch-liskf-test"
    image: "docker.elastic.co/elasticsearch/elasticsearch:7.4.1"
    command:
      - "sh"
      - "-c"
      - |
        #!/usr/bin/env bash -e
        curl -XGET --fail 'elasticsearch-master:9200/_cluster/health?wait_for_status=green&timeout=1s'
  restartPolicy: Never
MANIFEST:

---
# Source: elasticsearch/templates/poddisruptionbudget.yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: "elasticsearch-master-pdb"
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: "elasticsearch-master"
---
# Source: elasticsearch/templates/service.yaml
kind: Service
apiVersion: v1
metadata:
  name: elasticsearch-master
  labels:
    heritage: "Tiller"
    release: "elasticsearch"
    chart: "elasticsearch"
    app: "elasticsearch-master"
  annotations:
    {}

spec:
  type: ClusterIP
  selector:
    heritage: "Tiller"
    release: "elasticsearch"
    chart: "elasticsearch"
    app: "elasticsearch-master"
  ports:
  - name: http
    protocol: TCP
    port: 9200
  - name: transport
    protocol: TCP
    port: 9300
---
# Source: elasticsearch/templates/service.yaml
kind: Service
apiVersion: v1
metadata:
  name: elasticsearch-master-headless
  labels:
    heritage: "Tiller"
    release: "elasticsearch"
    chart: "elasticsearch"
    app: "elasticsearch-master"
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
spec:
  clusterIP: None # This is needed for statefulset hostnames like elasticsearch-0 to resolve
  # Create endpoints also if the related pod isn't ready
  publishNotReadyAddresses: true
  selector:
    app: "elasticsearch-master"
  ports:
  - name: http
    port: 9200
  - name: transport
    port: 9300
---
# Source: elasticsearch/templates/statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch-master
  labels:
    heritage: "Tiller"
    release: "elasticsearch"
    chart: "elasticsearch"
    app: "elasticsearch-master"
  annotations:
    esMajorVersion: "7"
spec:
  serviceName: elasticsearch-master-headless
  selector:
    matchLabels:
      app: "elasticsearch-master"
  replicas: 3
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
  volumeClaimTemplates:
  - metadata:
      name: elasticsearch-master
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 30Gi

  template:
    metadata:
      name: "elasticsearch-master"
      labels:
        heritage: "Tiller"
        release: "elasticsearch"
        chart: "elasticsearch"
        app: "elasticsearch-master"
      annotations:

    spec:
      securityContext:
        {}

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - "elasticsearch-master"
            topologyKey: kubernetes.io/hostname
      terminationGracePeriodSeconds: 120
      volumes:
      initContainers:

      containers:
      - name: "elasticsearch"
        securityContext:
          capabilities:
            drop:
            - ALL
          runAsNonRoot: false

        image: "docker.elastic.co/elasticsearch/elasticsearch:7.4.1"
        imagePullPolicy: "IfNotPresent"
        readinessProbe:
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 3
          timeoutSeconds: 5

          exec:
            command:
              - sh
              - -c
              - |
                #!/usr/bin/env bash -e
                # If the node is starting up wait for the cluster to be ready (request params: 'wait_for_status=green&timeout=1s' )
                # Once it has started only check that the node itself is responding
                START_FILE=/tmp/.es_start_file

                http () {
                    local path="${1}"
                    if [ -n "${ELASTIC_USERNAME}" ] && [ -n "${ELASTIC_PASSWORD}" ]; then
                      BASIC_AUTH="-u ${ELASTIC_USERNAME}:${ELASTIC_PASSWORD}"
                    else
                      BASIC_AUTH=''
                    fi
                    curl -XGET -s -k --fail ${BASIC_AUTH} http://<IP_ADDRESS>:9200${path}
                }

                if [ -f "${START_FILE}" ]; then
                    echo 'Elasticsearch is already running, lets check the node is healthy'
                    http "/"
                else
                    echo 'Waiting for elasticsearch cluster to become cluster to be ready (request params: "wait_for_status=green&timeout=1s" )'
                    if http "/_cluster/health?wait_for_status=green&timeout=1s" ; then
                        touch ${START_FILE}
                        exit 0
                    else
                        echo 'Cluster is not yet ready (request params: "wait_for_status=green&timeout=1s" )'
                        exit 1
                    fi
                fi
        ports:
        - name: http
          containerPort: 9200
        - name: transport
          containerPort: 9300
        resources:
          limits:
            cpu: 1000m
            memory: 2Gi
          requests:
            cpu: 100m
            memory: 2Gi

        env:
          - name: node.name
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: cluster.initial_master_nodes
            value: "elasticsearch-master-0,elasticsearch-master-1,elasticsearch-master-2,"
          - name: discovery.seed_hosts
            value: "elasticsearch-master-headless"
          - name: cluster.name
            value: "elasticsearch"
          - name: network.host
            value: "<IP_ADDRESS>"
          - name: ES_JAVA_OPTS
            value: "-Xmx1g -Xms1g"
          - name: node.data
            value: "true"
          - name: node.ingest
            value: "true"
          - name: node.master
            value: "true"
        volumeMounts:
          - name: "elasticsearch-master"
            mountPath: /usr/share/elasticsearch/data

Describe the bug:
All of the resources besides the pods are able to successfully spin up/bind. The pods are stuck in CrashLoopBackOff. When I get the logs they just have one line chroot: cannot change root directory to /: Operation not permitted
Steps to reproduce:

Expected behavior:
Provide logs and/or server output (if relevant):
Any additional context:

Please show your values.yml for this chart. Also as show kubectl describe of your elasticsearch-master-0. This would help. In my case init container didn't had privilege to change ownership for the volume as init-container started as non-privileged container.

@nfickas Is this still an issue for you?
If so, could you provide the output from the following commands in order to allow us to investigate further.

kubectl get events
kubectl describe elasticsearch-master-0

It will take me a bit to redeploy the helm chart but in any case here are the contents of my values.yml:
---
clusterName: "elasticsearch"
nodeGroup: "master"

# The service that non master groups will try to connect to when joining the cluster
# This should be set to clusterName + "-" + nodeGroup for your master group
masterService: ""

# Elasticsearch roles that will be applied to this nodeGroup
# These will be set as environment variables. E.g. node.master=true
roles:
  master: "true"
  ingest: "true"
  data: "true"

replicas: 3
minimumMasterNodes: 2

esMajorVersion: ""

# Allows you to add any config files in /usr/share/elasticsearch/config/
# such as elasticsearch.yml and log4j2.properties
esConfig: {}
#  elasticsearch.yml: |
#    key:
#      nestedkey: value
#  log4j2.properties: |
#    key = value

# Extra environment variables to append to this nodeGroup
# This will be appended to the current 'env:' key. You can use any of the kubernetes env
# syntax here
extraEnvs: []
#  - name: MY_ENVIRONMENT_VAR
#    value: the_value_goes_here

# A list of secrets and their paths to mount inside the pod
# This is useful for mounting certificates for security and for mounting
# the X-Pack license
secretMounts: []
#  - name: elastic-certificates
#    secretName: elastic-certificates
#    path: /usr/share/elasticsearch/config/certs

image: "docker.elastic.co/elasticsearch/elasticsearch"
imageTag: "7.4.1"
imagePullPolicy: "IfNotPresent"

podAnnotations: {}
  # iam.amazonaws.com/role: es-cluster

# additionals labels
labels: {}

esJavaOpts: "-Xmx1g -Xms1g"

resources:
  requests:
    cpu: "100m"
    memory: "2Gi"
  limits:
    cpu: "1000m"
    memory: "2Gi"

initResources: {}
  # limits:
  #   cpu: "25m"
  #   # memory: "128Mi"
  # requests:
  #   cpu: "25m"
  #   memory: "128Mi"

sidecarResources: {}
  # limits:
  #   cpu: "25m"
  #   # memory: "128Mi"
  # requests:
  #   cpu: "25m"
  #   memory: "128Mi"

networkHost: "<IP_ADDRESS>"

volumeClaimTemplate:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 30Gi

rbac:
  create: false
  serviceAccountName: ""

podSecurityPolicy:
  create: false
  name: ""
  spec:
    privileged: true
    fsGroup:
      rule: RunAsAny
    runAsUser:
      rule: RunAsAny
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    volumes:
      - secret
      - configMap
      - persistentVolumeClaim

persistence:
  enabled: true
  annotations: {}

extraVolumes: ""
  # - name: extras
  #   emptyDir: {}

extraVolumeMounts: ""
  # - name: extras
  #   mountPath: /usr/share/extras
  #   readOnly: true

extraInitContainers: ""
  # - name: do-something
  #   image: busybox
  #   command: ['do', 'something']

# This is the PriorityClass settings as defined in
# https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass
priorityClassName: ""

# By default this will make sure two pods don't end up on the same node
# Changing this to a region would allow you to spread pods across regions
antiAffinityTopologyKey: "kubernetes.io/hostname"

# Hard means that by default pods will only be scheduled if there are enough nodes for them
# and that they will never end up on the same node. Setting this to soft will do this "best effort"
antiAffinity: "hard"

# This is the node affinity settings as defined in
# https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature
nodeAffinity: {}

# The default is to deploy all pods serially. By setting this to parallel all pods are started at
# the same time when bootstrapping the cluster
podManagementPolicy: "Parallel"

protocol: http
httpPort: 9200
transportPort: 9300

service:
  labels: {}
  labelsHeadless: {}
  type: ClusterIP
  nodePort: ""
  annotations: {}
  httpPortName: http
  transportPortName: transport

updateStrategy: RollingUpdate

# This is the max unavailable setting for the pod disruption budget
# The default value of 1 will make sure that kubernetes won't allow more than 1
# of your pods to be unavailable during maintenance
maxUnavailable: 1

podSecurityContext:
  fsGroup: null
  runAsUser: null

# The following value is deprecated,
# please use the above podSecurityContext.fsGroup instead
fsGroup: ""

securityContext:
  capabilities:
    drop:
    - ALL
  # readOnlyRootFilesystem: true
  runAsNonRoot: false
  runAsUser: null

# How long to wait for elasticsearch to stop gracefully
terminationGracePeriod: 120

sysctlVmMaxMapCount: 262144

readinessProbe:
  failureThreshold: 3
  initialDelaySeconds: 10
  periodSeconds: 10
  successThreshold: 3
  timeoutSeconds: 5

# https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html#request-params wait_for_status
clusterHealthCheckParams: "wait_for_status=green&timeout=1s"

## Use an alternate scheduler.
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
schedulerName: ""

imagePullSecrets: []
nodeSelector: {}
tolerations: []

# Enabling this will publically expose your Elasticsearch instance.
# Only enable this if you have security enabled on your cluster
ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  path: /
  hosts:
    - chart-example.local
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

nameOverride: ""
fullnameOverride: ""

# https://github.com/elastic/helm-charts/issues/63
masterTerminationFix: false

lifecycle: {}
  # preStop:
  #   exec:
  #     command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  # postStart:
  #   exec:
  #     command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]

sysctlInitContainer:
  enabled: false

keystore: []

Output of kubectl describe pod elasticsearch-master-0:
Namespace:          elasticsearch
Priority:           0
PriorityClassName:  <none>
Node:               ip-10-104-100-235.ec2.internal/<IP_ADDRESS>
Start Time:         Tue, 12 Nov 2019 09:51:34 -0600
Labels:             app=elasticsearch-master
                    chart=elasticsearch
                    controller-revision-hash=elasticsearch-master-6cc89df559
                    heritage=Tiller
                    release=elasticsearch
                    statefulset.kubernetes.io/pod-name=elasticsearch-master-0
Annotations:        <none>
Status:             Running
IP:                 <IP_ADDRESS>
Controlled By:      StatefulSet/elasticsearch-master
Containers:
  elasticsearch:
    Container ID:   docker://9bab23650dbc38218d34db0aaffe8d660cbbcab118bd06289f8c87dbca4bca68
    Image:          docker.elastic.co/elasticsearch/elasticsearch:7.4.1
    Image ID:       docker-pullable://docker.elastic.co/elasticsearch/elasticsearch@sha256:88c2ee30115f378b8f7e66662ec26bca0c8778c69096bee6b161128ce833585f
    Ports:          9200/TCP, 9300/TCP
    Host Ports:     0/TCP, 0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    125
      Started:      Tue, 12 Nov 2019 09:54:42 -0600
      Finished:     Tue, 12 Nov 2019 09:54:42 -0600
    Ready:          False
    Restart Count:  5
    Limits:
      cpu:     1
      memory:  2Gi
    Requests:
      cpu:      100m
      memory:   2Gi
    Readiness:  exec [sh -c #!/usr/bin/env bash -e
# If the node is starting up wait for the cluster to be ready (request params: 'wait_for_status=green&timeout=1s' )
# Once it has started only check that the node itself is responding
START_FILE=/tmp/.es_start_file

http () {
    local path="${1}"
    if [ -n "${ELASTIC_USERNAME}" ] && [ -n "${ELASTIC_PASSWORD}" ]; then
      BASIC_AUTH="-u ${ELASTIC_USERNAME}:${ELASTIC_PASSWORD}"
    else
      BASIC_AUTH=''
    fi
    curl -XGET -s -k --fail ${BASIC_AUTH} http://<IP_ADDRESS>:9200${path}
}

if [ -f "${START_FILE}" ]; then
    echo 'Elasticsearch is already running, lets check the node is healthy'
    http "/"
else
    echo 'Waiting for elasticsearch cluster to become cluster to be ready (request params: "wait_for_status=green&timeout=1s" )'
    if http "/_cluster/health?wait_for_status=green&timeout=1s" ; then
        touch ${START_FILE}
        exit 0
    else
        echo 'Cluster is not yet ready (request params: "wait_for_status=green&timeout=1s" )'
        exit 1
    fi
fi
] delay=10s timeout=5s period=10s #success=3 #failure=3
    Environment:
      node.name:                     elasticsearch-master-0 (v1:metadata.name)
      cluster.initial_master_nodes:  elasticsearch-master-0,elasticsearch-master-1,elasticsearch-master-2,
      discovery.seed_hosts:          elasticsearch-master-headless
      cluster.name:                  elasticsearch
      network.host:                  <IP_ADDRESS>
      ES_JAVA_OPTS:                  -Xmx1g -Xms1g
      node.data:                     true
      node.ingest:                   true
      node.master:                   true
    Mounts:
      /usr/share/elasticsearch/data from elasticsearch-master (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-s4l2t (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  elasticsearch-master:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  elasticsearch-master-elasticsearch-master-0
    ReadOnly:   false
  default-token-s4l2t:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-s4l2t
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age                     From                                     Message
  ----     ------                  ----                    ----                                     -------
  Warning  FailedScheduling        4m22s (x13 over 4m31s)  default-scheduler                        pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
  Normal   Scheduled               4m22s                   default-scheduler                        Successfully assigned elasticsearch/elasticsearch-master-0 to ip-10-104-100-235.ec2.internal
  Warning  FailedAttachVolume      4m20s (x3 over 4m22s)   attachdetach-controller                  AttachVolume.Attach failed for volume "pvc-4869ac42-0564-11ea-afb3-128835a598bc" : "Error attaching EBS volume \"vol-03c493821fdc3f23e\"" to instance "i-02139df8fad8278e7" since volume is in "creating" state
  Normal   SuccessfulAttachVolume  4m14s                   attachdetach-controller                  AttachVolume.Attach succeeded for volume "pvc-4869ac42-0564-11ea-afb3-128835a598bc"
  Normal   Pulled                  2m37s (x5 over 4m3s)    kubelet, ip-10-104-100-235.ec2.internal  Container image "docker.elastic.co/elasticsearch/elasticsearch:7.4.1" already present on machine
  Normal   Created                 2m37s (x5 over 4m3s)    kubelet, ip-10-104-100-235.ec2.internal  Created container
  Normal   Started                 2m37s (x5 over 4m3s)    kubelet, ip-10-104-100-235.ec2.internal  Started container
  Warning  BackOff                 2m14s (x10 over 4m1s)   kubelet, ip-10-104-100-235.ec2.internal  Back-off restarting failed container

Output of kubectl get events:
5m53s       Warning   FailedScheduling         Pod                     pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
5m53s       Normal    Scheduled                Pod                     Successfully assigned elasticsearch/elasticsearch-master-0 to ip-10-104-100-235.ec2.internal
5m51s       Warning   FailedAttachVolume       Pod                     AttachVolume.Attach failed for volume "pvc-4869ac42-0564-11ea-afb3-128835a598bc" : "Error attaching EBS volume \"vol-03c493821fdc3f23e\"" to instance "i-02139df8fad8278e7" since volume is in "creating" state
5m45s       Normal    SuccessfulAttachVolume   Pod                     AttachVolume.Attach succeeded for volume "pvc-4869ac42-0564-11ea-afb3-128835a598bc"
4m8s        Normal    Pulled                   Pod                     Container image "docker.elastic.co/elasticsearch/elasticsearch:7.4.1" already present on machine
4m8s        Normal    Created                  Pod                     Created container
4m8s        Normal    Started                  Pod                     Started container
22s         Warning   BackOff                  Pod                     Back-off restarting failed container
6m1s        Warning   FailedScheduling         Pod                     pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
6m1s        Normal    Scheduled                Pod                     Successfully assigned elasticsearch/elasticsearch-master-1 to ip-10-104-98-216.ec2.internal
5m59s       Warning   FailedAttachVolume       Pod                     AttachVolume.Attach failed for volume "pvc-486d9292-0564-11ea-afb3-128835a598bc" : "Error attaching EBS volume \"vol-0113f8554c2c01f0d\"" to instance "i-03834a2a63878eb12" since volume is in "creating" state
5m53s       Normal    SuccessfulAttachVolume   Pod                     AttachVolume.Attach succeeded for volume "pvc-486d9292-0564-11ea-afb3-128835a598bc"
4m5s        Normal    Pulled                   Pod                     Container image "docker.elastic.co/elasticsearch/elasticsearch:7.4.1" already present on machine
4m5s        Normal    Created                  Pod                     Created container
4m4s        Normal    Started                  Pod                     Started container
31s         Warning   BackOff                  Pod                     Back-off restarting failed container
6m1s        Warning   FailedScheduling         Pod                     pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
6m1s        Normal    Scheduled                Pod                     Successfully assigned elasticsearch/elasticsearch-master-2 to ip-10-104-99-242.ec2.internal
5m59s       Warning   FailedAttachVolume       Pod                     AttachVolume.Attach failed for volume "pvc-48730fc7-0564-11ea-afb3-128835a598bc" : "Error attaching EBS volume \"vol-0b9267a8af7e0704c\"" to instance "i-046156496e52df2ff" since volume is in "creating" state
5m53s       Normal    SuccessfulAttachVolume   Pod                     AttachVolume.Attach succeeded for volume "pvc-48730fc7-0564-11ea-afb3-128835a598bc"
4m18s       Normal    Pulled                   Pod                     Container image "docker.elastic.co/elasticsearch/elasticsearch:7.4.1" already present on machine
4m18s       Normal    Created                  Pod                     Created container
4m17s       Normal    Started                  Pod                     Started container
30s         Warning   BackOff                  Pod                     Back-off restarting failed container
5m53s       Normal    ProvisioningSucceeded    PersistentVolumeClaim   Successfully provisioned volume pvc-4869ac42-0564-11ea-afb3-128835a598bc using kubernetes.io/aws-ebs
6m1s        Normal    ProvisioningSucceeded    PersistentVolumeClaim   Successfully provisioned volume pvc-486d9292-0564-11ea-afb3-128835a598bc using kubernetes.io/aws-ebs
6m1s        Normal    ProvisioningSucceeded    PersistentVolumeClaim   Successfully provisioned volume pvc-48730fc7-0564-11ea-afb3-128835a598bc using kubernetes.io/aws-ebs
6m2s        Normal    NoPods                   PodDisruptionBudget     No matching pods found
6m2s        Normal    SuccessfulCreate         StatefulSet             create Claim elasticsearch-master-elasticsearch-master-0 Pod elasticsearch-master-0 in StatefulSet elasticsearch-master success
6m2s        Normal    SuccessfulCreate         StatefulSet             create Pod elasticsearch-master-0 in StatefulSet elasticsearch-master successful
6m2s        Normal    SuccessfulCreate         StatefulSet             create Claim elasticsearch-master-elasticsearch-master-1 Pod elasticsearch-master-1 in StatefulSet elasticsearch-master success
6m2s        Normal    SuccessfulCreate         StatefulSet             create Pod elasticsearch-master-1 in StatefulSet elasticsearch-master successful
6m2s        Normal    SuccessfulCreate         StatefulSet             create Claim elasticsearch-master-elasticsearch-master-2 Pod elasticsearch-master-2 in StatefulSet elasticsearch-master success
6m2s        Normal    SuccessfulCreate         StatefulSet             create Pod elasticsearch-master-2 in StatefulSet elasticsearch-master successful

@nfickas Cheers for that.
The only thing that jumps out at me from your values.yml file is:
podSecurityContext:
  fsGroup: null
  runAsUser: null

Is there a specific reason you're not specifying the fsGroup and runAsUser values?
A difference in UID between the volume mount and the elasticsearch user running within the pod could cause the sort of issue you experienced with operation not permitted...

Well I thought default parameters would do. So just using that template as
is, init container fails. Usually defaults should work out of the box:) no?
--
Roman Gorodeckij
On 13 November 2019 at 13:53:25, Gavin Williams<EMAIL_ADDRESS>wrote:

@nfickas https://github.com/nfickas Cheers for that.
The only thing that jumps out at me from your values.yml file is:
podSecurityContext:
fsGroup: null
runAsUser: null
Is there a specific reason you're not specifying the fsGroup and runAsUser
values?
A difference in UID between the volume mount and the elasticsearch user
running within the pod could cause the sort of issue you experienced with operation
not permitted...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/elastic/helm-charts/issues/357?email_source=notifications&email_token=AACES7VG3SIETWMIIIWIITTQTPTDLA5CNFSM4JJ6EPN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED54LRQ#issuecomment-553371078,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACES7XNDQSV7H352VEA72TQTPTDLANCNFSM4JJ6EPNQ
.

@fatmcgav I took those out since I kept running into this error: SecurityContext.RunAsUser is forbidden. I think I could put the original values back in if I disabled the admission controller called SecurityContextDeny.

@nfickas Ah, ok... So that looks like something specific to the Pivotal Container Service (PKS) security.
From a quick look at the PKS docs, creating a Pod Security Policy might be another option - https://docs.pivotal.io/pks/1-4/pod-security-policy.html.
Unfortunately I'm not familiar enough with PKS to advise beyond what's available in the docs...
Please let us know what route you take though.

Thanks for the help was able to resolve by upgrading my version of PKS and disabling the SecurityContextDeny admission controller.

@nfickas great, glad you got it working...


Add DataFrame.spark.repartition to doc

Codecov Report

Merging #1868 into master will decrease coverage by 2.92%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1868      +/-   ##
==========================================
- Coverage   94.16%   91.24%   -2.93%
==========================================
  Files          40       40
  Lines        9819     9715     -104
==========================================
- Hits         9246     8864     -382
- Misses        573      851     +278

Impacted Files
Coverage Δ

databricks/koalas/usage_logging/__init__.py
25.66% <0.00%> (-66.65%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
47.82% <0.00%> (-52.18%)
:arrow_down:

databricks/koalas/__init__.py
76.66% <0.00%> (-13.34%)
:arrow_down:

databricks/conftest.py
88.13% <0.00%> (-11.87%)
:arrow_down:

databricks/koalas/spark/functions.py
88.88% <0.00%> (-7.41%)
:arrow_down:

databricks/koalas/accessors.py
86.13% <0.00%> (-6.94%)
:arrow_down:

databricks/koalas/namespace.py
77.87% <0.00%> (-4.94%)
:arrow_down:

databricks/koalas/generic.py
90.56% <0.00%> (-4.79%)
:arrow_down:

databricks/koalas/frame.py
93.38% <0.00%> (-3.38%)
:arrow_down:

databricks/koalas/typedef/typehints.py
89.47% <0.00%> (-2.64%)
:arrow_down:

... and 13 more

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 cb9c9d3...5f2f3a6. Read the comment docs.

Thanks! merging.


SSR Broken?

The document for SSR recommends to import renderStatic this way:
import { renderStatic } from 'glamor/server'
However it does not seem that the module glamor/server exists. Am I missing something?

Are you trying v3 by any chance?

It looks like renderStatic was moved to glamor-server. This tripped me up earlier, I just had to
npm install glamor-server

This shouldn't be an issue if you're using v2. Are you on v3 by any chance?

it appears v3 was marked as latest, I've marked v2 again

please reinstall glamor, and use glamor/server as normal

The problem was that I had the v3 version because of installing latest. Thank you for the fix.


Upgrade to latest stable OS versions.

The release workflow was already upgraded to Ubuntu 22.04 in #2127.

The merge pulls in changes from #2132 (5d25bbe & b5a42c1)to fix CI; so I'll wait on that to land before landing this.


Connecting to Server

Describe the bug
Dear team, I tried to make a connection to a local NAS system.  And I can not proceed. If I want to make aserver connection I have to connect via Windows Explorer to then see the connection in Files.
To Reproduce
Steps to reproduce the behavior:

Go to '....'
Click on '....'
Scroll down to '....'
See error

Expected behavior
Connect to a server and see it in Files.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS Version: Version	Windows 10 10.0.19042 Build 19042
App version: v<IP_ADDRESS>

Additional context
Every time I try to connect via Files.

Screenshot:
https://imgur.com/a/fOjpR9x


SCHEMA::Setup not work

Describe the bug
SCHEMA::Setup not work, after latest update
To Reproduce
for (int i = 0; i < nElements; i++)
	{
		const UtlTSHashHandle_t hElement = pElements[i];

		if (hElement == 0)
			continue;

		CSchemaClassBinding* pClassBinding = pTypeScope->hashClasses[hElement];
		if (pClassBinding == nullptr)
			continue;

		SchemaClassInfoData_t* pDeclaredClassInfo;
		pTypeScope->FindDeclaredClass(&pDeclaredClassInfo, pClassBinding->szBinaryName);

		if (pDeclaredClassInfo == nullptr)
			continue;

		if (pDeclaredClassInfo->nFieldSize == 0)
			continue;

		CRT::String_t<MAX_PATH> szClassBuffer(CS_XOR("class %s\n"), pDeclaredClassInfo->szName);
		::WriteFile(hOutFile, szClassBuffer.Data(), szClassBuffer.Length(), nullptr, nullptr);

		for (auto j = 0; j < pDeclaredClassInfo->nFieldSize; j++)
		{
			SchemaClassFieldData_t* pFields = pDeclaredClassInfo->pFields;
			CRT::String_t<MAX_PATH> szFieldClassBuffer(CS_XOR("%s->%s"), pClassBinding->szBinaryName, pFields[j].szName);
			// store field info
			vecSchemaData.emplace_back(FNV1A::Hash(szFieldClassBuffer.Data()), pFields[j].nSingleInheritanceOffset);

			CRT::String_t<MAX_PATH> szFieldBuffer(CS_XOR("    %s %s = 0x%X\n"), pFields[j].pSchemaType->szName, pFields[j].szName, pFields[j].nSingleInheritanceOffset);
			// write field info
			::WriteFile(hOutFile, szFieldBuffer.Data(), szFieldBuffer.Length(), nullptr, nullptr);
		}

		//L_PRINT(LOG_INFO) << CS_XOR("dumped \"") << pDeclaredClassInfo->szName << CS_XOR("\" (total: ") << pDeclaredClassInfo->nFieldSize << CS_XOR(" fields)");
	}

This step not work, maybe nElements is null

already mentioned in #60

Rerturns 1643 for client.dll
const int nTableSize = pTypeScope->hashClasses.Count();
Return 0
const auto nElements = pTypeScope->hashClasses.GetElements(0, nTableSize, pElements);

Rerturns 402 for client.dll
const int nTableSize = pTypeScope->hashClasses.Count();

Return 0
const auto nElements = pTypeScope->hashClasses.GetElements(0, nTableSize, pElements);

yes and I know about this issue as I already mentioned in other issue, will take a closer looks on what did they change to the hash struct, or if I feel lazy, I'll just throw a ghetto lazy way for this as other the ischemasystem's interfaces function still working fine

@maecry u know where could be the error?, im trying to find it but i dont know if im too lost

@maecry u know where could be the error?, im trying to find it but i dont know if im too lost

CUtlTSHash changed, will push a fix soon whenever there is no earthquake in Taiwan

@maecry u know where could be the error?, im trying to find it but i dont know if im too lost

CUtlTSHash changed and it seems like C_BaseEntity/CCSPlayerController and some others classes don't get exported to schema anymore, will push a fix soon whenever there is no earthquake in Taiwan and when I figure this out ofc

u don't need to use CUtlTSHash shit, u can grab all classes like there https://github.com/sneakyevil/CS2-SchemaDumper/blob/main/main.cpp#L120

https://github.com/sneakyevil/CS2-SchemaDumper/blob/main/main.cpp#L120
schema_client.txt

nah, I realize I already rebuilt most of it but I used offset to access the field, removed it and everything work now


Dynamic spatial node support

Adds the ability to specify a spatial node type (static or dynamic) when calling World.FromSpatialNode, as well as the ability to specify a timestamp (Windows QPC ticks, internally converted to XrTime) at which to locate the spatial node. Default behaviour remains unchanged (static nodes using 'current' SK time). Also adds some extra checking to better handle the common failure case where a xrCreateSpatialGraphNodeSpaceMSFT call succeeds but the subsequent openxr_get_space call fails.
This enables the use of the World.FramSpatialNode API with sensor APIs including Windows.Media.Capture and Research Mode, which may utilise dynamic nodes and/or timestamped (typically QPC-based) data.
Addresses #198

Cool stuff, thanks for the submission! I'll test this out on Monday, but two bits stand out while reading through it:

Your XrTime time = 0; definition is within a platform specific ifdef, but used outside that ifdef. I believe that probably will cause errors when compiling for other platforms :)
Your C# binding for bool32_t is a bool, which is a trap that springs inconsistently on different platforms! It's safest to marshal as an int instead.


Add subscription ID to Azure discovery screen

To connect to an Azure provider the user is now required to enter a subscription id, therefore the Azure provider discovery screen must be updated to capture one, just like the Azure "Add Cloud Provider" screen was. Otherwise, the attached error will be thrown.
This fix does not have to be backported to Darga since the subscription ID requirement was introduced to master after Darga was released.

@miq-bot assign @dclarizio

This should still be added for Darga IMO since the subscription ID was optional. It just shouldn't be mandatory for Darga.


[UI] Error Occurs When Reloading or Directly Accessing URLs with Configurations/Designs

Current Behavior
After setting up the server locally or on a remote provider and running the UI, an error occurs when directly accessing http://localhost:3000/configuration/designs in the browser or on reloading. However, if we navigate to this page step by step through the UI, it loads correctly without any issues.
Desired Behavior
page should load correctly
Screenshots/Logs
Issue.webm
logs
$ make ui
cd ui; npm run dev; cd ..;

><EMAIL_ADDRESS>dev
> next lint --fix && node ui_dev_server.js

(node:51782) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
✔ No ESLint warnings or errors
(node:51796) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Defining routes from exportPathMap
info  - Disabled SWC as replacement for Babel because of custom Babel configuration ".babelrc" https://nextjs.org/docs/messages/swc-disabled
info  - `compiler` options in `next.config.js` will be ignored while using Babel https://nextjs.org/docs/messages/ignored-compiler-options
event - compiled client and server successfully in 6.4s (9055 modules)
> Ready on http://localhost:3000
wait  - compiling / (client and server)...
event - compiled client and server successfully in 2.3s (9535 modules)
(node:51796) [DEP0060] DeprecationWarning: The `util._extend` API is deprecated. Please use Object.assign() instead.
Url '/configuration/designs' defines a query parameter '__nextDefaultLocale' that is missing in exportPathMap
wait  - compiling /configuration/designs (client and server)...
event - compiled client and server successfully in 7.7s (20909 modules)
error - ReferenceError: document is not defined
    at /home/kevin/Desktop/Meshery/meshery/ui/node_modules/codemirror/lib/codemirror.js:88:3
    at /home/kevin/Desktop/Meshery/meshery/ui/node_modules/codemirror/lib/codemirror.js:11:83
    at Object.<anonymous> (/home/kevin/Desktop/Meshery/meshery/ui/node_modules/codemirror/lib/codemirror.js:14:2)
    at Module._compile (node:internal/modules/cjs/loader:1460:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1544:10)
    at Module.load (node:internal/modules/cjs/loader:1275:32)
    at Module._load (node:internal/modules/cjs/loader:1091:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:212:19)
    at Module.require (node:internal/modules/cjs/loader:1297:12)
    at require (node:internal/modules/helpers:123:16) {
  page: '/configuration/designs'
}
wait  - compiling /_error (client and server)...

Contributor Guides and Handbook

🎨 Wireframes and designs for Meshery UI in Figma (open invite)
🖥 Contributing to Meshery UI
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@Kevin222004   i couldn't repro this error. Can you make sure if it still exists? Thanks.

@SSPlusUltra I have update my branch and rebuild all servers, I still have this issue.


ICU in estonia

It would be interesting and useful to know:

how many ICU beds are available in Estonia (and perhaps track their availability)
number of available ICU units fitted with ventilators

I immagine these information (at least the raw numbers) should be available somewhere.

Yes! It is much more informative and actionable that just the number of cases.
The number of cases does not give any actionable information. Furthermore, the number itself depends on the availability of the testing and who is being chosen for testing.
On the other hand, the percentage of occupied ICU beds in the country on tells directly how serious the situation is. As it approaches 80%, 90%, 100% the system breaks.
By looking at plot of occupied ICU beds, we can clearly predict, when will the healthcare system collapse under the pressure. -- This, is actionable.

We don't have this data now, but if it becomes available we will add it. I hope that @infokujur can help to get this information.

But the overall number of ICU beds should be available (or at least knowable), and we already have the number of people with corona in critical conditions (which usually also means ICU beds) as it is usually given in the daily updates by the health board.
Knowing how many ICU spaces are available at any given time may not be doable, but knowing the max capacity would have a pretty good idea of how many ICUs are (theoretically) available to non covid patients, and thus to track the covid induced saturation of ICUs beds.

the new science report has the numbers: https://www.valitsus.ee/et/uudised/covid-19-leviku-tokestamise-teadusnoukoja-raport
there doesn't seem to be a copy in English, but tl;dr is: 157 beds overall today, 80 of them available. 50 more could be added (by converting the lower-level ones), so total of 130 can be made available for Covid patients.

Thanks! Yes I read this today, the numbers are there I just have no idea how to visualize them. We wont get updated data on this I assume so everything would just be speculation from our part. If someone has a good idea on how to visualize then I can look into adding it.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Rivo Laks<EMAIL_ADDRESS>Sent: Tuesday, March 24, 2020 11:57:56 PM
To: okestonia/koroonakaart<EMAIL_ADDRESS>Cc: keeganmcbride<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [okestonia/koroonakaart] ICU in estonia (#32)
the new science report has the numbers: https://www.valitsus.ee/et/uudised/covid-19-leviku-tokestamise-teadusnoukoja-raport
there doesn't seem to be a copy in English, but tl;dr is: 157 beds overall today, 80 of them available. 50 more could be added (by converting the lower-level ones), so total of 130 can be made available for Covid patients.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/okestonia/koroonakaart/issues/32#issuecomment-603526166, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE7MKRYHAOFWIRY7A6A6CITRJEUGJANCNFSM4LQOQASQ.

hmmm... maybe add a second row of number to the statsbar thing? might also be useful to quickly show the daily increase (absolute or percentage) of other numbers.
here's a quick mockup:

For visualisation purposes a horizontal (red) line could be added to cases graph at 130 cases (conservative estimate of available ICU places according to the cited report) or two lines at 130 cases and 500 cases (maximum according to the Health Board if all possible conversions done (https://epl.delfi.ee/uudised/koroonakriisi-koige-mustemale-stsenaariumile-tervishoiususteem-vastu-ei-pea?id=89407295)).


Install tushare error

pip2.7 install tushare==0.8.4
Collecting tushare==0.8.4
Using cached tushare-0.8.4.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 1, in
File "/private/var/folders/6g/qpx730ks6g34j_6zrp0y7jk80000gn/T/pip-build-B9Mu3L/tushare/setup.py", line 4, in
import tushare
File "tushare/init.py", line 117, in
from tushare.futures.domestic import (get_cffex_daily, get_czce_daily,
File "tushare/futures/domestic.py", line 11, in
from bs4 import BeautifulSoup
File "/anaconda2.7/lib/python2.7/site-packages/bs4/init.py", line 30, in
from .builder import builder_registry, ParserRejectedMarkup
File "/anaconda2.7/lib/python2.7/site-packages/bs4/builder/init.py", line 314, in
from . import _html5lib
File "/anaconda2.7/lib/python2.7/site-packages/bs4/builder/_html5lib.py", line 70, in
class TreeBuilderForHtml5lib(html5lib.treebuilders._base.TreeBuilder):
AttributeError: 'module' object has no attribute '_base'
----------------------------------------

Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/6g/qpx730ks6g34j_6zrp0y7jk80000gn/T/pip-build-B9Mu3L/tushare/

just find a solution from http://blog.csdn.net/justdoitjs/article/details/63689061
pip install --upgrade html5lib==1.0b8


[BACKLOG-8272] Add MDI support to the Multiway Merge Join step

Build completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands:

ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands:
rm -r ~/.ivy2/local || echo no publish local to remove
Changed files:
engine/src/org/pentaho/di/trans/steps/multimerge/MultiMergeJoinMeta.java
engine/test-src/org/pentaho/di/trans/steps/multimerge/MultiMergeJoinMetaInjectionTest.java
Unit test coverage change:
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory:

Branch Change :  + 7.14%
Complexity Change :  + 7.69%

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics:

Branch Change :  + .39%
Complexity Change :  + .51%
Instruction Change :  + .08%

org.pentaho.di.job.entries.ftpsget.JobEntryFTPSGet:

Branch Change :  + .53%
Complexity Change :  + .56%
Instruction Change :  + .07%

org.pentaho.di.job.entries.sql.JobEntrySQL:

Instruction Change :  + 3.28%
Line Change :  + 3.87%

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper:

Branch Change : -1.64%
Complexity Change : -.69%
Instruction Change : -2.43%
Line Change : -3.70%

org.pentaho.di.trans.steps.constant.ConstantMeta:

Instruction Change :  + .10%

org.pentaho.di.trans.steps.dbproc.DBProcMeta:

Instruction Change : -.11%

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta:

Branch Change : -.66%
Complexity Change : -.41%
Instruction Change : -.50%
Line Change : -.24%

org.pentaho.di.trans.steps.groupby.GroupByMeta:

Branch Change : -2.08%
Complexity Change : -2.11%

org.pentaho.di.trans.steps.ifnull.IfNullMeta:

Branch Change : -2.00%
Complexity Change : -1.89%
Instruction Change : -.17%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta:

Instruction Change :  + .05%

org.pentaho.di.trans.steps.ivwloader.IngresVectorwiseLoader:

Branch Change :  + .71%
Complexity Change :  + 1.14%
Instruction Change :  + .55%
Line Change :  + .88%

org.pentaho.di.trans.steps.ivwloader.IngresVectorwiseLoader.FifoOpener:

Branch Change :  + 16.67%
Complexity Change :  + 12.50%
Instruction Change :  + 7.14%
Line Change :  + 10.53%
Method Change :  + 20.00%

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta:

Instruction Change :  + .06%

org.pentaho.di.trans.steps.multimerge.MultiMergeJoinMeta:

Instruction Change : -.39%
Line Change : -.68%

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta:

Instruction Change :  + .08%

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta:

Branch Change :  + .91%
Complexity Change :  + .82%

org.pentaho.di.trans.Trans:

Branch Change :  + .10%
Complexity Change :  + .14%
Instruction Change :  + .09%
Line Change :  + .11%

Integration test coverage change:
org.pentaho.di.trans.step.BaseStep:

Branch Change : -.59%
Complexity Change : -.36%
Instruction Change : -.18%
Line Change : -.15%


M29810: Possible wrong description at metadata

Hello, @mattbriggs,
Translator has reported possible source content issue.
"It appears that the two sentences accidentally be merged: "Monitor a test with Azure Stack validation as a service" and "Azure Stack validation as a service known issues.""
Please review and merge the suggested proposed file change to avoid this error. If you make related fix in another PR, then share your PR number, so we can confirm and close this PR.
Many thanks in advance.

@v-maudel : Thanks for your contribution! The author, @mattbriggs, has been notified to review your proposed change.

Thanks @mattbriggs


Code completion shouldn't appear on comments

Consider e.g. the following code
    // yield emits the next value and then
    // returns out of this method.

I'm getting code completion on method.

a dartpad or analysis server issue?

This is a good question. I think the answer is both. DartPad shouldn't be asking and Analysis Server shouldn't be answering.


Change the zip parameters to allow dot files

The previous parameters dropped dofiles and directories starting with a dot. This caused packaging of certain dependencies, namely cryptography, to break. I've tested this fix on a project exhibiting the issue and this has confirmed to have solved the problem. Thanks @ryandub for the
suggestion.

:shipit:


Use arm64 based tools when building stacks on arm64 architecture

Currently, the tools that are used by various dependent stack projects assume amd64 architecture even on arm64 machines. These tools don't work on all arm64 machines so we should use architecture specific versions of these tools.
Possible Solution
All the tools scripts (tools.sh) that are used by stack, builder, and buildpack projects can detect when they are running on an arm64 architecture using the uname -m command. If running on arm64, the tools these scripts download/install should then be the arm64 versions since the arm64 versions of these tools are now available. jam was the last holdout, but since 2.1.1 version that is not the case.
In addition, the stack create script (stack/scripts/create.sh) can use the same architecture detection mechanism and use architecture specific jam command passing in an architecture specific TOML filename. This is necessary since the TOML file contains architecture specific values. When creating the stack on arm64, we can possible rely on a file named stack-arm64.toml to keep it separate from stack.toml which is used to build amd64 architecture images for backwards compatibility.
Possible Side Effects
The stack project will now have to maintain multiple TOML files, one for each architecture. There would be bunch of common content between these TOML files but there would be enough differences to warrant a separate file for each architecture. For example, the Ubuntu Jammy APT repositories are completely different for different architectures. In some cases, the TOML files might need to specify architecture specific APT packages as well.
Another side effect of this change would be that stack artifacts (OCI image archives) produced will always match the architecture they were built on due to the auto-detection of architecture in the create script. This means that simply running scripts/create.sh on a dependent project (like on paketo-buildpacks/jammy-tiny-stack) on an arm64 machine, the resulting image archives would always produce arm64 versions.
Motivation
The amd64 version tools probably work OK on Apple M1 Macs due to Rosetta2 translation layer but won't work on other arm64 machines. All these changes should be backwards compatible and won't effect building amd64 stack image archives on an amd64 machine but would be helpful for the brave amongst us trying to build arm64 artifacts on arm64 machines.
I can submit a PR to get us started on this

Hey @maliksalman thanks for the details on this, we're glad for the support pushing forward ARM64 work!
We will definitely need to make some modifications to our various workflows and scripts to accommodate multi-arch builds, but I am a little bit confused about the ask here.
For stack creation specifically, I imagined that we could use a single stack.toml with platform-specific arguments as added in https://github.com/paketo-buildpacks/jam/pull/211. In the workflows we run to create the stacks via scripts/create.sh, we have the ability to spit out multi-arch stack images. From a project automation perspective, I think things would work as-is for stacks unless I'm missing something.
Is your use-case for utilising these scripts and tools locally on your M1?

I'm also a little confused about the scope of the ask.
I think I see a couple of levels to this request:

the scripts used to build a stack (e.g. tools.sh) should download tools that are specific to the architecture rather than relying on the fact that the host operating system might be able to do instruction translation from x86_64 (e.g. Rosetta on Mac OS).

Sounds good - feel free to submit a PR

Automatically setting the stack platform to match the host when running the create script (and making stack-specific stack.toml files).

I'm not sure about this.
It seems better for the Paketo stacks to be built for all supported architectures, and those architectures encoded in the stack.toml. I think we would want to add arm64 as a supported platform to all stacks' stack.toml files.
For custom stacks that make use of this automation, they can have whatever supported architectures they wish in their stack.toml files.
I'm a bit confused about your comment that the apt repositories would be different for amd64 vs arm64. It's been a while since I built a stack for multiple architectures, but my memory was that it worked just fine. If the URLs were different I would have expected a failure during stack creation.
I don't expect the paketo stacks to have architecture-specific dependencies, so I don't think we need to make stack specific stack.toml files for the Paketo stacks. It's possible that I'm missing something here, as we haven't tried building all stacks (full/base/tiny/static) for the arm architecture.

It would be really helpful if you could show us a concrete example of how the Paketo stacks fail when attempting build multi-arch images (after manually adding arm64 to the platforms in stack.toml).
To be clear, I'm open to the idea of arch-specific stack.toml if we prove the need for it - I just haven't seen the requirement come up yet. You may be the first to encounter it 😄

Sorry, was on vacation last week and didn't get a chance to respond.
@sophiewigmore, the use case is to be able to make it easier to create stacks/builders and run workloads on arm64 hardware with buildpacks that are as close to their amd64 counterparts as possible - other than Apple M1.
@robdimsdale, agreed this is two requests in one. I can create two separate PRs with the tools.sh changes going in first to use platform specific binaries.
On the 2nd point though, even though I agree that we can specify multiple platforms in stack.toml file, there are other values that need to be platform specific. I do think we would need separate stack.toml files, one for each platform. For example:

Trying to run apt update on an arm64 machine while your /etc/apt/sources.list points to

deb http://archive.ubuntu.com/ubuntu jammy main universe multiverse
deb http://archive.ubuntu.com/ubuntu jammy-updates main universe multiverse
deb http://archive.ubuntu.com/ubuntu jammy-security main universe multiverse

will result in errors, with subsequent apt commands no longer functional. On arm64, the contents of that file need to be:
deb http://ports.ubuntu.com/ubuntu-ports jammy main universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports jammy-updates main universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports jammy-security main universe multiverse

Also, if you look at https://github.com/paketo-buildpacks/jammy-full-stack/blob/main/stack/stack.toml - you'll see mentions of a lot of amd64 packages. When building an arm64 version of this stack, those packages would not be appropriate.

No worries @maliksalman .
Did you see this PR: https://github.com/paketo-buildpacks/jammy-tiny-stack/pull/108
It demonstrates how you would get architecture-specific configuration within a single stack.toml file. In short, you can override build/run arguments within a single stack.toml, which is primarily useful for the exact issue you're describing.
This was the mechanism I was thinking of above, but I couldn't find an example of how it works. I think this gives us all the tools we need to separate out architectures within a single stack.toml file. You should be able to either build all architectures for the stack via the single stack.toml, and if that didn't work you could fall back to modifing the stack.toml to only have a single architecture that you are able to build. If you agree with this, then do you also agree that we don't need to have separate handling for architecture within the script?

@robdimsdale, @sophiewigmore, thanks for pointing me to the paketo-buildpacks/jam#211 jam capability and the example in the PR mentioned above. This totally removes the need for architecture specific stack.toml files. I had somehow missed that.
I still think that architecture specific tools are needed in the various tools.sh scripts. This is in cases where these scripts are run on non Apple arm64 machines.

I still think that architecture specific tools are needed in the various tools.sh scripts. This is in cases where these scripts are run on non Apple arm64 machines.

To make sure we're on the same page - this is the idea that the scripts that download jam, pack, jq, etc need to download platform-specific binaries?

To make sure we're on the same page - this is the idea that the scripts that download jam, pack, jq, etc need to download platform-specific binaries?

Yes. Currently, the scripts explicitly downloads amd64 binaries.

Great. I would wholeheartedly welcome a PR to the scripts that download architecture-specific tools. You can constrain it to the stacks if that's all you care about, but at some point we'd want to do this for buildpacks too so there's no harm in you making that change all over this repo.

I will submit a PR shortly. For completeness, I am going to make the change to all tools.sh scripts and not just for stacks.


Find a good way of setting a remote HEAD or dealing with lack of a HEAD

Currently, we don't ever set the remote HEAD. Normally, this is something that's done on the server side - the git client doesn't have a method of setting a remote HEAD.
This isn't a huge issue in terms of usability, but it's nice to have a HEAD so that a branch is automatically checked out after cloning.
It would be good to see if there's any way we can set a remote HEAD or deal gracefully with the lack of a HEAD.
Note: As the code is right now, it is possible to manually create the HEAD file (to point to, say, master), and everything will work as expected.

Just so I understand correctly, there's currently no way to make git clone dropbox://myrepo.git automatically switch to master, right? We have to use one of the following options each time:
git clone dropbox://myrepo.git -b master

git clone dropbox://myrepo.git
cd myrepo
git checkout master

Yes, with the current implementation, that is true.

Got it, thanks

It's mentioned as the last item in this list: https://github.com/anishathalye/git-remote-dropbox#notes
Were you thinking that it should be somewhere else in the readme?

In the first section is written:

To clone repositories in folders or shared folders mounted in your Dropbox, you can run:
git clone "dropbox:///path/to/repo"

This what users are doing.
Why not directly guide to git clone "dropbox:///path/to/repo" -b master?

Sure, sounds reasonable. Updated.

Fixed in #84.


Does not work with Quora

When running FreeYourStuff on Quora, I get the error "Please log into Quora first." even though I am already logged in. Permissions have been granted.

Unfortunately this is a known issue with the Quora plugin. Quora redesigned its feed under the hood a while ago, making it very difficult to parse reliably. I'll take one final stab at trying to get it to work again this weekend, and if that doesn't do it, I'll have to disable Quora support for now. :(

(See #137 for latest update, closing as duplicate)


bump path-to-regexp to 3.3.0

There is a vulnerability in the package path-to-regexp, we use cosmosdb-server in our pipelines which are failing due to this issue.
https://github.com/advisories/GHSA-9wv6-86v2-598j

@ofhouse would you mind checking this out?

@elbasan Thanks for the contribution, released it in 0.15.1 👍

Thank you for releasing it so fast! @ofhouse


Diagnosis button update

It looks like this pr contains a bunch of privacy policy updates? Could you move those to your privacy policy pr #279 instead?
Also, the functionality to include a chevron was already part of the button component - you just need to set the internalLink prop on the button. Please use that instead.

When I used it, the internalLink icon's color is the same color as the button in the design, so that approach will not work here. Hence the need for a custom icon.

When I used it, the internalLink icon's color is the same color as the button in the design, so that approach will not work here. Hence the need for a custom icon.
Okay good point @its-anirudh! You can disregard that part of my review.