Ignore unknown sigalgs and groups in the configuration

Related to #20789
Unknown signature algorithms and groups in the configuration should not be fatal errors. The handling should be similar to handling of ciphers. I.e., there should be a failure only in case the configuration produces no valid sigalgs or groups.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

I am not sure whether we shouldn't backport it to 3.2.

IMO this would need an OTC exception for backporting to 3.2. Feel free to bring it in an OTC meeting.

@beldmit fixup pushed please reconfirm.

** OTC: do we want to backport it to 3.2? As we add support to pluggable signature algorithms in 3.2, this issue would create problems. **

Rebased to resolve conflict in CHANGES.md

OTC: This should not be backported to 3.2 branch because this is not a bug fix.

I'm against this change. It should return an error if there is some config error, and not do something random different that's totally unexpected. This will be make things very hard to debug what is going on. It's my understanding that an invalid line in a config file is currently just ignored, but it should return an error trying to load the config file.

If people are configuring something specific, why shouldn't we raise an error if we can't match what they ask for?  If I was the user, I'd find it very surprising if what I configured was dropped silently...
Viewed from another viewpoint, it may be that we haven't given users good enough tools to express how they want things to work.  Like, what if the user considers some sigalgs mandatory, and others optional based on availability?  That's a viable request in my mind, but I don't think there's a way for them to express that...  and it kinda seems like that's the main question being raised here; are we assuming that the configured sigalgs are mandatory or optional, from the user's perspective?

As an outsider here, it does seem that if I make a typo and it is silently ignored, that's not good for configuration of a security library...

The current code as of all stable versions will silently fall back to the default configuration if you make a typo. That is in case you use the configuration file to configure things. The SSL[_CTX]_set1_client_sigalgs() and SSL[_CTX]_set1_groups_list() will fail if there is a typo in the sigalgs or groups lists but that error is not propagated up when these functions are called during configuration file parsing.
I am going to change this PR to add syntax for optional sigalgs and groups and keep the existing behavior as mandatory.

Can we please get an approval from @openssl/commiters?

@t8m could you please rebase it to eliminate the CHANGES.md conflict?

This pull request is ready to merge

Merged with fixing the conflict in CHANGES.md
Many thanks for this work and review!


<ucdlib-sils-permalink> component

If we decide on moving the databases to the primo catalog, and for news items and other pages, it would be nice to have a standard component for representing primo links.  I imagine that we would have two particular behaviors in-line and as cards.  In both cases the user would use the permalink as a the identifier.  If you identified a tag inline like <ucdlib-sils-permalink href="https://search.library.ucdavis.edu/permalink/01UCD_INST/1uov27j/alma9981249369903126"/>, then the link would format as something like

Engineering victory : the Union siege of Vicksburg

For more citation information, we'd could add

<ucdlib-sils-permalink href=".." cite="full" /> => Solonick, Justin S. Engineering Victory : the Union Siege of Vicksburg . Carbondale: Southern Illinois University Press, 2015. Print.

Operation
This item would use the JSON api that is used by the SILS client, fetch and parse that.

Do we have a standard library for client API calls, with common error catching eg?
How do we wrap things?

Questions:

The current formulation wouldn't have a backup tag (like the stored name) for when the SILS site is down.

@sbagg - Originally I proposed that we use the JSON (particularly the PNX record) that is driving the website display for a record. For example, I pointed to https://search.library.ucdavis.edu/primaws/rest/pub/pnxs/undefined/alma9916924606106531?vid=01UCD_INST:UCD&lang=en  as a source on our example permalink page.  On Friday, I learned that the SILS also maintains a more complete linked data record, then the SE0 shows.  This Linked Data Example I think might be a better choice for our data, since we understand both the format, and we have the predictate schema


Include proof of concept

I wanted the ability to split my stacks up into multiple files for readability purposes.
Here is a somewhat naive proof of concept of one possible approach which I would love to get feedback on.
The way it works is you have a master file env_stack.rb
CloudFormation {
  Description "Test"
  include 'parameters_one'
  include 'parameters_two'
}

you can then create _parameters_one.rb and _parameters_two.rb
Parameter("One") {
  String
}

Parameter("Two") {
  String
}

This will generate the same output as
CloudFormation {
  Description "Test"
  Parameter("One") {
    String
  }
  Parameter("Two") {
    String
  }
}

Curious as to what others think of an approach like this?

@johnf One concern, is that #include is already defined in this context on Kernel so at a minimum, you should choose a different, more specific method name.
A second issue I have is the assumption of naming scheme. The _  prefix is fine, but shouldn't be dictated by the code. Developer preference is the only reason for a parameter file to have special naming conventions.

@kornypoet agree on the naming, I've been thinking about it and have a few ideas:
Inject "my_other_template"
Merge "my_other_template"
Combine "my_other_template"

Any thoughts on these? The problem is they're not as obvious as Require or Include which people instinctually get.. Out of those three I think Merge would make the most sense to me.
I can see @johnf point of if AWS decided further down the road to use Include or Require in their CF then we may have a problem.
Agree with @kornypoet that the naming convention of the required files shouldn't be dictated by the code, rather the developer.

@kornypoet
My reasoning for the use of underscore was that I wanted to emphasise that the files that are getting included aren't fully fledged cfndsl files.
They lack the CloudFormation {} wrapper. This is needed to enable them to be included in this way.
In that way I'm using a similar design pattern to Rails views and partials. Happy to lose it if others disagree though.
@stevenjack
I think I like Inject but should we lowercase it to inject, this would differentiate cfndsl directives from AWS directives which I assume would always by uppercase. Could be a useful pattern for any further expansions?

I'm not actually sure if this is feasible anymore. I discovered that the variables defined in the yaml file aren't available in the children.
If I put this in the parent file
caller_file = Pathname.new(__FILE__)
filename = caller_file.dirname + Pathname.new("_database.rb").
contents = filename.read

instance_eval contents

It works just fine.
If you put it inside the include method in the code then the binding ends up being wrong so the variables from the yaml aren't available.
I tried lots of things but I've reached the limits of my ruby meta programming.

This would be great to have, I have tried to do this to with cfndsl and ended up doing class_eval on JSONable or the CloudFormationTemplate objects. It was very messy to do so I kinda gave up.
I tried to do it the opposite way than here by wrapping Cloudformation {} in another method that took another block and then instance_evald inside the Cloudformation block eg:
def MyCloudFormation(app_name, &block)
  CloudFormation do
    Parameter('xyx') do
    end
    instance_eval(&block) if block_given?
  end
end

This way people would require my files/gem and then do"
MyCloudFormation('myapp') do
   # their resources
end

This way I could wrap any standard things in our environment around what the cloudformations, others created.
Either way it is quite hard to extend cfndsl in this manner so some sort of 'hook' inside cfndsl would be great!

@johnf If you want this to work, you need to add the method to CloudFormationTemplate instead of JSONable. You will then have access to the variables from your YAML files.
@pvdvreede I agree that we need better hooks into the template creation. Anyone who has multiple templates or any amount of complexity in architecture has probably tried to at least write helper methods, and cfndsl isn't easy to extend.
@stevenjack In conclusion, I don't think we should bring this method in specifically, but rather open a discussion about how best to extend cfndsl with outside functionality.

I've been breaking my templates up into multiple files like this:
template.rb:
require_relative "subtemplate.rb"

CloudFormation {
  INSTANCE_TYPE ||= "t2.micro"
  my_instance(INSTANCE_TYPE)
}

subtemplate.rb:
def my_instance(instance_type)
  EC2_Instance(:MyInstance) {
    InstanceType instance_type
  }
end

It seems to work quite well. You can't access the global cfndsl params from the sub-template, but you can pass them as parameters to the method call, which in some ways is actually better. Using this approach I've been able to assemble reusable cfndsl building blocks for use by multiple teams.

Any consensus here on if we want something like this? Or should we just close it.

I'm voting this one down for now. I believe the functionality can be replicated by the end-user in a few different ways. cfndsl's rake task and cli are currently structured to treat the dsl to template relationship as one-to-one. Splitting one conceptual template into multiple files (even if it makes sharing snippets easier) doesn't seem like a clean implementation for the core library to assume. There might be some merit in discussing cfndsl having a more open interface/api to allow for extensions like this to be added later, however.

@johnf agree with @kornypoet on this one.
@kornypoet @johnf Let's start a separate issue that we can track and ask others about what they would be looking for in terms of having a more open and clean interface/api that people can build upon.


Catch rejected promise when the wallet cannot message the mediator

If the wallet cannot communicate with the mediator they they first try to establish a connection the app will crash due to an unhandled promise. It should be caught and dealt with appropriately.
 DEBUG  DEBUG: Sending outbound message to endpoint 'https://aries-mediator-agent-test.apps.silver.devops.gov.bc.ca' {
  "payload": {
    "protected": "xxx",
    "iv": "YwWoSqPfOGyg3ObY",
    "ciphertext": "8WFDWvpLI6iv0CFcwK8nVmJLLkg4OByhhzhNL3RrBkzxVruY4azHrf822hSj2LsH6Sb_FFNdd5zgniLYuPeInb-M2kNvvqjWn1VliramWLOeVIbq1KjfQLutN5ffWE_MCVqLNEETOEGqLGQ30NFeEGCjbF7Lv76P2-EpnNzJ1VrsQD3UMDiljkVveeNPr3_OGzHmk0HDu0vKQKeqY8D6pd",
    "tag": "VJV601VQeqnxxDzBHYk2Kxg=="
  }
}
 WARN  Possible Unhandled Promise Rejection (id: 0):
[AriesFrameworkError: Message is undeliverable to connection 9ebb3c81-77ba-4932-b1d7-1ac086c97758 (Mediator)]
 DEBUG  DEBUG: Request was aborted due to timeout. Not throwing error due to return routing on sent message
 DEBUG  DEBUG: No response received.

