Assembly name cannot be named 'Common' (CodeConfigApplicationContext,  ScanAllAssemblies)

Hi,
Component scanning does not work if the application (class library, console application, etc...) assembly name is 'Common'. Easy to test :
namespace ConsoleApplication1 {
    [Component]
    class A {

    }
    class Program
    {
        static void Main(string[] args)
        {
            var ctx = new CodeConfigApplicationContext();
            ctx.ScanAllAssemblies();
            ctx.Refresh();
            Console.WriteLine(ctx.GetObject<A>());
            Console.Read();
        }
    }
}

Acording to the log the assembly is correctly scan but the object is not registered so GetObject fails.
If Common is a forbidden word it should be documented.

I'm doing a rude experiment with closing this, like what stale bot does, but maybe more human as I will probably actually react to feedback. As this issue has been stale for so long, I'll close it. If it's still an issue you would like to pursue, we can definitely reopen.
With limited resources this is just something that we need to do. Thank you for your understanding.


Preset: Organization owned presets

Wikimedia: https://github.com/jscs-dev/node-jscs/pull/1770#issuecomment-139113833
Airbnb: https://github.com/airbnb/javascript/pull/455#issuecomment-128103763 - ping @hshoff
Wordpress: @paulschreiber @westonruter
If an org wants to update/maintain their preset themselves, they can/should have the option to do? Otherwise we can maintain it.
Then they can update their preset independently of jscs itself and no one has to wait on us to release (although hopefully we can be more responsive in the future).
Example: Wikimedia preset (https://github.com/wikimedia/jscs-preset-wikimedia)
Added preset docs in 2.1.1 notes

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26955156-preset-organization-owned-presets?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

Another idea I had is that we make presets their own npm packages either in different repos, or in this repo (thinking of babel) so we can independently version them.

I'm happy to help out with the WordPress preset if you'd like.

@paulschreiber Ok cool - can make one with https://github.com/jscs-dev/node-jscs/wiki/Creating-a-Custom-Preset-or-Config and then we can use that in own package.json


Succes add alc 270 layout 10

AppleALC-master 3.zip
Here I'll share about my succes build the alc270 0x0100 using layout id 10. Hope u can share it

Hi
What did you change in this resources? Your revision-id is the same as in trunk. Did you made custom resources for this codec? I will not add unknown stuff in AppleALC without explanations. Provide description of what did you change, why and for what hardware.

Hi, I just added my Platfrom ALC270 sound for ASUS Laptop, because it not
same with resource in AppleALC file before and not working for me. So I
added it, and It's working to me. Some ASUS Laptop's user use AppleALC from
my Platfrom ALC270 and it's working for them. I asked to you to reupload
the new file who I have added the new platfrom ALC 270 using Layout 10. I
hope u can do it. Thanks
On Tue, Mar 27, 2018 at 11:59 PM, vandroiy2013<EMAIL_ADDRESS>wrote:

Hi
What did you change in this resources? Your revision-id is the same as in
trunk. Did you made custom resources for this codec? I will not add unknown
stuff in AppleALC without explanations. Provide description of what did you
change, why and for what hardware.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vit9696/AppleALC/issues/259#issuecomment-376598877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR4Uwepi9AVPdq-H3MeDLrNUNJYNOWUUks5tim_cgaJpZM4S6CFy
.


Health check support for long provisioned resources

Health check for external resources like Redis, RDS or other managed services like Mongo Atlas requires an extra step to perform a TCP connection to ensure that the target service is already up and running.
The Flagger project has some generic way to declare this test step, from which we could learn.

Could you provide a little more details on what you are envisioning?

Do you mean by flagger's metrics analysis?

This part:
https://docs.flagger.app/usage/webhooks

Maybe we can focus only at network-based health checks first. Something like this.
apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
spec:
  path: ./terraform
  healthchecks:
  - name: rds
    kind: TCP
    address: ${output.rds_ip_address}:3306
    timeout: 15m
  - name: nginx
    kind: HTTP
    address: https://${output.nginx_ip_address}/ping
    timeout: 15m

Thanks for the details. I implemented the basics of the health checks in the draft PR above. I would like to understand more on in which conditions the health checks should be performed.
IMO, they should be performed after terraform apply. Should the health check result change Ready state and any conditions?

  - name: nginx
    type: httpPost
    url: https://${output.nginx_ip_address}/post
    timeout: 15m

We should not include the HTTP Post method there as a POST normally requires a body content. Please goes with HTTP and assume that it's always the GET method to make thing simple.

In which state/conditions the health checks should be performed? After apply?

Yes, after Apply succeeded.

The condition state of HealthCheck is recorded. HealthCheck = unknown. The reason is "HealthChecking".

Should the health check result change Ready state and any conditions? Add a new healthCheck condition?

Yes to both.

The Ready state become Ready = true, and the reason changed from AppliedSucceed to HealthCheckSucceed.
The condition state of HealthCheck is recorded. HealthCheck = true. The reason can be the same value as above.

Does it perform a health check on every loop?

No, we could add an if to say that it's checking only after the Apply step is perfomed.

When the health check succeed, what should it do in the next loop?

When health check done, please return the Terraform object with a nil error. This will pass thru the reconcile login and it's going normally with Result{RetryAfter: the interval period}.

When the health check fails, what should it do in the next loop?

When checking fails, we'll do it another round with Result{RetryAfter:  health check interval } with an error

What if the user makes a change to the terraform file when the health check is in a failed state?

The current logic should make it thru the normal loop. We could add an if condition to fix that things go wrong.

Might want to consider adding a successThreshold and  failureThreshold to avoid transient network errors triggering health-check failures?
Generally, I think the application of tcp/http healthchecks could be limited, as it might often be the case that there's no network connectivity between the resources being created and the tf-controller. If outputs could be passed to exec then something like the following would be more practical:
exec: "aws s3api head-bucket --bucket {{ outputs.bucket_name }}"

Generic health check would be a great idea, @phoban01
I'll have another issue to track it as a follow up of this one!

When checking fails, we'll do it another round with Result{RetryAfter: health check interval } with an error
Does that mean we need an another Interval param for each health check?

Interesting. Could we?

To get the output url, can I use the go template format {{ outputs.url }} instead of terraform's format?

Of course, please use what you see fit.
Mine was just an example.

Are we good to close this?

Fixed by #53
Thank you @tomhuang12 !!


Request to theme textarea based on MDL guidelines

Here is a link (https://material.google.com/components/text-fields.html#text-fields-multi-line-text-field) to the MDL guidelines on textareas.
I would like to ask whether there is a plan in place to theme textareas based on the guidance provided there.  If not, would you be willing to accept a PR to do so?

Hi there,
Unfortunately, I do not really have the time to dedicate to things like this, but I'm be more than happy to accept a PR :)
Cheers


Warn users who try to use pipenv run before installing packages

Fixes #1080
Currently, pipenv run will create a virtualenv if one doesnt exist
However, it will not install packages if it needs to
This allows us to install packages only if we have a new venv

Super fast fix, thanks! How long until this makes its way into PyPI?

@cs01 We're unfortunately in a bit of a code freeze until we have everything ready for 9.0.0.
I wanted to get it landed this week but we'll likely look at releasing something after Thanksgiving.

Wow appveyor is 100% broken... erm...

This fix definitely works but i dont know if it's a good idea

These CI builds ran super slow... it’s possible this check is the cause. Don’t merge yet, I’ll just add some logic to bypass in most cases

@techalchemy It could be that we just have a lot of builds going on right now, with my new branch and PR

@kennethreitz this is partly why I needed --system available

explain what is happening
On Mon, Nov 20, 2017 at 6:48 PM, Dan Ryan<EMAIL_ADDRESS>wrote:

@techalchemy commented on this pull request.
In pipenv/utils.py
https://github.com/kennethreitz/pipenv/pull/1091#discussion_r152144055:

@@ -843,6 +843,15 @@ def is_installable_file(path):
path = urlparse(path['file']).path if 'file' in path else path['path']
if not isinstance(path, six.string_types) or path == '*':
return False

If the string starts with a valid specifier operator, test if it is a valid

it was required to pass appveyor tests in this one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/pipenv/pull/1091#discussion_r152144055,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHUVeGI1JYfv3bYnHkW-mSGtC5T0xFAks5s4g_YgaJpZM4Qi0R8
.

@kennethreitz explain what is happening to what

If you're asking what was happening with regard to the specifier check, the appveyor builds are here and I excerpted the error below.  This cropped up whenever the dependency resolution issue got extra visibility recently but I'm not sure what caused it or why. Let me try to remove it since it's not affecting any other prs, and i'll rebase onto master and squash
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '>=3.3.0,<4'
Command exited with code 1

ok seems like whenever we reverted that stuff it fixed appveyor's issues so we're all good on that end

Py27 failure is transient: https://ci.appveyor.com/project/techalchemy/pipenv/build/job/0o0fv1wi20e725tv

rebase required


Mechanism To Specify Hex Output in Convert DX12

For struct fields, function arguments, method arguments.
Applied to one struct field establishing the pattern if more need adding later.

CI gfxreconstruct build # 3593 running.

CI gfxreconstruct build # 3593 passed.


Support Data Locality option to always keep a replica local to the engine

Try to keep a replica local.

Need to delay the scheduling to after the volume being used for the first time.
Need to migrate replica automatically if there is no local replica on the node.

Thought more about this:

The setting Ensure One Replica co-located With Engine should be exposed as a global option.

We don't need to allow per volume configuration for now because the option will be enabled only when the network condition is bad.

There is still a question if we can delay the scheduling of replica, or does it make sense to do that.
The basic idea is, if a volume is attached to a node that has no replica, then we will start rebuilding the replica on the node after the volume is attached. Once the rebuilding process is done, we will randomly remove one of the other replicas to keep the replica count as specified.

If the volume was detached before the rebuilding was done, the half-finished replica will be removed automatically even in the current mechanism.

@yasker
When users choose the option to keep a replica on the same node as the engine. If for some reasons (e.g node tag, disk tag conflict, or not enough space), the replica cannot be migrated to the node. Do we error out and stop the volume or just skip the migration?

It's going to be the best effort. We cannot give user zero availability if there is no local disk satisfied the requirement. We should notify the user about that in some way.

reproduce/test steps:

Create a cluster of 6 nodes and install Longhorn. Having more nodes helps us to be more confident in verifying the PR because the chance of randomly scheduling a replica onto same node as the engine is small.
Create volume testvol with Number of Replicas = 2
####Case 1: keep-local-replica-on-same-node-as-engine set to false:
Attach testvol to a node which does not contain any replica
Expected: No new replica is created
####Case 2: keep-local-replica-on-same-node-as-engine set to true:
Attach testvol to a node which does not contain any replica
Expected: Longhorn starts rebuilding a local replica on the engine's node. After finishing rebuilding the local replica, Longhorn remove one of the other replicas to keep the total number of replicas == 2
Assume that the engine is currently on node-1. Delete a replica that is not in node-1. Verify that Longhorn creates and rebuild a new replica.
Delete the replica in node-1. Verify that Longhorn creates and rebuilds a new replica on another node. Then Longhorn creates and rebuilds a new replica on node-1. After finishing rebuilding, Longhorn delete one replica on a node # node-1
Repeat the above 2 cases with volume di

Need to investigate the scheduler option as well.

Kubernetes currently only have hard node-affinity for PV https://kubernetes.io/docs/concepts/storage/persistent-volumes/#node-affinity
We may want to consider submitting a PR to the upstream Kubernetes to fix this and use it to implement data locality

reproduce/test steps:

Create a cluster of 9 worker nodes and install Longhorn.
Having more nodes helps us to be more confident because the chance of randomly scheduling a replica onto the same node as the engine is small.
Using Rancher to install an L7 ingress pointing to longhorn-backend service

Test volume creation with dataLocality is best-effort:

Open the ingress and go to volume API at v1/volumes
In the volume API, create volume testvol with Number of Replicas = 2 and dataLocality is best-effort
Attach testvol to a node that doesn't contain any replica.
Verify that Longhorn schedules a local replica to the same node as the consuming pod.
After finishing rebuilding the local replica. Longhorn removes a random replica on other nodes to keep the number of replicas is 2.

Test volume creation with dataLocality is disable:

Open the ingress and go to volume API at v1/volumes
Create another volume, testvol2  with Number of Replicas = 2 and dataLocality is disable
Attach testvol2 to a node that doesn't contain any replica.
Verify that Longhorn doesn't move replica

Test volume creation with dataLocality is unspecified and DefaultDataLocality setting as diable:

Leave the DefaultDataLocality setting as diable in Longhorn UI.
Open the ingress and go to volume API at v1/volumes
Create another volume, testvol3  with Number of Replicas = 2 and dataLocality is empty
Attach testvol3 to a node that doesn't contain any replica.
Verify that the dataLocality of testvol3 is disable and that Longhorn doesn't move replica.

Test volume creation with dataLocality is unspecified and DefaultDataLocality setting as best-effort:

Set the DefaultDataLocality setting to best-effort in Longhorn UI.
Open the ingress and go to volume API at v1/volumes
Create another volume, testvol4  with Number of Replicas = 2 and dataLocality is empty
Attach testvol4 to a node that doesn't contain any replica.
Verify that the dataLocality of testvol4 is best-effort.
Verify that Longhorn schedules a local replica to the same node as the consuming pod.
After finishing rebuilding the local replica.
Longhorn removes a random replica on other nodes to keep the number of replicas is 2.

Test updateDataLocality from disable to best-effort:

Open the ingress and go to volume API at v1/volumes. Find the action section of testvol2
Click on the action updateDataLocality and change dataLocality to best-effort
Verify that Longhorn schedules a local replica to the same node as the consuming pod.
After finishing rebuilding the local replica.
Longhorn removes a random replica on other nodes to keep the number of replicas which is 2.

Test updateDataLocality from best-effort to disable :

Open the ingress and go to volume API at v1/volumes. Find the action section of testvol2
Click on the action updateDataLocality and change dataLocality to disable
Go to Longhorn UI, increase the number of replicas to 3. Wait until the new replica finishes rebuilding.
Delete the local replica on the same node as the consuming pod.
Verify that Longhorn doesn't move replica

Test volume creation by using storage class with dataLocality parameter is disable:

Create disable-longhorn storage class with from this yaml file:kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: disable-longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "1"
  dataLocality: "disable"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""

create a shell deployment of 1 pod using ubuntu:xenial image, and the PVC dynamically created by disable-longhorn storage class.
The consuming pod is likely scheduled onto a different node than the replica.
If this happens, verify that Longhorn doesn't move replica

Test volume creation by using storage class with dataLocality parameter is best-effort:

Create best-effort-longhorn storage class with from this yaml file:kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: best-effort-longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "1"
  dataLocality: "best-effort"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""

create a shell deployment of 1 pod using ubuntu:xenial image, and the PVC dynamically created by best-effort-longhorn storage class.
The consuming pod is likely scheduled onto a different node than the replica.
If this happens, verify that Longhorn schedules a local replica to the same node as the consuming pod.
After finishing rebuilding the local replica, Longhorn removes a random replica on other nodes to keep the number of replicas which is 1.
verify that the volume CRD has dataLocality is best-effort

Test volume creation by using storage class with dataLocality parameter is unspecified`:

Create unspecified-longhorn storage class with from this yaml file:kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: unspecified-longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""

create a shell deployment of 1 pod using ubuntu:xenial image, and the PVC dynamically created by unspecified-longhorn storage class.
The consuming pod is likely scheduled onto a different node than the replica.
If this happens, depend on DefaultDataLocality setting in Longhorn UI, verify that Longhorn does/doesn't migrate a local replica to the same node as the consuming pod.

Solution Space
When analyze this enhancement, I notice that there are many different moving parts/components from which we can use to build up a solution:

Longhorn's ability to move replica to a new node
Longhorn manager has ability to create a new replica, schedule it to a new node, and rebuild the replica on the node. When a pod uses Longhorn volume and the volume doesn't have any local replica, we can use this feature to schedule a new replica to the same node as the pod. Then, start rebuilding the replica on the new local replica. After the rebuilding finished, we can randomly delete one of the other volume's replica.

Register Scheduler Extender into a New Custom Scheduler
Scheduler extender means configurable webhooks, also knowns as filter and prioritize, which corresponds to the two major phases (Predicates and Priorities) in a scheduling cycle. Longhorn can configure 2 webhooks into the filter and prioritize phases of the scheduler. The workflow would be as follow. The scheduler watches on API server, and puts pods where its spec.nodeName is empty into its internal scheduling queue. It pops out a pod from the scheduling queue and starts a standard scheduling cycle:

First, in the filter phase, the scheduler filters out all the un-schedulable nodes base on the requirements (like CPU, memory, selector, affinity, ..). At the end of the filter phase, the result consists of a list of nodes that are compatible with the given Pod. This list of compatible nodes is sent to the first webhook. Longhorn can build an Http server that listens on the webhook. When the Http server receives the list of compatible nodes, it can decide whether it needs to filter out nodes that don't have a replica of volume depend on the data locality setting. After that, a new list of nodes is passed to the second phase.
In the prioritize phase, the scheduler will score the nodes based on attributes such as the state. Longhorn can register the Http server as a webhook at the end of this phase. The Http server can try to influence Kubernetes scheduling decisions by giving more points for the node which has the volume's replica.I believe this is how StorageOS approach. This is also Portworx's approach. The idea is that we can clone the standard Kubernetes Scheduler, deploy it under the name longhorn-scheduler. Then register 2 extender webhooks. I found a really good example demonstrating this approach here: GitHub - everpeace/k8s-scheduler-extender-example: An example of kubernetes scheduler extender.

Pros:

Clean separation of concern. Longhorn will be shipped with a separate custom scheduler.
When the user uninstalls Longhorn, everything will be tear down nicely.

Cons:

Users have to specify the scheduler name in Pods’ specs.
We need to keep up with Kubernetes release cycle.
Every time Kubernetes release a new version, we must release a new Longhorn version so that the custom longhorn scheduler is compatible with the new Kubernetes API server.
Moreover, even if we are able release a new version of Longhorn whenever Kubernetes releases a new version, we cannot ensure that user will upgrade Kubernetes and Longhorn at the same time.
This still leads to the mismatch between longhorn scheduler and Kubernetes API server.

Additional Context

I think that Portworx is doing some hacks to minimize the 2nd Cons. They build the extender webhook and give user 2 options. Users can either manually register the webhook into their existing default scheduler or users can directly use a provided yaml file that contains a custom scheduler and the webhook. Portworx puts the custom scheduler component (which they called Stork) into a separate project. Therefore, it can be updated/maintained independently. So, they can easily keep it up to date with the Kubernetes release cycle.

Register Scheduler Extender into the Existing Default Scheduler
Pros:

Users don't have to specify the schedulerName in the pod's spec.
We don't have to maintain a custom scheduler (which is build on top of the Kubernetes default scheduler).
This means that we don't have to release a new Longhorn version every time Kubernetes releases a new version.

Cons:

Don’t have separation of concern: all pods go through the extender webhooks
What if the webhooks go down?
The default scheduler timeouts when the webhooks stop responding.
The scheduling of every pod must wait for timeout seconds including the pods which don’t use Longhorn volume.

Additional Context

Can the extender webhooks be configured dynamically on any cluster: RKE, EKS, GKE, AKE? Different Kubernetes environments have different ways of deploying Kubernetes Scheduler. In the case Kubernetes Scheduler was deployed into pods using yaml file, we can change the yaml file to include the new configuration to register Longhorn extender webhooks. However, in case Kubernetes Scheduler was deployed by running a local docker image/binary file on nodes (e.g. the RKE cluster created by Rancher), I don't know to modify and redeploy it.

Kubernetes Scheduler Framework and Plugins
The scheduling framework is a new set of "plugin" APIs being added to the existing Kubernetes Scheduler. Plugins are compiled into the scheduler, and these APIs allow many scheduling features to be implemented as plugins, while keeping the scheduling "core" simple and maintainable. More detail about scheduling framework and plugin is at here. Longhorn can implement 2 plugins:

longhorn-filter-plugin for the filter extension point. In the case where we enforce data locality, longhorn-filter-plugin will filter out all the nodes which don't have the volume's replica. For best-effort data locality we  longhorn-filter-plugin doesn't filter out any nodes.
longhorn-scoring-plugin for the Scoring extension point. For best-effort data locality, the longhorn-scoring-plugin gives higher priority for nodes that have volume's replica and possibly subtract points for the nodes which don't have volume's replica.

We can then use Kubernetes Scheduler Framework to compile the 2 plugins with all default plugins. The end result is a custom scheduler without having to fork the core scheduler's code. We then push an image of this scheduler onto DockerHub. Then we can deploy the custom scheduler to the user's cluster using a deployment of 1 pod (similar to UI and driver deployer). See more detail about Kubernetes Scheduling Framework
Pros:

Clean separation of concern. Longhorn will be shipped with a separate custom scheduler.
When the user uninstalls Longhorn, everything will be tear down nicely.

Cons:

Users have to specify the scheduler name in Pods’ specs.
This feature is still in alpha
We need to keep up with Kubernetes release cycle. Every time Kubernetes release a new version, we must release a new Longhorn version so that the custom longhorn scheduler is compatible with the new Kubernetes API server. Moreover, even if we are able release a new version of Longhorn whenever Kubernetes releases a new version, we cannot ensure that user will upgrade Kubernetes and Longhorn at the same time. This still leads to the mismatch between longhorn scheduler and Kubernetes API server.

Additional Context

To minimize the impact of the 2nd Cons, I think that we can do something like Portwork. They put their custom scheduler component (which they called Stork) into a separate project. Therefore, it can be updated/maintained independently. So, they can easily keep it up to date with the Kubernetes release cycle.
Have more flexibility than the Register Scheduler Extender into a New Custom Scheduler though we don't need them.

Mutating Admission Controller
Admission webhooks are HTTP callbacks that receive admission requests and do something with them. There are two types of admission webhooks, validating admission webhook and mutating admission webhook. A mutating admission controller intercepts requests to the Kubernetes API server prior to the persistence of the object, but after the request is authenticated and authorized. More detail ar here. Longhorn can implement and configure a mutating admission controller webhook. During Pod creation, Kubernetes sends a web request to the Longhorn WebHook with the Pod specification. The PodSpec is only altered to use the custom longhorn-scheduler if the Pod uses a Longhorn volume.
Pros::

User doesn't need to specify spec.schedulerName in pods' spec.

Cons::

User will have to do more setup (e.g. maintain a cert for the external webhook)
It adds one more single point of failure: every pod creation has to go through the mutating admission controller webhook. Since every pod creation must go through this mutating admission controller, it may also be a scaling problem when the cluster getting bigger and bigger.

Dynamic Resource Binding
Users can create a StorageClass with volumeBindingMode set to WaitForFirstConsumer. This new setting instructs the volume provisioner to not create a volume immediately, and instead, wait for a pod using an associated PVC to run through scheduling. Longhorn can use this setting as a signal to wait for the pod to have NodeID before scheduling replicas.
Pros:

Utilize an existing Kubernetes mechanism so Longhorn doesn't need to introduce a new setting.

Cons:
The logic in the Volume Controller will get more complicated. If we want to delay scheduling until the volume is used the first time, there is a wait-cycle in the Volume Controller's sync logic which I don't know how to solve. Specifically, we have to wait until the CurrentNodeID of volume to be non-empty to know which node we need to schedule a replica onto. However, the auto attachment feature requires all replicas need to be scheduled before it can start the volume and assign CurrentNodeID. There might be other conflicts that I am not fully aware of.

Potential enhancement of Kubernetes
A PV can specify node affinity to define constraints that limit what nodes this volume can be accessed from. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity. More detail at https://kubernetes.io/docs/concepts/storage/persistent-volumes/#node-affinity. Longhorn can automatically add affinity to PV so that pod must move to the nodes which contain replicas. The problem is that it is hard affinity only. We cannot implement best-effort data locality mode using PV affinity alone.
We can consider contributing to the upstream Kubernetes so that it supports soft affinity for PV. By doing this, we can have a much cleaner solution for data locality. This also benefits everyone in the community as well. Right now, each storage vendor has a different workaround to solve the data locality problem

Conclusion
Because of the critical problems with scheduling approaches, Mutating Admission Controller, and the limitation of PV's node affinity, we decided to only support data locality with best-effort mode in the version v.1.1.0. In the future, we may come back and re-evaluate the other approaches.

One of the option of data locality should be disabled instead of disable, which is a verb.

Thanks Sheng!

Manual Testing:  PASSED
Longhorn version: master
Tests:

[x] volume creation with dataLocality is best-effort
[x] volume creation with dataLocality is disabled
[x] updateDataLocality from disabled to best-effort
[x] updateDataLocality from best-effort to disabled
[x] volume creation by using storage class with dataLocality parameter is disabled
[x] volume creation by using storage class with dataLocality parameter is best-effort
[x] volume creation by using storage class with dataLocality parameter is unspecified
[x] volumes created in old versions

Affected by https://github.com/longhorn/longhorn/issues/1679

After updating datalocality for the volume, new replica kept created and deleted indifinitely

Need re-validated manually after issue is fixed

The PR for this issue may affect https://github.com/longhorn/longhorn/issues/298. (e.g. When data locality is ON and users trying to evict the node that the volume is attaching to)

Manual Validation: PASSED
Longhorn version: master  - Sep, 8th, 2020
Tests:

[x] volume creation with dataLocality is best-effort
[x] volume creation with dataLocality is disabled
[x] updateDataLocality from disabled to best-effort
[x] updateDataLocality from best-effort to disabled
[x] volume creation by using storage class with dataLocality parameter is disabled
[x] volume creation by using storage class with dataLocality parameter is best-effort
[x] volume creation by using storage class with dataLocality parameter is unspecified
[x] volumes created in old versions

For data locality, along side disabled and best-effort, it would be nice if there is a third option for hard requirement for the primary storage and the replicas can scheduled on different nodes. Any update for LocalPV ?

@yasker For data locality, along side disabled and best-effort, it would be nice if there is a third option for hard requirement for the primary storage and the replicas can scheduled on different nodes. Any update for LocalPV ?

Local volume will be handled by https://github.com/longhorn/longhorn/issues/3957.

@innobead When is v1.4.0 getting released?


chore: improve errors expirience

:tada: This pull request is included in version<EMAIL_ADDRESS>:tada:
The release is available on GitHub release

:tada: This pull request is included in version<EMAIL_ADDRESS>:tada:
The release is available on GitHub release


Deleting event in boot method

I have an issue when try to add deleting event in boot method of my child class which exteneds User class which use EntrustTrait... :). The event is not fired. I have found the solution completely described here:
http://stackoverflow.com/questions/26244817/trouble-with-multiple-model-observers-in-laravel
Maybe 'return true' in EntrustUserTrait.php on line 42 (boot method) must be deleted?

I remove the return true in public static function boot() and it worked.


Unintuitive behavior of the March 1st version

For some reason, Chrome's March 1st update (2.24.0) automatically sets the "show only unread" option without telling the user, so it looks as if the feeds were removed.
Upon selecting a feed, the read items are only shown if you click on the unread count on the right, which is rather unintuitive and confusing, and again, there is not indication of this change of behavior to the user, so they might again think that unread items were removed.
If there is no unread items in a feed, you cannot even click the unread count to see the read items.

In case someone else also encounters the third problem: you can add this to the appearance - user css settings to show the unread counter so you can click it to see the full list:
:not(.has-unread) > .source-counter {
    visibility: visible;
    color: rgba(0, 0, 0, 0.2);
}

I'm sorry for the trouble. I'll take a look at these, that definitely wasn't intended. Do changing settings to your preferred work?

Do changing settings to your preferred work?

Which settings do you mean? I fixed the first problem by changing it in the settings, but there doesn't seem to be any settings related to the second and third problems.

I just updated to Firefox AMO v2.25.0 (from v2.23.2). Not only was "Toggle show only unread" enabled, but so was "DEFAULT_TO_UNREAD_ONLY!". Also, "Invert colors" was set to "Yes". None of these were enabled beforehand.

I'll investigate the reason of switching some of boolean settings. I'm almost certain it comes from wrong interpretation of saved settings but I never experienced it while working on it myself


Added init file to make modin/experimental/sql/hdk/query.py part of modin package

By making a contribution to this project, I certify that:
1.) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or 2.) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or 3.) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. 4.) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
What do these changes do?
This file is currently not part of modin package (for example, here in source files . To fix that we add __init__.py file to turn folder into normal python module.

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] signed commit with git commit -s
[ ] Resolves #?
[ ] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

Thanks for the fix!
Although, each file (even an empty one) requires the license thing and sometimes a brief one-line docstring, otherwise CI won't pass I believe
https://github.com/modin-project/modin/blob/master/modin/core/dataframe/__init__.py


fix: ignore module-not-found errors in doc-check

Sometimes we want to show examples that use modules that aren't a dependency of the module we are documenting.
In this case tsc throws TS2307 when trying to compile the example code block.
Ignore this error so we can just treat these deps as any while still getting the benefit of compiling the rest of the code block.

To make sure we have a paper trail: one implication of this is that with this change we won’t get type errors if an import is used incorrectly.
So in doc block examples if the import path is wrong, or we import a module without types, or the module isn’t installed locally we won’t see an error.


Website redesign

Summary:

Code sample:
Schema
// Code here

Model
// Code here

General
// Code here

GitHub linked issue:

#---

Other information:
Type (select 1):

[ ] Bug fix
[ ] Feature implementation
[ ] Documentation improvement
[ ] Testing improvement

[ ] Test added to report bug (GitHub issue #--- @---)
[ ] Something not listed here

Is this a breaking change? (select 1):

[ ] 🚨 YES 🚨
[ ] No
[ ] I'm not sure

Is this ready to be merged into Dynamoose? (select 1):

[ ] Yes
[ ] No

Are all the tests currently passing on this PR? (select 1):

[ ] Yes
[ ] No

Other:

[ ] I have searched through the GitHub pull requests to ensure this PR has not already been submitted
[ ] I have updated the Dynamoose documentation (if required) given the changes I made
[ ] I have added/updated the Dynamoose test cases (if required) given the changes I made
[ ] I have run npm test from the root of the project directory to ensure all tests continue to pass
[ ] I agree that all changes made in this pull request may be distributed and are made available in accordance with the Dynamoose license
[ ] All of my commits and commit messages are detailed, explain what changes were made, and are easy to follow and understand
[ ] I have confirmed that all my code changes are indented properly using 2 spaces
[ ] I have filled out all fields above

Pull Request Test Coverage Report for Build 796

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 85.466%

Totals

Change from base Build 793:
0.0%

Covered Lines:
2146

Relevant Lines:
2435

💛  - Coveralls


这个同志不顾全大局！自己爽了，别人怎么办？

Our Hypothesis 2 says it is still worthwhile to further explore the potential of SSM for visual detection and segmentation. We believe all visual mamba models cited in our paper deserve acceptance. For researchers who are working on visual Mamba, when writing papers, it may be beneficial to highlight Mamba's advantages in processing long sequences, as explained in Figure 2 in our paper.

没事，开个玩笑。你paper很棒的！

Thank you for recognizing our paper. We hope this paper, especially the "conceptual discussion" section, could offer a bit of insight for researchers.


Prevent widget click event after drag and resize

I create click event to each widget but after drag or resize, the click event is fired. How can I prevent click event from dragging and resizing?
Thanks.

hm, I belive this is not related to lib at all. Mute your event while drag/resize start and reenable on stop.

Thank you for reply.
I understand. I tried to call eventPreventDefault() on drag/resize start but after stop, click() is still fired...

eventPreventDefault has nothing to do with that. you need to remove and reattach event (or try to handle this in event function, I belive jQ UI offers is_dragging / is_resizing events)

try return false; to stop propagation and event bubbling as well as preventing the default behavior.

Thank you guys.
I solved this by add/remove click event listener on drag start/stop. Maybe adding a internal "click" event is good?

i odnt think that would be a good idea.. ux wise as the user dont usually expect dragggable objects to be clickable as well .. it's quite confusing.


Cannot auto assign hosts to cluster due to wrong label

I'm provisioning a cluster on Satellite in Azure using these scripts:
https://github.com/lionelmace/satellite-utils/tree/main/terraform/satellite-azure
The creation of the Azure VMs, Satellite location and the cluster is successfull.
I'm missing the final step where the VMs gets automatically assigned to the cluster.

Where in the terraform script can I change the
The module ibm_satellite_location create a label with zone eastus-1 instead of us-east-1
data "ibm_satellite_location" "location" {
        {
            cluster_name = "infrastructure"
            host_id      = "54b69e06af9f051ba8ce"
            host_labels  = {
                "cpu"      = "4"
                "env"      = "prod"
                "memory"   = "16266544"
                "os"       = "RHEL7"
                "provider" = "azure"
                "zone"     = "eastus-1"
            }
            host_name    = "satellite-azure-vm-0"
            ip_address   = "<IP_ADDRESS>"
            status       = "normal"
            zone         = "us-east-1"
        },

Due to this difference, the host auto assignement cannot performed. Can we fix that in the module to use the format us-east?
What is the workaround in the meantime?

@jsloyer any idea?

thats actually correct. azure names their zones a little different.  The correct azure zone naming is eastus-1.

@lionelmace Can you clarify a few things for me?

did the control plane hosts assign sucessfully? (i'm guessing yes since you're creating a cluster)
when you create the cluster, what zones are you passing in? is that in code, or just locally when you're running? if 1 is yes, and you pass in eastus-1, eastus-2, eastus-3, everything should be good.

@finken2

Yes
Change the location zones solved it. I thought I tried! Thanks

  default     = ["eastus-1", "eastus-2", "eastus-3"]
  # default     = ["us-east-1", "us-east-2", "us-east-3"]

@finken2 I created a pull request to enhance the Azure sample with the ability to create a cluster and assign worker nodes.
https://github.com/terraform-ibm-modules/terraform-ibm-satellite/pull/61


Function to reference the graphql(name) defined on an enum

Hi,
I have an enum defined as such
#[derive(Enum, Copy, Clone, Eq, PartialEq, Serialize, Debug, ToSql, FromSql)]
#[postgres(name = "home_quality_check_status")]
pub enum HomeQualityCheckStatus {
  #[postgres(name = "Ready")]
  Ready,
  #[graphql(name = "Not Ready")]
  #[postgres(name = "Not Ready")]
  NotReady,
}

If I have a field defined as:
pub home_quality_check_status: HomeQualityCheckStatus

is there a way to pull either the value of Ready or Not Ready as defined by the #[graphql(name = attribute?  If not, I'd like to request this as a feature enhancement!

You can implement the Display trait for HomeQualityCheckStatus
impl Display for HomeQualityCheckStatus {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            HomeQualityCheckStatus::Ready => f.write_str("Ready"),
            ...
        }
    }
}

Same question, I've already have display trait and would want to reuse it as instead duplicating #[graphql(name = "BAD_REQUEST")]

released in v7.0.5


Multiple SpeechInputSources in one Scene

Hello,
I want to detect different Keywords in my App. I want some Keywords to be only detactable upon some condition (eg Menu being open).
So far I used the old KeywordsManager and was able to place multiple KeywordManagers in my scene starting and stoping them as needed.
I tried to do the same with the SpeechInputSource. Unfortunalty the second SpeechInputSource gets started, but the Keywords are not picked up. Along the SpeechInputSource I use the SpeechInputHandler to register the events for the keywords.
Has someone an idea how to handle this? Am I doing something wrong? Or can I just register all keywords in one SpeechInputSource and just enable/disable the corresponding SpeechInputHandlers? Or the other way round (multiple Sources, one Handler)?
Thanks in advance.

Hey @HoloFan, great questions here.  I've done scenario 1, where I've put all my keywords on a single SpeechInputSource, but the use of multiple sources should work.  Be sure you're registering your InputHandler as a GlobalListener with the InputManager, if the voice command doesn't require your gaze (You can do this by checking the box on the InputHandler).  Also, if you're changing scenes, you need to use my updated PR to support persistent keywords https://github.com/Microsoft/HoloToolkit-Unity/pull/747.

@StephenHodgson : Thanks for your input.
I actually set up everything correctly but was calling StopKeywordRecognizer instead of StartKeywordRecognizer :/ After changing that everything works just fine. I think the new concept is well worth it and I like the idea of the SpeechInputHandler!

Hi,
Not sure if it is ok to ask question in closed issue. But it is highly related to it.
I also try to use few SpeechInputSources and it works fine in general case.
But  SpeechInputHandler doesn't see Keywords from SpeechInputSource that is placed on the same game object.
Use case - Main menu has a lot special buttons, I would like to place keywords and handlers on its prefab since they used only on menu.
Is it expected behavior?
Thanks.


Navigate to a (fragment)router is not working...

Here's an exmaple... http://router2-demo.m3c.space/docs/tutorial-demo-fragment.html#/fragment/sub-fragment
It jumps back to #, why?

Looks like decoupling load event from router3 still is a hard thing to achieve.


seasonvar.ru

@StevenBlack
As per  issue logged here - https://github.com/AdAway/AdAway/issues/934#issuecomment-326039368
On my own list Badd Boyz Hosts I have removed this entry as the web site is safe to visit as far as I am concerned and not actually in my opinion a bad host. This entry made it onto my list as I picked it up through fake referrer traffic on a number of my web sites, the data of which I use for my Nginx and Apache Bad Bot & Referrer Blockers.
So my latest commit to Badd Boys > https://github.com/mitchellkrogza/Badd-Boyz-Hosts/commit/a0181c421143c5cf29aa2b4c819a40ce0ad56408 has removed seasonvar.ru and instead introduced blocking of it's ad's with the addition of
serving.adbetclickin.pink
creatives.adbetclickin.pink
adbetclickin.pink
The latest build in progress on Badd Boyz, complete in about 2 hours time will also remove about 88 dead and no longer existent domains.

Awesome.  Thanks Mitchell @mitchellkrogza.

No problem @StevenBlack ... Next build will have additional domains 3 listed in https://github.com/AdAway/AdAway/issues/934#issuecomment-326268044 by @SMed79 and will also be cleaned of all dead and inactive domains.
The builds take a good 2 hours due to the funceble script used for checking for all the dead and inactive domains. But I like having clean lists which is why I have spent so much time with @funilrys helping him fine tune it to my needs and constantly throwing feature requests at him and he just kept stepping up to all the challenges and making them a reality. It's now truly a remarkable script.

@mitchellkrogza, thanks for linking that. I was actually going to ask you what you used for that. Definitely going to have to play with it later.

@ScriptTiger I think you will be massively impressed with funceble. Through my constant pushing for features @funilrys achieved what I thought was impossible an autosave and continue mode for Travis to beat the 50 minute timeout. I have a major build test in progress on this repo been going 4 days and still about 5 or 6 left. Have a look at >>> https://github.com/mitchellkrogza/Ultimate.Hosts.Blacklist And https://travis-ci.org/mitchellkrogza/Ultimate.Hosts.Blacklist/builds

Thank you for funceble script, it is the tool I was looking for.
I think it is better to check for dead domains more than one time and from different geo lock.
(some hosts can down for a period of time or blocked by default in certain country).

@SMed79 all the credit must go to @funilrys .... what I am doing is building a list of dead domains which I store in the repo and it get's stripped out of input file before I create my hosts file. I keep this list of dead-domains in the repo so that it can be added to and also re-tested by itself every now and again for any sites which have become active again.


React.createRef and correct usage

To my understanding the React 16 createRef API (with support for .current) should be working at present. Maybe I'm understanding something wrong but I've tried several different ways of writing the same thing and the related documentation is woefully out of date.
I have a sample TryFlow here and I'm unsure what I'm doing wrong. I want to define a <button> -ref with React.Ref, but that ultimately results in:
 Cannot get 'this._button.current' because property 'current' is missing in 'String' [1].
I've tried variations of:
_button: React.Ref<'button'>
_button: React.Ref<HTMLButtonElement>
_button: React.ElementRef<'button'>
_button: React.ElementRef<HTMLButtonElement>

... And no luck. At this point I don't really know which variation is even supposed to work. Using flow-bin 0.92.0.

@neutraali Look at what createRef returns
https://github.com/facebook/flow/blob/master/lib/react.js#L240
  declare export function createRef<T>(
  ): {current: null | T};

It's not React.Ref.
Here's fixed example
https://flow.org/try/#0JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQNwBQdMAnmFnAArFjoC8cA3nQCQAegRIAwhAB2MLLLgwIcMABs8bYNNTAAJmwB0AV2AGARkZhLpcLKqwh58BCOG4AFsFW7K0gFyYVDAGAHIQ+gA0wmJIACosbBAEcBZWMorIAOZwABSUqFgwEXCoRmYgwDAAlIiuQnYOAPwBqDBQWplRouJw8axwSXAAErEAsgAyGdk5yMWoYMjSxbrAAG41LsLMrM0lbR1dMXASyKqqZngA1nAA7u7ycLiqwLiXHSmW1rXCMhLPr7sZtImDUeAA+OAVAAeWF0dAAvvQ6FgoZBYHB9ARkEZVPAnmh0AAhT7pFFyaS6dDYPDBKTgGROAA8nAg3AhgiEAH1UtYAvxHkYoL4YAFqfgDABReyOWTYAiMsg8mRkCEAHzg0hxqjg8LcMlaUCM+GgOTAXFQARZ3BqHKEpVYUFN5qq9CEQhgnlQBm5JJsfDFwVwlGQcjlORdwl1dpgIZeGKwWJxMCtvAEwnq0oCit9ZC67oSWaV0lz6d+-0uAXDcHBAijiOEnPci109j+L2ufByWFWTgCixB1fZ6eAyRyAGV9tJMjkPcAvT60tIDLhBcLl+pUKgQshHFUDFp9FCAPIEHJkFaoZBmey6Mignh8AC0AEYbemhCPcgBCWfzovL1cnAMABHIwsCgJgxwaY1HTIAwZSMO83zdN1f29f8VyFIDr0FcNXTdKM3U-GcEkGNCzVZL0y3basH3IAgjGkfBgGVZCUPI80DGo14ux7WQIxQwi61dXx9EdNjiI4yiDAaUgvzo7NFzvNMUP0ew5EUT0DAo7gDG2LB8MIygYEFGwcnfEQRDgAASAAxVQIBuWzgChUY2BOaRpAgeBKAIcD5DYfTyF-Mg4CIEgUDgVZTjAlQIB0GAWOkRp30ZKTdNkgQDGynTUHhAZpDbV4eH4NDG2bVty3y3ySrKot4TBd8hFKrTcuXTxvF8QihEZER0q9WTGrdATdV1IA

Thanks for the fast reply @TrySound - Sorry if this was one of the more trivial "issues". Personally I think updating the docs section concerning this would help many of us whose first instinct is not to sift through the source code. 😸

@neutraali Would you like to submit a PR?


Fix buttons exposure

Exposed the "buttons" properties in material and bootstrap components

:tada: This PR is included in version 1.6.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Sass-loader 8.0.0 not working with Vue-cli 3

Version
3.11.0
Environment info
Environment Info:

  System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Binaries:
    Node: 12.6.0 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.10.3 - /usr/local/bin/npm
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 68.0.2
    Safari: 12.1.2
  npmPackages:
    @3yourmind/vue-yodify: ^0.2.9 => 0.2.9
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0
    @vue/babel-plugin-transform-vue-jsx:  1.0.0
    @vue/babel-preset-app: ^3.11.0 => 3.11.0
    @vue/babel-preset-jsx:  1.1.0
    @vue/babel-sugar-functional-vue:  1.0.0
    @vue/babel-sugar-inject-h:  1.0.0
    @vue/babel-sugar-v-model:  1.0.0
    @vue/babel-sugar-v-on:  1.1.0
    @vue/cli-overlay:  3.11.0
    @vue/cli-plugin-babel: ^3.11.0 => 3.11.0
    @vue/cli-plugin-unit-jest: ^3.11.0 => 3.11.0
    @vue/cli-service: ^3.11.0 => 3.11.0
    @vue/cli-shared-utils:  3.11.0
    @vue/component-compiler-utils:  3.0.0
    @vue/eslint-config-prettier: ^5.0.0 => 5.0.0
    @vue/preload-webpack-plugin:  1.1.1
    @vue/test-utils: ^1.0.0-beta.29 => 1.0.0-beta.29
    @vue/web-component-wrapper:  1.2.0
    babel-helper-vue-jsx-merge-props:  2.0.3
    eslint-plugin-vue: ^5.2.3 => 5.2.3
    jest-serializer-vue:  2.0.2
    typescript: ^3.6.2 => 3.6.2
    vue: ^2.6.10 => 2.6.10
    vue-autosize: ^1.0.2 => 1.0.2
    vue-clickaway: ^2.2.2 => 2.2.2
    vue-cropper: ^0.4.9 => 0.4.9
    vue-echarts: ^4.0.3 => 4.0.3
    vue-eslint-parser: ^6.0.4 => 6.0.4 (5.0.0)
    vue-hot-reload-api:  2.3.3
    vue-i18n: ^8.14.0 => 8.14.0
    vue-jest:  3.0.4
    vue-loader:  15.7.1
    vue-meta: ^2.2.1 => 2.2.1
    vue-multiselect: ^2.1.6 => 2.1.6
    vue-popperjs:  2.0.4
    vue-router: ^3.1.2 => 3.1.2
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.6.10 => 2.6.10
    vue-template-es2015-compiler:  1.9.1
    vue2-ace-editor: ^0.0.13 => 0.0.13
    vuedraggable: ^2.23.0 => 2.23.0
    vuex: ^3.1.1 => 3.1.1
    vuex-router-sync: ^5.0.0 => 5.0.0
  npmGlobalPackages:
    @vue/cli: 3.11.0

Steps to reproduce
Install Sass-loader 8.0.0 and try to configure it to prependData in the vue.config.js - this does not work.
What is expected?
This is working using v7.3.1 of sass-loader
css: {
	loaderOptions: {
		sass: {
			data: "@import '~::shared/assets/variables.scss';",
		},
	},
},

What is actually happening?
This is not working using version 8.0.0:
css: {
	loaderOptions: {
		sass: {
			prependData: "@import '~::shared/assets/variables.scss';",
		},
	},
},

I tried solving this using the chain webpack interface but didn't have much luck.

It's working on vue-cli 4.0.0-rc.0

Duplicate of https://github.com/vuejs/vue-cli/issues/4513

prependData works for me with sass-loader v8. Please provide a valid reproduction.

I can confirm this issue.
sass-loader does not work with version 8.0.0. and vue cli 3.10.0

I get a slightly different error when trying to upgrade to sass-loader 8.0:
11:28:22 AM: ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.
11:28:22 AM:  - options has an unknown property 'indentedSyntax'. These properties are valid:
11:28:22 AM:    object { implementation?, sassOptions?, prependData?, sourceMap?, webpackImporter? }
11:28:22 AM:     at validate (/opt/build/repo/node_modules/sass-loader/node_modules/schema-utils/dist/validate.js:49:11)
11:28:22 AM:     at Object.loader (/opt/build/repo/node_modules/sass-loader/dist/index.js:36:28)
11:28:22 AM:     at runLoaders (/opt/build/repo/node_modules/webpack/lib/NormalModule.js:313:20)
11:28:22 AM:     at /opt/build/repo/node_modules/loader-runner/lib/LoaderRunner.js:367:11
11:28:22 AM:     at /opt/build/repo/node_modules/loader-runner/lib/LoaderRunner.js:233:18
11:28:22 AM:     at runSyncOrAsync (/opt/build/repo/node_modules/loader-runner/lib/LoaderRunner.js:143:3)
11:28:22 AM:     at iterateNormalLoaders (/opt/build/repo/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
11:28:22 AM:     at Array.<anonymous> (/opt/build/repo/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
11:28:22 AM:     at Storage.finished (/opt/build/repo/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
11:28:22 AM:     at provider (/opt/build/repo/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9)
11:28:22 AM:     at /opt/build/repo/node_modules/graceful-fs/graceful-fs.js:115:16
11:28:22 AM:     at FSReqWrap.readFileAfterClose [as oncomplete] (internal/fs/read_file_context.js:53:3)

Supported in 4.0.0-rc.3

Still got problems with newest versions of Vuetify and sass-loader:
./node_modules/vuetify/src/components/VInput/VInput.sass (./node_modules/css-loader??ref--9-oneOf-3-1!./node_modules/postcss-loader/src??ref--9-oneOf-3-2!./node_modules/sass-loader/dist/cjs.js??ref--9-oneOf-3-3!./node_modules/vuetify/src/components/VInput/VInput.sass)
Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.
 - options has an unknown property 'indentedSyntax'. These properties are valid:
   object { implementation?, sassOptions?, prependData?, sourceMap?, webpackImporter? }
    at validate (C:\Projekte\urania\node_modules\sass-loader\node_modules\schema-utils\dist\validate.js:50:11)
    at Object.loader (C:\Projekte\urania\node_modules\sass-loader\dist\index.js:36:28)

Here is my pacakge.json file: https://gist.github.com/Chris2011/b4a5f0651f6abb09064a356848624655
First I had m own config part:
css: {
   loaderOptions: {
      scss: {
         data: `@import '@/assets/base.scss';`,
      },
   },
},

But then I got the error with the unknown property data so I commented it out. But now I got this error.

For global I use @vue/cli 3.11.0. In my project I also tried @vue/cli-service 4.0.0-rc.6, still no luck. When I switch to rc.6 and I uncomment the css loaderOptions, I got this error:
./node_modules/vuetify/src/components/VSheet/VSheet.sass (./node_modules/css-loader/dist/cjs.js??ref--9-oneOf-3-1!./node_modules/postcss-loader/src??ref--9-oneOf-3-2!./node_modules/sass-loader/dist/cjs.js??ref--9-oneOf-3-3!./node_modules/vuetify/src/components/VSheet/VSheet.sass)
Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.
 - options has an unknown property 'data'. These properties are valid:
   object { implementation?, sassOptions?, prependData?, sourceMap?, webpackImporter? }
    at validate (C:\Projekte\urania\node_modules\sass-loader\node_modules\schema-utils\dist\validate.js:50:11)
    at Object.loader (C:\Projekte\urania\node_modules\sass-loader\dist\index.js:36:28)

Does anyone of the commenters solved that problem?

https://next.cli.vuejs.org/guide/css.html#passing-options-to-pre-processor-loaders

CLI v3 works with sass-loader v7 only at the moment. You can downgrade it for now.
With CLI v4 + sass-loader v8 it’s prependData.

I updated now everything, my global vue cli (don't know whether it is needed or not) and the sass-loader to 8.0.0. Now I got this error:
Failed to compile.

./node_modules/vuetify/src/components/VAlert/VAlert.sass (./node_modules/css-loader/dist/cjs.js??ref--9-oneOf-3-1!./node_modules/postcss-loader/src??ref--9-oneOf-3-2!./node_modules/sass-loader/dist/cjs.js??ref--9-oneOf-3-3!./node_modules/vuetify/src/components/VAlert/VAlert.sass)
Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
SassError: semicolons aren't allowed in the indented syntax.
  ╷
1 │ @import<EMAIL_ADDRESS>  │                              ^
  ╵
  C:\Projekte\urania\node_modules\vuetify\src\components\VAlert\VAlert.sass 1:30  root stylesheet

So this is now the problem with mixed sass and scss, but first I installed sass-loader and second I already used the loaderOptions scss, and not sass.

My case is, I need a newer version of vuetify, before I got the problems, I used 1.5.*, but it has less features so I updated vuetify for that. Just to let you know what I need.

Ok, thx for your help and sry for the inconvenience :)

Fixed in rc.7.

CLI v3 works with sass-loader v7 only at the moment. You can downgrade it for now.
With CLI v4 + sass-loader v8 it’s prependData.

Just wanted to mention:
Using CLI v3.11.0, Node v12.10.0 and sass-loader v8.0.0 and it's working without any issues in my project with the config from the new r.c docs.
module.exports = {   css: {     loaderOptions: {       scss: {         prependData:
@import<EMAIL_ADDRESS>@import<EMAIL_ADDRESS>      }     }   } };
Note: the ~ is not needed?

@sodatea thx for the fix. It is working now :)

Getting the same error when using sass-loader 8 with vuetilfy and electron
  ERROR in ./node_modules/vuetify/src/components/VDataTable/VDataTable.sass (./node_modules/css-loader!./node_modules/sass-loader/dist/cjs.js?indentedSyntax!./node_modules/vuetify/src/components/VDataTable/VDataTable.sass)
  Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
  ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.
   - options has an unknown property 'indentedSyntax'. These properties are valid:
     object { implementation?, sassOptions?, prependData?, sourceMap?, webpackImporter? }
      at validate (/Users/varun/Documents/GitHub/gym-management/node_modules/sass-loader/node_modules/schema-utils/dist/validate.js:50:11)
      at Object.loader (/Users/varun/Documents/GitHub/gym-management/node_modules/sass-loader/dist/index.js:36:28)
   @ ./node_modules/vuetify/src/components/VDataTable/VDataTable.sass 4:14-127 14:3-18:5 15:22-135
   @ ./node_modules/vuetify/lib/components/VDataTable/VDataTable.js
   @ ./node_modules/vuetify/lib/components/VDataTable/index.js
   @ ./node_modules/vuetify/lib/components/index.js
   @ ./node_modules/vuetify/lib/index.js
   @ ./src/renderer/plugins/vuetify.js
   @ ./src/renderer/main.js
   @ multi ./.electron-vue/dev-client ./src/renderer/main.js

CLI v3 works with sass-loader v7 only at the moment. You can downgrade it for now.
With CLI v4 + sass-loader v8 it’s prependData.

Just wanted to mention:
I'm using CLI v3.11.0, Node v12.10.0 and sass-loader v8.0.0 and it's working without any issues in my project with the config from the new rc docs.
module.exports = {
  css: {
    loaderOptions: {
      scss: {
        prependData: `
          @import<EMAIL_ADDRESS>          @import<EMAIL_ADDRESS>        `
      }
    }
  }
};

Note: the ~ is not needed?

Where exactly is this change to be made? Thanks!

I'm just a simple regular user of vue-cli. I updated my project today to 4.0.1 but I get a yellow warning on npm run serve saying "A new version of sass-loader is available. Please upgrade for best experience." So I upgrade<EMAIL_ADDRESS>but then I get crashes same as @pdoria above.
I added that css stanza to my vue-config.js but it does not fix the problem.
This bug should be re-opened and the title changed to Vue-cli 4.

I'm just a simple regular user of vue-cli. I updated my project today to 4.0.1 but I get a yellow warning on npm run serve saying "A new version of sass-loader is available. Please upgrade for best experience." So I upgrade<EMAIL_ADDRESS>but then I get crashes same as @pdoria above.
I added that css stanza to my vue-config.js but it does not fix the problem.
This bug should be re-opened and the title changed to Vue-cli 4.

don't upgrade! It only works with sass-loader 7.1.0! (just tested it and works with 7.1 ;) )

@pdoria, well as I said it works (my sass-loader is v7.3.1) but that not's the point. The vue-cli release notes, and that prominent yellow warning, say to update sass-loader to v8.

module.exports = {   css: {     loaderOptions: {       sass: {         prependData:  @import<EMAIL_ADDRESS>      }     }   }, }
This works for me.. just put ; at the end of the

module.exports = {
  css: {
    loaderOptions: {
      sass: {
        prependData: ` @import '@/assets/sass/_theme.scss';`
      }
    }
  },
}

This works for me.. just put ; at the end of the file path

where exactly do you place those codes

module.exports = {
  css: {
    loaderOptions: {
      sass: {
        prependData: ` @import '@/assets/sass/_theme.scss';`
      }
    }
  },
}

This works for me.. just put ; at the end of the file path

where exactly do you place those codes

@kagz
Place it in vue.config.js

if you use material or something else which uses sass down in the modules you have to add one line to the above :
module.exports = {
lintOnSave: false,
css: {
loaderOptions: {
sass: {
prependData:  @import '@/assets/sass/_theme.scss';,
sassOptions: {
includePaths: [path.resolve(__dirname, "node_modules")]
}
}
}
}
};

Here's a definitive solution to those who have run into this problem:

upgrade your Vue CLI to 4.0+:

npm update -g @vue/cli
# OR
yarn global upgrade --latest @vue/cli

upgrade your sass-loader to 8.0+

npm update sass-loader
# OR
yarn upgrade --latest sass-loader

update your vue.config.js file

module.exports = {
  css: {
    loaderOptions: {
      // old
      sass: {
        data: `@import "@/styles/_global.scss";`,
      },
      // new
      sass: {
        prependData: `@import <EMAIL_ADDRESS>// change to *.sass; remove semi-colon
      },
      scss: { // separate one for scss
        prependData: `@import <EMAIL_ADDRESS>// this is .scss
      },
    },
  },
  // ...
}

remove /deep/ selector if you have any. Apparently it's deprecated. Luckily I could do this without too much trouble.

@jaiko86 - thanks man, that helped a lot. I had to add semicolon to make the scss work, this is my working config - also with node modules scss files import enabled.
module.exports = {
  css: {
    loaderOptions: {
      sass: {
        sassOptions: {
          includePaths: [
            './node_modules'
          ]
        },
        prependData: `@import "@/styles/global.scss";`,
      },
    },
  },
};

Hi,
Is this working for production build? . I am facing the issue with production as  .scss modules are not extracted while building.

The solution provided by @jaiko86 is not working for me... I'm using "sass-loader": "^8.0.2" with @vue/cli-service v4.3.1

The solution provided by @jaiko86 is not working for me... I'm using "sass-loader": "^8.0.2" with @vue/cli-service v4.3.1
css: {
  loaderOptions: {
    sass: {
      prependData: `@import "@/styles/global.scss";`,
    }
  }
}

I also tried to downgrade sass-loader to 7.3.1, but with no luck

Hi, i have the same version and it's working using the @jaiko86 configuration, but you should also include sassOptions attribute to load node_module directory just like @JakubHromada example when your scss files are imported from installed components. This is my configuration:
....
css: {
        loaderOptions: {
            sass: {
                sassOptions: {
                    includePaths: [
                        './node_modules'
                    ]
                },
                prependData: `@import <EMAIL_ADDRESS>            },
        },
}
.....

