Flexible facet

This PR is in preview state. It adds a Google App Engine Flexible facet to the IntelliJ plugin.
The New Project window looks like the following:

Notice that:

Google App Engine Flexible isn't under Web application, like the Google App Engine Standard one. We can put it under Web for more coherence and then move both of them out of Web at the same time.

Ideally, app.yaml and Dockerfile wouldn't be specifiable at New Project time, but template ones would be generated. However, the IJ framework is giving me a hard time to distinguish between addSupport() for New Project and Add Framework Support in order to hide those text boxes, so we should re-think whether it makes sense to configure them in the facet.

The Add Framework Support window looks like this:

Notice that:

We're suggesting the locations of the app.yaml and Dockerfile files to the user, based on where they should be (contentRoot + "/src/main/appengine/app.yaml or Dockerfile"). I left it as a TODO to auto-detect these files, but maybe for another PR.

A deployment run configuration is automatically generated. The deployable is automatically selected, though some testing is required for the case where there is neither a native IJ artifact (the Flexible facet doesn't depend on the Web one) or a Maven one (if project isn't imported as Maven project).

The run configuration editor looks like the following:

Notice that:

There is no Before Launch task. I spent some time looking into this and am convinced that this is an IJ bug. Asked a question on this here.

The app.yaml and Dockerfile locations from the facet were ported here. Path validation and messaging is still lacking but, if any of the paths is invalid, a generated file is used instead.

The service label reflects the service in the app.yaml file, and is updated every time the app.yaml text field changes.

For new deployment run configurations, no suggestions will be made for app.yaml or Dockerfile location. This is because there is no relation between a run configuration and a module, so the facet can't be read. It might be possible to connect both through the artifact (i.e., by assuming the artifact name is the same as the module it belongs to), but that would be normally hairy, especially hairier in the case the artifact is custom made from more than one module. In the latter case, we would want the user to specify their own app.yaml and Dockerfile files.

Still missing in this PR are also:

Adjustments to the Standard Deployment run config UI to remove anything Flexible (to be done in this PR),
Java 8 syntax (to be done in this PR),
Unit tests (to be done in this PR),
Other finer code adjustments to remove appengine-web.xml-based environment discovery logic (i.e., AppEngineProjectService),
Automatic framework detection (out of scope),
app.yaml and Dockerfile creation at New Project time (out of scope, maybe),
Stackdriver Debugger run config creation (out of scope).

@joaoandremartins Screenshots?  Is there an issue we can link this to?

Sorry, should have mentioned this isn't quite ready for a review yet!
I'll add screenshots and assign reviewers once I think it's ready.

@patflynn @etanshaul @aslo I added a new PR description which contains the state of the nation. You can go over the code if you want to get familiar with it, so the actual review won't be so heavy, but there are manifestly still open issues with it. I tried to identify those issues in the description, too.

This is getting in better shape for revision. I think you guys can give it a first pass whenever you want.
Some changes with the latest commits:

Back to only one type of GAE Cloud,
Deployment run config UIs only contain Standard stuff for Standard, and Flexible stuff for Flexible.

Flexible run config:

Standard run config:

Notice that in the Standard UI, we're using checkboxes, and in the Flexible one, radio buttons. Which ones do you prefer?

I'm also trying to kill as much code that handles appengine-web.xml as I can. There is still some left (e.g., compat deployment pings) that might have to stay there.

Looks promising! Taking a look at code and UX right now.
FYI radio-buttons vs checkboxes is for 'pick one of' vs 'select all that apply' respectively.
BTW what does 'override' mean?

this is a 2KLOC PR.  Has some of this been reviewed as PRs into the flex branch?

Yeah... sorry for the size of this. I found it really hard to split this unit among smaller PRs. None of this has been reviewed yet in other PRs. But I can give a quick walkthrough of this in person, if it makes code review any easier.

So I think in the end, I'll go for checkboxes.
Override was the way we had to specify a version name, instead of using the auto generated one. In the Flex deployment, I use the auto generated one if the version field is empty. I'm considering doing the same in the Standard deployment UI.

aha. You need to replicate the 'override' UX that is in the current
deployment run config.
On Fri, Jan 6, 2017 at 11:50 AM, João Martins<EMAIL_ADDRESS>wrote:

So I think in the end, I'll go for checkboxes.
Override was the way we had to specify a version name, instead of using
the auto generated one. In the Flex deployment, I use the auto generated
one if the version field is empty. I'm considering doing the same in the
Standard deployment UI.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-270947120,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HbeIhK7zEUQmg4rC2IvLvyoCH584ks5rPnC4gaJpZM4LRCXN
.

Looking really good! A couple thoughts:

It looks like the "region" label on the flex deployment config editor is missing - that should be included so the user can create their application if necessary before deploying.
Ideally it would be possible to specify an app.yaml without a custom Dockerfile. (i.e. if the user is using runtime: java) but I'm not sure if that's outside the scope of this PR.

@patflynn any reason why Override must be implemented? I was pretty glad to have gotten rid of it :disappointed:
@aslo it is possible to specify an app.yaml without a Dockerfile (and vice-versa). I should probably call out for that in a warning message or so, though.

@joaoandremartins I'm not sure I understand the question. Why wouldn't you have version override?

@patflynn @etanshaul @aslo apart from unit tests, this PR is now ready for review.
I'll still upload some new screenshots tomorrow since some things changed.

@etanshaul @patflynn I'm not expecting this PR to change much now, so you guys can start reviewing whenever you can. Thanks!

Not sure if this is a regression, but I am consistently getting NPE's upon saving the deployment run config (tested using a AE standard project generated using the wizard, selecting a project, giving a custom version, and saving):

That is a regression, and I meant to track it down. I think I found out what triggers it.

Have you noticed this:
Occasionally on deploying standard apps I get a deployment error:

However the app appears to be successfully deployed, and I can see the started version in the web console.

I have found some sporadic deployment issues, but they've all been caused by gcloud app deploy that I know.
I'm not sure about that specific scenario, but it also seems to be the case?
If that's so, there's not much we can do on our side, I think..

Strange scenario:
Open up an AE standard project (that has not yet had any framework support added).
IJ correctly asks you to add framework support via the popup -> Decline this.
Now, right click on the module and click "Add Framework Support". I only see an option for "Google App Engine Flexible". I would have expected "Standard" here.

Follow up to my last post:
I tested this out on master to compare the behavior:
An AE standard app pops up the "Add Framework Support" bubble, but does not have the ability to add framework support manually by right clicking on the module. I think this is a bug.

Yaml or YAML?

When we want to automatically generate app.yaml at add Flexible framework support time, I think we should also think about doing the same for Standard, and allow Standard support to be added without the appengine-web.xml constraint as you suggested.
Something more pressing in my mind is that Standard is a child of Web whereas Flexible is not. But I guess that makes sense, since we don't want to enforce more constraints and it's possible to deploy with Maven?
I'll need to do a global pass for Yaml to swap for YAML, yes.

Regarding flex/standard being a child of Web: its correct that flex is not a child of web as it does not have to be a web project necessarily.
I agree that we would want to auto generate the appengine-web.xml for standard projects and allow adding support without the file present. However, the potential bug I described (which appears to exist in master too) is that even with an appengine-web.xml attempting to manually add App Engine Standard framework support doesn't work because the option isn't there.

Let's file an issue if that bug also exists on master. I've also seen some weirdness with Standard not showing up (or the Web application option, for that matter) in some cases.

While were at it, regarding:

what about saying app.yaml instead of YAML?

Follow up to my last comment:
Even after generating the Dockerfile from the facet editor, the Deployment configuration does not show the Dockerfile.

Another update:
I noticed that the Dockerfile selection was missing because I had "use another YamlFile" checked and had a runtime:java yaml selected.
I think this makes sense, so you can ignore my last two posts.

Bug?

Flex project with a maven deployment source and a native deployment source
app.yaml with runtime:custom and a valid Docker file already exist:

Change the deployment source from Maven to Native. Notice how all of the sudden the Dockerfile field complains that its missing:

I replaced app.yaml by YAML everywhere in captions on purpose, since the configuration file doesn't have to be called app.yaml, can have any name actually.
Yeah, that last one with Dockerfile seems to be an issue. I'll go ahead and prepare a fix right away.

Is this how we should label flex compat in the UI? @patflynn

Flex compat deployment fails due to missing yaml file:

It was just 'App Engine Flexible Environment' before wasn't it?
'Compatible' isn't a quality of the deployment environment.
On Mon, Feb 13, 2017 at 10:51 AM, Etan Shaul<EMAIL_ADDRESS>wrote:

[image: image]
https://cloud.githubusercontent.com/assets/1735744/22890415/47a56efe-f1da-11e6-8582-d4e3209b403f.png
Is this how we should label flex compat in the UI? @patflynn
https://github.com/patflynn
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-279431861,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HXextE39HmI46o3Hfot1zP6JWqLLks5rcHvxgaJpZM4LRCXN
.

@patflynn yeah, previously there was no "compatible" wording

Just to document the offline chat:
We should make standard & flexible framework support mutually exclusive. Currently a user that has a project with standard support can also add flex support - last time we discussed this we decided we should not allow this.

Attempting to deploy a flex app without having first added framework support is not user friendly:

open a flex app - do not add flex support
open the deployment (tools -> deploy)

Notice that the configuration is in error since no yaml is selected. However, the yaml dropdown is empty, module settings is disabled:

Note that you can still select "use another yaml" file which gives the user another path here, however:

This can probably be improved by having a message indicating why the configuration is in its current state (e.g. framework support isn't there); or maybe auto selecting "use another yaml file", or doing both.
selecting "use another yaml" and then browsing to a yaml and a Dockerfile causes a failed deployment:

Regression?
Full deployment details not being shown anymore in the deployment window:
on master:

on this branch:

This was tested on a flex project but should be validated on all kinds.

Possible regression due to updates to region label:

save a valid deployment configuration that has a valid project (one with a region) selected
close it and reopen

on master:
after being initially blank, the following is shown after a slight delay:

on this branch:
this is shown indefinitely unless the user updates the project selector and re-selects the project

Also, I don't know how to consistently repro this, but I occasionally can get the region label in the following state:

Notice the line in the region value, almost as if its getting clipped.

Two random flyby comments:

Don't change the label colors for invalid fields (see that thread about
darcula being messed up)
'Another' is an additive word. 'Override' or something like it would be
better.