This is on hold until we can chat with the community. I'm not familiar with AFJ enough to know what the next steps are.
https://github.com/hyperledger/aries-mobile-agent-react-native/pull/233

Closing. Will change how this works after PIN screen work.


"Container entered status Running" in the wrong channel

Hi,
I've installed kube-slack via helm chart.
Basically I configured the slackUrl with an webhook with a default channel for the notifications. I've configured a deployment using kube-slack/slack-channel annotation to push pod notifications to a different "new" channel.
Basically I receive the "Container entered status CrashLoopBackOff" messages in the right "new" channel and the "Container entered status Running" messages in the default one. How is it possible?
I actually run v4.0.0 instead of v3.6.0 to check if this problem is fixed but I get the same behavior in both version.
Thank you in advance.

It's definitely a bug. I'll look into this.

I seems to be unable to reproduce the issue. In our company Slack, both messages appear in the right channel. I found nothing in the code either.

Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Installed charts
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
fluent-bit 6 Wed Jan 30 15:06:16 2019 DEPLOYED fluent-bit-1.5.0 1.0.3 logging
kube-slack 6 Wed Jan 16 15:56:42 2019 DEPLOYED kube-slack-0.4.0 v3.6.0 infrastructure
kube version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-13T23:15:13Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.3", GitCommit:"435f92c719f279a3a67808c80521ea17d5715c66", GitTreeState:"clean", BuildDate:"2018-11-26T12:46:57Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Maybe this could help