where main.scss has imports from node_modules path

Getting the same error when using sass-loader 8 with vuetilfy and electron
  ERROR in ./node_modules/vuetify/src/components/VDataTable/VDataTable.sass (./node_modules/css-loader!./node_modules/sass-loader/dist/cjs.js?indentedSyntax!./node_modules/vuetify/src/components/VDataTable/VDataTable.sass)
  Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
  ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.
   - options has an unknown property 'indentedSyntax'. These properties are valid:
     object { implementation?, sassOptions?, prependData?, sourceMap?, webpackImporter? }
      at validate (/Users/varun/Documents/GitHub/gym-management/node_modules/sass-loader/node_modules/schema-utils/dist/validate.js:50:11)
      at Object.loader (/Users/varun/Documents/GitHub/gym-management/node_modules/sass-loader/dist/index.js:36:28)
   @ ./node_modules/vuetify/src/components/VDataTable/VDataTable.sass 4:14-127 14:3-18:5 15:22-135
   @ ./node_modules/vuetify/lib/components/VDataTable/VDataTable.js
   @ ./node_modules/vuetify/lib/components/VDataTable/index.js
   @ ./node_modules/vuetify/lib/components/index.js
   @ ./node_modules/vuetify/lib/index.js
   @ ./src/renderer/plugins/vuetify.js
   @ ./src/renderer/main.js
   @ multi ./.electron-vue/dev-client ./src/renderer/main.js