On Tue, Feb 14, 2017 at 2:42 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

Regression?
Full deployment details not being shown anymore in the deployment window:
on master:
[image: image]
https://cloud.githubusercontent.com/assets/1735744/22945812/7fdb925a-f2c3-11e6-89d5-a27d40dc8663.png
on this branch:
[image: image]
https://cloud.githubusercontent.com/assets/1735744/22945872/bddd3c20-f2c3-11e6-968d-990d6326539a.png
This was tested on a flex project but should be validated on all kinds.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-279813583,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HQOWDzGUwIvRZg_KQHcvkQiLBAYqks5rcgORgaJpZM4LRCXN
.

runtime changes from "custom" to "java" (and the other way around) don't get reflected immediately:

start with a flex project with a "runtime: custom" app.yaml
open up the deployment config. notice that both app.yaml & dockerfile are shown.
click module settings and notice that both app.yaml & dockerfile are shown.
close the deployment config
update app.yaml to "runtime: java"
open up deploy config again:

notice that Dockerfile is shown still (its disabled, so this is ok?)

click on Module Settings..

Dockerfile is shown and enabled

Click 'ok', and you are taken back to the deploy config:

Notice that its now in a new state.

Click module settings again

Notice this is in a new state too.

This happens changing from "java" to "custom" too. Seems like the change isn't getting effected until clicking "ok" from the facet editor.

Stacktrace on maven source deploy of flex project

import a flex project
select the maven source deployable
deploy:

Thanks a bunch for all the testing, @etanshaul !

Changed the "Flexible Compatible" label to read "App Engine Flexible Environment"
Compat deployments no longer fail with that "YAML is required" error
The deployment without flex facet seems to be mostly working as intended. The only available deployment source is Filesystem WAR or JAR, and you have to specify a YAML file. The dropdown is empty, and I'm now even disabling it. I will also auto-tick the "Use another YAML" checkbox, and show the YAML text box. Let me know if you have any other suggestions for improvements here. I also wonder -- in this case, should we also display the Dockerfile text box? It can get hairy if a YAML containing runtime: java is selected.
I can't reproduce that -- deployment output is always visible to me. Maybe you can show it to me tomorrow?
Region issue was fixed.
I think I've seen this before, and I think I concluded that there was no possible fix here. I'll need to look into into tomorrow again.
Will need to look into this tomorrow.

@patflynn

The PR no longer colours labels to display errors.
I think it was you who suggested replacing Override by something more fluent in english? I don't think another necessarily has additive nature. I prefer this way to Override.

On Tue, Feb 14, 2017 at 6:17 PM, João Martins<EMAIL_ADDRESS>wrote:

Thanks a bunch for all the testing, @etanshaul
https://github.com/etanshaul !

Changed the "Flexible Compatible" label to read "App Engine
Flexible Environment"
Compat deployments no longer fail with that "YAML is required" error
The deployment without flex facet seems to be mostly working as
intended. The only available deployment source is Filesystem WAR or JAR,
and you have to specify a YAML file. The dropdown is empty, and I'm now
even disabling it. I will also auto-tick the "Use another YAML" checkbox,
and show the YAML text box. Let me know if you have any other suggestions
for improvements here. I also wonder -- in this case, should we also
display the Dockerfile text box? It can get hairy if a YAML containing
runtime: java is selected.
I can't reproduce that -- deployment output is always visible to
me. Maybe you can show it to me tomorrow?
Region issue was fixed.
I think I've seen this before, and I think I concluded that there
was no possible fix here. I'll need to look into into tomorrow again.
Will need to look into this tomorrow.

@patflynn https://github.com/patflynn

The PR no longer colours labels to display errors.
I think it was you who suggested replacing Override by something
more fluent in english? I don't think another necessarily has additive
nature. I prefer this way to Override.

If you're going the literate route, 'another' is just not the right
English word to use here, since it can mean 'one more'.  You could change
it to 'Use a different app.yaml'.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-279867860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HaWgtA3fB79XMTBEzFYcLIMymIEtks5rcjYPgaJpZM4LRCXN
.

Wikipedia for the rescue. You're talking about meaning 1, I'm talking about meaning 2.
Though, to be clearer, I'm taking your suggestion for "Use a different".

@joaoandremartins what about the issue of compat deployments containing the jar/war deployment source?

Autoticking the checkbox is a good start. Regarding showing the dockerfile, why not just stick to the pattern of showing it after selecting a yaml file (that has runtime: custom). I was also considering some sort of label to help the user understand why the options are so limited (e.g. the framework support is missing). The other completely different option is to disallow deployments without the framework support at all.

For any other issues you can't reproduce, ping me and I'll attempt it here again.

JAR/WAR no longer showing for compat. That was a regression.
Signaling lack of framework support is something I'm unsure of. I would leave it as a TODO after this PR.
I'm also automatically checking and disabling the Override Dockerfile checkbox, and enabling the Dockerfile text field if there are no module settings.

OK, fixed the flex deployment details (standard/compat deployments were working correctly and still are) and added a cue to the UI, when no GAE supported modules exist.
I can't reproduce the issue where you modify the YAML file from custom to java (and vice-versa). If I change the file, hit Ctrl + S and open the deployment config, Dockerfile stuff will be hidden.

I've also fixed the Maven deployables issue. There was an important underlying issue, nice catch.
I think that sorts out all the identified issues so far, so this PR is ready for another go.

Regarding the issue of modifying the yaml from java to custom, you weren't able to reproduce this using the steps I provided? It seemed to be that the deployment configuration wasn't getting updated until the module settings were opened and saved. But I will test again.

I was able to reproduce the issue if I just replace custom with java, don't save and open the run configuration. Although, in this way, it's not an issue, since the file doesn't get saved until later (likely when the other OK button is pressed)

What do you mean by "save" exactly? In intellij files aren't explicitly saved.

Yeah, they are. Ctrl + S.

https://www.jetbrains.com/help/idea/2016.2/saving-and-reverting-changes.html
are we talking about the same thing?

Could be that since its a not source file, autosave isn't being triggered...

It would be useful to know if by saving the files before opening the deployment run config, you're still seeing the same behaviour.
Also, regarding both Standard and Flex facets at the same time, it's possible to prevent adding support for one if the other already exists. But, for new projects, it gets kinda complicated because, if the user selects both Flexible and Standard, there's not much we can do there. Although I'm going to look deeper into this.

Yes, delayed auto-save is my bet here. I presume that the IJ build process auto-saves source before building it?

I can't find anywhere to interrupt new project creating if Standard and Flexible are selected at the same time.. So I suggest that in case of a tie, Standard wins.
The only other alternative I see is to merge the Flexible and Standard facets in the same one, and have a picker for which environment to choose, though I think we want to do this in another project?

somewhat oddly if I run the tests locally I get 10 test failures:
com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest#testValidateConfiguration_unexistingYaml
seems to be green on jenkins though.

Tests are all passing locally for me too.

@etanshaul @joaoandremartins weird. I'm wondering what's up with my workspace. It seems to be clean but I consistently get these tests failing. @etanshaul have you ran the tests locally?

Out of curiosity, what are some of the errors you're seeing?

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=250m; support was removed in 8.0
com.google.cloud.tools.intellij.debugger.CloudExecutionStackTest >
testGetTopFrame_nullFramesReturnsNull SKIPPED
com.google.cloud.tools.intellij.debugger.CloudExecutionStackTest >
testGetTopFrame_nonNull SKIPPED
com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testUpdateServiceName FAILED
java.lang.RuntimeException
Caused by: java.lang.NullPointerException at
AppEngineFlexibleDeploymentEditorTest.java:130

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testDockerfileSectionToggle FAILED
java.lang.RuntimeException
Caused by: java.lang.NullPointerException at
AppEngineFlexibleDeploymentEditorTest.java:139

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_unexistingYaml FAILED
java.lang.RuntimeException
Caused by: java.lang.NullPointerException at
AppEngineFlexibleDeploymentEditorTest.java:270

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_directoryYaml FAILED
java.lang.RuntimeException
Caused by: java.lang.NullPointerException at
AppEngineFlexibleDeploymentEditorTest.java:284

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_blankDockerfile FAILED
java.lang.RuntimeException
Caused by: junit.framework.AssertionFailedError at
AppEngineFlexibleDeploymentEditorTest.java:302

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_nullDockerfile FAILED
java.lang.RuntimeException
Caused by: junit.framework.AssertionFailedError at
AppEngineFlexibleDeploymentEditorTest.java:314

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_unexistingDockerfile FAILED
java.lang.RuntimeException
Caused by: junit.framework.AssertionFailedError at
AppEngineFlexibleDeploymentEditorTest.java:326

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testValidateConfiguration_directoryDockerfile FAILED
java.lang.RuntimeException
Caused by: junit.framework.AssertionFailedError at
AppEngineFlexibleDeploymentEditorTest.java:341

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testDockerfileOverride FAILED
java.lang.RuntimeException
Caused by: junit.framework.ComparisonFailure at
AppEngineFlexibleDeploymentEditorTest.java:386

com.google.cloud.tools.intellij.appengine.cloud.flexible.AppEngineFlexibleDeploymentEditorTest

testDockerfileStartsDisabledAndWithModuleSetting FAILED
java.lang.RuntimeException
Caused by: junit.framework.ComparisonFailure at
AppEngineFlexibleDeploymentEditorTest.java:399

On Fri, Feb 17, 2017 at 9:46 AM, João Martins<EMAIL_ADDRESS>wrote:

Out of curiosity, what are some of the errors you're seeing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-280668916,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HYe8UAS3s6CcqcG2D6KLPto5oUcUks5rdbLRgaJpZM4LRCXN
.

It seems like either customYaml isn't being created or editor.getYamlTextField() is returning null, sometimes.
Are you sure you have the latest version of the branch?
Do you mind debugging the Flexible editor test and seeing what is null?

Most of the test failures seem to be caused by the fact that AppEngineProjectService is a mock and returning null for getServiceNameFromAppYaml.  Looking at AppEngineFlexibleDeploymentEditorTest it doesn't appear to configure a mock for that service but I haven't looked too closely. Odd that the behavior is different on our machines for some reason.

