How to get more information about the B2C-signed in user ?

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Other... Please describe:

Browser:

[x] Chrome version 69
[ ] Firefox version XX
[ ] IE version XX
[ ] Edge version XX
[ ] Safari version XX

Library version

Library version: 0.2.3

How to get more information about the B2C-signed in user ?

For instance what groups the user is member of ?
Or any of the other things you can do with
https://graph.microsoft.com and https://graph.windows.net ?

Is it possible to use the B2C token, in one way or another, to retrieve another type of token,
i.e. an access token for one of these two endpoints ?

@valuesoft-dk you should be able to use the B2C token as any other id token obtained from AzureAD to read user information from graph. There may be some claims differences. The full documentation can be viewed here:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-tokens

@valuesoft-dk did you able to obtain graph token using b2c token. i tried but not success

@parakhj can you please help here.

@parakhj thanks, I have already long time ago read that article and I can use the ADAL client side library for that and so on. But I'm using the MSAL client side library to authenticate and then I have a B2C token. How can I use that token to get an access token for Graph API ? (without authenticating twice).

As mentioned earlier, the B2C token is useless for the Graph API. B2C tokens don't allow you to talk to the graph API. You need to spin up another application (a service application) which uses ADAL (or MSAL) to acquire an AAD token. You can use that to talk to the Graph API.
You don't need to authenticate twice in that case because the service app should be using the confidential client flow (essentially using a client ID and client secret) to get the AAD token