Hey did you find a fix for electron?

Should be replaced  prependData with additionalData.
This is how it works:
module.exports = {
css: {
loaderOptions: {
scss: {
additionalData : @import<EMAIL_ADDRESS>},
},
}
};
It doesn't work like that:
module.exports = {
css: {
loaderOptions: {
scss: {
prependData : @import<EMAIL_ADDRESS>},
},
}
};

problem solved for me with sass-loader 10.0.4 with additionalData not prependData
module.exports ={     css: { 	loaderOptions: { 		sass: { 			additionalData: "@import '@/sass/main.scss';", 		}, 	}, }, }

I have no idea how this is working for you guys.
I have tried every combination to no avail.
Semi-colon, no semi-colon.
data, additionalData, prependData.
sass, scss.
This is how it currently looks and isn't working:
module.exports = {     pluginOptions: {         electronBuilder: {             nodeIntegration: true         }     },     css: {         loaderOptions: {             scss: {                 additionalData: @import<EMAIL_ADDRESS>            }         }     } }
These are my dependencies:
"dependencies": {     "@fortawesome/fontawesome-free": "^5.15.1",     "core-js": "^3.6.5",     "nedb": "^1.8.0",     "path": "^0.12.7",     "reflect-metadata": "^0.1.13",     "vue": "^2.6.11",     "vue-class-component": "^7.2.3",     "vue-property-decorator": "^8.4.2",     "vue-router": "^3.2.0",     "vuex": "^3.4.0",     "vuex-class": "^0.3.2"   },   "devDependencies": {     "@types/electron-devtools-installer": "^2.2.0",     "@types/jest": "^24.0.19",     "@types/nedb": "^1.8.11",     "@typescript-eslint/eslint-plugin": "^2.33.0",     "@typescript-eslint/parser": "^2.33.0",     "@vue/cli-plugin-babel": "~4.5.0",     "@vue/cli-plugin-e2e-cypress": "~4.5.0",     "@vue/cli-plugin-eslint": "~4.5.0",     "@vue/cli-plugin-router": "~4.5.0",     "@vue/cli-plugin-typescript": "~4.5.0",     "@vue/cli-plugin-unit-jest": "~4.5.0",     "@vue/cli-plugin-vuex": "~4.5.0",     "@vue/cli-service": "~4.5.0",     "@vue/eslint-config-typescript": "^5.0.2",     "@vue/test-utils": "^1.0.3",     "electron": "^9.0.0",     "electron-devtools-installer": "^3.1.0",     "eslint": "^6.7.2",     "eslint-plugin-vue": "^6.2.2",     "node-sass": "^4.12.0",     "sass-loader": "^8.0.2",     "typescript": "~3.9.3",     "vue-cli-plugin-electron-builder": "~2.0.0-rc.5",     "vue-template-compiler": "^2.6.11",     "vuex-module-decorators": "^1.0.1"   }
Please help me.