I'm not using any AppEngineProjectService mocks, at least in AppEngineFlexibleDeploymentEditorTest

app.yaml validation is broken for the no-flex-framework support case:

open a flex project, but do not add flex framework support
create a deploy config, select a jar/war, browse to an app.yaml:

Notice that even though a yaml is selected, the validation is in error.
This doesn't seem to happen when framework support has been added already.

@joaoandremartins I think I'm good with the behavior now from my testing aside from my last comment dealing with missing framework support and validation. I'll do another code review pass now.

Doing second pass of this now.
2 things from the get go. If you haven't already can you:

make sure this is synced with master
make sure the files in the change have all been google java formatted. (you can't rely on our gradle config to check this as it's not working right now).

to google java format you need to ensure that your Other Settings -. G3Plugins Formatter Settings -> google-java-format settings are configured to enable the formatter for all modules.
you also need to run Code -> reformat with google-java-format at least once before 'reformat code' or ctrl+alt+L will use the google-java-formatter.

Cool. I just rebased with master again. I also set the google-java-formatter for all modules as you recommended. Running Reformat with google-java-format on code where I previously used Reformat code is producing the same layout, so I'm guessing this won't be a concern with other bits.
Tests are failing because I wanted to land these changes before you go too deep on your second pass.

@joaoandremartins I don't have further comments on this aside from my unadressed ones as well as Patrick's open comments. Was the bug with yaml validation for no framework support fixed?
I'll keep watch in case the code changes non-trivially.

Also, and I know I'm beating a dead horse here, but doing by doing rebases we lose the nice feature in github where the commits appear chronologically inline with the conversation messages (e.g you can clearly see what was committed after a comment was made).

I'm open to changing the workflow if github PRs work better that way.
On Fri, Feb 24, 2017 at 11:34 AM, Etan Shaul<EMAIL_ADDRESS>wrote:

Also, and I know I'm beating a dead horse here, but doing by doing rebases
we lose the nice feature in github where the commits appear chronologically
inline with the conversation messages (e.g you can clearly see what was
committed after a comment was made).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#issuecomment-282337518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HSFiXEIr9yapEevh9KOxVwer93hCks5rfwaZgaJpZM4LRCXN
.

Comments still appear in chronological order in the code diff view, which is what I use to review the code review.
I'll try to merge next time, how risky that might be doing it from IntelliJ.

comments appear inline (not chronologically) in the code review diff, yes. but thats not what I'm talking about. I meant that in the discussion you can see which commit hashes occurred chronologically with the discussion.

Besides the following open issues, I think I've addressed every comment and concern. @etanshaul the app.yaml fix was pushed, yeah.

Check if AppEngineEnvironment.APP_ENGINE_FLEX_COMPAT is really necessary and refactor if not,
Rename yaml -> appYaml on internal variables and leave UI labels with YAML.

ack. not sure why I was seeing it.
On Fri, Feb 24, 2017 at 2:25 PM, João Martins<EMAIL_ADDRESS>wrote:

@joaoandremartins commented on this pull request.
In gradle.properties
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r103014114
:

@@ -14,7 +14,7 @@

limitations under the License.

-ideaEdition = IC
+ideaEdition = IU
This is no longer in this PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r103014114,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp8QEpiBI00CLBZhCaCjbT45_qvT37qks5rfy7EgaJpZM4LRCXN
.

Sure. On re-read I do get what you are saying. It was just an odd use of
contemplating, and I didn't think of it as if we had another environment.
But I see your angle now.
On Fri, Feb 24, 2017 at 5:01 PM João Martins<EMAIL_ADDRESS>wrote:

@joaoandremartins commented on this pull request.
In
google-cloud-tools-plugin/src/com/google/cloud/tools/intellij/appengine/cloud/AppEngineEnvironment.java
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r103042376
:

@@ -23,7 +23,8 @@
*/
public enum AppEngineEnvironment {
APP_ENGINE_STANDARD("appengine.environment.name.standard"),

APP_ENGINE_FLEX("appengine.environment.name.flexible");

APP_ENGINE_FLEX("appengine.environment.name.flexible"),
APP_ENGINE_FLEX_COMPAT("appengine.environment.name.flexible");

I think my text conveys that in a more Javadoc-friendly manner. Pretty
sure you can say we consider another environment in english.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r103042376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp8QFWyudLk6vnBWwZUqIrosIeeQqLxks5rf1MngaJpZM4LRCXN
.

I'd use app.yaml in the UI as well. All of the public docs refer to it as
that.
On Fri, Feb 24, 2017 at 12:01 PM, João Martins<EMAIL_ADDRESS>wrote:

@joaoandremartins commented on this pull request.
In google-cloud-tools-plugin/src/com/google/cloud/tools/
intellij/appengine/cloud/AppEngineDeploymentConfiguration.java
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r102984772
:

@@ -61,13 +41,14 @@ public String toString() {
private String environment;

private String dockerFilePath;

private String appYamlPath;

private String yamlPath;

I have an issue with asking users to specify an app.yaml file when they
can specify any yaml file that's not called app.yaml.
I can rename the variables and internal stuff to appYaml but keep the UI
as YAML?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1177#discussion_r102984772,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HWeBd1-lkiCVSi1OUmlOvC_L0zVkks5rfwz1gaJpZM4LRCXN
.

Even though I don't think that makes a lot of sense, I changed it externally as well so we can proceed.

@etanshaul @patflynn with the environment and yaml parsing addressed, let me know if there's anything else you want to see here.

no, thats all I had


BUG: modin's df.equals() doesn't treat nans as equal like pandas

System information
Modin Version: 0.12.0
Ray 1.7.1
python 3.9.7
Describe the problem
>>> df = modin_pd.DataFrame({"d": [389.0, 24.0, 80.5, None]})
UserWarning: Distributing <class 'dict'> object. This may take some time.
>>> df.equals(df)
False

Pandas returns true
>>> df = pandas_pd.DataFrame({"d": [389.0, 24.0, 80.5, None]})
>>> df.equals(df)
True

@c3-cjazra thanks so much for reporting this! The problem appears to be the None. I can reproduce with just:
import pandas
import modin.pandas as pd

pdf = pandas.DataFrame([[None]])
# This gives True
print(pdf.equals(pdf))

df = pd.DataFrame([[None]])
print(df.equals(df))

Fixed in https://github.com/modin-project/modin/pull/6270.


bug: updating a component with the CLI does not remove files that are deleted upstream

Current Behavior
right now, when updating the Select component from a version < #500 to a version >= #500 with the CLI results in a leftover select.svelte.
this file was removed in #500 but the CLI only add or modifies files so it's still present after upgrading, which can be confusing (especially if it causes linting issues like it did for me in #528)
Expected Behavior
the select.svelte file should not remain after updating the Select component
More Information
I think the most reasonable option is to delete all files in a component folder before writing the new version there.
there is already a disclaimer that any potential modifications will be overwritten and the one should use source control.
so I don't think there is any additional risks with clearing the component folder before writing to it. instead I think it will lead to less confusion and fewer surprises

if you agree, I can attempt to work on this

Hmm, this is something I'm not 100% sure if we want to wipe the entire directory out with, even files that we don't control, but if not, we'd basically need a way to track the previous and current versions to determine if a file was deleted.
It should be very very rare that something is deleted from the original, in the case of the Select it wasn't necessary to include it in the first place, and was an oversight on my end.
I'll see if @AdrianGonz97 has any thoughts on this one, but my gut tells me we should not blow out the entire directory!

I'm not really comfortable deleting the whole folder as there may be additional files in there that we may not even own.. Honestly, I don't think any action is really necessary and we should just let the user handle it on their own.

Closing as not planned for now!


I cannot start the service

After "sudo systemctl start berry-share"
$ sudo systemctl status berry-share
● berry-share.service - BerryShare service
Loaded: loaded (/etc/systemd/system/berry-share.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Wed 2022-05-11 12:59:39 CEST; 24s ago
Process: 7086 ExecStart=/usr/bin/berry-share (code=killed, signal=ILL)
Main PID: 7086 (code=killed, signal=ILL)
CPU: 201ms
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 5.
May 11 12:59:39 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Start request repeated too quickly.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:39 raspberrypi systemd[1]: Failed to start BerryShare service.
$ journalctl -u berry-share
May 11 12:59:36 raspberrypi systemd[1]: Started BerryShare service.
May 11 12:59:36 raspberrypi systemd[1]: berry-share.service: Main process exited, code=killed, status=4/ILL
May 11 12:59:36 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:37 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 1.
May 11 12:59:37 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:37 raspberrypi systemd[1]: Started BerryShare service.
May 11 12:59:37 raspberrypi systemd[1]: berry-share.service: Main process exited, code=killed, status=4/ILL
May 11 12:59:37 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:37 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 2.
May 11 12:59:37 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:37 raspberrypi systemd[1]: Started BerryShare service.
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Main process exited, code=killed, status=4/ILL
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 3.
May 11 12:59:38 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:38 raspberrypi systemd[1]: Started BerryShare service.
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Main process exited, code=killed, status=4/ILL
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:38 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 4.
May 11 12:59:38 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:38 raspberrypi systemd[1]: Started BerryShare service.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Main process exited, code=killed, status=4/ILL
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 5.
May 11 12:59:39 raspberrypi systemd[1]: Stopped BerryShare service.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Start request repeated too quickly.
May 11 12:59:39 raspberrypi systemd[1]: berry-share.service: Failed with result 'signal'.
May 11 12:59:39 raspberrypi systemd[1]: Failed to start BerryShare service.

Similar issue: service failed to start
$ journalctl -u berry-share
gives:
févr. 19 09:22:09 raspberrypi systemd[1]: Started BerryShare service.
févr. 19 09:22:10 raspberrypi berry-share[6515]: /usr/bin/berry-share: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Main process exited, code=exited, status=127/n/a
févr. 19 09:22:10 raspberrypi berry-share[6516]: /usr/bin/berry-share: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:10 raspberrypi berry-share[6517]: /usr/bin/berry-share: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 1.
févr. 19 09:22:10 raspberrypi berry-share[6518]: /usr/bin/berry-share: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
févr. 19 09:22:09 raspberrypi systemd[1]: Stopped BerryShare service.
févr. 19 09:22:10 raspberrypi berry-share[6519]: /usr/bin/berry-share: error while loading shared libraries: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory
févr. 19 09:22:09 raspberrypi systemd[1]: Started BerryShare service.
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Main process exited, code=exited, status=127/n/a
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 2.
févr. 19 09:22:09 raspberrypi systemd[1]: Stopped BerryShare service.
févr. 19 09:22:09 raspberrypi systemd[1]: Started BerryShare service.
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Main process exited, code=exited, status=127/n/a
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 3.
févr. 19 09:22:09 raspberrypi systemd[1]: Stopped BerryShare service.
févr. 19 09:22:09 raspberrypi systemd[1]: Started BerryShare service.
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Main process exited, code=exited, status=127/n/a
févr. 19 09:22:09 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 4.
févr. 19 09:22:10 raspberrypi systemd[1]: Stopped BerryShare service.
févr. 19 09:22:10 raspberrypi systemd[1]: Started BerryShare service.
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Main process exited, code=exited, status=127/n/a
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Scheduled restart job, restart counter is at 5.
févr. 19 09:22:10 raspberrypi systemd[1]: Stopped BerryShare service.
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Start request repeated too quickly.
févr. 19 09:22:10 raspberrypi systemd[1]: berry-share.service: Failed with result 'exit-code'.
févr. 19 09:22:10 raspberrypi systemd[1]: Failed to start BerryShare service.
It seems that library libboost_system.so.1.67.0 is missing..
I've tried several manner to solve this:
$ sudo apt install libboost-all-dev
-> still the error
$ ln -s usr/lib/aarch64-linux-gnu/libboost_system.so.1.74.0 usr/lib/libboost_system.so.1.67.0
-> still the error
Please provide a turnaround.. thanks!


Socks encoder/decoder do not always follow RFC regarding port

Expected behavior
According to RFC1918 regarding Socks5 proxy protocol, destination port must be represented in network byte order. I didn't find a similar information for Socks4 proxy implementations but I would think the requirement is the same (and it seems that OpenJDK socks implementation follow that convention as well: https://github.com/openjdk/jdk/blob/5cd8af7622a93afb32f5f3fccdc453096992453c/test/jdk/java/net/Socks/SocksServer.java#L200)
Netty implementation should also obey the requirement, independently of the buffer internal order
Actual behavior
When an application uses byte buffers with little endian order, Netty socks encoder/decoder do not write the port information correctly, resulting in refused connection for example.
Steps to reproduce
0/ Setup a socks proxy (using ssh -D or mitmproxy)
1/ Write a small pipeline to connect to a remote system with a socks proxy handler
2/ Configure the pipeline to use an allocator to generate LE byte buffers
3/ Try and attempt to connect to the remote system
Minimal yet complete reproducer code (or URL to code)
Netty version
4.1.89
JVM version (e.g. java -version)
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment Temurin-11.0.18+10 (build 11.0.18+10)
OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (build 11.0.18+10, mixed mode)

OS version (e.g. uname -a)
Darwin  xxx.local 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:19 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6020 arm64

We love PRs

And I love writing them :) I guess I'm trying to understand the existing unit tests used here and how I can create an EmbeddedChannel with the proper byte buffer ordering (Advice welcome)


Disable compression and enhance ciphers

Hi everyone :)
For a hardened OpenVPN configuration, compression should be disabled (as stated by an OpenVPN current developper) : https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91#issuecomment-75388575

Sorry for the typo in the second commit title... ^^

For more informations : https://bettercrypto.org/static/applied-crypto-hardening.pdf

I'm okay with disabling comp-lzo, but the commtt is not complete : you forgot the client conf (https://github.com/Angristan/OpenVPN-install/blob/master/openvpn-install.sh#L427)
For the ciphers : I don't see why this is an improvement ^^ This is made to force the use of this unique cipher I put on each mode

Nailed it for client-side compression, thanks :)
Concerning the cipher list, It is only to prevent any otential downgrade or loss of connection in case of whatever could happen with only one cipher available :)