//If the user has authenticated...
userAgentApplication.acquireTokenSilent(graphAPIScopes).then(function (token) {
    //After token is acquired, call the Graph API, using the acquired token
}

@valuesoft-dk Please let us know if the pattern explained in the above comment resolved your issue.

Yes, I can see the idea, so I will put that into practice. Thanks


Admins must still invite themselves to private projects

If a project is made Private, Admins will get Access Denied errors from the non-admin UI on the project unless they are also invited to the project
Steps:

Preview the project - good
Set project to private
Try to preview again - good
Send invite
Try to preview again - FAIL

PR #2014

:+1:


Saved frozen_graph for serving the trained model

Hi,
I used the coach library to train a model for obstacle avoidance using distributed reinforcement learning in AWS Robomaker. I now want to use the model on the real robot as part of the obstacle avoidance ROS node. My issue is that I can't figure out how I can convert the checkpoint files for use with Tensorflow 2.
To be more specific, I found some scripts to convert checkpoint files to frozen graphs for serving models, but this requires the name of the output node. I'm unable to find this name, and more generally I'm not sure to understand how policy are structured inside coach and what i should do.
I tried to use 'main_level/agent/main/online/network_1/ppo_head_0/policy_std' as output node name but it seems like when i use the outputted graph for prediction, I always get the same output, no matter what input I choose.
I'm using the Clipped PPO algorithm and a custom environment. Do you have any guidance on how I can retrieve the policy as a tensorflow or Keras model to use for online prediction on the real robot ?
Thanks a lot for your help,
Feel free to ask for more details if necessary.
Here are some code snippets, first my preset file :
from rl_coach.agents.clipped_ppo_agent import ClippedPPOAgentParameters
from rl_coach.base_parameters import VisualizationParameters, PresetValidationParameters, DistributedCoachSynchronizationType
from rl_coach.core_types import TrainingSteps, EnvironmentEpisodes, EnvironmentSteps, RunPhase
from rl_coach.environments.gym_environment import GymVectorEnvironment
from rl_coach.graph_managers.basic_rl_graph_manager import BasicRLGraphManager
from rl_coach.graph_managers.graph_manager import ScheduleParameters
from rl_coach.schedules import LinearSchedule

from rl_coach.exploration_policies.categorical import CategoricalParameters
from rl_coach.filters.filter import NoInputFilter, NoOutputFilter, InputFilter
from rl_coach.filters.observation.observation_stacking_filter import ObservationStackingFilter
from rl_coach.filters.observation.observation_rgb_to_y_filter import ObservationRGBToYFilter
from rl_coach.filters.observation.observation_to_uint8_filter import ObservationToUInt8Filter
from rl_coach.memories.memory import MemoryGranularity

from markov.environments.base_env import BaseEnvironmentParameters

####################
# Graph Scheduling #
####################

schedule_params = ScheduleParameters()
schedule_params.improve_steps = TrainingSteps(1000000000)
schedule_params.steps_between_evaluation_periods = EnvironmentEpisodes(40)
schedule_params.evaluation_steps = EnvironmentEpisodes(5)
schedule_params.heatup_steps = EnvironmentEpisodes(10)

#########
# Agent #
#########
agent_params = ClippedPPOAgentParameters()

agent_params.network_wrappers['main'].learning_rate = 0.0003
agent_params.network_wrappers['main'].input_embedders_parameters['observation'].activation_function = 'relu'
agent_params.network_wrappers['main'].batch_size = 64
agent_params.network_wrappers['main'].optimizer_epsilon = 1e-5
agent_params.network_wrappers['main'].adam_optimizer_beta2 = 0.999

agent_params.algorithm.clip_likelihood_ratio_using_epsilon = 0.2
agent_params.algorithm.clipping_decay_schedule = LinearSchedule(1.0, 0, 100000)
agent_params.algorithm.beta_entropy = 0.01  # also try 0.001
agent_params.algorithm.gae_lambda = 0.95
agent_params.algorithm.discount = 0.999
agent_params.algorithm.optimization_epochs = 10
agent_params.algorithm.estimate_state_value_using_gae = True
agent_params.algorithm.num_steps_between_copying_online_weights_to_target = EnvironmentEpisodes(30)
agent_params.algorithm.num_consecutive_playing_steps = EnvironmentEpisodes(30)
agent_params.memory.max_size = (MemoryGranularity.Transitions, 10**5)
agent_params.algorithm.distributed_coach_synchronization_type == DistributedCoachSynchronizationType.SYNC

###############
# Environment #
###############

env_params = BaseEnvironmentParameters()
env_params.level = 'RoboMaker-oarl-v0'

vis_params = VisualizationParameters(render=False)

########
# Test #
########
preset_validation_params = PresetValidationParameters()
preset_validation_params.test = True
preset_validation_params.min_reward_threshold = 10000
preset_validation_params.max_episodes_to_achieve_reward = 100000

graph_manager = BasicRLGraphManager(agent_params=agent_params, env_params=env_params,
                                    schedule_params=schedule_params, vis_params=vis_params,
                                    preset_validation_params=preset_validation_params)

Here is the conversion code I used :
import tensorflow as tf
import os, argparse

dir = os.path.dirname(os.path.realpath(__file__))

def freeze_graph(model_dir, output_node_names):
    """Extract the sub graph defined by the output nodes and convert
    all its variables into constant
    Args:
        model_dir: the root folder containing the checkpoint state file
        output_node_names: a string, containing all the output node's names,
                            comma separated
    """
    if not tf.gfile.Exists(model_dir):
        raise AssertionError(
            "Export directory doesn't exists. Please specify an export "
            "directory: %s" % model_dir)

    if not output_node_names:
        print("You need to supply the name of a node to --output_node_names.")
        return -1

    # We retrieve our checkpoint fullpath
    checkpoint = tf.train.get_checkpoint_state(model_dir)
    input_checkpoint = checkpoint.model_checkpoint_path

    # We precise the file fullname of our freezed graph
    absolute_model_dir = "/".join(input_checkpoint.split('/')[:-1])
    output_graph = absolute_model_dir + "/frozen_model.pb"

    # We clear devices to allow TensorFlow to control on which device it will load operations
    clear_devices = True

    # We start a session using a temporary fresh Graph
    with tf.Session(graph=tf.Graph()) as sess:
        # We import the meta graph in the current default Graph
        saver = tf.train.import_meta_graph(input_checkpoint + '.meta', clear_devices=clear_devices)

        # We restore the weights
        saver.restore(sess, input_checkpoint)

        # We use a built-in TF helper to export variables to constants
        output_graph_def = tf.graph_util.convert_variables_to_constants(
            sess, # The session is used to retrieve the weights
            tf.get_default_graph().as_graph_def(), # The graph_def is used to retrieve the nodes
            output_node_names.split(",") # The output node names are used to select the usefull nodes
        )

        # Finally we serialize and dump the output graph to the filesystem
        with tf.gfile.GFile(output_graph, "wb") as f:
            f.write(output_graph_def.SerializeToString())
        print("%d ops in the final graph." % len(output_graph_def.node))

    return output_graph_def

if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument("--model_dir", type=str, default="./", help="Model folder to export")
    parser.add_argument("--output_node_names", type=str, default="main_level/agent/main/online/network_1/ppo_head_0/policy_log_std", help="The name of the output nodes, comma separated.")
    args = parser.parse_args()

    freeze_graph(args.model_dir, args.output_node_names)

The loading and prediction code :
import tensorflow as tf
import argparse
import numpy as np
from tensorflow.python.framework import tensor_util

def load_graph(model_filepath):
    '''
    Lode trained model.
    '''
    print('Loading model...')
    graph = tf.Graph()
    sess = tf.InteractiveSession(graph = graph)

    with tf.gfile.GFile(model_filepath, 'rb') as f:
        graph_def = tf.GraphDef()
        graph_def.ParseFromString(f.read())

    print('Check out the input placeholders:')
    nodes = [n.name + ' => ' +  n.op for n in graph_def.node if n.op in ('Placeholder')]
    for node in nodes:
        print(node)

    # Define input tensor
    input = tf.placeholder(np.float32, shape = [1,12], name='import/main_level/agent/main/online/network_0/observation/observation')

    tf.import_graph_def(graph_def, {'main_level/agent/main/online/network_0/observation/observation': input})

    print('Model loading complete!')
    # Get layer names
    layers = [op.name for op in graph.get_operations()]
    for layer in layers:
        print(layer)

     # Check out the weights of the nodes
    weight_nodes = [n for n in graph_def.node if n.op == 'Const']
    for n in weight_nodes:
        print("Name of the node - %s" % n.name)
        print("Value - " )
        print(tensor_util.MakeNdarray(n.attr['value'].tensor))

    output_tensor = graph.get_tensor_by_name("import/main_level/agent/main/online/network_1/ppo_head_0/policy_std:0")
    output = sess.run(output_tensor, feed_dict = {input: [[-1,0,1,0,1,1,1,1,1,1,1,1]]})

    print("output : " + str(output))

if __name__ == '__main__':
    # Let's allow the user to pass the filename as an argument
    parser = argparse.ArgumentParser()
    parser.add_argument("--frozen_model_filename", default="./frozen_model.pb", type=str, help="Frozen model file to import")
    args = parser.parse_args()

    # We use our "load_graph" function
    graph = load_graph(args.frozen_model_filename)

By doing a little more research I found issues #71 and #374 that pretty mush talk about what I want to do. I'd like to use my trained model for inference in a production environment. Is there a way to directly use the model for inference without using coach framework. I'm using a custom Gazebo environment for training and need to deploy on the real robot.
Computing power is limited and I'd like to avoid loading unnecessary parts of the GraphManager (especially the environment). Using TF Serving also seems a too heavy for my application. So maybe I can use the model as is for inference or define a GraphManager with no environment ?

Hi I want to switch from Clipped PPO to a new algorithm hence I am actually understanding a bit of the coach source code. Have you tried main_level/agent/main/online/network_1/ppo_head_0/policy ?

@ReHoss Yes i tried, but it tells me that it's not a graph...
I should probably precise that I've been using coach version 0.11.1 for training.
I've been able to use solution of issu #374 successfully in version 1.0.0. So my best guess is that i'll use this approach with a dummy environment. I just need to make my Robomaker code compatible with 1.0.0 for training.

I close the issue as the new one i've posted (#450) is more relevant to the evolution of my issue.


antigen update not updating user defined theme

set antigen to a user defined repo. such as antigen theme robbyrussell/oh-my-zsh themes/apple
After update the theme in remote, run antigen update, the local plugins are updated, but theme is still the same.
Go to the plugin folder ~/.antigen/bundles/robbyrussell/oh-my-zsh/themes/, we can see two files, one is apple.zsh-theme and another is apple.zsh-theme.antigen-compat, the later one is actually used but is not updated.

I think my intervention is late on this but as I just come across the same situation, I put my solution for other people coming here.
You can simply use the antigen-cache-gen command to regenerate the updated .antigen-compat file of your local theme.


Kill snark worker synchronously

Thank you for contributing to Coda! Please see CONTRIBUTING.md if you haven't
yet.
Checklist:

[ ] Tests were added for the new behavior
[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them:

Closes #3231

woot! Passed failing integration tests!


Fix typo in 02-stats-overview.md

Description
I noticed #14782 introduced this new feature, but the docs had the wrong property names. This PR just fixes the typo 👍
Functional changes

[x] Documentation is up-to-date.

Was about to fix this as I saw your PR.
Thanks, @jackwh!


Added Web Scraping Scripts

Description
Added web scraping scripts
Fixes #1655
Have you read the Contributing Guidelines on Pull Requests?

[ Y] Yes
[ ] No

Type of change
Please delete options that are not relevant.

[ ] New feature (non-breaking change which adds functionality)

Checklist:

[ Y] My code follows the style guidelines(Clean Code) of this project
[ Y] I have performed a self-review of my own code
[ Y] I have commented my code, particularly in hard-to-understand areas
[Y ] I've edited the SCRIPTS.md and link to my code.
[ Y] I have created a helpful and easy to understand README.md
[ Y] My documentation follows Template for README.md
[ Y] My changes generate no new warnings
[Y ] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works.

Mention the Issue Number.


[QUERY] Azure.AI.OpenAI Inference deploymentId can be both passed as ctor and method parameter

Library name and version
Azure.AI.OpenAI
Query/Question
Stemming from the discussion from this PR
Currently a user would be able to supply the deploymentId both as a constructor parameter and method parameter. Which is confusing as the user wouldn't be able to know which would be used at the time of the request.
Environment
No response

@tg-msft @KrzysztofCwalina opened this as a separate issue as the PR where the comment was made has been closed.
I think we need to do one of two things
Option 1

Update the method signatures to remove deploymentId
Remove ctors that don't have deploymentId
Add deploymentId to the AzureKeyCredential ctor as well

Option 2

Remove the deploymentId from the ctor for now

The issue with option 1 is its unclear how to specify that a parameter is a client scoped parameter I am working with @johanste on this to see if its something we can do in the short term.  We had this capability in swagger but its not finished yet to my understanding in cadl.  This means our only way to accomplish this is to write custom code for all of the methods which is a lot of debt to carry forward.
The issue with option 2 is we start in a less than ideal spot where the customer has to repeat parameters on each method call.  We would eventually fix this inside the beta timeframe.
My recommendation is to work with @johanste  to see if we can resolve the client scoped parameter quickly and if not revert back to Option 2.

Talked offline and we are going to go with Option 2 for the initial beta and follow up on moving deploymentId to the ctor in a future release.


Support If layer

Support if layer

:octocat: cibot: Thank you for posting issue #686. The person in charge will reply soon.


Expected fn not fn blah

impl Trait for Struct {
	cfg_if! {
		if #[cfg(feature = "blah")] {
			fn blah(&self) {
				unimplemented!();
			}
		} else {
			fn blah(&self) {
				unimplemented!();
			}
		}
	}
}

This generates the error:
expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`, found `fn blah(?) { unimplemented!(); }`

expected one of 8 possible tokens here

What gives? Putting the attribute myself works but the macro has a weird failure.

Thanks for the report! Currently though this crate only works with "item" AST nodes rather than "impl items" lie functions in an impl


STM32F446RE add CAN module to SoC and NUCLEO-F446RE board

Add can module to soc and board

Hi, I just took a look since I have this board... aren't you missing can2 in boards/arm/nucleo_f446re/doc/index.rst (CAN_2_TX & CAN_2_RX pins) and in boards/arm/nucleo_f446re/nucleo_f446re.dts?

Hi, I just took a look since I have this board... aren't you missing can2 in boards/arm/nucleo_f446re/doc/index.rst (CAN_2_TX & CAN_2_RX pins) and in boards/arm/nucleo_f446re/nucleo_f446re.dts?

Thank you for your notice @GunZi200. You're right, but currently there are many reasons, why I not added can2:

At the moment the can stack for stm32 does not supports two can modules at same time (see can_stm32.c line 26).
With already added can1 it is very simple to add can2. This is just almost copy'n'paste operation and good pctise for newbies :smiley:
I've added support of can2 to the stm32f446Xe SoC. Thus step #2 from above should be even simpler.

@erwango Please confirm changes.

@MaureenHelm Please merge.

@MaureenHelm Please merge.

A second approval is required before merge.


GitHub IO: Reduce noise

To remove the "noise" associated with the project, I suggest disabling the following unused features if it still applies:

Go to General settings and disable the Wiki, Projects and Discussions tabs
If empty or unused, hide Releases and Packages section on the right side

Rational
It is just to simplify things.
For example, if user support is provided via a forum then it is better to turn off Discussions here, so that there is no need to monitor two user support sites, but only one.
If Releases and Packages are not used, so it is cleaner to hide them (to indicate that it is not the way how we manage releases and packages).
Projects feature is rarely used in general and this repository does not use it either. If the user clicks on Projects then an empty page is s displayed. It is better to not display the heading at all, to save the extra two clicks for users exploring the project.
Wiki on Github is meant to be a lighter weight tool for documentation. The issue is that it is too limited, for example contributors either can make changes directly (without pull request) or they cannot make changes at all. It also lead to write redundant content, since Github quite nicely renders markdown pages in the main repository. For small projects it is simpler and more consistent to keep all documentation in markdown files in the main repository.
Co-authored by @lassoan

This comment was adapted from my GitHub saved replies, it is licensed under a Creative Commons Attribution 4.0 International License and you were welcome to reuse it.

I would say remove only Packages
Releases we will likely use
The rest we can keep, they are harmless and we might use them

Keep features disabled until then to avoid making your project look abandoned or half-ready. You can enable them anytime.

Hide: packages, wiki, projects.
Keep: releases, discussions


Watch mode: rebuild takes too long after adding a simple console.log to file (~2 minutes)

Bug Report

🔎 Search Terms

performance, tsc, watch, build, rebuild, declaration, emit, incremental
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about performance.
⏯ Playground Link

Unfortunately I cannot provide a reduced test case as I can only reproduce this on our very large project.
💻 Code
TypeScript 4.1.2

Clone and checkout https://github.com/unsplash/unsplash-web/tree/typescript-watch-issue, branch typescript-watch-issue. This is a private repository but I believe some members of the TS team already have access from debugging previous issues. If you don't have access, please send me your email address so I can provide access (TS team members only).
Run yarn to install TS
Run tsc --build ./tsconfig.json --watch
Wait for the first build to complete
Go to file app/actions/index.ts and add this line anywhere in the file, e.g. at the very bottom: console.log('foo')
Save the changes to trigger tsc to rebuild

🙁 Actual behavior
The rebuild takes too long. On my machine it takes over 2 minutes.
🙂 Expected behavior
I expected the rebuild to be very fast, because we're using all of the performance optimisations at our disposal: e.g. incremental and project references.

One thing I noticed that might be helpful for debugging: the generated declaration file for app/actions/index.ts—target-tsc-build/app/actions/index.d.ts—is fairly small after the first build (after step 4) but then for some reason it is significantly larger after the second build (after step 6). I don't understand why these declarations would change after such a simple change.
Subsequent changes to this file do not suffer from this problem, e.g. if we remove the console.log('foo') line that was added in step 5 and then save the changes to trigger another rebuild, the rebuild is very fast.

I tested this with TypeScript 4.2 RC. The rebuild time is faster but still quite slow—it's down from 2 minutes to about 45 seconds, on my machine.

I tested this again and the rebuild took closer to 1.5 minutes than 2 minutes (TypeScript 4.1.2).
I then upgraded to TypeScript 4.2 RC and repeated the test, and it seemed like there was no improvement.
I don't know how realistic this is but I would like to see rebuilds in the single digits, especially if I'm just adding a console.log for debugging purposes like in my example above.

This is because the d.ts emit takes long time.. The project in question C:/temp/unsplash-web/tsconfig.app.json seems to spend lot of time in .d.ts emit and you would need to diagnose which type is causing this and help annotate it.
Checking with @amcasey to see if our profiling tool can help you with that.
Below shows the timings:
[2:49:14 PM] Starting compilation in watch mode...

[2:49:14 PM] Projects in this build:
    * shared/tsconfig.json
    * tsconfig.app.json
    * webpack/tsconfig.json
    * cypress/tsconfig.json
    * build-tracker/tsconfig.json
    * service-worker/tsconfig.json
    * tsconfig.json

[2:49:14 PM] Project 'shared/tsconfig.json' is out of date because output file 'target-tsc-build/shared/api-env.js' does not exist

[2:49:14 PM] Building project 'C:/temp/unsplash-web/shared/tsconfig.json'...

Files:                           13
Lines:                        12402
Nodes:                        50116
Identifiers:                  19623
Symbols:                      12673
Types:                         4275
Instantiations:                1441
Memory used:               1240090K
Assignability cache size:       531
Identity cache size:              0
Subtype cache size:               4
Strict subtype cache size:        0
I/O Read time:                0.00s
Parse time:                   0.07s
Program time:                 0.08s
Bind time:                    0.03s
Check time:                   0.21s
transformTime time:           0.00s
commentTime time:             0.01s
printTime time:               0.03s
Emit time:                    0.03s
Source Map time:              0.00s
I/O Write time:               0.00s
Total time:                   0.35s
[2:52:25 PM] Found 0 errors. Watching for file changes.

[2:57:22 PM] File change detected. Starting incremental compilation...

[2:57:23 PM] Project 'tsconfig.app.json' is out of date because oldest output 'target-tsc-build/setup-env-vars.js' is older than newest input 'shared/tsconfig.json'

[2:57:23 PM] Building project 'C:/temp/unsplash-web/tsconfig.app.json'...

[2:59:46 PM] Updating unchanged output timestamps of project 'C:/temp/unsplash-web/tsconfig.app.json'...

 Watching for file changes.

Just chatted with @amcasey offline and here is the link to analyze the trace https://www.npmjs.com/package/@amcasey/ts-analyze-trace but it might not show anything apart from the fact that d.ts is slow..  He will be looking into improving analysing which type causes slow conversion but thats not yet part of it

At present, that tool specifically only outputs information about check time.  However, it builds on an underlying tracing system that will show tracing time.  Unfortunately, it nearly always just shows that many files took a small amount of time each.  I've been working on figuring out how to pinpoint problematic input code.

Do you expect the changes in 4.3 beta (https://github.com/microsoft/TypeScript/pull/43314) will help improve this issue at all?

Don’t think so .. at least for the scenario you shared .. because at some point you do need .d.ts calculation and that’s where the issue lies

I spent time trying to enhance the tracing code for another project with slow emit and found more or less what I expected - that tracing is not well-suited to identifying why emit is slow.  Basically, tracing is fundamentally about finding individual expensive calls.  When cost is spread across lots of little calls with the same stack, it's more effective to use a profiler.  Nevertheless, I added a bunch of tiny tracepoints (and disabled sampling), in case there was something I could learn by aggregating.  Some observations:

When outputting JS, printing takes much longer than transforming.  Unsurprisingly, the reverse is true when outputting declaration files.
Most transformation time is spent in typeToTypeNode.  For this repo on this box, a slow call was around 40ms (i.e. well below the threshold where tracing would help) and an average call was closer to 0.5ms.  Some types were converted many times, so a cache might help, but it would be non-trivial because a complex "context" object guides each conversion (maybe it's always the same in practice?).
So far, there are no obvious hotspots in printing (via either tracing or profiler), but it's hard to pick apart because of the deep, recursive call stacks.
A bunch of time is spent writing the files to disk but, in build mode, it doesn't count towards either transformation or print time.

My personal, but unverified, suspicious is that types that require an import() expression in .d.ts files are slow to emit.  Typically, the easiest way to get rid of those, is to explicitly import the required assembly in the input file so that it can be used in the output file.  (These are easy to find with grep and I'd love to hear whether cleaning them up helps.)
@OliverJAsh I don't have access to your sample repo.  It's not urgent, since I don't expect the results to be different than for the repos I've already looked at, but I'm happy to confirm, if you're interested.  first.last@microsoft

@amcasey You should now have access.

Typically, the easiest way to get rid of those, is to explicitly import the required assembly in the input file so that it can be used in the output file. (These are easy to find with grep and I'd love to hear whether cleaning them up helps.)

Any guidance on this would be really appreciated. I've tried to optimise declaration size and emit time using the tricks mentioned in https://github.com/microsoft/TypeScript/issues/34119 but this is as good as I could get it. I wish we didn't have to resort to these tricks.

@OliverJAsh do you mind trying #41219 to see if that is helping in your scenario.. That PR will skip calculating d.ts all together and assume that all your changes are always affect your dependency tree. so there is some trade off with that PR but given that in your code time spent in d.ts is larger even for non local change it might be acceptable.. Just a thought.. we are weighing benefits of that PR and option so your feedback would be helpful.
Thanks

Also #43973 might be relevant to you in case its some kind of visibility calculation taking longer

@OliverJAsh Step one for getting rid of the tricks is working with engaged community members to identify best practices we can identify and automate. ;)
Looks like you're going to hit some snags when you move to TS 4.2 because of the DOM updates.  You'll need to update (or just drop?) @types/resize-observer-browser.
I'm starting with a full build because that's easier to reason about than an incremental build.  I'm already seeing 10 or files that each take 2-3 seconds to emit, which is crazy.  I'll investigate.  Are you okay with me posting paths and sketchy details in this issue or do you want to discuss project-specific issues over email (you have mine)?

Incidentally, you're spending about 1.5 seconds checking @babel/types.  If you don't have a good reason not to, you might want to enable skipLibCheck.

@sheetalkamat Individual .d.ts files are being emitted more than once (and I'm pretty confident the second one isn't a no-op since it also takes multiple seconds).  Expected?
First stack
emitDeclarationFileOrBundle (e:\ts_gh\src\compiler\emitter.ts:452)
emitSourceFileOrBundle (e:\ts_gh\src\compiler\emitter.ts:348)
forEachEmittedFile (e:\ts_gh\src\compiler\emitter.ts:41)
emitFiles (e:\ts_gh\src\compiler\emitter.ts:315)
emitWorker (e:\ts_gh\src\compiler\program.ts:1760)
(anonymous function) (e:\ts_gh\src\compiler\program.ts:1733)
runWithCancellationToken (e:\ts_gh\src\compiler\program.ts:1854)
emit (e:\ts_gh\src\compiler\program.ts:1733)
getFileEmitOutput (e:\ts_gh\src\compiler\builderState.ts:6)
updateShapeSignature (e:\ts_gh\src\compiler\builderState.ts:326)
getFilesAffectedByUpdatedShapeWhenModuleEmit (e:\ts_gh\src\compiler\builderState.ts:547)
getFilesAffectedBy (e:\ts_gh\src\compiler\builderState.ts:279)
getNextAffectedFile (e:\ts_gh\src\compiler\builder.ts:389)
getSemanticDiagnosticsOfNextAffectedFile (e:\ts_gh\src\compiler\builder.ts:1083)
getSemanticDiagnostics (e:\ts_gh\src\compiler\builder.ts:1142)
getSemanticDiagnostics (e:\ts_gh\src\compiler\tsbuildPublic.ts:890)
executeSteps (e:\ts_gh\src\compiler\tsbuildPublic.ts:1101)

Second stack
emitDeclarationFileOrBundle (e:\ts_gh\src\compiler\emitter.ts:452)
emitSourceFileOrBundle (e:\ts_gh\src\compiler\emitter.ts:348)
forEachEmittedFile (e:\ts_gh\src\compiler\emitter.ts:41)
emitFiles (e:\ts_gh\src\compiler\emitter.ts:315)
emitWorker (e:\ts_gh\src\compiler\program.ts:1760)
(anonymous function) (e:\ts_gh\src\compiler\program.ts:1733)
runWithCancellationToken (e:\ts_gh\src\compiler\program.ts:1854)
emit (e:\ts_gh\src\compiler\program.ts:1733)
emitNextAffectedFile (e:\ts_gh\src\compiler\builder.ts:997)
emit (e:\ts_gh\src\compiler\builder.ts:1061)
emitFilesAndReportErrors (e:\ts_gh\src\compiler\watch.ts:337)
emit (e:\ts_gh\src\compiler\tsbuildPublic.ts:904)
executeSteps (e:\ts_gh\src\compiler\tsbuildPublic.ts:1105)

Line numbers are from release-4.2 (fb6c8392681f50a305236a7d662123a69827061f).

Yes and we have todo on investigation on caching the declaration emit but haven’t gotten to it .. One is to get the signature of the file while other is actual emit .. I think I had looked this and we needed to store some diagnostics and emit etc as well as need to handle custom transformers and other api things which makes it not so trivial and hence it was postponed for future

@amcasey

Looks like you're going to hit some snags when you move to TS 4.2 because of the DOM updates. You'll need to update @types/resize-observer-browser.

We have upgraded to TS 4.2 since I originally posted this issue. I have pushed a new branch with master merged in to it: typescript-watch-issue-2. This branch uses TS 4.2.

Are you okay with me posting paths and sketchy details in this issue

That's fine!

@sheetalkamat

do you mind trying #41219 to see if that is helping in your scenario

Here's a branch with that change: typescript-watch-issue-3
Unfortunately, when I save a file (step 5/6 in my original issue description at the top), I get this error:
[11:57:23] Found 0 errors. Watching for file changes.
[11:57:30] File change detected. Starting incremental compilation...

/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:1899
            throw e;
            ^

Error: Debug Failure. False expression.
    at updateRedirectsMap (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:32806:22)
    at Object.update (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:32853:13)
    at createProgram (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:96353:88)
    at executeSteps (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:96497:25)
    at Object.done (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:96324:13)
    at Timeout.buildNextInvalidatedProject [as _onTimeout] (/Users/oliverash/Development/unsplash-web/node_modules/typescript/lib/tsc.js:97031:32)
    at listOnTimeout (internal/timers.js:533:17)
    at processTimers (internal/timers.js:475:7)

@OliverJAsh to give an example of locally optimizing emit, if you export type OwnProps in app\components\MainRouteContainer\components\UploaderContainer\UploaderContainer.tsx, target-tsc-build\app\components\MainRouteContainer\components\UploaderContainer\UploaderContainer-demos.d.ts drops from 6500 lines to 15.
How did I figure that out?  --generateTrace told me which files were slow to emit and then I checked the contents of those files to figure out which types were being expanded, rather than simply named.
Is it ugly?  Very much so - you would only do this after confirming you have a performance problem.
Should the compiler do this for you?  I would argue not - what you export and don't export is an important design decision and the compiler shouldn't be making those for you.  There is, however, room for another tool that would warn you when this happens and point out opportunities.  I'm currently exploring how we could discover cases like this automatically.

Unfortunately, when I save a file (step 5/6 in my original issue description at the top), I get this error:

Thank you for reporting this.. have created #43986 to fix that part

Are you sure the middle one wasn't an incremental build? That's suspiciously fast.

I tested it twice just to double check. Each time I ran my test (following the steps in my original post above) I deleted the build folder to ensure there was no cache.

Is there an option for not checking the types and just run the app without typechecking?


Documentation fixes from last pull.

Pull Request Checklist
Is this in reference to an existing issue?
No.
General

[ ] Update Changelog following the conventions laid out on Keep A Changelog
N/A

[N/A] Update README with any necessary configuration snippets

[N/A] Binstubs are created if needed

[N/A] RuboCop passes

[N/A] Existing tests pass

New Plugins

[N/A] Tests

[N/A] Add the plugin to the README

[N/A] Does it have a complete header as outlined here

Purpose
Fixing a few documentation formatting issues with the last pull.
Known Compatablity Issues
None.

That was a mess, going to rebase.


New TV Show: Artwork of Specials not shown

Version: 3.0-SNAPSHOT
Build: 2018-09-05 00:36
OS: Linux 4.15.0-33-generic
JDK: 1.8.0_181 amd64 Oracle Corporation
What is the actual behaviour?
When I created a new tv show (no data available from tvdb), I added artwork (poster, fanart, banner) to the specials, which was shown in tmm and also stored as season-specials-*.jpg.
When I started tmm again, the artwork of the specials is not shown anymore.
What is the expected behaviour?
tmm should show the artwork of the specials after each restart.
Steps to reproduce:

Create a new tv show.
Add a specials directory and insert the videos
Edit the tv show in tmm.
Add artwork (local files: poster, fanart, banner) to the tv show.
Edit the artwork for the specials. Use the artwork from the tv show.
The specials artwork is stored as season-specials-*.jpg.
Restart tmm.
The tv show's artwork is still shown.
The specials artwork is not shown anymore, but still existing in the tv show's directory.

Additional
Have you attached the logfile from the day it happened?
tmm_logs_2018-09-05.zip

will be fixed in the next build


Derive view descriptions from view names.

This is a very humble first step towards better descriptions.
Next steps:

Use real singleton view value (not just the "name" property) in description - this will allow to populate occasion "birthday" and date (currently showing {occasion} and {timeframe} placeholders)
Update view values on dynamically, if the view has changed (currently showing wrong "..and 2 more products", when there is actually more products)
Allow particles update descriptions of "create" views

I was thinking, there should eventually be a manifest level descriptions (eg "Browsing context") and then view descriptions could be derived from it (eg "Product List from Browsing context")... But i wanted to start with smth simple, to just see how it goes.
Do you mean, smth like:
view PageProducts of [Product] in 'products.json'
description Products from browsing context
? I like this, let me do it as the first of the next steps, because the current solution is kind of ugly.

Do you mean, smth like:
view PageProducts of [Product] in 'products.json'
description Products from browsing context
? I like this, let me do it as the first of the next steps, because the current solution is kind of ugly.

OK, SGTM.


Service Network not working with Azure CNI

Is this a request for help?:
Yes

Is this an ISSUE or FEATURE REQUEST? (choose one):
Issue

Which release version?:
v1.0.20

Which component (CNI/IPAM/CNM/CNS):
CNI

Which Operating System (Linux/Windows):
Linux

For Linux: Include Distro and kernel version using "uname -a"
laadmin@master-1:~$ uname -a
Linux master-1 4.18.0-1014-azure #14~18.04.1-Ubuntu SMP Mon Mar 18 16:15:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Which Orchestrator and version (e.g. Kubernetes, Docker)
Kubernetes 1.14.1

What happened:
In this below the following IP Ranges are in play:

Azure VNet Address Space: <IP_ADDRESS>/16
Azure VNet Subnet: <IP_ADDRESS>/16
Kubernetes Service Range: <IP_ADDRESS>/20

And the following hosts are running:

master-1: <IP_ADDRESS>
worker-1: <IP_ADDRESS>

When building a PoC Kubernetes Cluster using the Azure CNI we're unable to get Service Networking or External Networking to behave as expected. This leads to issues such as CoreDNS being unable to connect to the Kubernetes API.
laadmin@master-1:~$ kubectl logs -n kube-system coredns-6b44cf876f-97l4p
E0425 09:14:45.151912       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:355: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
E0425 09:14:45.152182       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:348: Failed to list *v1.Service: Get https://<IP_ADDRESS>:443/api/v1/services?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
E0425 09:14:45.152477       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:350: Failed to list *v1.Endpoints: Get https://<IP_ADDRESS>:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout

If we spin up a busybox pod we can see it gets a Azure VNet IP from the Azure-CNI as expected:
laadmin@master-1:~$ kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP          NODE
busybox   1/1     Running   0          9s    <IP_ADDRESS>   worker-1

And we can also see that the CoreDNS pods also have VNet issued IPs:
laadmin@master-1:~$ kubectl get pods -o wide -n kube-system
NAME                       READY   STATUS    RESTARTS   AGE   IP          NODE
coredns-6b44cf876f-5dhz4   1/1     Running   0          69s   <IP_ADDRESS>   worker-1
coredns-6b44cf876f-xs9b2   1/1     Running   0          69s   <IP_ADDRESS>   master-1

And we can see that in the default namespace kubernetes has a service with a valid endpoint:
laadmin@master-1:~$ kubectl describe svc kubernetes
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                <IP_ADDRESS>
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         <IP_ADDRESS>:6443
Session Affinity:  None
Events:            <none>

Inside the busybox pod we can connect back to the kubernetes API directly using it's real IP address:
laadmin@master-1:~$ kubectl exec busybox -- wget https://<IP_ADDRESS>:6443/
Connecting to <IP_ADDRESS>:6443 (<IP_ADDRESS>:6443)
wget: server returned error: HTTP/1.1 401 Unauthorized

And we see the following in tcpdump on the Kubernetes API Server:
laadmin@master-1:~$ sudo tcpdump host <IP_ADDRESS>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:44:42.009275 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1418,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:44:42.009321 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [S.], seq<PHONE_NUMBER>, ack<PHONE_NUMBER>, win 28960, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>,nop,wscale 7], length 0
09:44:42.010453 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [.], ack 1, win 229, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.010517 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [P.], seq 1:74, ack 1, win 229, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 73
09:44:42.010546 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [.], ack 74, win 227, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.011104 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [P.], seq 1:1292, ack 74, win 227, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 1291
09:44:42.011900 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [.], ack 1292, win 251, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.011925 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [P.], seq 74:86, ack 1292, win 251, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 12
09:44:42.054068 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [.], ack 86, win 227, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.054714 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [P.], seq 86:428, ack 1292, win 251, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 342
09:44:42.054734 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [.], ack 428, win 235, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.057370 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [P.], seq 1292:1367, ack 428, win 235, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 75
09:44:42.057931 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [P.], seq 428:561, ack 1367, win 251, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 133
09:44:42.058204 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [P.], seq 1367:1724, ack 561, win 243, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 357
09:44:42.058268 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [FP.], seq 1724:1777, ack 561, win 243, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 53
09:44:42.058854 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [.], ack 1778, win 271, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.058884 IP <IP_ADDRESS>.38842 > <IP_ADDRESS>.6443: Flags [F.], seq 561, ack 1778, win 271, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
09:44:42.058913 IP <IP_ADDRESS>.6443 > <IP_ADDRESS>.38842: Flags [.], ack 562, win 243, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0

However, if we try the same connecting to the Kubernetes Service IP:Port (<IP_ADDRESS>:443) we don't see anything in TCP on the Kubernetes API Server and we get a timeout in the busybox pod:
laadmin@master-1:~$ kubectl exec busybox -- wget https://<IP_ADDRESS>:443/
Connecting to <IP_ADDRESS>:443 (<IP_ADDRESS>:443)
wget: can't connect to remote host (<IP_ADDRESS>): Connection timed out

But on the Container Host (worker-1, <IP_ADDRESS>) we do see the following:
laadmin@worker-1:~$ sudo tcpdump host <IP_ADDRESS>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:49:52.842105 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:49:53.844880 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:49:54.868956 IP <IP_ADDRESS>.51678 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:49:55.860944 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:49:57.940864 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:49:58.964929 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:49:59.988911 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:49:59.988926 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:08.180871 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:50:13.300929 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:14.324907 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:15.348950 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:24.308935 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:50:29.428938 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:30.452865 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:31.476861 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:50:58.356911 IP <IP_ADDRESS>.51990 > <IP_ADDRESS>.https: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:51:03.476941 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:51:04.500919 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:51:05.524888 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28

Finally, it's also worth noting that connections to the outside world also end up behaving the same way, example here with me trying to connect to a random cloudflare IP address:
laadmin@master-1:~$ kubectl exec busybox -- wget http://<IP_ADDRESS>/
Connecting to <IP_ADDRESS> (<IP_ADDRESS>:80)
wget: can't connect to remote host (<IP_ADDRESS>): Connection timed out

And once again, similar looking tcpdumps:
laadmin@worker-1:~$ sudo tcpdump host <IP_ADDRESS>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:55:43.264067 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:55:44.276914 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:55:46.292937 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:55:47.124867 IP <IP_ADDRESS>.44692 > <IP_ADDRESS>.http: Flags [S], seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:55:48.404853 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:55:49.428904 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:55:50.452915 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:55:50.452936 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:55:58.644918 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:56:03.764936 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:04.788931 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:05.812919 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:14.772916 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:14.773344 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:56:19.892900 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:20.916894 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:21.940900 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:48.564962 IP <IP_ADDRESS>.45012 > <IP_ADDRESS>.http: Flags [S], seq 962823545, win 29200, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
09:56:53.684930 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:54.708908 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
09:56:55.732900 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28

Dump of iptables -L from master-1
laadmin@master-1:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes externally-visible service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain KUBE-EXTERNAL-SERVICES (1 references)
target     prot opt source               destination

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules */ mark match 0x4000/0x4000
ACCEPT     all  --  <IP_ADDRESS>/16          anywhere             /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             <IP_ADDRESS>/16          /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-SERVICES (3 references)
target     prot opt source               destination
REJECT     udp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns has no endpoints */ udp dpt:domain reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns-tcp has no endpoints */ tcp dpt:domain reject-with icmp-port-unreachable

Dump of iptables -t nat -L from master-1:
laadmin@master-1:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain KUBE-MARK-DROP (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x8000

Chain KUBE-MARK-MASQ (2 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x4000

Chain KUBE-NODEPORTS (1 references)
target     prot opt source               destination

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000

Chain KUBE-SEP-SCDYEFQS53DIYLB3 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>             anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:6443

Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
KUBE-MARK-MASQ  tcp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-SVC-NPX46M4PTMTKRN6Y  tcp  --  anywhere             <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-NODEPORTS  all  --  anywhere             anywhere             /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL

Chain KUBE-SVC-NPX46M4PTMTKRN6Y (1 references)
target     prot opt source               destination
KUBE-SEP-SCDYEFQS53DIYLB3  all  --  anywhere             anywhere

Dump of iptables -L from worker-1
laadmin@worker-1:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes externally-visible service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain KUBE-EXTERNAL-SERVICES (1 references)
target     prot opt source               destination

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules */ mark match 0x4000/0x4000
ACCEPT     all  --  <IP_ADDRESS>/16          anywhere             /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             <IP_ADDRESS>/16          /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-SERVICES (3 references)
target     prot opt source               destination

Dump of iptables -t nat -L from worker-1
laadmin@worker-1:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain KUBE-MARK-DROP (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x8000

Chain KUBE-MARK-MASQ (8 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x4000

Chain KUBE-NODEPORTS (1 references)
target     prot opt source               destination

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000

Chain KUBE-SEP-5NKNC6M5UH7VEERO (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       udp  --  anywhere             anywhere             udp to:<IP_ADDRESS>:53

Chain KUBE-SEP-RTMBYJA6QVQRTSE6 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:53

Chain KUBE-SEP-SCDYEFQS53DIYLB3 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>             anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:6443

Chain KUBE-SEP-VOJPPBBE5YONN4JH (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:53

Chain KUBE-SEP-WLO6D7YSWNLWXGK6 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       udp  --  anywhere             anywhere             udp to:<IP_ADDRESS>:53

Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
KUBE-MARK-MASQ  tcp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-SVC-NPX46M4PTMTKRN6Y  tcp  --  anywhere             <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-MARK-MASQ  udp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>          /* kube-system/coredns:dns cluster IP */ udp dpt:domain
KUBE-SVC-ZRLRAB2E5DTUX37C  udp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns cluster IP */ udp dpt:domain
KUBE-MARK-MASQ  tcp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>          /* kube-system/coredns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-SVC-FAITROITGXHS3QVF  tcp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-NODEPORTS  all  --  anywhere             anywhere             /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL

Chain KUBE-SVC-FAITROITGXHS3QVF (1 references)
target     prot opt source               destination
KUBE-SEP-VOJPPBBE5YONN4JH  all  --  anywhere             anywhere             statistic mode random probability 0.50000000000
KUBE-SEP-RTMBYJA6QVQRTSE6  all  --  anywhere             anywhere

Chain KUBE-SVC-NPX46M4PTMTKRN6Y (1 references)
target     prot opt source               destination
KUBE-SEP-SCDYEFQS53DIYLB3  all  --  anywhere             anywhere

Chain KUBE-SVC-ZRLRAB2E5DTUX37C (1 references)
target     prot opt source               destination
KUBE-SEP-WLO6D7YSWNLWXGK6  all  --  anywhere             anywhere             statistic mode random probability 0.50000000000
KUBE-SEP-5NKNC6M5UH7VEERO  all  --  anywhere             anywhere

What you expected to happen:
Service Networking to work from Pod IPs

How to reproduce it:
Create the following resources in Azure Resource Manager:

1 VNet with IP Range of your choice
1 Public IP (Standard SKU)
1 Public Load Balancer (Standard SKU)

Frontend connected to Public IP
2 Probes, HTTP and SSH
2 Backends, master and worker
2 rules, SSH to master backend, HTTP to worker backend

1 NSG connected to default subnet of VNet (Port 22/tcp allowed from all)
2 Ubuntu 18.04 VMs

No Public Inbound Ports
No accelerated networking
No Public IP
Add to load balancer - one in master backend, one in worker
Using the Azure CLI, add 30 IPs to each NIC, e.g.:

for i in {1..30}; do az network nic ip-config create -g cni-test --nic-name worker-1108 --name pod-$i; done

Install CNI, I'm doing it like this:
mkdir -p /opt/cni/bin
wget https://github.com/containernetworking/plugins/releases/download/v0.7.5/cni-plugins-amd64-v0.7.5.tgz -O /tmp/cni.tgz
tar xzvf /tmp/cni.tgz -C /opt/cni/bin

mkdir -p /etc/cni/net.d
wget https://github.com/Azure/azure-container-networking/releases/download/v1.0.20/azure-vnet-cni-linux-amd64-v1.0.20.tgz -O /tmp/azurecni.tgz
tar xzvf /tmp/azurecni.tgz -C /opt/cni/bin azure-vnet azure-vnet-ipam azure-vnet-telemetry
rm -rf /etc/cni/net.d/*.conf
rm -rf /etc/cni/net.d/*.conflist
tar xzvf /tmp/azurecni.tgz -C /etc/cni/net.d 10-azure.conflist

On the VMs, Deploy Docker/Containerd using your preferred method, again mine is as follows:
modprobe overlay
modprobe br_netfilter

cat <<EOF | tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sysctl --system

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"
apt-get update && apt-get install -y containerd.io
mkdir -p /etc/containerd
cd /etc/containerd
containerd config default > /etc/containerd/config.toml
sed -i 's/systemd_cgroup = false/systemd_cgroup = true/g' config.toml
systemctl restart containerd.service

Deploy Kubernetes using your favourite method, I'm doing it from scratch and I'm happy to provide the complete end-to-end script if thats helpful? But kubeadm with defaults (docker, etc) produces the same results for me.

@cpressland Please try again with Azure CNI v1.0.22. This version supports Ubuntu 18+.

@saiyan86 can we reopen this? After deploying version 1.0.22 onto a node the network stack appears to be broken. External VNet communication appears to be offline and as such the node can no longer communicate with <IP_ADDRESS>. The Kubelet can no longer start as it needs to talk to this IP to get the Node IP Address. Worth noting that node-to-node and pod-to-pod traffic is fine.
Rebooting the node now takes upwards of half an hour as the node gets stuck on the following cloud-init job: Starting Initial cloud-init job (metadata service crawler)...
Finally, before the reboot the issue remained even when kube-proxy was operating in IPVS or iptables modes. So this version doesn't appear to change anything regarding my specific issue.

Destroyed my master-0 and worker-0 nodes and bootstrapped again. Here is the error I get from CoreDNS:
E0504 23:50:58.337751       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:355: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
E0504 23:50:58.337951       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:350: Failed to list *v1.Endpoints: Get https://<IP_ADDRESS>:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout
E0504 23:50:58.338070       1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:348: Failed to list *v1.Service: Get https://<IP_ADDRESS>:443/api/v1/services?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout

From the host this works fine:
laadmin@master-0:~$ telnet <IP_ADDRESS> 443
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.

ifconfig output on the host:
azure0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::20d:3aff:fe0b:488d  prefixlen 64  scopeid 0x20<link>
        ether 00:0d:3a:0b:48:8d  txqueuelen 1000  (Ethernet)
        RX packets 3108  bytes 12431115 (12.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2521  bytes 406059 (406.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

azv0b78befc4db: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet6 fe80::846:ffff:fef1:6eb5  prefixlen 64  scopeid 0x20<link>
        ether 0a:46:ff:f1:6e:b5  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 8937 (8.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 135  bytes 8463 (8.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

azv9e93cc71ba8: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet6 fe80::b0ab:dfff:fec0:e7e6  prefixlen 64  scopeid 0x20<link>
        ether b2:ab:df:c0:e7:e6  txqueuelen 1000  (Ethernet)
        RX packets 121  bytes 8577 (8.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 140  bytes 8764 (8.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet6 fe80::20d:3aff:fe0b:488d  prefixlen 64  scopeid 0x20<link>
        ether 00:0d:3a:0b:48:8d  txqueuelen 1000  (Ethernet)
        RX packets 18270  bytes 14877915 (14.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9773  bytes 1844291 (1.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 59768  bytes 10514916 (10.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 59768  bytes 10514916 (10.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Output of iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-FIREWALL  all  --  anywhere             anywhere
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes externally-visible service portals */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-FIREWALL  all  --  anywhere             anywhere
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */

Chain KUBE-EXTERNAL-SERVICES (1 references)
target     prot opt source               destination

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules */ mark match 0x4000/0x4000
ACCEPT     all  --  <IP_ADDRESS>/16          anywhere             /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             <IP_ADDRESS>/16          /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-SERVICES (3 references)
target     prot opt source               destination

Output of iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             /* kubernetes service portals */

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain KUBE-MARK-DROP (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x8000

Chain KUBE-MARK-MASQ (8 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x4000

Chain KUBE-NODEPORTS (1 references)
target     prot opt source               destination

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000

Chain KUBE-SEP-3KMN2M7HVJ6NJ7R4 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       udp  --  anywhere             anywhere             udp to:<IP_ADDRESS>:53

Chain KUBE-SEP-EODZHVGXMPR65AQG (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>             anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:53

Chain KUBE-SEP-KU4NHU4OEUQXNSNJ (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>            anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:53

Chain KUBE-SEP-SCDYEFQS53DIYLB3 (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  master-0             anywhere
DNAT       tcp  --  anywhere             anywhere             tcp to:<IP_ADDRESS>:6443

Chain KUBE-SEP-V5LWH4IZOOKXWHBQ (1 references)
target     prot opt source               destination
KUBE-MARK-MASQ  all  --  <IP_ADDRESS>             anywhere
DNAT       udp  --  anywhere             anywhere             udp to:<IP_ADDRESS>:53

Chain KUBE-SERVICES (2 references)
target     prot opt source               destination
KUBE-MARK-MASQ  tcp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>          /* kube-system/coredns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-SVC-FAITROITGXHS3QVF  tcp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns-tcp cluster IP */ tcp dpt:domain
KUBE-MARK-MASQ  tcp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-SVC-NPX46M4PTMTKRN6Y  tcp  --  anywhere             <IP_ADDRESS>           /* default/kubernetes:https cluster IP */ tcp dpt:https
KUBE-MARK-MASQ  udp  -- !<IP_ADDRESS>/16          <IP_ADDRESS>          /* kube-system/coredns:dns cluster IP */ udp dpt:domain
KUBE-SVC-ZRLRAB2E5DTUX37C  udp  --  anywhere             <IP_ADDRESS>          /* kube-system/coredns:dns cluster IP */ udp dpt:domain
KUBE-NODEPORTS  all  --  anywhere             anywhere             /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL

Chain KUBE-SVC-FAITROITGXHS3QVF (1 references)
target     prot opt source               destination
KUBE-SEP-KU4NHU4OEUQXNSNJ  all  --  anywhere             anywhere             statistic mode random probability 0.50000000000
KUBE-SEP-EODZHVGXMPR65AQG  all  --  anywhere             anywhere

Chain KUBE-SVC-NPX46M4PTMTKRN6Y (1 references)
target     prot opt source               destination
KUBE-SEP-SCDYEFQS53DIYLB3  all  --  anywhere             anywhere

Chain KUBE-SVC-ZRLRAB2E5DTUX37C (1 references)
target     prot opt source               destination
KUBE-SEP-3KMN2M7HVJ6NJ7R4  all  --  anywhere             anywhere             statistic mode random probability 0.50000000000
KUBE-SEP-V5LWH4IZOOKXWHBQ  all  --  anywhere             anywhere

And again, after a reboot of this node I get the VM go into a very long timeout that takes a long time to clear, this is from the Serial Log.
[  OK  ] Started File System Check on /dev/disk/cloud/azure_resource-part1.
[  OK  ] Started Set console font and keymap.
[  OK  ] Started Tell Plymouth To Write Out Runtime Data.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Update UTMP about System Boot/Shutdown...
         Starting Network Time Synchronization...
[  OK  ] Started ebtables ruleset management.
[  OK  ] Started Update UTMP about System Boot/Shutdown.
[  OK  ] Started AppArmor initialization.
         Starting Initial cloud-init job (pre-networking)...
[    9.283403] sh[755]: + [ -e /var/lib/cloud/instance/obj.pkl ]
[    9.298100] sh[755]: + echo cleaning persistent cloud-init object
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Time Synchronized.
[    9.316719] sh[755]: cleaning persistent cloud-init object
[    9.322984] sh[755]: + rm /var/lib/cloud/instance/obj.pkl
[    9.332687] sh[755]: + exit 0
[   11.261773] cloud-init[760]: Cloud-init v. 18.5-45-g3554ffe8-0ubuntu1~18.04.1 running 'init-local' at Sat, 04 May 2019 23:56:00 +0000. Up 10.09 seconds.
[  OK  ] Started Initial cloud-init job (pre-networking).
[  OK  ] Reached target Network (Pre).
         Starting Network Service...
[  OK  ] Started Network Service.
         Starting Network Name Resolution...
         Starting Wait for Network to be Configured...
[  OK  ] Started Network Name Resolution.
[  OK  ] Reached target Network.
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Started Wait for Network to be Configured.
         Starting Initial cloud-init job (metadata service crawler)...

This is also happening for me when I set a default route on the cluster subnet (service subnet is not accessible from pods).

@cpressland I looked at your iptables nat rules. It looks like a snat rule is missing for external connectivity to happen. I hope that you haven't deploy kubernetes cluster using aks or aks-engine..
Please add this rule and check for internet connectivity
iptables -t nat -A POSTROUTING  -m addrtype ! --dst-type local ! -d <vnet_address_space> -j MASQUERADE

@tamilmani1989 that certainly helps with outbound communication from pods to external sources. Any suggestions on making that persistent on my cluster? And no, I'm not using aks or aks-engine - we're building a cluster from scratch as we have some unique security requirements.
Else, IPVS still doesn't appear to work at all with Azure-CNI, I've yet to track down why. iptables appears to be fine on 16.04, while Azure-CNI renders 18.04 nodes unbootable.

For ubuntu18 please use latest cni.
For persisting iptable rules, you have to install iptables-persistent and do iptables-save. check below link:
https://www.thomas-krenn.com/en/wiki/Saving_Iptables_Firewall_Rules_Permanently

I'm experiencing the same thin using IPVS and Azure CNI.
CoreDNS log:
.:53 2019-09-11T18:42:20.864Z [INFO] CoreDNS-1.3.1 2019-09-11T18:42:20.865Z [INFO] linux/amd64, go1.11.4, 6b56a9c CoreDNS-1.3.1 linux/amd64, go1.11.4, 6b56a9c 2019-09-11T18:42:20.865Z [INFO] plugin/reload: Running configuration MD5 = 00544075aef6676ea56bc6d88f2b7467 E0911 18:42:45.865301       1 reflector.go:134] github.com/coredns/coredns/plugin/kubernetes/controller.go:322: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout E0911 18:42:45.865301       1 reflector.go:134] github.com/coredns/coredns/plugin/kubernetes/controller.go:322: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:443: i/o timeout log: exiting because of error: log: cannot create log: open /tmp/coredns.coredns-5c98db65d4-wsdz9.unknownuser.log.ERROR.20190911-184245.1: no such file or directory
Environment:
OS: CentOS Linux release 7.4.1708 (Core)
Kernel: 3.10.0-693.11.1.el7.x86_64
Kubernetes: v1.15.4
Azure CNI: v1.0.27
CNI Plugin: v0.8.2
CNI: v0.6.0
ipset: ipset v6.38, protocol version: 6
kube-proxy log:
I0911 13:46:44.779517       1 server_others.go:170] Using ipvs Proxier. W0911 13:46:44.824262       1 proxier.go:401] IPVS scheduler not specified, use rr by default I0911 13:46:44.825186       1 server.go:534] Version: v1.15.3 I0911 13:46:44.927248       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 131072 I0911 13:46:44.927303       1 conntrack.go:52] Setting nf_conntrack_max to 131072 I0911 13:46:44.927392       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400 I0911 13:46:44.927451       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600 I0911 13:46:44.928860       1 config.go:96] Starting endpoints config controller I0911 13:46:44.928981       1 controller_utils.go:1029] Waiting for caches to sync for endpoints config controller I0911 13:46:44.929692       1 config.go:187] Starting service config controller I0911 13:46:44.929722       1 controller_utils.go:1029] Waiting for caches to sync for service config controller I0911 13:46:45.029157       1 controller_utils.go:1036] Caches are synced for endpoints config controller I0911 13:46:45.031635       1 controller_utils.go:1036] Caches are synced for service config controller
ipvsadm:
$ ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn TCP  <IP_ADDRESS>:443 rr   -> <IP_ADDRESS>:6443          Masq    1      0          0          TCP  <IP_ADDRESS>:53 rr TCP  <IP_ADDRESS>:9153 rr TCP  <IP_ADDRESS>:443 rr TCP  <IP_ADDRESS>:44134 rr   -> <IP_ADDRESS>:44134         Masq    1      0          0          UDP  <IP_ADDRESS>:53 rr
iptables:
`
$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-FIREWALL  all  --  anywhere             anywhere
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-FIREWALL  all  --  anywhere             anywhere
Chain DOCKER (1 references)
target     prot opt source               destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere
Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere
Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000
Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules / mark match 0x4000/0x4000
ACCEPT     all  --  <IP_ADDRESS>/21      anywhere             / kubernetes forwarding conntrack pod source rule / ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             <IP_ADDRESS>/21      / kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED
`
ipset:
`
$ ipset list
Name: KUBE-LOOP-BACK
Type: hash:ip,port,ip
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16632
References: 1
Members:
<IP_ADDRESS>,tcp:44134,<IP_ADDRESS>
Name: KUBE-LOAD-BALANCER
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-NODE-PORT-UDP
Type: bitmap:port
Revision: 1
Header: range 0-65535
Size in memory: 524432
References: 0
Members:
Name: KUBE-NODE-PORT-LOCAL-UDP
Type: bitmap:port
Revision: 1
Header: range 0-65535
Size in memory: 524432
References: 0
Members:
Name: KUBE-NODE-PORT-SCTP-HASH
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-CLUSTER-IP
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16720
References: 2
Members:
<IP_ADDRESS>,tcp:9153
<IP_ADDRESS>,tcp:443
<IP_ADDRESS>,udp:53
<IP_ADDRESS>,tcp:53
<IP_ADDRESS>,tcp:44134
<IP_ADDRESS>,tcp:443
Name: KUBE-EXTERNAL-IP
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-LOAD-BALANCER-SOURCE-CIDR
Type: hash:ip,port,net
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16792
References: 0
Members:
Name: KUBE-NODE-PORT-TCP
Type: bitmap:port
Revision: 1
Header: range 0-65535
Size in memory: 524432
References: 0
Members:
Name: KUBE-NODE-PORT-LOCAL-SCTP-HASH
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-LOAD-BALANCER-FW
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-NODE-PORT-LOCAL-TCP
Type: bitmap:port
Revision: 1
Header: range 0-65535
Size in memory: 524432
References: 0
Members:
Name: KUBE-LOAD-BALANCER-LOCAL
Type: hash:ip,port
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16528
References: 0
Members:
Name: KUBE-LOAD-BALANCER-SOURCE-IP
Type: hash:ip,port,ip
Revision: 2
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16536
References: 0
Members:
`
modules:
$ cut -f1 -d " "  /proc/modules | grep -e ip_vs -e nf_conntrack_ipv4 ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack_ipv4
ifconfig:
`
$ ifconfig
azure0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
ether 00:0d:3a:7b:1c:de  txqueuelen 1000  (Ethernet)
RX packets 2988967  bytes<PHONE_NUMBER> (1.0 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2661508  bytes 502781258 (479.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
azv6b28cfd207e: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
ether 72:58:81:d0:56:dc  txqueuelen 1000  (Ethernet)
RX packets 527  bytes 32738 (31.9 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1005  bytes 42754 (41.7 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
azv91fdf643bf7: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
ether 6a:9b:4e:12:0b:d7  txqueuelen 1000  (Ethernet)
RX packets 2096  bytes 164001 (160.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2106  bytes 144316 (140.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
azvb791fc10b26: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
ether 66:70:b9:cb:08:1b  txqueuelen 1000  (Ethernet)
RX packets 2083  bytes 162984 (159.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2092  bytes 143195 (139.8 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
ether 02:42:c7:4a:3e:19  txqueuelen 0  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth0: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
ether 00:0d:3a:7b:1c:de  txqueuelen 1000  (Ethernet)
RX packets 3351737  bytes<PHONE_NUMBER> (1.5 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2772953  bytes 513726390 (489.9 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet <IP_ADDRESS>  netmask <IP_ADDRESS>
loop  txqueuelen 1  (Local Loopback)
RX packets 1685102  bytes 240771614 (229.6 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1685102  bytes 240771614 (229.6 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
`
Note: The same setup works when kube-proxy is in iptables mode.


Need to add code to handle power monitoring

I have added the ACS712 to the design. I need to add code to check if there is current andif there is then 1. report that, 2. log it power usage

Code is in place but I need to get the updated boards to test the code


added delay and duration parameters to jfr telmetry device

Have you signed the contributor license agreement? - YES
Have you followed the contributor guidelines?  - YES
Have you run make check-all successfully? - YES
Did you choose a descriptive title and description for your PR? - YES
(Only for maintainers) Did you apply appropriate labels and a milestone?

This closes: https://github.com/elastic/rally/issues/1617
Two additional parameters have been added for JFR

delay
duration

Additionally, the code block for the existing parameter recording-template has been refactored to avoid code duplication.

@elasticmachine test this please

Thank you for the quick and meticulous PR!
I left a question/suggestion about how we expose the options as telemetry parameters (sorry the issue should have thought about it) and that preferably we should namespace them as we do for other telemetry params e.g. node-stats-sample-internal etc.
I haven't tested the PR myself, but triggered a CI run.

I've let my replies. Shall I proceed with the changes? Additionally just wanted to know if there should be separate commits or a single squashed commit?

Shall I proceed with the changes? Additionally just wanted to know if there should be separate commits or a single squashed commit?

Feel free to proceed based on the feedback of @pquentin and mine. No particular preferences for the commits as anyway when it's time to merge we'll be squashing.

@elasticmachine test this please

@elasticmachine test this please

This looks great! We only need to test that it actually works. Have you tried?
Also left a small question.

Although I have checked that the final java cmd is as expected, I didn't get the opportunity to actually test this out.

Thanks for the quick reviews and suggestions @dliappis @pquentin !


Create app bundle

Not creating an app bundle at the moment. Easier to stay with the APKs since I also want to publish on F-Droid.


[Snyk] Security upgrade node from 22.6.0 to 22.10

Snyk has created this PR to fix 4 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

Dockerfile

We recommend upgrading to node:22.10, as this image has only 167 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Integer Overflow or Wraparound SNYK-DEBIAN12-ZLIB-6008963
  264

Integer Overflow or Wraparound SNYK-DEBIAN12-ZLIB-6008963
  264

Integer Overflow or Wraparound SNYK-DEBIAN12-AOM-7197979
  263

Integer Overflow or Wraparound SNYK-DEBIAN12-EXPAT-7855503
  263

XML External Entity (XXE) Injection SNYK-DEBIAN12-EXPAT-7855507
  161

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 XML External Entity (XXE) Injection

🎉 Snyk hasn't found any issues so far.
✅ security/snyk check is completed. No issues were found. (View Details)
✅ license/snyk check is completed. No issues were found. (View Details)
✅ code/snyk check is completed. No issues were found. (View Details)


Failed to load the atom-html-preview package

[Enter steps to reproduce below:]

...
...

Atom Version: 1.0.19
System: Mac OS X 10.11
Thrown From: atom-html-preview package, v0.1.11
Stack Trace
Failed to load the atom-html-preview package
At missing ' in /Users/samyounger/.atom/packages/atom-html-preview/keymaps/atom-html-preview.cson:2:37

SyntaxError: missing '
  at /Users/samyounger/.atom/packages/atom-html-preview/keymaps/atom-html-preview.cson:2:37

Commands

Config
{
  "core": {}
}

Installed Packages
# User
atom-html-preview, v0.1.11

# Dev
No dev packages

This problem persists, even with the new V 1.2.3 update. Is there a resolution? I'm on an iMac (2012) running Yosemite.

I have this problem as well.

I have this issue as well

How to solve?

why atom is so useless on windows?

same problem here - how can it be solved?


Shift tab to get documentation

Kindly implement the shift tab documentation shortcut to get documentation like original Jupiter notebook .

That feature is availalable in the Jupyter power toys extension from this issue https://github.com/microsoft/vscode-jupyter/issues/1307
The language server also provides the Trigger Parameter Hints command, which might be what you're looking for - ctrl+shift+space by default.

Thanks a lot for the information.
On Tue, May 16, 2023, 3:35 AM Aaron Munger @.***> wrote:

That feature is availalable in the Jupyter power toys extension
https://marketplace.visualstudio.com/items?itemName=ms-toolsai.vscode-jupyter-powertoys
from this issue #1307
https://github.com/microsoft/vscode-jupyter/issues/1307
The language server also provides the Trigger Parameter Hints command,
which might be what you're looking for - ctrl+shift+space by default.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-jupyter/issues/13502#issuecomment-1548672024,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZE2UFFSF4LBOWYDD66RPATXGKSC5ANCNFSM6AAAAAAYCSN25I
.
You are receiving this because you authored the thread.Message ID:
@.***>


Adding python library cookiecutter

We plan on putting all edx cookiecutters in this repo. For this PR, we are trying a layering approach to our cookiecutters. Thus, there is a "python-template" cookiecutter that is meant to be called by "cookiecutter-python-library".
Eventually, we will add a "django-template" that builds on top of "python-template".
For now, we are testing this approach through just python.
** I will reach out to IT to move this repo to edx soon

Can you add https://github.com/edx/ecommerce/blob/master/.readthedocs.yml?

I think I'v successfully responded to all your review requests. For now, I'm gonna merge this in and move on to implementing django template on top of this. I will continue fixing things here as they are brought to my attention.


Use the future module to make iteritems compatible with both python2 …

…and python3

Well, tests fail because of
from future.utils import iteritems

I guess instead of iteritems we can just use items, too. Would be simpler.


Introduction page to the foodsaving tool

Showing off its features and its usage.
Possibly creating a how-to video, ask around in yunity.
The page could either be in this codebase or in the upcoming blog.

I scribbled a text with a lot of screenshots here: https://github.com/yunity/foodsaving-docs/tree/master/foodsaving-tool-intro
What do you think? Maybe @djahnie can extend the content? ;)

I love it! Actually I wasn't able to think of anything that's missing; at least not on the spot. Will give it a deeper thought next week. 👍
Also, I guess what's most important is to keep the content up-to-date, whenever there are changes in the UI. I'll try to keep that in mind.

It's in the blog now: https://blog.foodsaving.world/2017/05/11/walkthrough.html