Downgrading to version 7 worked for me:
npm uninstall --save-dev sass-loader
npm install --save-dev<EMAIL_ADDRESS>

I have no idea how this is working for you guys.
I have tried every combination to no avail.
Semi-colon, no semi-colon.
data, additionalData, prependData.
sass, scss.
This is how it currently looks and isn't working:
module.exports = {
    pluginOptions: {
        electronBuilder: {
            nodeIntegration: true
        }
    },
    css: {
        loaderOptions: {
            scss: {
                additionalData: `@import "@/theme/components/_tab-view.scss";`
            }
        }
    }
}

These are my dependencies:
"dependencies": {
    "@fortawesome/fontawesome-free": "^5.15.1",
    "core-js": "^3.6.5",
    "nedb": "^1.8.0",
    "path": "^0.12.7",
    "reflect-metadata": "^0.1.13",
    "vue": "^2.6.11",
    "vue-class-component": "^7.2.3",
    "vue-property-decorator": "^8.4.2",
    "vue-router": "^3.2.0",
    "vuex": "^3.4.0",
    "vuex-class": "^0.3.2"
  },
  "devDependencies": {
    "@types/electron-devtools-installer": "^2.2.0",
    "@types/jest": "^24.0.19",
    "@types/nedb": "^1.8.11",
    "@typescript-eslint/eslint-plugin": "^2.33.0",
    "@typescript-eslint/parser": "^2.33.0",
    "@vue/cli-plugin-babel": "~4.5.0",
    "@vue/cli-plugin-e2e-cypress": "~4.5.0",
    "@vue/cli-plugin-eslint": "~4.5.0",
    "@vue/cli-plugin-router": "~4.5.0",
    "@vue/cli-plugin-typescript": "~4.5.0",
    "@vue/cli-plugin-unit-jest": "~4.5.0",
    "@vue/cli-plugin-vuex": "~4.5.0",
    "@vue/cli-service": "~4.5.0",
    "@vue/eslint-config-typescript": "^5.0.2",
    "@vue/test-utils": "^1.0.3",
    "electron": "^9.0.0",
    "electron-devtools-installer": "^3.1.0",
    "eslint": "^6.7.2",
    "eslint-plugin-vue": "^6.2.2",
    "node-sass": "^4.12.0",
    "sass-loader": "^8.0.2",
    "typescript": "~3.9.3",
    "vue-cli-plugin-electron-builder": "~2.0.0-rc.5",
    "vue-template-compiler": "^2.6.11",
    "vuex-module-decorators": "^1.0.1"
  }