Concerning the cipher list, It is only to prevent any otential downgrade or loss of connection in case of whatever could happen with only one cipher available :)

Are you sure about that ? The cipher is included in the client and in the server conf !
Or we can do that : AES-GCM/AES-CBC/CAMELLIA 256 bits for "slow" and AES-GCM/AES-CBC/CAMELLIA 128 bits for "fast"
Note you're using depreciated cipher (OpenVPN < 2.3.3)

i.e. :
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA for "fast" and
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA for "slow"

After re-reading the hardening openVPN Wiki page, I think my reasoning was wrong : https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher
"It's wise to use as small of a list as possible for your --tls-cipher option. Exceptions could include if you wish to provide the client their choice of several acceptable options."
My bad.
Also, do you want me to work on adding tls-auth ? (https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth)

Okay, no problem !
Why not, but I don't really understand what it adds :/


API Docs Update

This pull request has as an objective updating all the API documentation of poliastro project, including:

[x] Menu based on modules
[x] Latex Formulas, to see clearly equations behind the functions
[x] Examples, so users can check the power of poliastro
[x] More references and notes

Formatting edits by @Juanlu001

Thanks a lot for the pull request @IngenieroDeAviones! There are some minor PEP8 failures, you can check them by clicking the Circle CI report:
https://circleci.com/gh/poliastro/poliastro/1006
Also, is this finished or do you intend to add more commits to it?

The test failures now are because of the doctests, for example https://circleci.com/gh/poliastro/poliastro/1014

The main challenge now will be to rebase it on current master, because after the Black restyling there are lots of merge conflicts. I will lend a hand with that when you're done pushing @IngenieroDeAviones :muscle:

I finally added more information on NEOs and also Orbit module. Waiting for your suggestions and code review @Juanlu001 :smile:

Wohooooooo merging! :tada: It took a while but I was so excited about the results. Great job @IngenieroDeAviones, looking forward to collaborating in the future :wink:


Unable to read in DWG after updating ACadSharp

Hello,
In version 2.2.0-beta of ACadSharp I am able to successfully read in the attached DWG file.
Milborne.zip
However after updating ACadSharp to version 2.3.1-beta I now receive the following error when trying to read in the same DWG file:

Kind regards,
Luke

Hi @Lukeor,
It seems to be an issue regarding on how the CadDictionary handles the new NonGraphicalObject.
I'm creating a PR now.
Thanks for reporting the issue!


Auth to filter and header

Problem Description
Fixes #18
Solution
Migrated the current Token handling to use the JAX-RS SecurityContext system for better future integration.
Setup support for automated tests.
how you tested the change
In progress:

Initial integration of the test extension created for https://github.com/opendcs/opendcs

There's a few things I need to cleanup in the extension to better support downstream use.

Create handful of tests that require authorization and use RestAssured library to verify things actually work.

Where the following done:

[ ] Tests. Check all that apply:

[ ] Unit tests created or modified that run during ant test.
[ ] Integration tests created or modified that run during integration testing
(Formerly called regression tests.)
[ ] Test procedure descriptions for manual testing

[ ] Was relevant documentation updated?
[ ] Were relevant config element (e.g. XML data) updated as appropriate

If you aren't sure leave unchecked and we will help guide you to want needs changing where.

NOTE: the stage directory will be removed before final merge. They are left in at present to make it easier for anyone to test the branch.
The 7.0.10 opendcs-test-extension will need to be manually push to you're local maven repo with
ant -Dno.docs=true -Dopendcs.test.engine=OpenDCS-XML release (ignore the gpg.key.id mesage)
and
mvn org.apache.maven.plugins:maven-install-plugin:3.1.1:install-file -Dfile=build/lib/opendcs.jar -DpomFile=build/lib/opendcs.pom
mvn org.apache.maven.plugins:maven-install-plugin:3.1.1:install-file -Dfile=build/lib/opendcs-test-extension.jar -DpomFile=build/lib/opendcs-test-extension.pom


The mux-input plugin crashed: Invalid credentials

Hi,
I get the error message that the mux-input plugin crashed and that the credentials are invalid.

I have created a new access token in my Mux dashboard. How can I set my new generated access token? I already tried to remove the sanity-plugin-mux-input and install it again but it doesn't work. Basically, I want to popup this window:

I use:

"next-sanity": "^5.1.1"
"sanity-plugin-mux-input": "^2.1.1"

Cheers

Is there not a way to clear credentials so we can apply new ones?


Bump go to latest to address CVE-2023-39325

Pull Request Motivation
NB: We're not particularly concerned about the effects of this CVE on cert-manager, but want to address it (and fix our security scanners 😁 )
Kind
/kind cleanup
Release Note
Bump go to 1.21.3 to address CVE-2023-39325. Also bumps base images.

/hold
Want to check something first!

/approve
/lgtm

/unhold
Checks complete! I'll raise manual backports for 1.13 and 1.12 since they use go 1.20.x


Bluetooth: Host: fix host misconfiguration dependencies

Commit fixes usage of sc_indicate function.
Declaration and implementation have different
KConfig option dependencies.

I suggest:

I created a fix variation with most of the ifdefs removed: https://github.com/zephyrproject-rtos/zephyr/pull/65242
I'm waiting to see if the CI passes it.

@alwa-nordic created PR with the better solution. I closed mine.


Improve formatting of examples in intrinsics section

At https://fortran-lang.org/learn/intrinsics/array/#merge there is code
   write(*,*)merge (1.0, 0.0, k > 0)
   k=-2
   write(*,*)merge (1.0, 0.0, k > 0)

I think there should be a space after write(*,*) and should not be a space between a function name and its arguments, so the code should be
   write(*,*) merge(1.0, 0.0, k > 0)
   k = -2
   write(*,*) merge(1.0, 0.0, k > 0)

I think there should be spaces around equal signs but not just after opening brackets or just before closing brackets, so that
   tvals(1,:)=[  10, -60,  50 ]
   tvals(2,:)=[ -20,  40, -60 ]

becomes
   tvals(1,:) = [10, -60,  50]
   tvals(2,:) = [-20,  40, -60]

Ideally all code would be run through an auto-formatter to achieve this instead of having us fiddle with the code manually.

i would like to work on this issue please assign this to me @Beliavsky


Default/fallback route

Is there a way to have a default route?