Re-enable screenshots taking except for SubmissionTanFragment (closes  #77)

Checklist

[x] Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests.
[x] If this PR comes from a fork, please Allow edits from maintainers
[x] Set a speaking title. Format: {task_name} (closes #{issue_number}). For example: Use logger (closes # 41)
[x] Link your Pull Request to an issue (if applicable)
[x] Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.
[x] Make sure that your PR is not introducing unnecessary reformatting (e.g., introduced by on-save hooks in your IDE)
[x] Make sure that your PR does not contain changes in strings.xml (see issue #332)
[x] Make sure that your PR does not contain compiled sources (already set by the default .gitignore) and / or binary files

Description
It is not fair to block the users from taking screenshots from the entire app because of a security concern in a couple of screens.
This PR reintroduces taking screenshots from the app except for the SubmissionTanFragment (If you'd like to disable it for other screens please state in the comments so that I can add the interface there).
The trick here is to mark a Fragment with ScreenshotCaptureBlockable (not sure about the name) marker interface and once it gets attached or the user reaches that screen, the ActivityScreenshotHelper will set the FLAG_SECURE flag on the Activity Window. However there is one caveat, is that once this flag is set for a Window it can't be reverted (even with using clearFlags) and the Activity will stay in secured mode until its destruction.
Tested on Emulator with API 23 and a Samsung S6.

Hi @R4md4c  ,
thank's for your detailed contribution! :) But this was implemented as a recommendation of the BSI in #9 . So we won't remove it for now, but you aren't alone with your opinion and we are discussing it internally.
That's why I'll close this PR.
Cheers,
Luka

@harambasicluka But this doesn't contradict with #9, it keeps the FLAG_SECURE usage, however only defers it until the user reaches the screen in question.
Anyway hopefully the internal people would agree in re-enabling the screenshots back.

This seems to be the BSI being prohibitively restrictive in their recommendations. Rather than the BSI's recommendation being regurgitated every time this comes up: What about asking the BSI what it thinks about the new proposal?

Wonderful implementation. Why was this PR closed? That's really unfair to the contributor.
As said before, the iOS App allows screenshots, Android not. Why?

Nevertheless: the issues as described by @R4md4c could be resolved in a less Jacky way by making the submission a separate activity like the onboarding one. I opened an issue about that already more than 2 weeks ago. See #77

@uschindler Actually sorry, I take back what I said earlier. I found a way to clear the flag after the Fragment gets destroyed. You can see the work done in this commit (It's not visible in the PR because it got closed). The trick is to set the flag before the Fragment's View gets created.

This seems to be the BSI being prohibitively restrictive in their recommendations.

I only know what's written in #9, but there I do not see the BSI being too restrictive as their statement is limited only to "sensitive information". This PR should have been the solution to #9. not what was implemented there.

closes #745 or #745 closes this one

We are switching our branching approach, dev is going to be deleted, to do this there can't be any open PRs against it. I'm switching this PR to master, before merging this PR switch it to a fitting target release branch, i.e. release/1.X.Y

Closing since this PR won't add any value after #987 was marked as obsolete.


Fix: responsiveness

Notes for Reviewers
This PR fixes #
Signed commits

[x] Yes, I signed my commits.

The tab names should not be clipped. Maybe width: 'max-content' can work here?

The icons in these cards should be centered.

When navigating to the configurations (designs) page in mobile mode, the page loads with these desktop dimensions for a few seconds.

The view icon is out of the bar, and the long names on cards need to be formatted with word breaks and ellipses properties.

The data table's checkboxes persist over other information.

The registry tab widths and section heights need fixing.

@lakshz are you willing to take over this pr ? If yes just first complete the dashboard part for responsiveness and rest in iterations.

or @dragon-slayer875 if you have nothing in plate you can take over


Freestanding stdatomic.h headers in GCC appear to be unsuitable

This function, which uses atomic_flag_test_and_set, uses xchg and test. Presumably, an atomic operation would be preferable to avoid races, like lock cmpxchg.

Spinel was since rewritten in Rust, so this is no longer an issue.


merge to live

DocFx metadata update: add ms.suite & header

OPS Build status updates of commit b625990:
:clock10: Preparing: average preparing time is 46 sec(s)

OPS Build status updates of commit b625990:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Articles/docfx.json
:white_check_mark:Succeeded

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


[cherry] Emulating cherry-picking of 7992

CATEGORY
Choose one

[ ] Bug Fix
[x] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
This PR emulates cherry-picking of https://github.com/apache/incubator-superset/pull/7992 (actual cherry-picking isn't viable because of the Black formatting).
TEST PLAN
CI.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS
to: @etr2460 @graceguo-supercat @michellethomas

@etr2460 I cherry-picked https://github.com/apache/incubator-superset/pull/7992 into release--0.34.


create API docs

also some plugin tutorials?

Please! I would love to start to contribute to this project!

Starting to dig into this today, I was starting to create my own but a search led me here. Happy to find this repo! I'm currently trying to add border/titlebar hiding but even so far this suits my needs better than bug.n did. Thanks a ton, some documentation would go a long way.

@ianelletson, we can actually implement lots of ideas already used on other projects, but having an API basic documentation it will boost the development of third party contribution. I'll give a look to see if I can help somewhat on this...


Pechakucha

[ ] Have a solid group of friends
[ ] Rain
[ ] Horrible food
[ ] Coding

will this come out to 20 images?
also 😭 about the horrible food


dwm-status: 1.2.0 -> 1.4.0

Motivation for this change
Update dwm-status.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg dwm-status

@GrahamcOfBorg build dwm-status

Failure on aarch64-linux (full log)
Attempted: dwm-status
Partial log (click to expand)
cannot build derivation '/nix/store/6bzb54zcqhxqgj4zmzs0j4apain0crxx-rust_serde_derive-1.0.18.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/1hm9s00vympr8l3vj4g0bjb9g5ks3fn5-rust_crates-io-0.11.0.drv': 30 dependencies couldn't be built
cannot build derivation '/nix/store/b3xl74izggh5xy0kfja3ijdvzwrzmmwa-rust_docopt-0.8.1.drv': 19 dependencies couldn't be built
cannot build derivation '/nix/store/dgcn42fmjhmvkfbgzr2y10qrpbgxb53w-rust_git2-curl-0.7.0.drv': 20 dependencies couldn't be built
cannot build derivation '/nix/store/nk7yzv0z4654aqfp2sickswr82ic1fi0-rust_ignore-0.2.2.drv': 18 dependencies couldn't be built
cannot build derivation '/nix/store/x426m8qz6r4vsl1sfyzv4mvvvn7ji9pq-rust_cargo-0.22.0.drv': 78 dependencies couldn't be built
cannot build derivation '/nix/store/k17dmgldlpva0l3sy97cwpp7b520p20f-rust_cargo-vendor-0.1.13.drv': 79 dependencies couldn't be built
cannot build derivation '/nix/store/fx5a5shszrsbcww3r00xz3ls52qw70n1-dwm-status-1.4.0-vendor.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/lwkrmmw010vzx47dhnfkcs76lm97lkaj-dwm-status-1.4.0.drv': 3 dependencies couldn't be built
error: build of '/nix/store/lwkrmmw010vzx47dhnfkcs76lm97lkaj-dwm-status-1.4.0.drv' failed

Timed out, unknown build status on x86_64-linux (full log)
Attempted: dwm-status
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/y3n2h3mv9hxn2z4lpkc6rr0jcark46w5-xcb-util-0.4.0-dev/lib
patching script interpreter paths in /nix/store/y3n2h3mv9hxn2z4lpkc6rr0jcark46w5-xcb-util-0.4.0-dev
checking for references to /build in /nix/store/y3n2h3mv9hxn2z4lpkc6rr0jcark46w5-xcb-util-0.4.0-dev...
cannot build derivation '/nix/store/0jmx6ac7rx4f45pdrn72ri4piszz9mdk-cairo-1.16.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/l7jfmlydq8948yha7w8n2vnkpx98441h-absolute_gir_path.patch.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/1gvf5kf08glj6gp8vs1xx2kdwmr0c3dr-gobject-introspection-1.56.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/v54w3mldybxa4i9b68rfh9fr2l6jxn44-gdk-pixbuf-2.36.12.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/v0i0xqc36ih4dsrk59kqnqrmal8lw2xc-libnotify-0.7.7.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/gwfpwgf2h1cwr7n7iiqwk4d4dyj7f811-dwm-status-1.4.0.drv': 5 dependencies couldn't be built
error: build of '/nix/store/gwfpwgf2h1cwr7n7iiqwk4d4dyj7f811-dwm-status-1.4.0.drv' failed


Design a Modular Data Input Interface

References user story #22
Create a design for a data input interface that is separate from the core executable.

I built a skeleton version of program using tkinter as GUI.
I am able to open .csv files.
Opening a new file transitions GUI to new window with editor panel.
[t:180]


Validate the first argument of parse method

The first argument type of parse method can only be of String or HTML Element.

I've commented this here: https://github.com/twitter/twemoji/pull/136#issuecomment-205283021
I'd like to know what do you think. Thanks.

It's definitely not hard. I've already fixed that issue in our code base. Just my little feedback :)
My suggestion was majorly based on the usability of this method. As a developer, I seldom expect a 3rd-party library which deals with string or DOM would throw errors. Say if jQuery or String.js throws errors as their API design instead of the error callback or promise, they are probably not so popular now.
If the point is still not persuasive to you, I would only suggest to throw a proper error message and close my pull request and issue. Thanks.

jQuery has silent errors by default which is sometimes the thing developers expect, and sometimes the footgun they didn't.
Millions of sites are using this library already, including Wordpress sites, nobody until now complained about the fact parsing undefined should be handled somehow.
I'd like to have other developers opinion in here 'cause I know the fix is trivial, but I don't know if we want that fix in here. As example, your initial || "" suggestion was assuming you only parses strings, there's no such easy fallback for DOM nodes so it takes nothing in your case to fallback to empty string, but you still need to verify the content you are trying to parse if you are passing a DOM node, otherwise everything else will break anyway ( node.appendChild(undefined) )
I wonder what @twuttke thinks about this.

My preference is not to add bloat to a library because it increased this size of everyone's web site download. I prefer it be the responsibility of the caller to pass valid data.
In your case,  if you need garbage input to be silently ignored, then consider calling it with something like emoji.parse(myString || "") or myString && emoji.parse(myString)  That way people can see at the calling level you are expecting invalid input and how you are dealing with it rather than hiding it inside the library.
Consider this:
"hello".concat(undefined)

What do you suppose that does? This is what I mean by not expecting library functions to fix invalid input, because it might not fix it the way you expect it will. In this case, it does not silently ignore the undefined. It also does not throw an exception.
As far as why not throw a detailed exception, again, I prefer not to add bloat to a library unless it adds value to most users. Is the passive "TypeError: Cannot read property 'nodeValue' of undefined(…)" exception stack enough to trace the root of the problem? If we had to choose something, maybe
  if (typeof what !== 'string' &&
        !(what && what.nodeName)
  ) {
    throw("Invalid arguments to Twemoji.parse");
  }

is a little clearer to a developer, but I'm not accustomed to that much extra run-time checking.

Agreed, I also wouldn't invalidate the cache of every twemoji CDN user to just add an error that is obvious to spot anyway.
I guess this is a won't fix then. Maybe we'll sneak in a better error next time there's a better reason to invalidate all caches.


Accessibility - Screen Reader Support

Is sidr supposed to be accessible? It seems to be broken with VoiceOver and NVDA.

It depends on the content you place there. It's up to you.


[Feature Request] Support FP8 mixed precision with FSDP Plugin

System Info
accelerate == 0.22 or 0.23.dev (build from main)
transformers == 4.33 or 4.34.dev (build from main)
transformer-engine == 0.11.0
torch == 2.1.1

Information

[ ] The official example scripts
[X] My own modified scripts

Tasks

[ ] One of the scripts in the examples/ folder of Accelerate or an officially supported no_trainer script in the examples folder of the transformers repo (such as run_no_trainer_glue.py)
[X] My own task or dataset (give details below)

Reproduction
I'm trying to launch multi-node multi-gpu Llama-2 for continued pretraining. My training script is using Accelerate to setup distributed environment and HF Transfomers Trainer to execute the training loop. I'd like to use FP8 precision with FSDP plugin, but seeing issues.
Below are some details on how to reproduce the issue. In my example I omitted some custom code which distributed the tasks and preparers the data to make it more simple. Let me know if any key details are missing.
I start training script with following command line which runs on each machine in multi-node environment):
torch.distributed.run -m accelerate.commands.launch -- main_process_ip=$(MASTER_ADDR) --main_process_port=2940 --mixed_precision=fp8|bf16
--rdzv_backend=c10d --machine_rank=$(RANK) --num_machines=$(WORLD_SIZE) --num_processes=4 --use_fsdp --fsdp_auto_wrap_policy=TRANSFORMER_BASED_WRAP'
--fsdp_backward_prefetch_policy=BACKWARD_PRE --fsdp_offload_params=false --fsdp_sharding_strategy=1 --fsdp_state_dict_type=SHARDED_STATE_DICT --fsdp_transformer_layer_cls_to_wrap=LlamaDecoderLayer --module - train_module.train   <training script args>

where train_module.train() is a custom wrapper on top of HuggingFace Trainer class with minimal changes to it.
When running my script with --mixed_precision=bf16, the script works as expected, the model is successfully sharded across GPUs, training starts and loss decreases.
However, when passing --mixed_precision=fp8 I'm getting following error:
<omitting some client specific code >
t = Trainer(
  File "/layers/pip/requirements/lib/python3.10/site-packages/transformers/trainer.py", line 347, in __init__
    self.create_accelerator_and_postprocess()
  File "/layers/pip/requirements/lib/python3.10/site-packages/transformers/trainer.py", line 3940, in create_accelerator_and_postprocess
    self.accelerator = Accelerator(
  File "/layers/pip/requirements/lib/python3.10/site-packages/accelerate/accelerator.py", line 365, in __init__
    self.state = AcceleratorState(
  File "pip/requirements/lib/python3.10/site-packages/accelerate/state.py", line 765, in __init__
    fsdp_plugin.set_mixed_precision(self._mixed_precision)
  File "/layers/pip/requirements/lib/python3.10/site-packages/accelerate/utils/dataclasses.py", line 979, in set_mixed_precision
    raise ValueError(f"Unknown mixed precision value: {mixed_precision}")
ValueError: Unknown mixed precision value: fp8

Looking into stacktrace I can see that while accelerate CLI supports --mixed_precision=fp8 (reference) FSDP plugin seems to only support "no", "fp16" or "bf16" options (reference)
Can you please confirm that my understanding is correct, that Accelerate supports FP8 only withoud Zero-3 sharding frameworks (e.g. FSDP or DeepSpeed). If my understanding is correct, does Accelerate team have a timeline to add FP8 support to FSDP Plugin?
Expected behavior
I expect that both bf16 and fp8 to work similarly.

cc @pacman100

FSDP support for fp8 is experimental and is on NVIDIA's roadmap. We need to wait on them.

After over a year, will be solved by https://github.com/huggingface/accelerate/pull/2983


Updated proposal

@lattner

Updated with community review feedback
Trimmed to focus the proposal.

Submitted to review manager as pull request per standards for substantive changes in an active review

@erica I'm about to send out the core teams feedback on the proposal.  After I do so, let me know what you want to do with this PR.

@lattner
Toss it. :)
-- E

On Mar 23, 2016, at 9:43 PM, Chris Lattner<EMAIL_ADDRESS>wrote:
@erica https://github.com/erica I'm about to send out the core teams feedback on the proposal. After I do so, let me know what you want to do with this PR.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/apple/swift-evolution/pull/227#issuecomment-200643435

Ok, tossed at your request! :-)


[camera] Add front camera mirroring update on iOS

This PR intents to update mirroring on front camera on iOS devices
https://github.com/flutter/flutter/issues/91491
The current and updated videos, example.zip
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
[x] All existing and new tests are passing.

I have tried to revert the mirroring effect (currently videos are horizontally mirrored) on iOS when front camera is active. The video mirror enabled in CameraPlugin.m#L394-L396.

What is the purpose of having one part of the plugin code enable mirroring only to manually undo that mirroring elsewhere in the same plugin?

I have tried to revert the mirroring effect (currently videos are horizontally mirrored) on iOS when front camera is active. The video mirror enabled in CameraPlugin.m#L394-L396.

What is the purpose of having one part of the plugin code enable mirroring only to manually undo that mirroring elsewhere in the same plugin?

When we remove mirroring from CameraPlugin.m#L394-L396 the camera preview does not show the video correctly (which is video flipped horizontally in the preview and this is not expected behavior from camera) but output is quite right.
I believe the maintainers had 2 options, showing the correct video in the preview (videoMirrored = YES) or saving the correct video for the output (videoMirrored = NO or removing the lines 394:396), I think camera preview has higher priority in this case.

for the initial work, I didn't want to change the main logic so I only applied flip operation on native side. I have tried to do flip operation on Dart side in here camera_preview.dart#L47 by using Matrix4 transformation, seems working properly.
Should I update the Dart code or keep it on native side @stuartmorgan? /cc @bparrishMines
Tested on iPhone 11, iPhone 7 and Redmi 8A with camera plugin example application.
The test code added in camera_preview.dart#L47,
return Transform(
    alignment: Alignment.center,
    transform: Matrix4.rotationY(
        controller.description.lensDirection == CameraLensDirection.front ? pi : 0,
    ),
    child: child,
);

@bparrishMines Any input on the question above? It seems like it would make much more sense to record unflipped and only flip the preview display itself, but I'm not sure if there's context for the original design that I'm missing.

@trK54Ylmz You may also need to handle the fact that Transform rotates prior to painting and not prior to layout. Which could have some consequences in how the Widget is laid out.
@stuartmorgan I believe the Dart solution provided by @trK54Ylmz would definitely be the quickest and easiest solution to this problem. But, I'll provide some context why that is below.
The TLDR is that preview and video recording share the same capture output because it didn't require preview to use a PlatformView (we currently render it to a Texture). And this implementation was written before PlatformViews existed.
The longer explanation is that preview, video Recording, and byte streaming all use the same [AVCaptureVideoDataOutput] because:

An AVCaptureSession can only have one AVCaptureVideoDataOutput at a time. And since all three required this output, they had to share the output frames.
Previews can be streamed to an AVCaptureVideoPreviewLayer. However, as far as I have been able to research, this would require using PlatformViews to show the frames. (e.g. with a UIView). And PlatformViews didn't exist during the implementation.
Video recording could be done with AVCaptureMovieFileOutput. However, AVCaptureMovieFileOutput and AVCaptureVideoDataOutput can't be used with the same AVCaptureSession.
Video recording also couldn't use AVCaptureMovieFileOutput because there is no support for pausing and resuming recording on iOS, only MacOS. And this feature was required by a major customer, so we can't really remove it either. (Side note: support for this on iOS required a complex solution I implemented with AVCaptureVideoDataOutput.

So assuming this is all still true and I didn't forget anything, we could swap out the preview frames to render to a UIView instead. Then the mirroring could be handled separately on the native side.

So assuming this is all still true and I didn't forget anything, we could swap out the preview frames to render to a UIView instead. Then the mirroring could be handled separately on the native side.

We have the same issue on Android though, as I understand it, which is part of why I was suggesting a Dart-side mirroring solution.

I only really know the context of the native side of the API. Most of the Dart code is relatively new to me. But it makes sense from my understanding of how the frames are obtained.
I don't think Android had the same issue since mirroring is handled automatically by Camera2 and there is no option to change it. I think the issue with Android had to do with a rotation on the z-axis: https://github.com/flutter/flutter/issues/76210
@mvanbeusekom Do you have thoughts on this solution since you worked on rotation issues for camera before?

@bparrishMines @mvanbeusekom What's the status on deciding how we want to move forward here?

I think @bparrishMines is correct and this issue only occurs on iOS.
I have been studying the AVFoundation API a bit and I had the impression we could resolve the mirroring problem using the  AVCaptureConnection.videoMirrored() method. Something along the lines of (which is a small extension of the current code at CameraPlugin.m#L414-416):
  if ([_captureDevice position] == AVCaptureDevicePositionFront && connection.supportsVideoMirroring) {
    connection.automaticallyAdjustsVideoMirroring = NO;
    connection.videoMirrored = YES;
  }

I didn't have the time to fully test this, but it seems the suggested solution on the Apple developer forums.

I think @bparrishMines is correct and this issue only occurs on iOS.

Why are people in https://github.com/flutter/flutter/issues/27650 saying it's happening on Android as well though?

There's also a mirroring issue on windows. Camera preview is mirrored (wrong), actual picture taken is not mirrored (correct). Tested both with an integrated laptop webcam and an external usb webcam

There's also a mirroring issue on windows. Camera preview is mirrored (wrong), actual picture taken is not mirrored (correct).

That sounds like correct behavior to me; please file a new issue for discussion.

@trK54Ylmz are you planning on creating an issue for further discussion? Implementation wise @mvanbeusekom's approach sounds very promising IMO.

Thanks for your contribution! Since I haven't seen a reply, I'm going to reluctantly close this pull request for now, but if you get time to address the comments, we'd be more than happy to take a look at a new patch. If you do send a new patch, it would be very useful to reference this one in the description in order to help reviewers see the previous context.

Any update on this? This is happening on Android too @jmagman.
Reversing the mirror is easy for images, but for videos we can't do much without making the user wait, wait and then Hate our app.

This PR is closed, the issue is tracked at https://github.com/flutter/flutter/issues/27650.  We had a big backlog of PRs, which is why this one took so long to be reviewed.  We've cleared out most of that backlog and would happily review a PR similar to this one with the feedback addressed.


pass headers to prepareBody

passing headers to prepareBody can be useful when you want to serialize depending content-type header, for example if it is text/...

Why do this when there is a prepareHeaders method?
Are you needing the headers to make decisions regarding the body?

@DingoEatingFuzz you mean "why not to do this inside prepareHeaders" ?
well there you don't have access to body
you mean "Do you need headers to make decisions regarding body?"
yes
   this.get('/api/songs', function(request){
    return [
      200,
      {'content-type': 'text/csv'},
      "firstname,lastname\nbob,dylon"
    ];
  });

and if I have prepareBody like this
server.prepareBody = function(body){
  return body ? JSON.stringify(body) : '{"error": "not found"}';
}

so I would like to do this
server.prepareBody = function(body, headers) {
  if (headers['content-type'] === 'application/javascript') {
    return body ? JSON.stringify(body) : '{"error": "not found"}';
  } else {
    return body;
  }
}

then I get ""firstname,lastname\nbob,dylon"" double quotes as the header is text/csv

Thanks!

This is now released in 0.12.0


Change the keyboard layout for highlighted text

Description of the new feature / enhancement

you enter text into the text field
select the text in the wrong layout
press the key to change the layout (e.g. Win+Shift+L)
and voila, the text is converted to another layout!

Scenario when this would be used?
People who have more than one keyboard layout installed in Windows are always faced with the problem of typing text in the wrong layout. it would be very convenient to highlight text and use a keyboard shortcut to translate it to the desired layout.
Supporting information
No response

/dup https://github.com/microsoft/PowerToys/issues/14850


Is it possible to share the config.yml for models?

Hi,
I'm wondering if the showing case for the chair is using the same configuration as the neus-blender.yml you provided in the repo, and if it is possible to share the training params for several scenes as a guidance of hyper-params fine-tuning. Thanks in advance!
Currently, the chair model I trained using the provided .yml cannot reproduce the mesh as good as the one in your show case. Here is my test result (256 resolution mesh).

All the results are produced using the given config file. This is probably due to the randomness during training and maybe you should try different seeds to see if results differ :)

It indeed produces a slightly different mesh by changing the seed, but it still easily gets holes, especially on the flat surface.


[BUG] UI n

Description
The UI has too much space between components, especially between the header and main content area, and between different sections of the main content area.

Steps to reproduce

Go to https://www.illacloud.com/hacktoberfest2023#oss
Set the screen size to 570X1336
Scroll down
See error

Version
cloud
ILLA Builder Version
1.0.0
Browser
Firefox Version 118.0.1 (64-bit)
Operating System

[X] macOS
[ ] Windows
[ ] Linux

Additional Information
No response

**Assign me this issue ** @AruSeito !!

Hello, that's what we need. Not need to fix it


.os reports 'Linux' for Android devices

I guess it is technically correct, but with Android being the vast majority of all Linux users, I think it needs to be separated from the rest. Please discuss! :)

@angelcustodio Why didn't you merge the fork into this repository? As you are contributor to this repository this would be nice to have all required things in a single repo.


App services swap behavior discussion

A few of us in the azure channel on the asp.net core slack (sign up page) were talking about the swap functionality and trying to figure out exactly how the auto swap setup works vs. what our expectations are of it. Is this under the kudu umbrella and can be talked about here, or is there somewhere else this should be talked about?

It's part of App Service and not really part of Kudu, but it's probably ok discussing here. You should start with http://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/. @ruslany is the expert on swap, and if there is missing info on that post, he may be able to clarify it.

From the linked blog post:

Then the site in the staging slot gets warmed up. To warm up the site an HTTP request is made to the root directory of the site to every VM instance where site is supposed to run. The warm up request has a User-Agent header set to “SiteWarmup”;
After warm up has completed the host names for the sites in production and staging slots get swapped.

It would be good to get some clarity around what "after warm up has completed" actually means. I can only assume that it doesn't mean a 2XX status code is returned? In practice, if we perform a swap there can be ~60 seconds whilst the live site is unresponsive (and in some cases, time outs, depending on the site).
This makes deployments reaaally painful. The "two-step" "Swap with Preview" gets around this issue, but it's clumsy to use and isn't really integrated into "auto-swap" or the CI functionality in things like VSTS

I have some code that runs on site startup and can be turned on or off with an app setting. This is enabled in my warm up slot, and disabled in my production slot. I had a deploy yesterday where the swap happened without that piece of code running in the warm up slot. This is where some of my confusion starts. The docs seem to indicate that the site will be started up before the swap happens, yet in this instance it wasn't. I've added three endpoints under applicationInitialization but that doesn't seem to have made a difference.
I'm also experiencing what @ctolkien mentioned where the auto swap occurs, and then my site's down for a minute while it starts back up. The whole reason for wanting to use a deployment slot with swap was to prevent that.
Now that I'm using the deployment slot I've also seen my builds go from about 6-8 minutes to 20+ minutes. I'm not sure if that's including the swap time or not, but it seems once the post deploy webhook is fired the swap can take another 5 minutes or so to happen. I have two additional instances of this site running for internal use without deployment slots and those still take 10 minutes or less.
The final thing I've noticed is post swap my initial page load times go up as if the views are being compiled. I'm precompiling my views so I'm not really sure why initial page loads are in the 5 second range. I don't recall this being a problem before the slot & swap was setup.

@ctolkien - having live site unresponsive during the swap is an unexpected behavior that we should investigate. The idea of the deployment slot swap is that the site that is in production slot is never restarted during the swap. Can you please let me know the name of the site where you have this repro and I'll look into this?
As to your question about what "warmup has completed" means, the current logic is as follows:

We first wait until site's worker process has been restarted and picked up the configuration changes (such as slot app settings and connection strings)
If local cache is enabled then we make a request to a root directory of the site and wait until it returns any status code and then keep polling it until the local cache initialization is complete
If AppInit warmup is enabled then we make a request to a root directory of the site and wait until it returns any status code and then keep polling it until the appinit module initialization is complete.

@xt0rted - can you please let me know the name of your site and timeframe when you had a repro? I'll check in our logs to understand your site in production slot is being restarted.

@ruslany dummy1326 and it's the site with portal in its name. My deploys on 10/4 around 5:04 PM EST and the second around 8:27 PM EST (this is the one where the startup code didn't run in the warm up slot).

@xt0rted I see that the site in the swap has completed in 2 minutes, but then the production slot was restarted at 2017-10-03 21:21:27.6907435 UTC, which is more than 10 minutes after the swap. The restart is unexpected and is caused by the bug that we have fixed, but have not yet enabled the fix worldwide. I'll enable it everywhere sometime this or next month, but meanwhile you can enable it just for your web app by adding this app setting to EVERY deployment slot:
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG = 1
@ctolkien - can you try the same and see if it makes any different for your case?

@ruslany I added that setting to my site and upon site restart received the following error on first page load, then all subsequent page loads were fine.
System.InvalidOperationException:
   at System.Web.Mvc.DefaultControllerFactory+DefaultControllerActivator.Create (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.DefaultControllerFactory.GetControllerInstance (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.DefaultControllerFactory.CreateController (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.MvcHandler.ProcessRequestInit (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.MvcHandler.BeginProcessRequest (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.MvcHandler.BeginProcessRequest (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
   at System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute (System.Web, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
   at System.Web.HttpApplication.ExecuteStep (System.Web, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
Inner exception System.MissingMethodException handled at System.Web.Mvc.DefaultControllerFactory+DefaultControllerActivator.Create:
   at System.RuntimeTypeHandle.CreateInstance (mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.RuntimeType.CreateInstanceSlow (mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.RuntimeType.CreateInstanceDefaultCtor (mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Activator.CreateInstance (mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Activator.CreateInstance (mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Web.Mvc.DefaultControllerFactory+DefaultControllerActivator.Create (System.Web.Mvc, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35)

After the setting was in place I did a new deploy (around 4:07 PM EST). The build time was ~12 minutes and then ~5 minutes after the post deploy hook fired the site swapped. After the swap my first page load took at least 30 seconds. After that my second page load took about 30 seconds as well. Then all page loads seemed to load right away.
Something else I've noticed since setting up the deployment slot is my debug snapshots from app insights are no longer being captured. After setting up auto swap I did go back through and make sure app insights was setup on each slot, but the snapshots still aren't being captured. I'm not sure if this is due to a configuration change or possibly an issue with how that works. I can file a bug report on that repo if this is out of scope of the swapping.

@xt0rted - Do you get this exception every time after restart of the site? One of the reason the fix hasn't been enabled everywhere is because there maybe side effects from it. If you get it every time then it is definitely caused by this setting.
In our logs I can see that when we started warming up the site by sending HTTP requests to the root directory of the site the latencies were anywhere from 20 to 50 seconds. Then the last ping latency was 2 seconds and after that we've performed the swap.
Then later I see that there were requests made from a browser to /prospective-buyers/signup and to /api/prospective-buyers/create-profile and those took 23 and 4 seconds respectively. After that all subsequent requests took no longer than 2 seconds.
Do you use AppInit module for your site and do you have those two URL paths included in its configuration?

@ruslany those requests were from me browsing the site after the deploy.  The appinit module is setup with the following settings:
<applicationInitialization>
    <add initializationPage="/" hostName="***-staging.azurewebsites.net" />
    <add initializationPage="/heartbeat" hostName="***-staging.azurewebsites.net" />
    <add initializationPage="/account/login" hostName="***-staging.azurewebsites.net" />
</applicationInitialization>

Nothing special happens on those pages, I just added them in to see if anything changed during deploy.

@ruslany as far as I can tell that exception only happened once after first adding the setting, since then I haven't seen it.

Ok, then it is not conclusive if this exception is the result of adding this new app setting.
Even if the root directory and other pages listed in AppInit module have been warmed up it still may be possible that other pages would take longer on the first hit. If you want them to be warmed up too then I would recommend adding them to the AppInit configuration.
The issue with debug snapshots and deployments slots is something I have not heard about before. We'll need to look into this.

The name of the site is dummy90210
OK, doing some testing right now.
Have had the production site return HTTP502 timeout - and be unresponsive.
We also had an error logged with resetting the slots be logged.
Visualised:

This does not have the WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG = 1 in place - just testing vanilla at the moment.

@ctolkien - yes, I see in our logs that the site is restarted for the same reason as in @xt0rted's case. The app setting should prevent that.

@ruslany  - I put that app setting in place. It seems "improved", but still no seamless. We still logged 500 errors for timeouts (last part of graph):

And the response time shot up to 30 seconds:

No idea if related, but there is a stack of data usage in line with when swaps are taking place:

Also CPU usage spikes right up whilst this is taking place, which I guess makes sense... in that it is having to reboot the staged site - not sure if that is what is impacting the performance of the live site.

I triggered a swap with preview and as soon as I did my live site hung for about 20 seconds. When the swap was completed the site then hung again for another 20 seconds or so, second page load hung about that long as well, then the rest of the page loads seemed fine. This was completed around 7:11 PM EST.
I then triggered the swap again to get back to where I started. As soon as I did my live site hung for around 50 seconds on first page load, and 25 seconds on second page load then the rest were fine. Once the swap was completed the site then hung for around 20-30 seconds for first page load and a little less for the second. This was started at 7:14 PM EST and completed at 7:21 PM EST.
During the swaps I'm not seeing any 500 errors, the data in/out seems fine, requests are up some, and the average response time goes up.

@xt0rted - I am wondering if these latency increases are caused by the fact that both production and staging slots run on the same VM instance so when the site in the staging slot is restarted during the first step of swap with preview it causes more CPU usage on the VM which affects the site in the production slot. Also after the swap is completed we restart the "used to be in production" site which again may increase the CPU usage. I see in the VM logs that CPU spiked around the time you performed the swap with preview.
We are in a process of enabling swap between slots that are located in different app service plans. With that you would be able to place production and staging slots in different VMs so that during the swap they do not affect each other's performance.

@ruslany right now kudu is doing my build & deploy, would moving this out to say AppVeyor with webdeploy help at all? That's been my plan all along (already using them for PR builds), I've just wanted to get a two stage deployment in place first.
I have two other sites and some functions running in this VM. None of them are doing much, but I could see about moving the functions out.
I also forgot about Local Cache. None of my sites store anything on disk that needs to be persisted between reboots, so if enabling that could help I can try doing that as well.

We are using AppVeyor, it's not making any difference.

We are in a process of enabling swap between slots that are located in different app service plans. With that you would be able to place production and staging slots in different VMs so that during the swap they do not affect each other's performance.

That's going to double my clients costs - they aren't going to wear that :/

@ruslany I did another deploy earlier and the same things happened, existing slot restarted, the staging slot started to warm up, then after the swap the new production slot restarted again. The deploy finished around 10:27 AM EST and the swap happened about 5 minutes later. Here's the cpu/memory graph from that time span.

We're running on a single S2 plan right now with zero traffic to the site when this deploy happened, and no webjobs of functions running (aside from the queue triggers polling). The only resources in use was kudu doing the build & deploy and I was the only user on the site.
Over the weekend I was looking around the web and I kept finding people asking about this same thing, why is the production slot restarting after swap. There's a number of these questions on Stack Overflow and Server Fault dating from this past July to over 2 years ago. Everyone asking about this seems to think that there should be no downtime and no cold start but runs into the similar issue of the slot restarting after swap, and the responses are just people reiterating what the docs & your blog post says. I've yet to find someone who says they're actually running with this setup working as intended.

@ruslany Hi Ruslan! I've also been a heavy user of deployment swaps for a while now - since they came out. We all totally understand the requirement for a restart when you have PINNED application settings. So that's ok.. .. but it feels like someting in the deployment workflow is not working as expected. It's like, something is out of step.
What we expected was a deployment workflow like the following:

Human swaps slot_a to slot_b
LB takes slot_b offline
normal stuff happens, like app settings are copied over, etc
hit the 'offline' website to warm it up.
wait for 200 OK (or whatever the requirements for 'website is warm/ok/online' is .. as mentioned above).
** At this point, the site is now considered READY if HTTP200OK was receieved **
Tell LB to now stop pointing to the old slot and point to the new slot.

If feels like the LB flips over to the new slot SOONER than it should and as such, starts sending requests to that way soon than it should, before the site is really fully deployed, warmed and ready to rock'n'roll.

I just stumbled upon the xdt transform wiki page and the http to https redirect rule looks a little different from mine (I don't have the <add input="{WARMUP_REQUEST}" pattern="1" negate="true" /> condition). This has me wondering, could some of the issues we're seeing in regards to warm up be due to not having that condition in the rewrite rule? This Stack Overflow question from a few months ago seems to hint towards this as well.

@xt0rted it could be, is it could prevent the warmup requests from actually reaching your app.

We run CloudFlare (as does @PureKrome  from what I understand) in front of all our sites - and it will redirect all HTTP requests to HTTPS before being sent on to our origin server. HTTP requests never reach us.

As what @ctolkien said.
Also, we have other sites that use the URL redirection in the web.config and they do all http => https 301 PERM's.

@ctolkien , @PureKrome - yes, warmup logic does not follow the HTTP redirects.

I've updated my url rewrite rule to include <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />. I think this helps some since I'm not noticing any restarts or unresponsiveness during deploy, but that's as far as it goes towards the original issues. The exact changes I made was adding the rewrite condition, and changing the app init section to a single endpoint of / without any host.
What I've observed over my last few deploys is as follows:

deploy to the staging slot is triggered
staging slot builds & deploys
site warm up is triggered
auto swap is triggered the moment site warm up is finished
the now production slot restarts
30 seconds later the production slot comes back up
about a minute or two later the now staging slot restarts
the production slot also restarts
30 seconds later the production slot comes back up

Using the app insights live metrics view I can see the cpu peg at ~45% for a good 30 seconds or so each time the site starts up, so I can confirm with certainty that the staging slot is warming up before the swap happens.
I do have two slot settings, one of which is to keep my webjobs disabled in the staging slot since I don't want them running outside of the production slot. Given this setup, is it possible to achieve a zero downtime deployment as we're expecting?

@ruslany Thanks for the reply. So .. if we have a really simple .NET Website with a simple URL redirect rule => any/all HTTP traffic gets redirected to HTTPS (which to me is a pretty damn common scenario) then ..

warmup logic does not follow the HTTP redirects.

which means the warmup logic doesn't apply.
If yes - then this is pretty damn serious.
Would be really nice if there's an option in the Azure portal for us (the developers) to set the warmup URL because then we could :-

define http or https
define any route, like / or /health or /ping or whatever..

Yeah, that the warmup modules doesn't follow the standard HTTP status codes is a.) very surprising b.) seemingly undocumented. I would strongly suggest it is a bug - just about everysite these days should be automatically redirecting to HTTPS.
I've just attempted the following:
<rule name="Azure Exception" xdt:Transform="Insert" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
            <add input="{HTTP_HOST}" pattern="myclient(-\w+)?\.azurewebsites\.net" />
          </conditions>
          <action type="None" />
    </rule>

This stops other (HTTP -> HTTPS) that we have configured.
Have also configured:
<applicationInitialization xdt:Transform="Insert">
      <add initializationPage="/" hostName="myclient.azurewebsites.net" />
    </applicationInitialization>

To hit the azurewebsites.net hostname, so as to not run through CloudFlare.

Response time shows at 5 mins...
However, I don't know if I trust that figure, it could be from the "staging" side before promoted to production.
Am going to script out some tests to measure TTFB from a remote location whilst a swap takes place.

OK, it works!
I wrote a quick and dirty PowerShell script:
do {
    $elapsed = [System.Diagnostics.Stopwatch]::StartNew()
    Invoke-RestMethod $clientUrl -MaximumRedirection 0 | Out-Null
    Write-Host "Elapsed Time: $($elapsed.Elapsed.ToString())"
    Start-Sleep -Seconds 1
} while($true)

And the results are here:
https://gist.github.com/ctolkien/33e646c675f6da2455b1a49d852983fb
TL;DR - a few requests broke 1 second but nothing catastrophic. No timeouts, HTTP500's either.

OK wait, my solution shouldn't work:
<applicationInitialization xdt:Transform="Insert">
  <add initializationPage="/" hostName="myclient.azurewebsites.net" />
</applicationInitialization>

That is going to hit the production site, not the staging site.

@ruslany knows best, but I think it's something that comes from IIS and is not new to App Service. @ahmelsayed mentioned it in this old IIS AppInit post. It doesn't seem to be well documented though...

I turned auto swap off and I'm working with the manual swap for right now seeing if I can get that working. So far I'm not having any luck with that either.

That's a shot of my CPU after I triggered the swap. The 60-40 second range is when the staging slot was warming up, the 40-25 second range is after the warm up but before the actual swap, then the swap happened, and from 25-0 is when the production slot started back up.

This is 5-6 minutes later when I refreshed the 3 pages I had open from after the swap. All hung until the ~10 second mark when the cpu died back down, and it's been flat with instant page responses since then.
Upon further investigation I noticed in my log files that the site only ever started up once, but at the exact time of the cpu spike 5 minutes later there were these two groups of entries (not sure if they're both for the production slot, there's 8 log files for this timespan for some reason).
2017-10-17T04:37:10,Verbose,******,-1,SnapshotHelper::TakeSnapshotTimerCallback,
2017-10-17T04:37:10,Verbose,******,-1,SnapshotHelper::TakeSnapshotInternal - no new files in CodeGen,
2017-10-17T04:37:13,Verbose,******,-1,SnapshotHelper::TakeSnapshotTimerCallback,
2017-10-17T04:37:13,Verbose,******,-1,SnapshotHelper::TakeSnapshotInternal - no new files in CodeGen,

2017-10-17T04:40:36,Verbose,******,-1,SnapshotHelper::TakeSnapshotTimerCallback,
2017-10-17T04:40:36,Verbose,******,-1,SnapshotHelper::TakeSnapshotInternal - snapshot is newer than freshness threshold ,

That's all that I see regarding the snapshotter though and the only thing logged during that time.

@PureKrome @ctolkien - the reason the warmup logic does not follow redirects is that because the warmup bypasses our frontends and goes directly to each worker that hosts the site. The workers do not have knowledge of HTTPS and custom domains, only frontends do. So if a site has rewrite rules to enforce a domain name or https then warmup code won't be able to make requests to the workers after redirect.
The suggestion to define a specific route to hit to initiate a warmup is interesting. I think we can add that capability.
The  WARMUP_REQUEST is a server variable set by IIS AppInit module. When the first request to a site is made it starts the appinit module which in turn makes requests to all the URL's listed in the appinit configuration section in the web.config file. All those requests have the WARMUP_REQUEST server variable set to 1.

@ctolkien - when a first warmup requests is made to a site's worker process the AppInit module in that worker process starts and it makes internal child requests to all the URL's listed in the configuration in web.config file. This configuration that you used:

just means that when it makes HTTP request to the "/" page it will set the HTTP host header to myclient.azurewebsites.net. It does not mean that it will hit the production slot.

@xt0rted - I assume you are still swapping this site ("dummy1326 and it's the site with portal"). I'll check our logs today to see what's going on.

@ruslany correct, same site

OK,
So I spent all of yesterday  running every scenario and writing up a giant doc of everything I'd learned.. only to discover only one of the deployment slots was running the correct config and it was all for nought.
I have managed 0 impact swaps on an S1 instance. Here you can see a user seamlessly transition from version 722 to 733:

Which is:

However it's the lead up to this swap that is the issue. I haven't nailed down the exact specifics, but it seems like rebooting the staging slot prior to swapping can put enough load to cause major issues for your production users - with response times peaking up to 30 seconds.
Then again, I've also had the CPU maxed and have no discernible impact on production users:

(Couldn't easily get a screen grab of the previous 40 seconds, but all requests were < 1 sec, some much faster).
So as things stand right now - the below is probably all wrong:

Warmup is working. I think. It seems the warmup request is fired to the staging slot at standard foo-slotname.azurewebsites.net hostname - this should not be impacted by CloudFlare.
We had a canonical host name redirect in place which would have stopped warmup requests making it through. Have had to add the following conditions:

<add input="{HTTP_HOST}" pattern="[\w\d-]+\.azurewebsites\.net$" negate="true" />
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
<add input="{HTTP_USER_AGENT}" pattern="^AlwaysOn$" negate="true" />

AlwaysOn suffers a similar fate re: not respecting redirects. I disabled CloudFlare and have logs of it hitting a random hostname that we have configured for production. Which makes it effectively useless for this scenario.

End of the day however, I still don't have seamless deploys. Having requests spike to 30 seconds still isn't good enough. More testing required to determine the secret sauce that had us swapping without requests to prod being majorly impacted.

@xt0rted - for the swap that happened around at 2017-10-17 04:29:39.3249895 UTC I do not see in our logs any subsequent restarts of the site in production 5 minutes later. I see a couple of requests that took around 20 seconds shortly after the swap. One to the "/" and one to "/marketplace".
I've noticed that in your appinit configuration you only have this url path:
    <applicationInitialization>
      <add initializationPage="/heartbeat" />
    </applicationInitialization>

I recommend to add "/" there too. Without this what happens is that swap warmup makes request to the "/" page and gets redirected to HTTPS because at that point "WARMUP_REQUEST" is not set yet. So it does not actually warmup your application's root URL. If you add "/" there then appinit module will make request to the root and "WARMUP_REQUEST" will be set, so your redirect rule won't be executed.

@ruslany the reason I removed / is because that will redirect to the login page. I switched it for /heartbeat since that route always returns a 200 response and doesn't require auth. Should I still include an entry for / or does that not work in my setup?

I see that there were deployments at the following times:
2017-10-17 03:44:34.6635553 UTC (which is close enough to 11:42 PM EST)
2017-10-17 04:26:33.6181898 UTC
In both cases I do not see the logs that would indicate that the site has been restarted any time soon after it got into production slot.
I would still try to include "/" there anyway. The redirect to login page happens from your application code, not from the rewrite rule. This means that at least some code path in app will be executed during warmup.

For what it’s worth, I also ran into the problem of cold starts after swaps after migrating some apps to Azure App Service, and I traced it to an HTTPS redirect rule. The request to / would get redirected to HTTPS, but that happens early enough that the juicy stuff in App_Start never ran, leaving it to the first real user request to wait on it. It made sense when I figured it out, but was not intuitive and will probably only get worse as HTTPS becomes the default.
<rewrite>
  <rules>
    <clear />
    <rule name="Do not force HTTPS for application initialization" enabled="true" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="localhost" />
        <add input="{HTTP_USER_AGENT}" pattern="Initialization" />
      </conditions>
      <action type="Rewrite" url="{URL}" />
    </rule>
    <rule name="Force HTTPS" enabled="true" stopProcessing="true">
      <match url="(.*)" ignoreCase="false" />
      <conditions>
        <add input="{HTTPS}" pattern="off" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

For a few weeks now I've been doing manual swaps (no auto, no swap with preview). This has been giving me a better experience than the auto swap setup I had, but I haven't tried going back to auto swap since the url rewrite rule was updated to handle warm up requests.
What I'm seeing with this setup is all of my pages have a <200 ms load time until shortly after a swap is initiated. Once initiated the load times shoot up to 20-25 seconds. Based on the logs the site is not restarting when this happens. Instead it seems as if the "warmed up" pages need to be warmed back up. I'm not familiar with the inner workings of asp.net in this regard, but it's almost as if something with the swap initiation is invalidating a low level .net cache. The time it takes for this to happen seems to vary, it can be anywhere from a second or two after initiation on up to about 20 seconds later.
I've adjusted my warm up end points so /, /account/login, and /account/register are all hit before the swap. The login & registration pages take a couple extra seconds and then they're <200 ms from there on out. Everything behind the login page hits the dB. What I've seen on these pages is there's a 20-30 second load time on most of these and then they settle in at <200 ms. While these pages are hanging the login & registration pages are responsive and continue to have <200 ms load times.
Once I realized this was happening I setup MiniProfiler in production. This is showing me that when I hit refresh after the swap my / page starts loading right away, but there's a 20-25 second hang on the first dB hit. Further investigation has shown that EF caches views/metadata on first hit and that there are some ways to pre-compile that but those resources are years old and I just haven't had a chance to try any of it out. The EF docs even mention this and the built-in apis to work around it, but there's no out of the box solution from EF.
As of now I want to try setting up a /warmup route that simply queries a couple of the dB tables for the first row and to include that in my list of warm up pages. I'm not sure how much time that may cut off from the other pages, but for now that's my next step. Once I see how that goes I'll try moving back to auto swap to see how that works.

As a side note, the profiling I've been doing has really opened my eyes up to just how poor EF's performance is if you're not really careful with it. For instance source.Skip(result.PageIndex * result.PageSize).Take(result.PageSize) doesn't generate a parameterized query, nor do most of my where clauses, while source.Skip(() => skip).Take(() => take) does. For the most part these things aren't bad without load, but they'll definitely become an issue with the resources available on Azure vs. local dev where most of them aren't even noticeable to me. I really wish the EF team had some Roslyn analyzers for these things since they do mention them deep in the docs where very few will see it.

@xt0rted very interesting info there Brian!
One thing that I keep seeing is the HTTPS problem. I'm thinking about starting new side projects with no https anymore. I used to always enforce it, etc. and then have the URL-Rewrite rule to force all http to https. Insertad, maybe now started playing with moving this concern to CLOUDFLARE. so the only public way into my website is via CF which terminates the HTTPS connection and then passes the query to my Azure App Service website as http, accepting that the traffic from CF->Azure shouldn't be acceptable to a ManInTheMiddle attack.
This isn't a solution for all, though ... which means this problem still exists and hopefully can be resolved.

Instead, maybe now started playing with moving this concern to CLOUDFLARE.

We have CloudFlare do our HTTP -> HTTPS redirection currently but I'd still hesitate to remove HTTP -> HTTPS redirection rule from our site - if we happen to move away from CloudFlare, or it's temporarily disabled, etc. then it's easy to get overlooked.
At the moment, I think the best course of action is to have an IIS rule which matches on Warmup/AlwaysOn requests and then stops processing all further rules.
Canonical hostname, stripping trailing slashes, etc. there are other rules which can impact this too.
This also doesn't help with Always On either, but that is a discussion for another day.

While we're on the topic of restarts, the past week in East US my S2 instance has been booted to 3 different hosts, which seems a higher rate than normal (used to only happen about once every couple weeks).
In each case, the sites seem to warm up, but then I get a flurry of "can't write to filesystem" errors in my logs, and the new "Diagnose and solve problems" shows a double restart due to storage latency issues, causing 2-3 minutes of very slow response times. It's as if the system is booting me to a new host for upgrades (fine), but then after the LB switches to the new host, the new host immediately restarts due to latency, causing everything to go sideways for a few minutes.

Has East US been just having a lot of updates this week?

I published a blog post that explains in more details how application initialization works and how to fix most common problems with it: "Most common deployment slot swap failures and how to fix them"

So, what does this do then?

How is this implemented? What knock-ons does it have? etc...
Seems to have popped up in the last few weeks on the Custom Domains tab on App Services.

@ctolkien yes, this is a brand new feature, and is now the preferred way of forcing https. It all happens on the Front End server, so there is no need to make any changes to the app itself. This is controlled at ARM API level by the new httpsOnly flag on the site object.

Is there some place things like this get announced? I follow Azure/app-service-announcements but didn't see it there.

@xt0rted it should have been on there, but this tracker being new, things don't go there consistently enough. Hopefully we'll get better over time :)

@davidebbo , can we assume that as this happens on a server in front of our app, that all the app initialising bits discussed above are not impacted as they run local to the app?

@ctolkien correct. The redirection happens before the VM that has your code comes in the picture at all.

I switched from the https url rewrite rule to the https only option in the portal, and I'm noticing some interesting behavior that I wasn't getting before doing that. Post-swap the staging slot seem to start up but no always on requests come in for it according to the requests chart in the portal. If I curl -I https://thesite-staging.azurewebsites.net I get an instant response back  and then the normal ~2 requests every minute or two starts back up.

The spike around 6:40 is when the initial deployment & swap was going on, and then right after 7:00 is when the swap finished. Prior to the swap I was getting ~2 requests consistently coming in from the always on option, but then afterwards they stopped.
When I first enabled the https only option I triggered a deployment that experienced similar issues post deployment but before the swap was initiated. In that instance the staging slot never started up pre-swap which I know for a fact because there's a piece of code that runs in the "staging" environment but not the "production" environment due to a sticky slot setting.

@davidebbo Does the HTTPS Only feature live at the slot level? I had it enabled, did a swap, and it was suddenly disabled, so it either does or I'm losing my mind

It is not a slot setting. It stays with the site instance during the swap. So if you had it on for site in production slot and off for site in the staging slot then after swap it will be off in production slot and on in the staging slot. You'll need to explicitly enable it on all slots if you want to enforce https regardless of swap operations.

@ruslany @davidebbo I'm seeing mentions of a SnapshotHelper in my log file (this isn't new https://github.com/projectkudu/kudu/issues/2583#issuecomment-337119179), but according to the response I got from<EMAIL_ADDRESS>these entries aren't from the app insights snapshot collector. Do either of you know what causes them? Their showing up in my log seems to almost always correspond to when I experience my slow requests (during & after swapping) but I can't find anything saying where they're coming from or what's causing them.
The log entries I saw earlier are:
SnapshotHelper::RestoreSnapshotInternal   SUCCESS - File.Copy
SnapshotHelper::RestoreSnapshotInternal   SUCCESS - process
SnapshotHelper::TakeSnapshotTimerCallback
SnapshotHelper::TakeSnapshotInternal   SUCCESS - Process
SnapshotHelper::TakeSnapshotInternal   SUCCESS - File.Copy

Continuing in this theme, I switched by sites to use the new HTTPS Only option and nuked my SSL rewrite rules in hopes that this would solve the cold starts I'm seeing during infrastructure upgrades when I get booted to a new VM. (Swaps work just fine, but I get nailed with cold starts when I get moved to a new VM, which Pingdom confirms by reporting it as a period of timeout > 30 s.)
It happened again today around 3:30 Eastern as I got booted for the Server 2016 upgrade. After studying my Application Insights logs, I noticed that my staging slots start once, but my production slots start twice (with different AppDomains), about 2 minutes apart, and Pingdom reports (and I experienced, since it was in the middle of the day) slow requests around the timestamps of the last restart.
I had enabled WEBSITE_LOCAL_CACHE_OPTION on my production slots some time ago in an attempt to minimize the number of restarts I experience, and now I feel it could explain why I'm getting hit with these double restarts on infrastructure upgrades.
Is it all possible that the load balancer is switching to the new VM when the normal content share is ready, serves a few requests successfully, then 1-2 minutes later the local cache is ready and the whole thing restarts, and bam! I see a cold start in production?

Hello, just checking in to see if there are any updates to this issue? We are too experiencing restart issues when swapping slots. Similar setup as previously mentioned, web-apps that enforce HTTPS but we also have Cloudflare.
I read the blog post by Ruslan, I tried to apply it, but I don't think it's working 100% for us still so wondering if there are any updates or what the suggested way forward is? With daily or multiple deploys per day, this becomes a severe issue that we will need to solve very soon.

Just want to chime in. I have an open premier issue that has been going on for weeks now with our swaps. I've got a Teams call today to do some real-time diagnostics, but on one of our sites (I have a node in Canada East and one in Canada Central, load balanced behind Front Door) I have autoswap turned on. It seems that after we deploy to both nodes (using Octopus) it's literally 10 minutes before the swap "finishes" (even though the logs said they did 10 minutes ago) and the site shows the newly deployed code. The other sites in question (that I have the support call on) I've turned off autoswap (by Microsoft's request) and doing a manual stop, start, warmup, etc. and the swap is "better" (down to about 2-3 minutes after we deploy from 10) but the other issue is that a 2 minute swap overlaps between nodes, so Front Door sees the entire site down for 1-2 minutes. Less than desirable. I'll post any new findings today and information on autoswap vs. manual. These are all just web apps so no VMs involved.

@bsimser Any news? We can't figure out how to swap app service slots behind Front Door without downtime. It worked perfectly without Front Door.

@tmmueller no word yet. There is a default 30 second timeout in Front Door that will cause a timeout. It's hard coded by default. The PG team just pushed a change out that allows you to change this value to something other than 30 seconds but there's no UI for it. Has to be done with PowerShell. I haven't tried it because as I told premier support (many times) this doesn't actually fix the problem of having both nodes go down at the same time. I've asked many times that I'm willing to manipulate Front Door with PowerShell to take a node down, do the deployment, bring the node back up (in the backend service) but haven't found any PowerShell to do this. Support continues to believe that increasing the default timeout beyond 30 seconds will fix this problem but I don't see how it can.
I've got two systems now, one using a series of steps to deploy the app node by node, and other just to push the updated app to the slot and let autoswap take care of it. Both nodes end up with an overlap of about 2 minutes when both nodes go down which IMHO is wrong. And deployment to the autoswap nodes finishes (as far as returning from the PowerShell command) but still doesn't actually kick in (i.e. you won't see the new site) until at least 10 minutes after that (and then both nodes kick in on top of each other and the entire system is down for 1-2 minutes with a lovely non-configurable non-brandable message from Front Door). Nobody seems to be able to answer me in support on my original questions.
Still trying to figure out a solution.

@bsimser Thanks for the details. We're going to try increasing the sendRecvTimeoutSeconds setting to see if we can at least get it to respond eventually rather than throwing errors at the end of the swap.

I've had the same issues as described above. More specifically, I don't have issues with random restarts, but issues during swapping. I'm on the P1V2 option, with both slots tied to that. It seems when the full swap process starts, the first step is to restart the deploy/stage slot, which causes CPU spikes. This in turn causes performance issues for everything on the same app service plan, since it's the same resources. I've confirmed this by doing the restart manually, which causes similar behavior.
It would be great to be able to isolate the deploy slot resource wise so that it doens't affect the production slot while starting/warming up. By not doing that, the slot swapping becomes much less valuable. The only solution I can see is to load balance between two completely (as in two different app service plans) environments, so you can deploy one environment at a time. Then again, I hoped the point of swapping slots was to not needing that...
PS. It's also very strange that the actual swapping takes so much time. 5+ minutes seems unreasonable. It would also be wonderful if the (re)start of an app doesn't take that long and use up that many resources, albeit I understand that's a trickier thing to deal with.

@cjblomqvist the CPU spikes are worrysome. Like you mentioned the only option is to separate the nodes. That's what I have setup. I have a P2V2 node in Canada Central with a deployment slot, and the same in Canada East with Front Door load balancing between the two (pro tip: unless you set the latency sensitivity to something other than 0 it won't round-robin and the load will come from the nearest data centre, which in the case of Canada means you're probably always getting served up form one node only).
The problem with this approach (which still exists to this day) is that either using autoswap or manually starting the swap, there's an overlap of 1-2 minutes when both sides are down. Luckily this has decreased with the P2V2 nodes so it's hard to detect (and sometimes we get lucky and there's no downtime) but it's still not 100%. As for load balancing, at some point, hopefully the Traffic Manager AzureRm commands will be available for Front Door then I can just shut down one side, do the deployment to it, then bring the other side down but again in all my testing, there are delays everywhere when you run PowerShell commands and even though they finish you still might see the actual results for a few minutes.
Trying to achieve zero downtime seems almost impossible with the slot swapping behaviour so far for me.

1-2 minutes when both sides are down is in no way acceptable, especially running multiple instances with frontdoor!
We need to deploy updates and have them be seamless midway through users making purchasing decisions on our site. Likewise, we've discerned that it is the restarting of the staging slots which can wreak havoc on the CPU, which in turn impacts production users.
Would be awesome, to ... perhaps set the priority of that task to lower so that it doesn't impact production. I don't care if warming up staging takes another 30 seconds.

Another 3 months with no updates. Anyone heard anything?

We are trying to migrate from cloud services classic to app services and I ran into this exactly issue - my production slot performance goes totally out of wack during a swap.  It seems that the CPU on the staging spikes and causes the production response time to 10x.
Is there now a way to use 2 different app service plans one for prod and one for staging?
if not, how can people run production sites on app services? I'm going to have to abort this and keep my site on cloud services...

@raaviiqbal load balancing is most likely your only alternative to avoid the spikes (which will give you basically the same effect as swapping with two different resources, but less convenient)

@raaviiqbal load balancing is most likely your only alternative to avoid the spikes (which will give you basically the same effect as swapping with two different resources, but less convenient)

@cjblomqvist gotcha - so the staging swap built into the app service stuff isn't really designed for a production system where it is unacceptable to have impacts to the production response time during swap?
I'm using Azure FrontDoor so would it basically work like this?

use ARM template to deploy an entirely new app service with it's own app service plan
warm it up and run automated tests on it
add it into the frontdoor as a backend
tell frontdoor to route all the traffic to the new backend
destroy the old backend

Sort of like what's described in @philliproux's article here: https://philliproux.com/post/azure-front-door-blue-green-deployments/

@cjblomqvist gotcha - so the staging swap built into the app service stuff isn't really designed for a production system where it is unacceptable to have impacts to the production response time during swap?
I'm using Azure FrontDoor so would it basically work like this?

use ARM template to deploy an entirely new app service with it's own app service plan
warm it up and run automated tests on it
add it into the frontdoor as a backend
tell frontdoor to route all the traffic to the new backend
destroy the old backend

Sort of like what's described in @philliproux's article here: https://philliproux.com/post/azure-front-door-blue-green-deployments/

Yep, although it might make more sense to keep both up unless you're very budget constrained. @raaviiqbal

Yep, although it might make more sense to keep both up unless you're very budget constrained. @raaviiqbal

@cjblomqvist @bsimser  @pollax  - you can split the app service across app service plans now such that the prod slot is on a different plan than the staging slot - thereby eliminating the issue of the slot warmup bogging the CPU and affecting prod traffic.  @ruslany cleared this up for me on his blog and I confirmed it has the desired effect.

@cjblomqvist @bsimser  @pollax  - you can split the app service across app service plans now such that the prod slot is on a different plan than the staging slot - thereby eliminating the issue of the slot warmup bogging the CPU and affecting prod traffic.  @ruslany cleared this up for me on his blog and I confirmed it has the desired effect.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


element (policy/filter/action) method/attribute specifying iam permissions used

will depend on config values, but want to generate an iam policy out.

done and required for all filters/actions


Create jekyll-docker.yml

Hello @Hawthorne001 ... Thanks, but we're not going to include anything Jekyll/Docker related in the Blazor samples.


MACOSX_DEPLOYMENT_TARGET

I suggest to include MACOSX_DEPLOYMENT_TARGET for macOS x86_64 target.
For example, MACOSX_DEPLOYMENT_TARGET=10.11

Hi Aleksid1, can you explain why you would recommend this setting? What would happen if the script is executed with this target on a 10.10 machine?

Markus

Hi Markus,
I modified your script to build dynamic libraries. And I discovered that by default  minimum macOS version is set as 11.0 (as my current macOS version). I checked with: otool -l libraryname.dylib
So these dylibs cannot be used on macOS 10.12 High Sierra - I get error on startup of my app.
When I added export MACOSX_DEPLOYMENT_TARGET=10.11 to the script the produced dylibs are not works fine on macOS High Sierra.
Probaby MACOSX_DEPLOYMENT_TARGET=10.10 would be fine for x86_64 Mac (and 11.0 for Apple M1 as already set in the script).

The script builds a binary with the license "nonfree and unredistributable". You should not include such binary or library in any app.

"I modified your script"

But as I can see, changing the deployment target makes only sense if you want to distribute the built binary/library on older systems? Otherwise, we can rely on the systems deployment target.


CI Functional Test: Error with "test_node_workflows_del_active" and "pollers_data_get"

Seeing roughly 3.5% failures during CI Functional Test. After preliminary review by @benbp , "these seem like legitimate bugs." Error being reported:
ERROR: Testing node DELETE:id/workflows/active
Traceback (most recent call last):
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/Continuous-Test/Continuous-Functional/build/test/tests/api/v1_1/nodes_tests.py", line 376, in test_node_workflows_del_active
raise e
ApiException: (500)
Reason: Internal Server Error
HTTP response headers: HTTPHeaderDict({'Content-Length': '55', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"37-zOsyQq00pF/MeBunE+SFSg"', 'Date': 'Fri, 08 Apr 2016 18:47:34 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"Failed to cancel 5707fcc2289fd320a9674c34"}
-------------------- >> begin captured logging << --------------------
urllib3.connectionpool: WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after connection broken by 'ProtocolError('Connection aborted.', BadStatusLine("''",))': /api/1.1/nodes
urllib3.connectionpool: INFO: Starting new HTTP connection (11): localhost
--------------------- >> end captured logging << ---------------------
======================================================================
FAIL: Test GET:/api/2.0/pollers/:identifier/data
Traceback (most recent call last):
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/tmp/.venv/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/Continuous-Test/Continuous-Functional/build/test/tests/api/v2_0/pollers_tests.py", line 157, in pollers_data_get
assert_false(poller.get('lastFinished', False))
AssertionError: Condition was True.

As of 4/27/16, frequency of this issue has dropped to 0.6% (1 failing case out of the sample of 159 runs)

Closing this issue.  As of 5/18/16, frequency is 0% and no longer seeing these failures in CI.


Fix the decoration is not included, when isWrapRequired is called.

Problem & How to solve
When the screen which is using FlexboxLayoutManager is rendered, FlexboxHelper#isWrapRequired is called. In that case, we are using RecyclerView, so the decoration length must be calculated, but it is not calculated in FlexboxHelper#isWrapRequired. So, I added calculateItemDecorationsForChild when FlexContainer has to calculate the decoration.
I know that calculateItemDecorationsForChild does not to be called in FlexLayout, but FlexLayout and FlexLayoutManager is abstracted with FlexContainer, so I could not find the way how distribute calculateItemDecorationsForChild function.
Welcome any comments.

@googlebot I signed it!

Hi @forceson thanks for your pull request and apologies for the delayed reply.
Indeed it should be resolved that the decoration length is not taken into account for FlexboxLayoutManager.
Is it possible to add some test cases that fail unless this pull request is applied?