I tried to just @import the SCSS file into the

@edu-aguilar I think this thread has been abandoned.
Did my workaround work for you?
I've just made peace with doing it that way.

опять трансгендерные олени-смузихлебы на самокатах все сломали


I think you mixed up the name of the commit, it should be "why am i so stupid"

still hasn't learned how to read @sparkychild

PS - you didn't change the name of the commit, just the title of the PR


Release artifacts on github don't include arm so file

Both linux and mac variants under https://github.com/lyft/envoy-mobile/releases include
jni/x86/libenvoy_jni.so - which likely works under x86 devices and emulator. It would be great if the armeabi library would also be included so it can be run on phone.
Also the JNI is not stripped - would be nice to also have a stripped (rel) variant, seems the size goes from 68 to 54M.

Thanks for the issue @costinm! Valid on both fronts.

We have been building against emulators, but will soon start building against physical devices. We will publish arm artifacts soon!
I am currently working on #17 and stripping away symbols will definitely be part of that work.

Related, the iOS Envoy.framework artifact in the release also doesn't have support for all architectures. Fix here: https://github.com/lyft/envoy-mobile/pull/155

It appears that building from source does create the right jni.
BTW - it would be great to copy an updated "run_envoy_docker.sh" from envoy to envoy-mobile, it seems the most reliable and frustration-free way to build.
I used:
docker run -it --rm -v `pwd`:`pwd` -w `pwd` \
    -v $ANDROID_HOME:/Android -v $ANDROID_NDK_HOME:/AndroidNDK \
    -e ANDROID_HOME=/Android -e ANDROID_NDK_HOME=/AndroidNDK \
    --name envoy envoyproxy/envoy-build:ec38ecb88fd1abe55ab1daa2f6bd239ffccc9d98