Absolutely! The default route can be done as a combination of wildcard modifiers e.g. /:foo* and a Switch component (which was released in the latest version v1.2.0).
I put together this demo, hope it helps!
https://codesandbox.io/s/oqk302k2y


[BUG] Global tenant still enabled despite setting to disabled

Describe the bug
We're running opendistroforelasticsearch-kibana v1.13.2, and have set the following in kibana.yml.
opendistro_security.multitenancy.tenants.enable_global: false
opendistro_security.multitenancy.tenants.enable_private: false
This was working fine on version 1.11. Global tenant was disabled, inaccessible to everyone.
We recently updated to 1.13.2 and this is no longer working as expected. After a brief period, Kibana will reload, switching us back to the global tenant.
To Reproduce
Steps to reproduce the behavior:

Log into Kibana in any tenant
Browse for a while, leave idle ~10 minutes
Return to Kibana, user is still logged in but tenant has been set to global_tenant despite the fact that that is disabled in the config

Expected behavior
Kibana stays in the tenant you were originally in and global_tenant remains disabled.
Plugins
opendistro-alerting
opendistro-anomaly-detection
opendistro-asynchronous-search
opendistro-index-management
opendistro-job-scheduler
opendistro-knn
opendistro-performance-analyzer
opendistro-reports-scheduler
opendistro-sql
opendistro_security
repository-s3

Host/Environment (please complete the following information):

OS: Ubuntu

opendistro-alerting <IP_ADDRESS>-1
opendistro-anomaly-detection <IP_ADDRESS>-1
opendistro-asynchronous-search <IP_ADDRESS>-1
opendistro-index-management <IP_ADDRESS>-1
opendistro-job-scheduler <IP_ADDRESS>-1
opendistro-knn <IP_ADDRESS>-1
opendistro-knnlib <IP_ADDRESS>
opendistro-performance-analyzer <IP_ADDRESS>-1
opendistro-reports-scheduler <IP_ADDRESS>-1
opendistro-security <IP_ADDRESS>-1
opendistro-sql <IP_ADDRESS>-1
opendistroforelasticsearch 1.13.2-1
opendistroforelasticsearch-kibana 1.13.2

@CEHENKLE or @nknize is the security-plugin issue queue the right place for this?

i thought about that but wasn't sure. i can recreate if so.

i thought about that but wasn't sure. i can recreate if so.

@shortstack if you don't mind let's recreate it here: https://github.com/opensearch-project/security/issues

Hi, the issue might belong to Security Dashboards Plugin.
I noticed some similar issues were also there, such as https://github.com/opensearch-project/security-dashboards-plugin/issues/727 and https://github.com/opensearch-project/security-dashboards-plugin/issues/779.
In addition, we can help transfer the issue to the target repository, so creating a new issue is not necessary. 😄

@tlfeng that would be great, thank you!

@tlfeng do i need to do something to have it transferred?

@shortstack Sorry for the delay. I will ask the admin to transfer the issue.


Migration Guide

Added Migration Guide file, plus scrubbing the old VideoKeypair object

Forcing through, bumping that version has knockon effects. Will deal with security problem asap.


old web: fix backspace issue in input

Fixes TLON-2600
Turns out this was caused by a version mismatch for prosemirror-state that was causing the history plugin in tiptap not to load/work.
Tested to make sure everything still works w/the mobile input and in the new app, all works fine.

The type check fail issue is weird. pnpm -r tsc runs fine locally. Looking into it.

Ok, this seems to be the right incantation. Everything works in local testing, no more tsc fails.


FAQ RAT new entries

Internal Tracking ID: EXPOSUREAPP-6914

I would suggest changing the style of the new FAQ entries to directly address the user. Unfortunately the last changes have now introduced inconsistencies.
In the blogs it is appropriate to describe new features applying to the third person (i.e. users), in the FAQs we should expect individual users to be looking for answers to their issues, so users should be addressed directly (i.e. you).

As @MikeMcC399 suggests: directly address the user.
@DerVogel2020 Sorry, this reverts your PR.


Fix a typo in az CLI queue creation command

Wrong quote/char in queue name made the command fail in az CLI

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

#sign-off


what's purpuse of nll_loss?

❓ Questions and Help
What is your question?
loss_sum / sample_size is the average loss for each token.
what about loss_sum / ntokens
Code
https://github.com/pytorch/fairseq/blob/adbd89fd4be9e68100bf9a4ba9eed1e7fb2e4040/fairseq/criterions/sentence_prediction.py#L80-L83

If you have --sentence-avg then the loss will be normalized by the number of sentences.  In that case you may still want the token-level NLL loss, so we log that as an extra key :)


Compiler Warnings

It would be good to have compiler warnings for at least the following cases:

[x] incomplete pattern matches
[ ] variable shadowing
[x] missing top-level type signatures
[x] unused imports

If you were watching #829, follow this issue instead.

Just thought i'd give a :+1: to non-exhaustive pattern matches resulting in a compiler error! I just spent about an hour trying to determine the source of some strange runtime behaviour and it turned out to be two missing branches :bomb:
Also thought I'd mention Rust gives a compiler error for this also, has saved my feet from bullets many a time :dancer: :gun:

I'd also like compiler warnings for unused imports, and maybe unused variables/functions.

Yes, this would be great. Sometimes I remove import after import manually to check with every step if it compiles, but sometimes I just do not have the nerves to do this. It gets especially tedious when it's not about whole modules but about a list of single function imported from a module.

:+1: to unused imports :)

Just lost a couple hours to an error before realising it was #829 :tired_face:  just thought I'd give this a bump!

This would be really, really, really, really nice.  It's the single biggest issue I have with Elm right now that isn't a bug.

There have been discussions on the mailing list, and the general consensus is to eliminate as many runtime errors as reasonably possible.
Like JavaScript, division by zero results in Infinity.

The compiler now has nice support for warnings throughout all phases, so adding this stuff is much more plausible. I have "unused imports" working, and we are working on "incomplete pattern matches" in #930

Another case for warning messages is shadowing using case expressions. From #948:
import Graphics.Element exposing (show)

type Foo = Bar Int
whatever = Bar 7

main = show <| case Bar 5 of
  Bar 3 -> "nope"
  whatever -> "hooray!"
  _ -> "something else"

This is always "hooray!" because whatever is a constraint-free identifier and not equal to Bar 7.

+1 to exhaustive pattern matching enforcement.

Alright, this is mostly done, so I am migrating us to #1018 which is about the specific warning that still needs to be done.

@evancz, how about unused assignments? For example if let defines a value, which is never used in the in.


Update bots-guide.md

Added an additional instruction to "How to run a bot", suggesting that the user should create a help bot.

@theairportexplorer I think this merge conflicts with some of the other doc changes we merged to this file today; can you rebase?  Thanks!


GSE237204 - RetinaEvolutionHumanHahn

part of Retina Atlas v1.0
Project short name:
RetinaEvolutionHumanHahn
Primary Wrangler:
Ida
Secondary Wrangler:
Arsenios

Associated files

Google Drive: folder
ingest: c3dd819d-abab-4957-b209-88f1e0900368

Published study links

Paper: Evolution of neuronal cell classes and types in the vertebrate retina
Accessioned data: GSE237204 - human data

Key Events

[ ] Convert published metadata to HCA spreadsheet
[ ] Manually curate dataset to meet HCA metadata standard
[ ] Collect any matrix and cell-type annotation files
[ ] Are the analysis files suitable for CellxGene? If something is missing get in touch with the authors to request it
[ ] Upload sheet to validate metadata
[ ] Transfer raw files to ingest to validate data files
[ ] Check linking using ingest graph validator
[ ] Ask the Secondary Wrangler for an end-to-end review of the project. Ask the Expertise Wrangler to review specific tabs if needed
[ ] Submit dataset to Production
[ ] Complete the Export SOP
[ ] Convert project data to SCEA format following the SCEA conversion SOP if appropriate

I didn't find any donor metadata, the only metadata available is about samples here
About sample Hu218OSmAll - the sample key says it's mac_neun-_218 but this sample is absent in extended data Fig1 - instead there is mac_all_218
I think mac_neun-_218 is a mistake and the sample is not enriched

Hi Ida! There were very limited metadata available but you've done a nice job.
I only have two suggestions and one comment.
Project

abstract you can remove the reference numbers

Analysis protocol

intron_inclusion you could fill yes here

To include both exonic and intronic reads in the quantification of gene expression for each sample, regardless of cellular or nuclear origin, we applied velocyto to the corresponding.bam files. This generated two separate gene expression matrices (GEMs) (genes × cells) for each sample, corresponding to ‘spliced’ and ‘unspliced’ reads.

Analysis file

input biomaterials Each of the 4 files, should have different input. If you open the count matrices the cell index includes the sample_ID. I've removed the UMI and the duplicates

sample_id extraction
for file in GSE237204*; do echo $file; zcat < $file | head -1 | sed 's/\,/\n/g' | sed 's/.\{18\}$//' | sort | uniq; done

GSE237204_Human_count_mat_1.csv.gz

Hu032616OD_macula_NeuNPos.possorted_genome_bam_PNH7N
Hu035516OS_macula_NeuNPosS1.possorted_genome_bam_TXN7J
Hu035516OS_macula_NeuNPosS2.possorted_genome_bam_D2QGV
Hu035516OS_macula_NeuNPosS2.possorted_genome_bam_PNH7N
Hu056316OD_macula_NeuNPos.possorted_genome_bam_M7UFG
Hu056416OS_macula_NeuNPos.possorted_genome_bam_RCC8P
Hu082219_macular_All.possorted_genome_bam_M28FQ
Hu086916OD_macula_NeuNPos.possorted_genome_bam_VL2TA

GSE237204_Human_count_mat_2.csv.gz

Hu086916OD_macula_NeuNPos.possorted_genome_bam_VL2TA
Hu088716OS_macula_NeuNPos.possorted_genome_bam_2L1A9
Hu105916OD_macula_NeuNPos.possorted_genome_bam_C9Z7N
Hu218OSPeriRetina.possorted_genome_bam_WYD8B
Hu218OSmAll.possorted_genome_bam_DGNOI
Hu218OSmRGC.possorted_genome_bam_Q49J3

GSE237204_Human_count_mat_3.csv.gz