The arm binary is also smaller (67M x86 vs 57M arm unstripped). Seems to go down to 42M stripped.

I did a fresh build - and it appears the arm no long shows in in the .ear file.
Is there any new option to generate arm ?

It seems worse - on a second machine, where I previously built the arm binaries, using the exact same command I get build errors. I'm starting to suspect the android SDK or NDK are different, and somehow
the NDK I used on the machine that worked for arm is confusing bazel.
Starting local Bazel server and connecting to it...
ERROR: /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/envoy/source/exe/BUILD:33:1: Label '@envoy//source/extensions/transport_sockets/tls:config' is duplicated in the 'deps' attribute of rule 'envoy_common_lib'
INFO: Call stack for the definition of repository 'remote_java_tools_linux' which is a http_archive (rule definition at /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/bazel_tools/tools/build_defs/repo/http.bzl:229:16):
 - /DEFAULT.WORKSPACE.SUFFIX:229:1
INFO: Call stack for the definition of repository 'android_tools' which is a http_archive (rule definition at /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/bazel_tools/tools/build_defs/repo/http.bzl:229:16):
 - /DEFAULT.WORKSPACE.SUFFIX:267:1
INFO: Call stack for the definition of repository 'remotejdk11_linux' which is a http_archive (rule definition at /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/bazel_tools/tools/build_defs/repo/http.bzl:229:16):
 - /DEFAULT.WORKSPACE.SUFFIX:199:1
INFO: Call stack for the definition of repository 'com_github_jetbrains_kotlin' which is a http_archive (rule definition at /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/bazel_tools/tools/build_defs/repo/http.bzl:229:16):
 - /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/io_bazel_rules_kotlin/kotlin/internal/repositories/repositories.bzl:64:5
 - /ws/envoy-mobile/WORKSPACE:134:1
INFO: Call stack for the definition of repository 'com_github_fmtlib_fmt' which is a http_archive (rule definition at /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/bazel_tools/tools/build_defs/repo/http.bzl:229:16):
 - /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/envoy_api/bazel/envoy_http_archive.bzl:18:5
 - /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/envoy/bazel/repositories.bzl:24:5
 - /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/envoy/bazel/repositories.bzl:233:5
 - /root/.cache/bazel/_bazel_root/1512acf4df716dad75482ca507bdf0de/external/envoy/bazel/repositories.bzl:133:5
 - /ws/envoy-mobile/WORKSPACE:54:1
ERROR: /ws/envoy-mobile/library/common/BUILD:7:1: Target '@envoy//source/exe:envoy_main_common_lib' contains an error and its package is in error and referenced by '//library/common:envoy_main_interface_lib'
ERROR: Analysis of target '//:android_dist' failed; build aborted: Cannot compute config conditions
INFO: Elapsed time: 23.522s
INFO: 0 processes.

I verified that on both machines the ndk is identical.
The sdk on the machine that doesn't build has additional build tools - 29.0.0.rc1/2
and android-27 and android-Q platforms added.
I'm running the builds in a docker, confirmed that git is at same SHA.
The joy of using bazel for 'reproducible builds'...

Some update: on the same machine I tried older SHAs.
45d1413af9d1547a373de891d0bb3460d0802341 - worked and generated ARM binaries.
24ba3e20f929f32ae9cfd0b4947b26d9c7740a5c - works but only generates x86
2f3b0be690b8bcae1809f4e3f56f7101cbc0e416 - is the one where the bazel errors showed up.
I'll try to find the last version that still generates ARM, since I'm mainly testing on devices.

Never mind - found the change, it seems the bazel target changed to 'device' instead of android.
And head seems to compile again after removing everything and fresh checkout, I suspect some leftovers.

@costinm Thanks for the update here. I'm glad that you were able to figure out what the issue is :)


Arrays are equal to Objects

I am fixing a bug where arrays have been accidentally converted to objects:
['test', 'the', 'things'] -> { 0: 'test', 1: 'the', 2: 'things' }

I have written a function that tests if this has happened and converts back to the array form. I want to test that my patch works recursively, so it would be very convenient to use deep-equal.
Unfortunately though:
deepEqual(['test', 'the', 'things'], {
    0: 'test',
    1: 'the',
    2: 'things'
});
// -> true

Would you accept a patch (perhaps with opts) to allow this to return false?

See this issue: https://github.com/substack/tape/issues/186

I've filed #65. This will be a breaking change, but I think it's worth making.


Bug 2043234: In FRR mode its not possible to have duplicate BGPPeers

for the same BGP Instance and in the same VRF its not
possible to have two BGP peers even with different remoteASN
For example:
neighbor <IP_ADDRESS> remote-as 65000
neighbor <IP_ADDRESS> remote-as 65001
only one of the entries will get applied
Signed-off-by: Mohamed Mahmoud<EMAIL_ADDRESS>

/aasign fedepaol

/aasign @fedepaol

/lgtm

/retest

/test metallb-e2e-metal-ipi-ovn