Hu218OSPeriRetina.possorted_genome_bam_WYD8B
Hu220235OSmAll.possorted_genome_bam_V6O4A
Hu220OSPeriRetina.possorted_genome_bam_L340L
Hu220OSmRGC.possorted_genome_bam_Z9VX3
Hu235OSPeriRetina.possorted_genome_bam_3URIL
Hu235OSmRGC.possorted_genome_bam_W3LJK
HuCMixS1.possorted_genome_bam_B7X1A

GSE237204_Human_count_mat_4.csv.gz

HuCMixS1.possorted_genome_bam_B7X1A
HuCMixS2.possorted_genome_bam_HGXY1
HuPRet1059fc564mc.possorted_genome_bam_56BDZ
HuPRet326mc355fc.possorted_genome_bam_RJJ6M
HuPRet563mc.possorted_genome_bam_PYRF4
HuPRet887mc869fc.possorted_genome_bam_CHBYN

CS assignment
GSE237204_Human_count_mat_1.csv.gz -> Hu032616OD_macula_NeuNPos||Hu035516OS_macula_NeuNPosS1||Hu035516OS_macula_NeuNPosS2||Hu056316OD_macula_NeuNPos||Hu056416OS_macula_NeuNPos||Hu082219_macular_All||Hu086916OD_macula_NeuNPos
GSE237204_Human_count_mat_2.csv.gz -> Hu086916OD_macula_NeuNPos||Hu088716OS_macula_NeuNPos||Hu105916OD_macula_NeuNPos||Hu218OSPeriRetina||Hu218OSmAll||Hu218OSmRGC
GSE237204_Human_count_mat_3.csv.gz -> Hu218OSPeriRetina||Hu220235OSmAll||Hu220OSPeriRetina||Hu220OSmRGC||Hu235OSPeriRetina||Hu235OSmRGC||HuCMixS1
GSE237204_Human_count_mat_4.csv.gz -> HuCMixS1||HuCMixS2||HuPRet1059fc564mc||HuPRet326mc355fc||HuPRet563mc||HuPRet887mc869fc

fixed the issues and tried to export but the dataset is stuck on export

Enrique restarted the export and it worked - I've filled in the import form

verified in the browser


fix(iOS): present mail and SMS composers in main thread

I noticed also happened on the SMS composer, so fixed both
Closes #1078

Perfect, thanks buddy!


[incubator/kubeless] Update kubeless v1.0.0-alpha.3

What this PR does / why we need it: Update Kubeless version
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer: cc/ @prydonius @carrodher

/ok-to-test


my orders keeping returning 405

Hi There,
Kind assist.
I am trying to test out new version of cert-manager 0.14.1 on my eks cluster, but when I request for a new certificate I get error 405 method not allowed.
Below is the proceed, I use to configure my cert-manager:
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager-legacy.crds.yaml
helm install --name cert-manager --namespace cert-manager --version v0.14.1 --set installCRDs=true --set ingressShim.defaultACMEChallengeType=dns01 --set
ingressShim.defaultACMEDNS01ChallengeProvider=route53 --set ingressShim.defaultIssuerName=letsencrypt-prod --set ingressShim.defaultIssuerKind=ClusterIssuer jetstack/cert-manager
--debug
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email<EMAIL_ADDRESS>    privateKeySecretRef:
      name: letsencrypt-staging
    dns01:
      providers:
      - name: route53
        route53:
          region: us-east-1
          hostedZoneID: ZNJUMGR6D1VXL4
          accessKeyID: C34567866877795PW
          secretAccessKeySecretRef:
            name: cert-manager-route53
            key: secret-access-key
---
# Source: cert-manager/app-testing/Certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: selfsigned-cert-dev
  namespace: app-testing
spec:
  dnsNames:
    - dev.example.net
  secretName: selfsigned-cert-tls-dev
  duration: 24h
  renewBefore: 12h
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

Error below:
{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Method not allowed",
  "status": 405
}

Environment details::

Kubernetes version : v1.14.9
Cloud-provider/provisioner: AWS EKS
cert-manager version: v0.14.1
Install method: helm

/kind bug

/triage needs-information
Can you get us a kubectl describe of the order and challenge resources?

Get the same with cert manager 1.2, kubernetes 1.20.4, Minikube with virtualbox on MacOS:
Order:
Name:         keycloak-internal-secret-tpgd6-2128746746
Namespace:    default
Labels:       <none>
Annotations:  acme.cert-manager.io/http01-override-ingress-name: keycloak-internal-ingress
              cert-manager.io/certificate-name: keycloak-internal-secret
              cert-manager.io/certificate-revision: 1
              cert-manager.io/issue-temporary-certificate: true
              cert-manager.io/private-key-secret-name: keycloak-internal-secret-nqdph
API Version:  acme.cert-manager.io/v1
Kind:         Order
Metadata:
  Creation Timestamp:  2021-03-17T11:36:54Z
  Generation:          1
  Managed Fields:
    API Version:  acme.cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:acme.cert-manager.io/http01-override-ingress-name:
          f:cert-manager.io/certificate-name:
          f:cert-manager.io/certificate-revision:
          f:cert-manager.io/issue-temporary-certificate:
          f:cert-manager.io/private-key-secret-name:
        f:ownerReferences:
          .:
          k:{"uid":"b496faa7-3cd5-4d08-a71d-d041b12ce0ac"}:
            .:
            f:apiVersion:
            f:blockOwnerDeletion:
            f:controller:
            f:kind:
            f:name:
            f:uid:
      f:spec:
        .:
        f:dnsNames:
        f:issuerRef:
          .:
          f:group:
          f:kind:
          f:name:
        f:request:
      f:status:
        .:
        f:authorizations:
        f:finalizeURL:
        f:state:
        f:url:
    Manager:    controller
    Operation:  Update
    Time:       2021-03-17T11:36:55Z
  Owner References:
    API Version:           cert-manager.io/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  CertificateRequest
    Name:                  keycloak-internal-secret-tpgd6
    UID:                   b496faa7-3cd5-4d08-a71d-d041b12ce0ac
  Resource Version:        23075
  UID:                     e49060e1-a279-431c-b1b1-ae540f040630
Spec:
  Dns Names:
    keycloak-internal.<IP_ADDRESS>.nip.io
  Issuer Ref:
    Group:  cert-manager.io
    Kind:   ClusterIssuer
    Name:   letsencrypt-staging
  Request:  LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2x6Q0NBWDhDQVFBd0FEQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUxZdwplQnMwU1BBV1A1RU5ZdFY1M1ljVm5qM3V3dFQ2NklWRUtQTTJvbjA4OUFDZDZkYkdEZm52cUc1Rm1wUnJ3NFJQCml2Smo3Y254MjNRVUpzM05sZU1zdG44bTdlT1cwTTZXNkdwL2cyQ2dyaUFNbmdISEFwRCs5MVlYN3NHMDgrdVEKWmdsSUVTSWR0T0hYTGdOa25SYUdmVzJ1Z1pHZDMvcFRPdHZUSk9NQW1hWkJqbk5LdGtKMUo3bG5zQ25hTmFQVwpjbElaZE1yeVZIQ2FmUC91ZWpZVVM4WnZlTkcvYXlicWgwMG5lSFBFcGZqbnhLTy8zOTV1b3JoN1JXc091TTU1ClBNOWRCUHkrTVppcng2TklpOGdUb3M2Q0VxZWtuR3BlNmR1cVZFV0wwMUROV1RrVzU4RHZNMEJ1RjdReXN6QmoKNFRyY1JnTTBCUU45a0hIYTBiOENBd0VBQWFCU01GQUdDU3FHU0liM0RRRUpEakZETUVFd01nWURWUjBSQkNzdwpLWUluYTJWNVkyeHZZV3N0YVc1MFpYSnVZV3d1TVRreUxqRTJPQzQ1T1M0eE1EQXVibWx3TG1sdk1Bc0dBMVVkCkR3UUVBd0lGb0RBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQWRMWkc4Q29aQ2J3ZzdBVG1odC9HdVJoN0MreG4KMytveVBHYWpaSmRDM0Z6VTZQWlh6K1FGczZ1V2F5SzVYSlArcHdKUTlWeUZPL01TVm9TZnAyWDgxckdIRGY2VQpwWStFMCtYQzB5cWNyRFJPcWFaSmxOVWt6ODJNOTJUK0xvNnZDMGFkeWthcHBuUjc5NTVrN0hOMnRNSWpJUVVFClM4Z3E5a1RrbjBxNSt1SDBCMGtjdUtVeGlXUTlUZkdoVTVpRU9EcHdxV09pN2lGSzBQTktNVHhDaTZ6dmtZdkgKZHZ3NzlkbkF2djhOekNoYmxSUEdscXhVVUN1OEdlU01QN1lVOTlGRjBpa05oRXdmcGV3TktWRW8vN1F6UzI0bQpRdFUzSWxLbGVSN2Z5MW1wSE5YVnh0YkpUbGR4RnlZR0kybHJmZWRUYVI0b0luQUUxUExYd3RMaSt3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==
Status:
  Authorizations:
    Challenges:
      Token:        n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU
      Type:         http-01
      URL:          https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/9647447/i3ValQ
      Token:        n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU
      Type:         dns-01
      URL:          https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/9647447/5rFKgw
      Token:        n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU
      Type:         tls-alpn-01
      URL:          https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/9647447/edic2w
    Identifier:     keycloak-internal.<IP_ADDRESS>.nip.io
    Initial State:  pending
    URL:            https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/9647447
    Wildcard:       false
  Finalize URL:     https://acme-staging-v02.api.letsencrypt.org/acme/finalize/18622508/11248998
  State:            pending
  URL:              https://acme-staging-v02.api.letsencrypt.org/acme/order/18622508/11248998
Events:
  Type    Reason   Age   From          Message
  ----    ------   ----  ----          -------
  Normal  Created  18s   cert-manager  Created Challenge resource "keycloak-internal-secret-tpgd6-2128746746-858182461" for domain "keycloak-internal.<IP_ADDRESS>.nip.io"