ipi ovn test seems to have issue not related to this PR
 * could not run steps: step metallb-e2e-metal-ipi-ovn failed: ["metallb-e2e-metal-ipi-ovn" pre steps failed: "metallb-e2e-metal-ipi-ovn" pod "metallb-e2e-metal-ipi-ovn-baremetalds-devscripts-setup" failed: the pod ci-op-216fmf4g/metallb-e2e-metal-ipi-ovn-baremetalds-devscripts-setup failed after 54m52s (failed containers: test): ContainerFailed one or more containers exited

/override ci/prow/metallb-e2e-metal-ipi-ovn


Unit Test Cause

Cause is now the backbone of almost the entire event system and as such, it needs to be tested in all use cases such that any changes to Cause that can break the system will be caught before they are pushed to master.

Completed.


Possible fix to stress + tcp test failing

Added a simple wait function to the stress/test.py which makes sure it does not continue until the TIME_WAIT connections are below a set limit. Not sure if this is a solution you want, but it makes sure this test does not interfere with other tests.
Last commit fixes some irregular function calls.

Now passes all tests in the pipeline on my personal fork: https://jenkins.includeos.org/job/personal_pipeline_mnordsletten_dev/


more log statements.  sns subscribe is now in a for loop for debugging.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Harter, Nicholas (Contractor) seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


[Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ?

This looks a great HACS for Americans but it would be great if we could add our own delivery options also.
Im guessing the UK versions of Amazon and DHL would not be too much but if we could have Royal Mail and Parcelforce. That would be amazing.
I see someone else has already asked for Germany to be added
Thanks
Martyn

Amazon UK is already supported.
In order to properly support other shippers, we'd need sample emails.

Hi, the actual email or a screenshot ?
Ill see if I have any
Thanks for the quick response
Martyn
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Thursday, November 26, 2020 2:38:21 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
Amazon UK is already supported.
In order to properly support other shippers, we'd need sample emails.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-734333447, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQCARFFCEWH2ABSGNWDSRZR53ANCNFSM4UDPZVTA.

Yes the actual email, if you're using Gmail you can review the steps here on how to download the email(s).
We'd need samples for "out for delivery" and "delivered", if applicable.
Note even old emails will be fine, any personal info can be redacted, but I do ask that if tracking numbers are present please leave them intact so I can devise a regex for them.

Ill have a look and supply what information I can tomorrow.
Does amazon on the current build cover all countries or do i have to do anything as Im monitoring that now. ?
What about ebay as I buy a lot of stuff on there as this has a lot of the information for tracking ? I had a royal mail tracked package delivered today and everything was in ebay and it puts each stage in there and also in my hotmail calendar.
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Thursday, November 26, 2020 9:27:54 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
Yes the actual email, if you're using Gmail you can review the steps herehttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/206#issuecomment-699272620 on how to download the email(s).
We'd need samples for "out for delivery" and "delivered", if applicable.
Note even old emails will be fine, any personal info can be redacted, but I do ask that if tracking numbers are present please leave them intact so I can devise a regex for them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-734483456, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQFZMLY347VDQUI3LXLSR3B5VANCNFSM4UDPZVTA.

Does amazon on the current build cover all countries or do i have to do anything as Im monitoring that now. ?

It doesn't cover all countries, but the ones listed in the const.py file.

What about ebay as I buy a lot of stuff on there as this has a lot of the information for tracking ?

Since eBay isn't actually a delivery service like UPS, DHL, etc we don't utilize those.

Hi
Hotmail.com set up on smtp.live.com and port 993
Purchased 4 items from Amazon yesterday but nothing updated on the addon. It says its updating and I have the email in the inbox like I chose it to look.
Was there anything else I had to set up ?
Thanks
Martyn
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Thursday, November 26, 2020 10:19:48 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
Does amazon on the current build cover all countries or do i have to do anything as Im monitoring that now. ?
It doesn't cover all countries, but the ones listed in the const.py file.
What about ebay as I buy a lot of stuff on there as this has a lot of the information for tracking ?
Since eBay isn't actually a delivery service like UPS, DHL, etc we don't utilize those.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-734495319, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQAWZAZCER6RMN575U3SR3IAJANCNFSM4UDPZVTA.

Also trying Server
imap-mail.outlook.comhttp://imap-mail.outlook.com
993
Now
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Thursday, November 26, 2020 10:19:48 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
Does amazon on the current build cover all countries or do i have to do anything as Im monitoring that now. ?
It doesn't cover all countries, but the ones listed in the const.py file.
What about ebay as I buy a lot of stuff on there as this has a lot of the information for tracking ?
Since eBay isn't actually a delivery service like UPS, DHL, etc we don't utilize those.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-734495319, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQAWZAZCER6RMN575U3SR3IAJANCNFSM4UDPZVTA.

According to outlook.com's help page these are the settings:
IMAP server name: outlook.office365.com
IMAP port: 993

Hi
Thanks for that. Ill try that but i put a post on Facebook this morning on a home assistant group and a few having issues in UK.
A guy I was speaking to said it was worded wrong for UK on the email search.

Okay, you stimulated me to debug it instead of my morning workout:)
There is indeed a bug (or rather lack of localisation) for amazon.co.ukhttp://amazon.co.uk email format. https://github.com/moralmunky/Home-Assistant-Mail-And-Packages/blob/a360c4b01a049f95f660374f95a1c66d456e4abe/custom_components/mail_and_packages/sensor.py#L744 expects email to contain "Will arrive:" and "Track your package:", while my emails have "Arriving:" and "Track your item(s):". Changing these strings make the integration work.
Martyn, if you are talking to author, please let him know about this. I can also prepare PR for this, but after my workout.

Im not sure if that helps too. Ill dig an email out and have a look.
Martyn
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Saturday, November 28, 2020 3:33:17 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
According to outlook.com's help page these are the settings:
IMAP server name: outlook.office365.com
IMAP port: 993
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-735245240, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQA24TQUSNO5YTZEEGTSSEJ33ANCNFSM4UDPZVTA.

From: Chris<EMAIL_ADDRESS>Sent: Saturday, November 28, 2020 3:33:17 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
According to outlook.com's help page these are the settings:
IMAP server name: outlook.office365.com
IMAP port: 993
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-735245240, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQA24TQUSNO5YTZEEGTSSEJ33ANCNFSM4UDPZVTA.
[Image]

email to contain "Will arrive:" and "Track your package:", while my emails have "Arriving:" and "Track your item(s):". Changing these strings make the integration work.

This is part of the reason I ask for example emails 😉
I then use those in the tests to see if the expected outcome occurs.

Yeah. Screen shot of a delivery on its way for me[Image]
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Saturday, November 28, 2020 7:15:26 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
email to contain "Will arrive:" and "Track your package:", while my emails have "Arriving:" and "Track your item(s):". Changing these strings make the integration work.
This is part of the reason I ask for example emails 😉
I then use those in the tests to see if the expected outcome occurs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-735278704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQGBGFJTQXJGHJIOJBDSSFD45ANCNFSM4UDPZVTA.

This was the original email.
[Image]
Regards
Martyn

From: Chris<EMAIL_ADDRESS>Sent: Saturday, November 28, 2020 7:15:26 PM
To: moralmunky/Home-Assistant-Mail-And-Packages<EMAIL_ADDRESS>Cc: nytram-md<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [moralmunky/Home-Assistant-Mail-And-Packages] [Feature Request] - How can we include the UK for Amazon, Royal Mail, DHL, etc ? (#262)
email to contain "Will arrive:" and "Track your package:", while my emails have "Arriving:" and "Track your item(s):". Changing these strings make the integration work.
This is part of the reason I ask for example emails 😉
I then use those in the tests to see if the expected outcome occurs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-735278704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANHZVQGBGFJTQXJGHJIOJBDSSFD45ANCNFSM4UDPZVTA.

Sorry email images don't translate into github.
I'd need the actual email in order to properly setup tests.

Heres a few amazon UK emails for your tests:
Out for Delivery: https://gist.github.com/tomanderson2/2c58b28dc4bc5de806267761c99dcbac
Delivered: https://gist.github.com/tomanderson2/335ada33a5ff449b99752cc5d420207c
and one more for luck (with multiple items if it makes a difference...)
Out for Delivery: https://gist.github.com/tomanderson2/08be4818503d5363ebc4b0dae42f1681
Delivered: https://gist.github.com/tomanderson2/b057c61296a84e112be69aa6e0fffbf6

I'll get these Amazon UK ones sorted.
I have grabbed the gists.

updated to the latest version and its broken what I had working again.
My emails for tracking in the UK are<EMAIL_ADDRESS>but I cant see that in your new Amazon set up.
The search worked on "Track your Package" also
not sure if that helps.

If you updated to 0.22 - Release, this isn't the 0.3.0 branch where these changes exist.
I'll get a 0.3.0-b0 released soon with these particular changes.

@nytram-md are you able to provide information similar to what is found in supported shippers and requirements that provides a link to the service to sign up and details any required settings to begin receiving the correct email messages?

Hi,
This is still not working for me for Amazon deliveries in the UK.
I think it may be because my emails are worded differently.

Mine says Arriving: not will arrive:
Also when it is out for delivery it doesnt show anything

I am running 0.3.0-b12.
What file do I need to change if at all to make it work?
Great integration BTW. Thanks

@clicky73 I think this is still in progress (according to github anyway). It might be an idea to provide samples of your emails in eml format to help with development and testing, because screenshots don't quite cut it. Its easy to do, details in this post https://github.com/moralmunky/Home-Assistant-Mail-And-Packages/issues/262#issuecomment-734483456
FWIW I anonymised my email address and tracking number when I shared mine, but there isn't much personal in there to worry about.

Amazon-UK-Email-Examples.zip
Hope this helps.
There are 3 examples. Arriving date, delivering today and delivered.

Give b13 a go. Should properly pick up your Amazon UK emails now.


model sanity check only in Run_Simulation!()

The check for a valid Reproduction model and warning message only happens after calling Run_Simulation!() .
Should this be earlier when calling read_input() already?

Sure, that would be more useful!

can stay as is


CASMINST-4863: run csm_ntp.py on a newly imaged/upgraded node

Description
CSM-1.2 images contain a pool.conf file that needs to be removed.
This is one of the things csm_ntp.py can fix, so invoke it before
attempting to sync the clock.
Also, add a wait loop like we have in prerequsites.sh.  The 5s wait
is not always enough.
This is ugly from a code duplication POV, but less risky than trying
to reorganize the code at this point in time.

Checklist Before Merging

[ ] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I don't have a JIRA.

/backport main


Define browser support for the theme

We don't explicitly define the theme supported browsers anywhere. RTD has been moving towards only supporting IE >= 11, and we haven't yet defined Android browser support.
We should communicate what we officially support, what the last version to support $BROWSER_VERSION was, and what we allow for degradation on unsupported browsers.
Unsupported browsers might include behaviors such as unsupported typefaces (minor), improper positioning of block level elements (medium impact), and I'm sure some old version have trouble display anything at all.
Changes that we've discussed in the past that would affect these browsers:

woff/woff2 font files only are not supported by IE < 9 or 10 and Android < 4.x. Both are small amounts of RTD annual traffic
Remove modernizer
etc

Modernizr can actually be removed for all browsers, since we do not use its feature detection. The only thing from Modernizr that is used by IE <11 is html5shiv. There is a PR that removes Modernizr but keeps html5shiv #756

We could also probably drop html5shiv if we want to limit our browser focus. If we want to remove html5shiv, we should discuss our position on supporting the older non IE browsers as well. Those versions are:

html5shiv provides basic HTML5 styling for Internet Explorer 6-9, Safari 4.x (and iPhone 3.x), and Firefox 3.x

html5shiv include is guarded by <!--[if lt IE 9]>, so it is not loaded for any other browser

We do have a list of supported browsers now at https://sphinx-rtd-theme.readthedocs.io/en/stable/development.html#supported-browsers


Fix leftovers in EventWriter interface

The initial intent was that the EventWriter object would use golang's
io.Writer interface. This ended up not being the case, and the
EventEncoder interface was favored instead as it allowed more
flexibility.
This removes traces of the unused io.Writer interface reference.
Signed-off-by: Juan Antonio Osorio<EMAIL_ADDRESS>

Codecov Report

Merging #89 (6ece4fc) into main (b1accd3) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #89   +/-   ##
=======================================
  Coverage   98.96%   98.96%
=======================================
  Files           9        9
  Lines         289      289
=======================================
  Hits          286      286
  Misses          2        2
  Partials        1        1

Flag
Coverage Δ

unittests
98.96% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

auditevent.go
100.00% <ø> (ø)

writer.go
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.