Challenge:
Name:         keycloak-internal-secret-tpgd6-2128746746-858182461
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  acme.cert-manager.io/v1
Kind:         Challenge
Metadata:
  Creation Timestamp:  2021-03-17T11:36:55Z
  Finalizers:
    finalizer.acme.cert-manager.io
  Generation:  1
  Managed Fields:
    API Version:  acme.cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:finalizers:
          .:
          v:"finalizer.acme.cert-manager.io":
        f:ownerReferences:
          .:
          k:{"uid":"e49060e1-a279-431c-b1b1-ae540f040630"}:
            .:
            f:apiVersion:
            f:blockOwnerDeletion:
            f:controller:
            f:kind:
            f:name:
            f:uid:
      f:spec:
        .:
        f:authorizationURL:
        f:dnsName:
        f:issuerRef:
          .:
          f:group:
          f:kind:
          f:name:
        f:key:
        f:solver:
          .:
          f:http01:
            .:
            f:ingress:
              .:
              f:name:
        f:token:
        f:type:
        f:url:
        f:wildcard:
      f:status:
        .:
        f:presented:
        f:processing:
        f:reason:
        f:state:
    Manager:    controller
    Operation:  Update
    Time:       2021-03-17T11:36:56Z
  Owner References:
    API Version:           acme.cert-manager.io/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Order
    Name:                  keycloak-internal-secret-tpgd6-2128746746
    UID:                   e49060e1-a279-431c-b1b1-ae540f040630
  Resource Version:        23119
  UID:                     2912e4e8-b760-49bc-a650-0c9f4b87f2e7
Spec:
  Authorization URL:  https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/9647447
  Dns Name:           keycloak-internal.<IP_ADDRESS>.nip.io
  Issuer Ref:
    Group:  cert-manager.io
    Kind:   ClusterIssuer
    Name:   letsencrypt-staging
  Key:      n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU.JWZdW0xFdVbFd1kzEzoLJAND886y2QM4BT63Jjnz1ME
  Solver:
    http01:
      Ingress:
        Name:  keycloak-internal-ingress
  Token:       n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU
  Type:        HTTP-01
  URL:         https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/9647447/i3ValQ
  Wildcard:    false
Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for HTTP-01 challenge propagation: did not get expected response when querying endpoint, expected "n-37GapICvU2ZorsGPpoJGG3fqjcJqNDYBkC5FJtzbU.JWZdW0xFdVbFd1kzEzoLJAND886y2QM4BT63Jjnz1ME" but got:
  State:       pending
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Started    2m43s  cert-manager  Challenge scheduled for processing
  Normal  Presented  2m43s  cert-manager  Presented challenge using HTTP-01 challenge mechanism

The order's state URL has the same content as the error in the original post.

@dirkbolte I'm seeing the same thing in 1.2.0 and 1.3.0-alpha0 with K8s 1.19

Judging from the challenge describe the issue seems to be a failing self-check rather than the 405 from ACME (altough I have no idea how that happens...) I would suggest calling the URL from inside the cluster to see what is happening (more info https://cert-manager.io/docs/faq/acme/)

I found this issue caused by situations where there is a forward-zone in DNS. Essentially a split-horizon DNS scenario. So if you're running say Cloudflare and behind that Route53 and only passing some sub-domains via an NS record that this occurs.
So essentially it seems that there is a self-check limitation on the propagation based on the cert-manager limitation. The cert-manager design team was aware of this since there is a flag to change to a different type of recursive DNS verification.
I'd love to hear if people are able to resolve the self-check in another fashion. I also think the error message could be much more explicit to say "self-check failed" - Since the records are created by cert-manager it's unclear that the propagation check is cert-manager waiting to let LetsEncrypt to proceed (likely to prevent hammering LetsEncrypt when a self-check can save a lot of traffic) and doing its own check. I mistakenly went down the path of thinking LetsEncrypt wasn't seeing the DNS entries which is a different kind've problem. If I knew it was a self-check failing it would've saved a lot of time.
Here are the flags:
In Terraform args format extraArgs: ["--dns01-recursive-nameservers-only","--dns01-recursive-nameservers=<IP_ADDRESS>:53,<IP_ADDRESS>:53"]
In Helm CLI
 helm upgrade --namespace <YOURNS> --install --set ingressShim.defaultIssuerName=<DEFAULTISSUER>,ingressShim.defaultIssuerKind=ClusterIssuer,global.rbac.create=true,extraArgs="{--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=<IP_ADDRESS>:53\,<IP_ADDRESS>:53}" --wait --version v1.2.0 --set installCRDs=true cert-manager jetstack/cert-manager
Obv you drop RBAC option and other args if you don't use those or use a values.yaml or whatever. This changes the DNS resolver in cert-manager to use Google/Cloudflare and to utilize recursive nameservers.
Here is some other relevant reading material:
https://github.com/jetstack/cert-manager/issues/894

--set ingressShim.defaultIssuerName=letsencrypt-prod

Just wondering... I see in your helm command you have --set ingressShim.defaultIssuerName=letsencrypt-prod, but the ClusterIssuer name is letsencrypt-staging. Should they suppose to be the same?
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging

Hi,
I encountered similar behavior on my installation and wanted to verify,
Will removing the certificate order cause the cert-manager process to recreate it and possibly resolve the issue?
Will I risk a situation where it will not be recreated?

ause the cert-manager process to recreate it and possibly resolve the issue?
Will I risk a situation where it will not be recreated?

@assaf-grth Just want to give how I solved it in case anyone had the same issue and googled to reach here:
https://github.com/rivernews/iriversland2-kubernetes/issues/52
In a nutshell, I recommend you try the cert-manager CLI tool first. Once installed on your local, you can do a manual renewal, or verify anything you'd like.


Fix for assume statement

The assume statement was not understanding the complete expression present inside. The predicate was not getting appended along with the buffer access. The additional predicate was added to the conditions list but was not appended while creating the buffer touch . This fix helps to resolve it.
The issue is that the "TestSimplifyUsingPartiallyProvenBufferValueScatter" test is not completing after the fix. Rest of the tests are passing. I guess the issue is not with the fix but might be somewhere else.
For reference : https://github.com/apache/tvm/issues/16577
@Lunderberg and @jverma-quic Can you please review and point to the possible issue with the above test.

@tvm-bot rerun

Thanks @Lunderberg I will do the above changes recommended!
I realized the issues that after this fix the "TestSimplifyUsingPartiallyProvenBufferValueScatter" test is not completing but, "TestSimplifyUsingPartiallyProvenBufferValueGather" test is passing. There does not seem to be an issue while generating the control flow graph but somewhere later after introducing the fix. Can you please point what might be the possible issue?
Currently src/tir/transforms/simplify.cc and src/tir/transforms/reduce_branching_through_overcompute.cc pass works with lowered IR but is there any way how we can use it for T.blocks level implementation of the IR?
Thank you!

Hello @Lunderberg and @junrushao can you please review the above PR?

Since there is bug in the scatter test which is not yet resolved it might get difficult to upstream this PR. Closing it for now may raise the same PR later.


Add "You-" as a prefix if it's you (:

Please describe the changes this PR makes and why it should be merged
Soo this pull request is very important, fix a major flaw in the potato farm and I think our production will increse after the merge (maybe +47%)
Nah I'm just kidding, I'm just lonely, I feel bad and I rly want a hug
Ow, beside my mental health being rly bad, this PR add a "YOU -" prefix on the levels page if it's you (:
In this PR:

Code changes were not tested
Strings were edited (text changed while the key stayed the same)

I applied ethe changes I was asked for

Think I've done everything needed, gtg watch smth on netflix now :D

@Mergifyio refresh


Ligatures

Hi matthew
just wanted to say thanks that was a great idea to have a better connection of symbol and name. An alternative I have considered is using the font-built-in ligature support. Did you consider or try it? I cannot get it to work in wpf and the material symbols, only the material icons seem to work though.
Thanks and best wishes
Simon

Hi @kleinpoe, glad to hear this little library is helpful for you!
I'm not familiar with the other way (built in ligature) and haven't tried it. For me, the static class has worked super well enough.


Support for \oiint

Are there any plans to support \oiint ?

No plans in particular.  Pull requests are welcome.

I just did a quick test at https://khan.github.io/KaTeX/ and it looks liek $\oint$ is now supported.  Can somebody close this issue.

@williamstein this issue is about \oiint which is different from \oint.

It looks like KaTeX supports \int, \iint, \iiint, \oint, but no variations with more is.  They are all implemented as symbols in the font.  I checked esint which implements \oiint, and it also uses symbols in a font.  So I think to address this we would need to add symbols via the fonts repo.


CLI: using --sample-masks option

When running:
texture-synthesis --inpaint mask.png -o output.png --sample-masks IGNORE mask.png -- generate white_square.png texture.png

I get:
error: The subcommand 'generate' wasn't recognized
	Did you mean 'generate'?

If you believe you received this message in error, try re-running with 'texture-synthesis -- generate'

USAGE:
    texture-synthesis --inpaint <inpaint> --out-size <out-size> --out <output-path> --sample-masks <sample-masks>...

Is this the expected behavior? How should I use sample-masks option? (there is no example in the README).
The help says:
--sample-masks <sample-masks>...
            Path(s) to sample masks used to determine which pixels in an example can be used as inputs during
            generation, any example that doesn't have a mask, or uses `ALL`, will consider all pixels in the example. If
            `IGNORE` is specified, then the example image won't be used at all, which is useful with `--inpaint`.

I'm precisely trying to use sample-masks in combination with inpaint but can not manage to do it.

This is a bug in the argument parser we are using, you need to make it so that the last option before the generate subcommand only takes a single value, so if you swap -o output.png with --samples-masks IGNORE mask.png and get rid of the -- it should work.

I tried swapping the options to get rid of the parsing problem, but it runs forever using two CPU cores at 100%. It's seems to be a bug, but I do not know how to fix it. Can you reproduce it? I tried both with the 0.7.1 release binary and a self build binary. I can not address #86 before fixing this.

Fixed by #98


When opening an .ipynb in VS Code, there are empty cells.

Empty cells when opening an .ipynb. In the screen shot here, I opened /samples/notebooks/Extensions.ipynb and the notebook contains empty cells, though not missing code.
Version: 1.0.126511+f4313f53dc1b70447ef17c2116588ee27b6bac25

I propose not to open or auto convert .ipynb files but to have a gesture to import and export such file format. But the extension only works reading/writing our file format, so not to interfere and modify those notebooks without the user knowing or having a way to revert the changes.

Due to language aliases (#!pwsh instead of #!powershell) and magic commands (#!clock) being misinterpreted.


[SPARK-11954][SQL] Encoder for JavaBeans

create java version of constructorFor and extractorFor in JavaTypeInference

Test build #46608 has started for PR 9937 at commit d7a4bf9.

Test build #46608 has finished for PR 9937 at commit d7a4bf9.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(n: NewInstance, fields: Seq[Expression], setters: Seq[String])\n

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46608/
Test FAILed.

I think Java beans is different from pojo. Beans only care about fields that have getters and setters, while pojo should care about all the fiedls.

A POJO is not rigorously defined, and I'm not sure how to detect it and re-construct it...

Use reflection to find all the public and private fields?

Perhaps we should start with Java Beans.  They are well defined, we have existing reflection code, and I've never heard a java user complain that was not sufficient (this is what we support for creating java data frames).

Sounds good.

Test build #46691 has started for PR 9937 at commit a31ea94.

Test build #46691 has finished for PR 9937 at commit a31ea94.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * trait ScalaReflection \n  * case class InitializeJavaBean(n: NewInstance, fields: Seq[Expression], setters: Seq[String])\n

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46691/
Test FAILed.

Test build #46693 has started for PR 9937 at commit 58d1cc1.

Test build #46693 has finished for PR 9937 at commit 58d1cc1.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * trait ScalaReflection \n  * case class InitializeJavaBean(n: NewInstance, fields: Seq[Expression], setters: Seq[String])\n

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46693/
Test FAILed.

Merged build finished. Test FAILed.

Test build #46763 has started for PR 9937 at commit 40433ca.

Test build #46763 has finished for PR 9937 at commit 40433ca.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * trait ScalaReflection \n  * case class InitializeJavaBean(n: NewInstance, fields: Seq[Expression], setters: Seq[String])\n

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46763/
Test PASSed.

Merged build finished. Test PASSed.

Thanks for working on this.  I'm not sure that this is the right tactic though.  I don't think that we want to make java bean the default fall back in our scala reflection code path.  Instead I think that we only want to create a java bean encoder when the user explicitly asks for it and thus this should be a separate code path.  The only common code should be ExpressionEncoder probably.
Also, instead of hacking this into scala's reflection, I think we should use the builtin java support for introspecting on beans.  I would probably start with the code in JavaTypeInference and use that to construct expressions.

@marmbrus do you mean we should write java version of extractorsFor and constructorFor in JavaTypeInference?

Test build #46871 has started for PR 9937 at commit c634aa4.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46870/
Test FAILed.

Test build #46871 has finished for PR 9937 at commit c634aa4.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(n: NewInstance, setters: Map[String, Expression])\n

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46871/
Test FAILed.

Merged build finished. Test FAILed.

Test build #46880 has started for PR 9937 at commit e852710.

Test build #46880 has finished for PR 9937 at commit e852710.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(n: NewInstance, setters: Map[String, Expression])\n

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46880/
Test FAILed.

Test build #46882 has started for PR 9937 at commit 7940ec7.

Test build #46883 has started for PR 9937 at commit fb9a898.

Test build #46882 has finished for PR 9937 at commit 7940ec7.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(n: NewInstance, setters: Map[String, Expression])\n

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46882/
Test FAILed.

Test build #46883 has finished for PR 9937 at commit fb9a898.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(n: NewInstance, setters: Map[String, Expression])\n

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46883/
Test PASSed.

Merged build finished. Test PASSed.

Some minor comments, but this is looking really good!

Test build #46939 has started for PR 9937 at commit 0d95daf.

Test build #46939 has finished for PR 9937 at commit 0d95daf.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * case class InitializeJavaBean(beanInstance: Expression, setters: Map[String, Expression])\n

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46939/
Test PASSed.

Merged build finished. Test PASSed.

Thanks!  I'm going to try and fix conflicts while merging to master and 1.6.


Make JRE_IMAGE parameter workspace relative

Prior to this patch it was already possible to pass JRE_IMAGE path via a
Jenkins parameter. However, string parameters won't get String-interpolated.
That means a param value of ${WORKSPACE}/foo/bar results in a literal
${WORKSPACE} which isn't the user's intention.
This patch modifies the JRE_IMAGE environment variable to be workspace
relative if it comes from a Jenkins parameter. This solves a test issue we have
been seeing for upstream JDK builds, where math JRE tests would fail for no good
reason. After this patch one can set JRE_IMAGE=openjdkbinary/j2sdk-image/jre
and would then have the tests passing. Thoughts?
Tested with a sandbox grinder here:
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder_Sandbox/387/

Thanks!


thank you msg overriding and role main adding

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes and the overall coverage did not decrease.
[ ] All unit tests pass on CircleCi.
[ ] I ran all tests locally and they pass.

How is this test even passing, since you have two embed forms, so you need to submit the form by clicking the relevant submit button. Please fix this in the next iteration once aemds is released with your changes.
Also, remove the test suffix from the collateral. Please adhere to the naming conventions.

The tests are passing because as of now embed container test are skipped because those are dependent on rest api changes once rest api's changes will be released I will fix these multiple embed container tests.
Also there are multiple test collaterals with test suffix that why I also added that. Even all the existing embed container test collaterals have test suffix.

@rajatkhurana-adobe ,
Just confirming that if the test cases are dependant on rest api release then does it mean the actual functionality is also dependent on rest api (forms-sdk) release in future

How is this test even passing, since you have two embed forms, so you need to submit the form by clicking the relevant submit button. Please fix this in the next iteration once aemds is released with your changes.
Also, remove the test suffix from the collateral. Please adhere to the naming conventions.

The tests are passing because as of now embed container test are skipped because those are dependent on rest api changes once rest api's changes will be released I will fix these multiple embed container tests.
Also there are multiple test collaterals with test suffix that why I also added that. Even all the existing embed container test collaterals have test suffix.

@rajatkhurana-adobe , Just confirming that if the test cases are dependant on rest api release then does it mean the actual functionality is also dependent on rest api (forms-sdk) release in future

Yes functionality is also dependent on rest API changes. I mean if the rest API changes are not released then the form submission will work as it is working right now i.e. without overriding the config of embed container on form.

How is this test even passing, since you have two embed forms, so you need to submit the form by clicking the relevant submit button. Please fix this in the next iteration once aemds is released with your changes.
Also, remove the test suffix from the collateral. Please adhere to the naming conventions.

The tests are passing because as of now embed container test are skipped because those are dependent on rest api changes once rest api's changes will be released I will fix these multiple embed container tests.
Also there are multiple test collaterals with test suffix that why I also added that. Even all the existing embed container test collaterals have test suffix.

@rajatkhurana-adobe , Just confirming that if the test cases are dependant on rest api release then does it mean the actual functionality is also dependent on rest api (forms-sdk) release in future

Yes functionality is also dependent on rest API changes. I mean if the rest API changes are not released then the form submission will work as it is working right now i.e. without overriding the config of embed container on form.

Ok, thanks

Please incorporate other review comments iteratively


fix: fasta headers from sequence extractor output are truncated

Where the fasta header from bedtools output is
>1:3069197-3069296(+)

the one from the subsequent step (adding poly(A) tails) is
>1:3069197-30692

Investigate module sequence extractor/post-bed processing to identify the cause for this behavior.

Note to self: Tool is expecting the header to contain transcript ids, and is then only considering the first 15 characters. So header output from bedtools has to be changed, and then the transcript selection has to be revisited.


Option to not tokenize

Allow a field to be used as is, with no ngram tokenization, for exact matching.

#290 introduces the ability to do exact matching.


accuracy comparison with official implementation

Hi, @bonlime ,
Have you compared your keras implementation with the official one in terms of iOU accuracy?

I've checked that for 3 different images outputs were absolutely the same (average difference < 1e-5). I didn't check the IoU accuracy explicitly.


Avoid using Duration.parse directly due to JDK8 bug

Ported the JDK16 implementation of Duration.parse to work around the JDK8 issue described https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054978
Fixes https://github.com/zio/zio-json/issues/214

CI is upset. Did you run prepare?

oops let me fix

@fsvehla should I remove the Either and just throw exceptions to avoid the extra overhead (relying on mapStringOrFail to catch Exceptions)

@calvinlfer Sure — why not follow up on this one?

@calvinlfer With both of these changes


Implementing views.* methods?

Description
Hello Slack folks!
I was trying to implement the new modal views in one of my apps, but the views.open, views.push, and views.update methods are not available in slack-ruby/slack-ruby-client . After reading the source for that library, it looks like the methods are missing because they are not in the OpenAPI spec.
Is support for these new methods coming? Is there a timeline for implementation? I'm wondering if I should abandon slack-ruby-client and just write my own instead.
Thanks!
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[X] enhancement (feature request)
[ ] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[X] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[X] I've read and agree to the Code of Conduct.
[X] I've searched for any related issues and avoided creating a duplicate issue.

I hope to get a new OpenAPI spec generated in time for our Spec conference next week -- it's a pretty manual process unfortunately. I'll update this ticket when it goes out -- it'll include the views.* methods.
I'm not sure if the slack-ruby-client uses the OpenAPI spec to build its definition or not, but in the meantime you can should be able to use the library's more abstract web request interface to start interacting with the method directly, without a bit of the abstraction.
response = Slack::Web::Faraday::Request::post("https://slack.com/api/views.open", your_method_arguments)

@episod Thanks for the quick and helpful response! That solves my issue for now.
Looks like I was wrong, slack-ruby actually uses slack-api-ref, which scrapes the web documentation. Doesn't look like there is movement to switch it over to slack-api-spec, since this issue has been open since April 2018 😿
Good luck with the Spec conference!

@episod did you ever get the OpenAPI spec updated?
I'm maintaining an autogenerated package for Elixir and it looks like we're still missing the views.* details in the OpenAPI spec.
I'd prefer it if I didn't need to manually write in support for the views...

@idyll any chance you have that available somewhere? would love to get this added to the Elixir-Slack package, we're experiencing the same problem there as well: https://github.com/BlakeWilliams/Elixir-Slack/issues/150

Good news, views.* is now in the spec. Let us know if you have any issues with them.