[FEATURE] Predictive Primary shard count by ISM and Index Management

Is your feature request related to a problem?

Users who are new to OpenSearch or any Lucene based search engines often learn about sharding best practices the hard way when they end up producing 500,900GiB shard size or toooo many smaller shards (usually under 1gb each).
As an OpenSearch consultant (who has reviewed countless OpenSearch Clusters) I see majority of the OpenSearch indices use 5 primary (which is the default in Amazon OpenSearch), which goes to say that users do not pay attention to sharding strategy, especially when they are new to OpenSearch
To give an concrete example, in a multi-tenant cluster setup with varying ingestion rates, relying solely on a static primary count in the index template isn't sufficient. Consider a log observability workload with over 200 different types of applications, each represented by its own index-pattern. These rolling indices have varying size, ranging from extremely large to extremely small. Additionally, the ingestion rate fluctuates over time, causing low-volume indices to temporarily become medium-sized before returning to their original state. In such a dynamic environment, a "set it and forget it" approach for primary shard counts isn't ideal. Manual adjustments are impractical, and shard size-based retention doesn't work well for short retention periods (e.g., 30 hours). Using a static primary count at the index template level can lead to skewed metrics and storage inefficiencies.

What solution would you like?

Long term solution - to have a predictive primary shard sizing for indices, adaptively applied, and considering resource utilization, workload, data stored, and other metrics from the fleet with ML for classification. More on this later.

First step towards the long term solution (solution for time-series workload) - An ISM policy driven Action, let's call it "Mutating Rollover", which looks at past x hours of ingestion rate (where x is the HOT retention period), takes into account the number of data nodes, predicts a suitable primary shard count for the next rollover index. The prediction may not be precise but at least better than having a static primary shard count for an index with fluctuating ingestion rate.

Additional solution (solution for search workload) - Index Management allows to create an index. This page should ask for additional details such as,
1. Type of workload (search/timeseries/vector)
2. Expected primary storage size
3. Number of data nodes (should probably can be auto populated)
4. Multi-tenant domain domain or not
5. etc., etc.,
and suggest a primary shard count that the user can either choose or ignore and go with a manual value.

What alternatives have you considered?
Developed a python script which does looks at the past ingestion rate for an index to determine the suitable primary shard count for the index rollover. The script will run every 1 hour to update the index templates. This could be available out of the box as a "Mutating Rollover" Action in ISM. The  python script does the below,
* GET _cat/indices/_hot?v&h=index,creation.date.string,pri.store.size,pri&s=index:desc,creation.date.string:desc #used to get calculate the ingestion volume for the last 30 hours
* 0gb to 30gb would be the general shard size
* size based rollover at shard size 30gb (30gb shard size is used in this example as optimal shard size but optimal shard size depends on the workload, usually ranging from 10gb to 50gb)
* For each index family, for last 30 hours if total ingested size (gb) is,
  - less than 10gb —> 1p1r sharding strategy —> 0gb to 10 gb would be the shard size range
  - 10gb to 30gb —> 2p1r sharding strategy —> 5gb to 15 gb would be the shard size range
  - 30gb to 60gb —> 3p1r sharding strategy —> 10gb to 20gb would be the shard size range
  - 60gb+ to 30*NO_OF_DATA_NODES gb —> 1p for every 30gb —> approx. 30gb would be the shard size range
  - 30*NO_OF_DATA_NODES+ gb -> (NO_OF_DATA_NODES)p —> approx. 30gb would be the shard size range
  - (optional) 30*(NO_OF_DATA_NODES/2) -> (NO_OF_DATA_NODES/2)p —> approx. 30gb would be the shard size range

Do you have any additional context?
I can provide the python script (for the above mentioned alternative solution) if it helps but it's fairly straight forward.

@aswath86 making any assumptions on the shards count can cause unpredictable issues.
In logging there are sudden spikes, and/or night/day activity patterns of different types (spiking high to a decreasing-saw-tooth pattern is a thing, not just nice wavey patterns).  Making predictions would require analyzing the indexing pattern over a longer period and hoping it represents the future. This only works if there is a pattern.
Additionally, if the cluster changes the shards' count every time it sees a spike we may cause a state of high shard count (which may cause instability and can't be undone).
On the flip side - we may reduce shards due to little shipping but when the next spike arrives we would get a hotspot.
I don't think this is a bad idea, but the approach you described is similar to one I tried as well, and there are many manual tweaks that need to be made. Some are done on a daily basis.
A great way to avoid any of the issues you stated is to spread the shards on the total number of nodes. While this solves all those issues it creates another one - too many shards. if we were ok with that then there would be no problem to have a full spread on all the nodes.

Making predictions would require analyzing the indexing pattern over a longer period and hoping it represents the future. This only works if there is a pattern. This only works if there is a pattern.

Additionally, if the cluster changes the shards' count every time it sees a spike we may cause a state of high shard count (which may cause instability and can't be undone).

I'm with you on the "This only works if there is a pattern". And I'm not in favour of analyzing an index pattern over a period of time for various reasons (sales season, newly onboarded features producing more logging, etc.,), so analyzing over a period of time would be misleading. We should be only considering the ingestion volume for the last x hours of the data, where x is the HOT retention period. We could also look at last few hours (say 2 hours) ingestion volume, as a means to validate the outcome that is based on the x hours.

In logging there are sudden spikes, and/or night/day activity patterns of different types (spiking high to a decreasing-saw-tooth pattern is a thing, not just nice wavey patterns).

This FR is primarily for an ISM Action which is going to be completely optional, suitable for shorter retention period (eg., 24 hours, 30 hours etc.,) index patterns that has a surge in ingestion pattern for a period of time before the surge disappearing. For example, a sale season where the application starts producing more logs for few days in which case it is not practical to change the sharding strategy manually, each time.
Generally, setting the shard count to a static value is not the ideal solution for a fluctuating ingestion rate. Changing the primary count each time there is a change is workload pattern is also not ideal.

A great way to avoid any of the issues you stated is to spread the shards on the total number of nodes. While this solves all those issues it creates another one - too many shards. if we were ok with that then there would be no problem to have a full spread on all the nodes.

Its usually is straight forward if a cluster has very fewer tenants (handful of index patterns) where all of them are either large volume or have a longer retention period. But this FR is for cases where there are too many tenants in the same cluster, each with varying index volume/size with fluctuating ignition rate. For instance, if you classify the index patterns by volume and you end up with high, medium and low volume indices, then during an surge, a low volume index would become a medium volume index, yet the sharding strategy is unchanged until manually updated. This FR aims to automat the sharding strategy according to the best practices.

making any assumptions on the shards count can cause unpredictable issues.

This FR is primarily geared for multi-tenant cluster with shorter retention period and this Action is to be used in combination with shard size based rollover to prevent shards getting bigger than the ideal size. We could also provide a parameter to overwrite the primary count in case a particular index patter is experiencing significant surge which the OpenSearch Admin is aware of (says application is undergoing stress testing or performance benchmarking and hence is going to produce significantly more logs), in which case they could overwrite the primary count, or better yet, don't use this action.
This feature was successfully implemented via a python script that runs every hour, which updates the primary count of the index for the sub-sequent rollover, on a large cluster that has 200 tenants with varying index volume that has fluctuating ingestion rate. This FR is to offer this feature natively with OpenSearch.

Making predictions would require analyzing the indexing pattern over a longer period and hoping it represents the future. This only works if there is a pattern. This only works if there is a pattern.

I'm with you on the "This only works if there is a pattern". And I'm not in favour of analyzing an index pattern over a period of time for various reasons (sales season, newly onboarded features producing more logging, etc.,), so analyzing over a period of time would be misleading. We should be only considering the ingestion volume for the last x hours of the data, where x is the HOT retention period. We could also look at last few hours (say 2 hours) ingestion volume, as a means to validate the outcome that is based on the x hours.

We can/should also include guard rails that prevent large changes in primary count. Some change in primary count, with a limited scope, will be better than not adjusting the shard count. Again, it's an optional feature, that users will choose to use by adding to the policy.
Some potential, user-settable parameters

time window to evaluate or maybe a weight on the sizing based on time
limit on the change in shard count

In logging there are sudden spikes, and/or night/day activity patterns of different types (spiking high to a decreasing-saw-tooth pattern is a thing, not just nice wavey patterns).

This FR is primarily for an ISM Action which is going to be completely optional, suitable for shorter retention period (eg., 24 hours, 30 hours etc.,) index patterns that has a surge in ingestion pattern for a period of time before the surge disappearing. For example, a sale season where the application starts producing more logs for few days in which case it is not practical to change the sharding strategy manually, each time.

+1 optional, and aimed at weekly/seasonal pattern changes. Without this feature, users have to change everything manually.

A great way to avoid any of the issues you stated is to spread the shards on the total number of nodes. While this solves all those issues it creates another one - too many shards. if we were ok with that then there would be no problem to have a full spread on all the nodes.

I wanted to echo @aswath86 comments here. Users with multi-tenant logging clusters have the most problems with these kinds of index size changes. Especially for people managing 10s or 100s of end user groups in a centralized IT department, this FR can bring a ton of value where they don't have to manually configure every change or reach out to their end users to figure out what's changing, whether it's permanent, and what is the ideal primary count.

This feature was successfully implemented via a python script that runs every hour, which updates the primary count of the index for the sub-sequent rollover, on a large cluster that has 200 tenants with varying index volume that has fluctuating ingestion rate. This FR is to offer this feature natively with OpenSearch.

I don't doubt that. I manage many clusters each with thousands of tenants sending logging data (of varying sharding). And I have implemented features similar to what you are describing in the FR. as external services. The problem that arrises over time in many cases is that there start to be too many shards per node after increasing and decreasing several times, 24 hour retention is rare in logging. This leads to guard rails that make the feature ineffective to avoid manual tampering.
I think my main point here is that the approach taken is external and not making use of information that you can get your hands on when writing code in the project - such as some metric for indexing pressure of a specific tenant.
Another approach for ism could be a set of indices with various shard counts and when pressure goes up you shift the write alias and this way the transition is smooth and have fewer shards in the end since it isn't an "all or nothing" shards increase (can be one size up and only create a standby index for the next available size) then you can later reindex and merge small indices if needed.
Bottom line is - i agree with the requirement for adjustment due to load changes, but the algorithm provided doesn't fit well enough to avoid many manual adjustments on-the-fly on high tenant clusters from my experience, and doesn't use the OpenSearch internals that are available to us when running within the node.

@aswath86 I have a different approach to suggest:
Rather than have the algorithm added as a feature how about enriching the policy with a way to make whatever shard adjustment rule the user wants? This way people can add the algorithm that works best for them and perhaps other interesting policies can be generated.
This way you can implement your algorithm and we can also offer a way to implement many others (yours can be the default?).
Wdyt?

@aswath86 and I will meet in the next week or so and add a summary of our discussion over here. just so we can expedite the conversation - does anyone else wanna join the call? @Jon-AtAWS ?

Thanks @AmiStrn I'd love to join!
BTW,

enriching the policy with a way to make whatever shard adjustment rule the user wants

Sounds like what we were thinking about, but maybe didn't say so clearly? Let's figure out the details.
J-

Thanks @AmiStrn I'd love to join!
BTW,

enriching the policy with a way to make whatever shard adjustment rule the user wants

Sounds like what we were thinking about, but maybe didn't say so clearly? Let's figure out the details.
J-

Great, invite is still open if anyone else wants in:) probably going to happen this upcoming week.

Goals

Nudge users to adopt sharding strategy best practices — Not a lot of them read the best practices documentation? Only Amazon OpenSearch has the sharding strategy best practices and this is not even available in the opensource documentation? Especially for new OpenSearch users.
Reduce storage & shard skewness — Storage skewness will introduce other hardware resource usage skewness, starting with CPU and Memory, disk throttle etc.,
Avoid too small/large shards
Reduce node hot spots

??? means undecided/unsure
ISM — Mutating Rollover
This can either be an Action that is separate from existing Rollover Action which only determines the primary count and sets its at the index template OR an extension to the Rollover Action. Properties for the Actions would be,

Min Index age
Min doc count — not necessary if this is separate Action???
Min Index size — not necessary if this is separate Action???
Min Primary shard size
Default primary shard count — could be the last value OR 5 OR value set by the user???
HOT retention period — The same value used in the warm migration
Alert Channel — When the ingestion rate deviates from the estimation (a deviation is when the primary count estimation changes between the _hot estimation Vs. estimation based on current index Vs estimation based on last 1 hour, 2 hours, 3 hours etc., )
Ingestion rate deviation threshold — ???

Sample implementation
To calculate the ingestion volume for the last 30 hours. Consider all the indices of an Index pattern in _hot.
GET _cat/indices/_hot?v&h=index,creation.date.string,pri.store.size,pri&
s=index:desc,creation.date.string:desc

It was found that 30gb to be an optimal shard size for the given workload (but optimal shard size depends on the workload, usually ranging from 10gb to 50gb)
Size based rollover at shard size 30gb
0gb to 30gb would be the general shard size
For each index pattern, in the last last 30 hours if total ingested size (gb) is,

less than 10gb —> 1p1r sharding strategy —> 0gb to 10 gb would be the shard size range
10gb to 30gb —> 2p1r sharding strategy —> 5gb to 15 gb would be the shard size range
30gb to 60gb —> 3p1r sharding strategy —> 10gb to 20gb would be the shard size range
60gb+ to 30*NO_OF_DATA_NODES gb —> 1p for every 30gb —> approx. 30gb would be the shard size range
30*NO_OF_DATA_NODES+ gb -> (NO_OF_DATA_NODES)p —> approx. 30gb would be the shard size range
(optional) 30*(NO_OF_DATA_NODES/2) -> (NO_OF_DATA_NODES/2)p —> approx. 30gb would be the shard size range

Estimating the ingestion rate
Get the sum of primary store size of all the indices of an index pattern. The HOT retention period is already known (let’s assume ‘x’ hours is HOT retention period). Estimate the ingestion volume for the last x hours. Look at the sample implementation (above) for estimating the primary shard count
GET _cat/indices/_hot?v&h=index,creation.date.string,pri.store.size,pri&
s=index:desc,creation.date.string:desc

Validate the accuracy of the estimation

Get the _count of documents from the current index for the last 1 hour, 2 hours, 3 hours etc., — This type of validation may be misleading if there is an off-hour traffic. Instead of last 1 hour, 2 hours, 3 hours random one hour window can be used, says now-7, now-5, now-1 etc.,

GET opensearch_dashboards_sample_data_logs_00002/_count
{
  "query": {
    "bool": {
      "filter": [
        {
          "range": {
            "timestamp": {
              "gte": "now-1h",
              "lte": "now"
            }
          }
        }
      ]
    }
  }
}

Get the docs.count, pri.store.size of the current index

GET _cat/indices/opensearch_dashboards_sample_data_logs_00002?
h=index,creation.date.string,pri.store.size,pri,docs.count&
format=json

Get the current timestamp
Find the ingestion rate deviation from the original estimate. A deviation is when the primary count estimation changes between the _hot estimation Vs. estimation based on current index Vs estimation based on last 1 hour, 2 hours, 3 hours etc.,
Optionally, Get the pri.store.size of the last rolled-over Index AND/OR last by one rolled-over Index for further analysis on ingestion rate deviation

The worst that can happen

Unpredictable issues???

Incomplete section
Challenges

Find all indices of an index pattern in _hot is currently not a straightforward API call as GET _cat/indices/_hot/<<index_name>> doesn’t work. This needs to be fixed first.
Assumption here is 'timestamp' or any field that is used as Time Field uses current time. Otherwise this won't work
How do we handle data streams ??? May be handle this at Index Management Rollover — https://opensearch.org/docs/latest/dashboards/im-dashboards/rollover/
Not suitable for longer HOT retentions???

Index Management — Create Index
The Create Index page on the OSD can be suggest the primary shard count. Ask the user to input the following information so a primary shard can be suggested to them. They can choose the suggested sharding strategy or overwrite it manually. Goal is to guide the user  to adopt the Sharding Strategy best practices.
Side question: Do people really use this to create indices? :-) What can be done for indices created via PUT <<index_name>>. That should be the ultimate goal

Type of Index — Search or Timeseries or Vector
Number of Data nodes (NO_OF_DATA_NODES) — Auto populate so user can verify it
Expected storage volume
Index growth rate
Expected Search SLA — ???
Expected type of searches — Intensive aggregation query usage can influence the optimal shard size
Desired shard size — This should be auto populated based on the above input but user can overwrite it
When Timeseries is chosen as the type of index, ISM should be suggested here for the user

Quoting AOS best practices documentation — https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html#bp-storage

The total size of the source data plus the index is often 110% of the source, with the index up to 10% of the source data.
(Source data + room to grow) * (1 + indexing overhead) / desired shard size = approximate number of primary shards

@aswath86 Thanks! can you add that to the feature description above?
if you want to clarify that it is added later you can append it after adding a line and writing [Edit Sep 3rd:] before the new part. but it is up to you. Im not sure we have guidelines for editing the RFC as the conversation continues.

Thanks for the meeting @aswath86 @Jon-AtAWS and Robert (what is your github handle?)
Summary:

I am not opposed to the RFC, as we agree that the project should have a way for users to get a better out-of-the-box experience (adding the ease-of-use label is a good idea)
The solution should provide users with controls over an automated policy, with the flexibility to tailor it to their use cases
The solution does not completely solve hotspots, but provides a better starting point and provide better experience to first time users and if they suffer from hotspots this will provide some basic instrumentation to solve some/all of it per their use case.

Thanks all!
One more quick thought from me... the feature should work in the data node count as part of the guardrails, and attempt to make changes that are congruent with that node count. This will also help with hot spots

Thanks for the meeting @aswath86 @Jon-AtAWS and Robert (what is your github handle?)

I am @486 - thanks again for the discussion @AmiStrn , looking forward to the next steps!


'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead.

I'm now getting this message: "'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead." and because of it actions are taking seconds to process.  This is related to localStorage. Any ideas?

Could you provide the stack trace? I don't see it being used here.

I think it is related to exceeding 10MB in the history.  When it happens to me again today I'll post more.

I am also facing same issue. Please update if any solution found.

@ananddodia, you can limit the data to be stored by adding maxAge parameter as following:
const enhancer = compose(
  applyMiddleware(d1, d2, d3),
  DevTools.instrument({ maxAge: 50 }),
  persistState(getDebugSessionKey())
);


Release Candidate for v1.4.9

Signer v1.4.9 Asset
Signer v1.4.9

@piotrwitek it was probably resolved as part of the GitHub action pipeline prior to release but I'll create a hotfix for it so it's correct on here.

@George-cl it is clear the issue still is on the develop branch, it should be corrected in the release branch, there is no issue with the Github action pipeline.

@George-cl it is clear the issue still is on the develop branch, it should be corrected in the release branch, there is no issue with the Github action pipeline.

What I meant is that as part of the GitHub action responsible for publishing the extension, npm i is run which means the published package should be correct despite it having the incorrect version in GitHub.


eksctl anywhere upgrade cluster doesn't use the extra hardware from hardware.csv

What happened:
I created an EKS anywhere cluster with 1 CP node and 1 worker node, kubernetes 1.26
Then I try to upgrade it to 1.27, with a new CP node plus the existing CP node and the worker node in the new hardware file.
cluster config file change is:
diff eksa-mgmt02-standalone2-md-cluster.yaml eksa-mgmt02-standalone2-md-cluster-new.yaml
25c25
<   kubernetesVersion: "1.26"
---
>   kubernetesVersion: "1.27"
48c48
<   osImageURL: "https://<image store>.blob.core.windows.net/ubuntu-2004-efi/ubuntu-2004-efi-eksa-sp-kube-v1.26.7.gz"
---
>   osImageURL: "https://<image store>.blob.core.windows.net/ubuntu-2004-efi/ubuntu-2004-efi-eksa-sp-kube-v1.27.11.gz"
99c99
<           IMG_URL: https://<image store>.blob.core.windows.net/ubuntu-2004-efi/ubuntu-2004-efi-eksa-sp-kube-v1.26.7.gz
---
>           IMG_URL: https://<image store>.blob.core.windows.net/ubuntu-2004-efi/ubuntu-2004-efi-eksa-sp-kube-v1.27.11.gz

hardware change is:
armada@admin-machine2:~/eksa/mgmt02$ diff hardware-mgmt02-standalone2.csv hardware-mgmt02-standalone2-new.csv
2a3
> eksa-control-02,...,type=cp,/dev/sda

The command I use:
eksctl anywhere upgrade cluster -f eksa-mgmt02-standalone2-md-cluster-new.yaml --hardware-csv hardware-mgmt02-standalone2-new.csv --no-timeouts -v 9
I see upgrade stuck with following errors:
...
2024-03-10T21:52:12.727Z	V6	Executing command	{"cmd": "/usr/bin/docker exec -i eksa_1710107518038170593 kubectl get --ignore-not-found -o json --kubeconfig /home/armada/eksa/mgmt02/mgmt02-standalone2/mgmt02-standalone2-eks-a-cluster.kubeconfig Cluster.v1alpha1.anywhere.eks.amazonaws.com --namespace default mgmt02-standalone2"}
2024-03-10T21:52:12.836Z	V9	Cluster generation and observedGeneration	{"Generation": 2, "ObservedGeneration": 2}
2024-03-10T21:52:12.836Z	V5	Error happened during retry	{"error": "cluster has an error: hardware validation failure: for rolling upgrade, minimum hardware count not met for selector '{\"type\":\"cp\"}': have 0, require 1", "retries": 1}
2024-03-10T21:52:12.836Z	V5	Sleeping before next retry	{"time": "1s"}
...
2024-03-10T22:23:21.692Z	V6	Executing command	{"cmd": "/usr/bin/docker exec -i eksa_1710107518038170593 kubectl get --ignore-not-found -o json --kubeconfig /home/armada/eksa/mgmt02/mgmt02-standalone2/mgmt02-standalone2-eks-a-cluster.kubeconfig Cluster.v1alpha1.anywhere.eks.amazonaws.com --namespace default mgmt02-standalone2"}
2024-03-10T22:23:21.805Z	V9	Cluster generation and observedGeneration	{"Generation": 2, "ObservedGeneration": 2}
2024-03-10T22:23:21.805Z	V5	Error happened during retry	{"error": "cluster has an error: hardware validation failure: for rolling upgrade, minimum hardware count not met for selector '{\"type\":\"cp\"}': have 0, require 1", "retries": 1678}
2024-03-10T22:23:21.805Z	V5	Sleeping before next retry	{"time": "1s"}
...

What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

EKS Anywhere Release: v0.18.2
EKS Distro Release: 1.26/1.27

From the initial look what I understand is this was a rolling and scaling upgrade request. This means that 2 extra hardwares were expected for the upgrade - 1 for the scale up, 1 spare for the rolling upgrade of 1.26 -> 1.27. My guess is that the extra hardware you added to the csv was used for the new CP node and eks anywhere didn't have enough for the rolling upgrade.

@mitalipaygude I just try to use 1 more machine (1 existing host + 2 idle hosts), same issue shows:
2024-04-14T08:59:52.814Z	V6	Executing command	{"cmd": "/usr/bin/docker exec -i eksa_1713084293614893292 kubectl get --ignore-not-found -o json --kubeconfig /home/armada/eksa/mgmt02/mgmt02/mgmt02-eks-a-cluster.kubeconfig Cluster.v1alpha1.anywhere.eks.amazonaws.com --namespace default mgmt02"}
2024-04-14T08:59:52.934Z	V9	Cluster generation and observedGeneration	{"Generation": 3, "ObservedGeneration": 3}
2024-04-14T08:59:52.934Z	V5	Error happened during retry	{"error": "cluster has an error: hardware validation failure: for rolling upgrade, minimum hardware count not met for selector '{\"type\":\"cp\"}': have 0, require 1", "retries": 794}
2024-04-14T08:59:52.934Z	V5	Sleeping before next retry	{"time": "1s"}

At the same time, according to https://anywhere.eks.amazonaws.com/docs/clustermgmt/cluster-upgrades/baremetal-upgrades/:
EKS Anywhere upgrades on Bare Metal require at least one spare hardware server for control plane upgrade and one for each worker node group upgrade.
So 1 spare machine is good enough.


dockerTools introduced breaking changes?

I have a setup for creating a layered docker image which used to work just fine. Trying to build this on master fails:
{ stdenv
, dockerTools
, nodejs
, nodeModules
, imageName
, tagName
, app
}:

let

  dependOnNodeModules = import ./buildRuntimeDep.nix {
    inherit stdenv;
    pkg = nodeModules;
    name = "node_modules_prod";
  };

  dependOnNodejs = import ./buildRuntimeDep.nix {
    inherit stdenv;
    pkg = nodejs;
    name = "nodejs";
  };

  nodejsImage = dockerTools.buildImage {
    name = imageName + "-nodejs";
    tag = tagName;
    fromImage = null;
    contents = [ dependOnNodejs ];
  };

  nodeModulesImage = dockerTools.buildImage {
    name = imageName + "-modules";
    tag = tagName;
    fromImage = nodejsImage;
    contents = [ dependOnNodeModules ];
  };

in
  dockerTools.buildImage {
    fromImage = nodeModulesImage;

    name = imageName;
    tag = tagName;

    runAsRoot = ''
      #!${stdenv.shell}
      ${dockerTools.shadowSetup}
      groupadd -r app
      useradd -r -g app -d / -M app
    '';

    config = {
      Env = [ "BABEL_DISABLE_CACHE=1" "NODE_ENV=production" ];
      Cmd = [ "${nodejs}/bin/node" "${app}/index.js" ];
      WorkingDir = "${app}";
      ExposedPorts = {
        "3000/tcp" = {};
      };
    };
  }

This is called with:
imageName = docker-registry.hc.ag/hc/hc-web:nodejs-testing.932ff5fcf472763d7d4738ecdde95b699f1b7ff4`
tagName = nodejs-testing.932ff5fcf472763d7d4738ecdde95b699f1b7ff4

And results in:
error: while evaluating the attribute ‘fromImage’ of the derivation ‘docker-image-hc-web.tar.gz’ at /nix/store/giv1wvnk2xmdl6rbh94hhxwmplwqv9kc-8839f0356fb913447364c7160778995db8583ba2/pkgs/build-support/trivial-builders.nix:7:14:
while evaluating the attribute ‘fromImage’ of the derivation ‘docker-image-hc-web-modules.tar.gz’ at /nix/store/giv1wvnk2xmdl6rbh94hhxwmplwqv9kc-8839f0356fb913447364c7160778995db8583ba2/pkgs/build-support/trivial-builders.nix:7:14:
while evaluating the attribute ‘buildCommand’ of the derivation ‘docker-image-hc-web-nodejs.tar.gz’ at /nix/store/giv1wvnk2xmdl6rbh94hhxwmplwqv9kc-8839f0356fb913447364c7160778995db8583ba2/pkgs/build-support/trivial-builders.nix:7:14:
invalid character ‘/’ in name ‘docker-layer-docker-registry.hc.ag/hc/hc-web-nodejs’

I am also confused by the fact that layers are prefixed with docker-layer- now. This way it cannot be pushed to the repository since the name is not correct anymore

I think this is caused by one of the recent changes to dockerTools by @adnelson - can you have a look at this? I need to find the time to git bisect this.
UPDATE: I did bisect this and as expected it fails starting with  d5316884e4177f8d77366886eeffc2d66f599358

I had the same error the other day. Pretty annoying.

Only fix I can provide for this right now is to revert the breaking changes: https://github.com/holidaycheck/nixpkgs/commit/a24fac3ee18fbfc0a00886c462551e7c05fad547
Makes me wonder if we could add a proper test for this.

I can take a look at this, it looks like it should be easy to fix. Looks
like it's just complaining because there are slashes in the name; the fix
for that is probably just to call baseNameOf on derivation name for the
layer. Can you give an example which I can build that has no
non-nixpkgs dependencies?
On Monday, October 31, 2016, Tobias Pflug<EMAIL_ADDRESS>wrote:

Only fix I can provide for this right now is to revert the breaking
changes: holidaycheck@a24fac3
https://github.com/holidaycheck/nixpkgs/commit/a24fac3ee18fbfc0a00886c462551e7c05fad547
Makes me wonder if we could add a proper test for this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/20016#issuecomment-257287351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2wtyA5Tp_ZiP0VvTLX6VpGxjc21h_Pks5q5eYqgaJpZM4Kk6y_
.

--
-- Allen

@adnelson i am somewhat confused ..

why does the naming change at all?
I think name would commonly be something like some.host.com/foo/bar:latest right?
If I create a docker image with multiple layers which is to be pushed to some.host.com shouldn't all layers have this name then? Or put in a different way: The fact that docker-layer is being prefixed seems unexpected. I am really not exactly a docker expert so I might be getting something wrong here

Let me try to put something reproducible together. @puffnfresh you wouldn't happen to have something ready would you?

The naming was changed to make the role of the resulting store objects more clear. When you build a docker image, part of what is being built is the docker layer; this is wrapped into the final image tarball. Prefixing the name with docker-layer simply makes it easier when looking at the contents of your nix store to see what the object is. The name of the layer should only be used internally anyway, at least according to the "api" of dockerTools.buildImage.

name in this case is a nix concept; docker of course has its own naming scheme of repository:tag. There is no necessary relationship between the two; however if we call baseNameOf on some.host.com/foo/bar:latest then we will get a valid nix name. In fact I went back and checked; in fact before we were giving every layer the name "docker-layer", so I think it's definitely an improvement to include the name in this. Of course we were also using baseNameOf which as your issue brings up we have regressed from.

The names of the layers (as nix objects) are really incidental; as long as the nix expression knows how to find them, which it does because it references them via a variable name, the build will succeed. The only problem here is that we are passing name directly to the mkLayer functions rather than name = baseName or name = baseNameOf name.

Here is some failing test case:
{ pkgs ? import <nixpkgs> {}
, imageName ? "some-registry.com/foo/bar"
, tagName ?  "foobar"
}:

let

  inherit (pkgs) stdenv nodejs;

  mkRuntimeDep = pkg: name: stdenv.mkDerivation {
    name = "runtime-dep-${name}";
    src = pkg;
    installPhase = ''
      mkdir -p $out
      echo ${pkg} >> $out/depend_on-${name}
    '';
  };

  nodejsDep = mkRuntimeDep nodejs "nodejs";

  nodejsImage = pkgs.dockerTools.buildImage {
    name = imageName + "-nodejs";
    tag = tagName;
    fromImage = null;
    contents = [ nodejsDep ];
  };

in
  pkgs.dockerTools.buildImage {
    fromImage = nodejsImage;

    name = imageName;
    tag = tagName;

    runAsRoot = ''
      #!${stdenv.shell}
      ${pkgs.dockerTools.shadowSetup}
      groupadd -r app
      useradd -r -g app -d / -M app
    '';

    config = {
      Env = [ "NODE_ENV=production" ];
      Cmd = [ "${nodejs}/bin/node"];
      ExposedPorts = {
        "3000/tcp" = {};
      };
    };
  }

I guess it could be smaller since the mkRuntimeDep stuff is not relevant for this but anyway: this yields the error.

@adnelson thanks for your elaborations. I remain confused about the naming. You say the name attribute is a nix thing and not necessarily related to the docker concept of repository:tag.
So if name is indeed not necessarily directly related to repository:tag - lets say what I want to get is foobar.com/blah:something - how do I specify this to buildImage then?
Sorry if I'm missing something obvious here :)

@gilligan well, there's nothing in these build steps that are telling nix to fetch a particular image from a remote repository, or anything... in fact despite the name dockerTools.buildImage never invokes the docker command at all :) so if you want it to pull an image from foobar.com then you need to use pullImage -- although, this command is currently broken :(

@gilligan I have a pull request that fixes this issue; give it a test :)

@adnelson thanks - I commented over there. It fixes the problem for me. @NeQuissimus mind merging @adnelson 's fix? then I can close this issue.


input method settings

Can you please add a settings to change input method like VSCodeVim?
https://github.com/VSCodeVim/Vim#input-method

Does something like this work for you? (put into your init.vim, you need im-select binary)
autocmd InsertEnter :!/usr/local/bin/im-select com.apple.keylayout.US

Does something like this work for you? (put into your init.vim, you need im-select binary if you're on win/mac)
autocmd InsertEnter :!/usr/local/bin/im-select com.apple.keylayout.US

I tried this in windows10, but not work.
autocmd InsertEnter :!notepad

when I leave insert mode, it will automatically jump to neovim output pane instead of staying in editor, how could i solve this problem?

@Jackiexiao, could you try it with clear Neovim config?

Try
autocmd InsertLeave * :silent !C:\\....

Try
autocmd InsertLeave * :silent !C:\\....

Works! Thx!


Remote MySQL Server

Is it possible to use a remote mysql server, all tests fail as it's looking for the socket and not reading the correct info from /etc/mysql/my.cnf and see no option to set a mysql db host in the config.
Keep getting error OperationalError: (_mysql_exceptions.OperationalError) (2002, 'Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (2 "No such file or directory")') when running make

Figured it out with editing the myqsl host in file app/flask_config.py.

Glad to hear you worked around it. I've added DATABASE_HOST to config.py to make this easier: f081a181cae5449ad9fc42378aa5de9cf5db3424


reporting -- filtro de "select a class" não segue o filtro de strands e não se adapta conforme mudamos a expedição (i.e., precisamos sempre mudar o filtro manualmente)

currently, all filters (year, subject, classes, and cycles) are global — e.g. if you select a grade 2A class in the context of a grade 2 strand, the same filter will apply even if you go to a grade 10 strand.
what we should have is a contextualized (more intelligent) filter — it makes sense to list grade 2A students in the context of the grade 2 strand, and the grade 10 students in the context of a grade 10 strand.
in order to do this, I need to investigate where a global filter can be more useful than a contextualized filter, before implementing this feature.

quick note about the current implementation for documentation: the global filters exist because I was focused in the elementary teacher persona — they'll mostly want to look at the same students, no matter the context

I believe the filters should be global and remain stored in the Strands tab ( lanttern.org/strands/ ) since specialist teachers will often want the same filters applied all the time (e.g. Grade 6 / Grade 7 / Grade 8, Science).
In the strand page, the filter should not be global and could be pre applied (and probably not stored) following the grade level tag. I.e. when you open a strand page that has the tag Grade 6, the filter is applied to show only and all Grade 6 classes.
Error handling: if the strand doesn't have a grade tag, don't show any classes, forcing the user to apply the filter manually.

I created a new issue (#127) to implement the isolation of the class filters between strands. it's not as smart as the one you suggested @andrematui (there's no automatic initial selection) but I think it's better than the previous implementation — let's see if it improves the UX, and we can continue this discussion latter on


JwtBearerDefaults.AuthenticationScheme no longer exists in .NET Core 2.2

(Where did it go?)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ee71441f-471a-89cd-0ef4-9b32b5dd85cf
Version Independent ID: 0096c365-2f4e-5d21-89a0-c4f10fcb0ed9
Content: Authorize with a specific scheme in ASP.NET Core
Content Source: aspnetcore/security/authorization/limitingidentitybyscheme.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Nevermind, apparently Microsoft.AspNetCore.Authentication.JwtBearer is just no longer included by default in the Microsoft.AspNetCore.App package. Sorry!


treat domain not found as ok for CAA checks

What this PR does / why we need it:
During some testing @munnerz found that the CAA check would error out when a domain is not found. This is not the right CAA check behavior
Additionally, improve error messages when we do get an unexpected code
Release note:

NONE

/lgtm
/approve
/milestone v0.7


fix: remove mas-auth  url

URL is no longer valid and have been included in +2 releases as deprecated. We can remove it

LGTM :+1:


Refactor btree iterator last index

After working on #124.
I did realize many variants of LastIndex were useless.
This PR changes:
LastIndex::Start -> LastIndex::Before(0)
LastIndex::End -> LastIndex::Before(last separator + 1) . (so can be equal to ORDER).
LastIndex::After(i) -> LastIndex::Before(i + 1)
Also a seek operation do not need a direction.
And seek_to_last is now using a variant of SeekTo enum.
Close #124

Thank you, I also see other issue with seek, I will fix this.

I ended up refactoring (see updated description) a bit but should be a good thing.


how to use?

Hello, how can i use this package?
i am trying to implement " Nova BelongsTo Or Create" but cant find a documentation for how to..
i have allready installed nova fields package

oh yeah, thank you very much


ASCII Binary file not working

According to the readme, the switch -i bits resp --input bits will load ASCII files with 1 and 0. But I don't get any output?
andreas@E535:~$ cat ~/Downloads/5218_binaer.txt | redsea --input bits
andreas@E535:~$

The file itself contains all 4 blocks, 0x5218 is<PHONE_NUMBER>011000
$ more ~/Downloads/5218_binaer.txt | grep<PHONE_NUMBER>011000
0101001000011000000001010010110011100000110011010101001001010100

5218_binaer.txt
In the source code I also found the still existing switch -b
case 'b': // For backwards compatibility

But none of the methods is working here?

Hmm. Could there be something up with the input data source? It seems as though the PI is not repeating every 104 bits but instead every 64 bits:
$ grep --only-matching --byte-offset '0101001000011000' ~/Downloads/5218_binaer.txt | head
0:0101001000011000
64:0101001000011000
128:0101001000011000
192:0101001000011000
256:0101001000011000
320:0101001000011000
384:0101001000011000
448:0101001000011000
512:0101001000011000
576:0101001000011000

Maybe the 10-bit checkwords have been stripped out? That would make the group length to be 64 (40 bits missing from every group). Redsea can't decode binary without the correct checkwords, but you can first transform the data into the RDS Spy hex format, where they are not needed.

Well, it's an old file in my archive. I will just convert the 4x 16 bits (which is 64 bits) to hex. Seems there is no additional overhead. That's why the PI is repeated after 64 bits.
Unfortunately I don't know which tool has created that file.
You can close it, if you want.

Closed

But thank you for the grep parameter!

No probs! Glad I could help


More transmission debugging information

[ ] At least the server response code here
[ ] Check that additional details are available for both GET and POST, see #231

Thanks Matthias, you are right, yesterday i figured it out it is a POST call.
it will be better to have also the post param in the log. Thanks


Matt Hogstrom

Email
<EMAIL_ADDRESS>Bio
Matt has been involved with the mainframe since the days of the dinosaurs.  He started as a batch assembler, moved onto systems programming and worked as a consumer of IBM z/OS, VSE and z/VM services for over 20 years.  In addition, Matt has been actively involved to integrate distributed technologies with the mainframe starting with Novell Networking allowing CICS to print to distributed printers not registered with the mainframe.
In early 2000 Matt switched to the darkside of creating IT products when he joined IBM.  He was involved in the formation of Java at IBM participating in the Java Community Process (JSR-004 and JSR-131) as well as building performance benchmarks at SPEC (SPECjAppServer 2001 and SPECjAppServer 2004).  He is also a member of the Apache Software Foundation and participated on Apache Geronimo which was used to create the WebSphere Community Edition.  In all these efforts they were focused on the union of the Mainframe and Distributed usage.
Later he took on the role of CTO of the IBM z Manage suite of products and was a founding member of the Zowe Community which is the most active OMP project having broad reach to join mainframers to open source technologies.
Currently Matt is a Distinguished Engineer in AIOPs at Broadcom.  Matt’s role at Broadcom is to explore ways to simplify using Broadcom Monitoring and Automation products by enabling them to be easily consumable as RESTful services to create better solutions and outcomes for our products and customers.
Projects within OMP you would want to be an ambassador for
Zowe
Mainframe Modernization
List any other topics you would be able to speak about
Career advice for those considering being a mainframer which includes the industry, culture along with the technology.
How to help people find a path to engage with open source.
The benefits of Linux and K8s for the IBM Z platform across z/OS and other operating systems.
Why do you want to be an ambassador?
I really enjoy sharing my experience with others with the goal of providing knowledge transfer and inspiration.  If we only do but do not share and pass the torch our impact is limited.  My intention is to share, inspire and encourage others to see evolving IT and role of the mainframe in that ecosystem.
Attach a headshot

Hey Matt - since you are already an Ambassador - no need to re-apply.


Docs: question about surface culling and vertex order.

The tutorial docs show how to create a simple 4 vertex surface. I've tried to create "Suzane" from blender, and have some Z-buffer/culling/intersection issue.
I'm not sure if this is something that should be documentented ? At least I could not find it easily.

But arguably, maybe my code is wrong:
from stl import mesh
import napari
import numpy as np
from os.path import expanduser
# https://fr.wikipedia.org/wiki/Fichier:Suzanne.stl
m = mesh.Mesh.from_file(expanduser('~/Downloads/Suzanne.stl'))
# make suzane face us
m.rotate((0,0,1), np.pi/2)
m.rotate((1,0,0), -np.pi/2)
vs = list(m.vectors.reshape(-1, 1, 3).squeeze(1))

vertices = np.array(sorted({tuple(x) for x in vs}))

faces = []
for face in m.vectors:
    fc = []
    for vec in face:
        wh = np.where((vertices == np.array(vec)).sum(axis=1) == 3)
        idx = wh[0][0]
        fc.append(idx)
    faces.append(fc)
faces = np.array(faces)

faces = np.array(faces)
values = np.linspace(0, 1, len(vertices))
surface = (vertices, faces, values)
viewer = napari.view_surface(surface)  # add the surface

Originally posted by @Carreau in https://github.com/napari/napari/pull/4124#discussion_r811310753

Note that in addition it would be good for the tutorial to actually use real data – later is shows brain with regions, so maybe this one.


reconstruct memory when set EnableMemory to false in tracing

Checklist
OpCodes Impl

[x] CALLDATACOPY
[x] RETURNDATACOPY
[x] CODECOPY
[x] EXTCODECOPY
[x] MSTORE
[x] MSTORE8
[x] RETURN

Test
Unit Tests

[x] CALLDATACOPY
[x] RETURNDATACOPY
[x] CODECOPY
[x] EXTCODECOPY
[x] MSTORE
[x] MSTORE8
[x] RETURN

Integration Test

[x] Test with tracer config: EnableMemory: false

Note
this pr is related to scroll-tech/go-ethereum/issues/94 and privacy-scaling-explorations/zkevm-circuits/issues/502.

very clean codes.
After addressing the above comments, i think it can be sent to upstream for the first round of reviewing

i will merge this branch into https://github.com/scroll-tech/zkevm-circuits/pull/166 soon and use it to fuzz test a lot of mainnet blocks

hmm.. i clone the branch locally and i found i have to change some memory: Memory::from(...) to memory: RefCell::new(Memory::from...) in eth-types/src/lib.rs to pass compiling... strange that the CI passed.

is the name "reconstruct_memory" good enough? or change it to:
 -> reconstruct_memory_for_next_step

or
-> replay_memory_updates
?
@icemelon

I add some debug output. Here's the most common failed reason caller id not found in call map.
test evm_circuit::execution::begin_tx::test::begin_tx_gadget_rand ... FAILED
test evm_circuit::execution::begin_tx::test::begin_tx_gadget_simple ... FAILED
test evm_circuit::execution::call::test::call_gadget_nested ... FAILED
test evm_circuit::execution::call::test::call_gadget_simple ... FAILED
test evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_multi_step ... FAILED
test evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_out_of_bound ... FAILED
test evm_circuit::execution::calldataload::test::calldataload_gadget_internal ... FAILED
test evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_simple ... FAILED
test evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_zero_length ... FAILED
test evm_circuit::execution::sload::test::sload_gadget_rand ... FAILED
test evm_circuit::execution::sload::test::sload_gadget_simple ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_delete_slot ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_no_refund ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot_and_reset_inexistent ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_reset_existing ... FAILED
test evm_circuit::execution::sstore::test::sstore_gadget_reset_inexistent ... FAILED

failures:

---- evm_circuit::execution::begin_tx::test::begin_tx_gadget_rand stdout ----
[zkevm-circuits/src/evm_circuit/execution/begin_tx.rs:376] random_amount =<PHONE_NUMBER>05302761
[zkevm-circuits/src/evm_circuit/execution/begin_tx.rs:376] random_gas_price =<PHONE_NUMBER>
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::begin_tx::test::begin_tx_gadget_rand' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- evm_circuit::execution::begin_tx::test::begin_tx_gadget_simple stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::begin_tx::test::begin_tx_gadget_simple' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::call::test::call_gadget_nested stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 30,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0xfefefefefefefefefefefefefefefefefefefefe,
    address: 0xffffffffffffffffffffffffffffffffffffffff,
    code_source: Address(
        0xffffffffffffffffffffffffffffffffffffffff,
    ),
    code_hash: 0xd003426e799329b8dca093f3bbab55a5e4e9f3c40160fc942068eef712ae88ad,
    depth: 2,
    value: 0,
    call_data_offset: 0,
    call_data_length: 0,
    return_data_offset: 0,
    return_data_length: 0,
}
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
    30: (
        0,
        1,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 1
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 83,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0xfefefefefefefefefefefefefefefefefefefefe,
    address: 0xffffffffffffffffffffffffffffffffffffffff,
    code_source: Address(
        0xffffffffffffffffffffffffffffffffffffffff,
    ),
    code_hash: 0xd003426e799329b8dca093f3bbab55a5e4e9f3c40160fc942068eef712ae88ad,
    depth: 2,
    value: 0,
    call_data_offset: 0,
    call_data_length: 0,
    return_data_offset: 0,
    return_data_length: 0,
}
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    83: (
        0,
        2,
    ),
    1: (
        0,
        0,
    ),
    30: (
        0,
        1,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 1
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    83: (
        0,
        2,
    ),
    1: (
        0,
        0,
    ),
    30: (
        0,
        1,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::call::test::call_gadget_nested' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::call::test::call_gadget_simple stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 30,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0xfefefefefefefefefefefefefefefefefefefefe,
    address: 0xffffffffffffffffffffffffffffffffffffffff,
    code_source: Address(
        0xffffffffffffffffffffffffffffffffffffffff,
    ),
    code_hash: 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470,
    depth: 2,
    value: 0,
    call_data_offset: 0,
    call_data_length: 0,
    return_data_offset: 0,
    return_data_length: 0,
}
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 61,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0xfefefefefefefefefefefefefefefefefefefefe,
    address: 0xffffffffffffffffffffffffffffffffffffffff,
    code_source: Address(
        0xffffffffffffffffffffffffffffffffffffffff,
    ),
    code_hash: 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470,
    depth: 2,
    value: 0,
    call_data_offset: 0,
    call_data_length: 0,
    return_data_offset: 0,
    return_data_length: 0,
}
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    30: (
        0,
        1,
    ),
    61: (
        0,
        2,
    ),
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::call::test::call_gadget_simple' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_multi_step stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 66,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0x000000000000000000000000000000000cafe111,
    address: 0x000000000000000000000000000000000cafe222,
    code_source: Address(
        0x000000000000000000000000000000000cafe222,
    ),
    code_hash: 0x45c14d30a01509fc14647d97006bc426571f2f9876d39f76a4d1f77e0f1fbd3e,
    depth: 2,
    value: 0,
    call_data_offset: 48,
    call_data_length: 112,
    return_data_offset: 0,
    return_data_length: 0,
}
thread 'evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_multi_step' panicked at 'assertion failed: `(left == right)`
  left: `[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, b7, 88, be, 89, af, 05, a0, c7, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]`,
 right: `[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]`', bus-mapping/src/evm/opcodes.rs:260:17

---- evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_out_of_bound stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 66,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0x000000000000000000000000000000000cafe111,
    address: 0x000000000000000000000000000000000cafe222,
    code_source: Address(
        0x000000000000000000000000000000000cafe222,
    ),
    code_hash: 0x5eeb596a7c7c1e11813c44dd342c3ad900b5c234941356220928b397fc231ba8,
    depth: 2,
    value: 0,
    call_data_offset: 64,
    call_data_length: 32,
    return_data_offset: 0,
    return_data_length: 0,
}
thread 'evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_out_of_bound' panicked at 'attempt to subtract with overflow', bus-mapping/src/evm/opcodes/calldatacopy.rs:51:37

---- evm_circuit::execution::calldataload::test::calldataload_gadget_internal stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 66,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0x000000000000000000000000000000000cafe111,
    address: 0x000000000000000000000000000000000cafe222,
    code_source: Address(
        0x000000000000000000000000000000000cafe222,
    ),
    code_hash: 0xd3178cec3f148ffc5e90101c9fe44a5c40ccd7cdd304e78ef157d777a9c7f49a,
    depth: 2,
    value: 0,
    call_data_offset: 0,
    call_data_length: 32,
    return_data_offset: 0,
    return_data_length: 0,
}
thread 'evm_circuit::execution::calldataload::test::calldataload_gadget_internal' panicked at 'assertion failed: `(left == right)`
  left: `Err([ConstraintNotSatisfied { constraint: Constraint { gate: Gate { index: 48, name: "CALL" }, index: 248, name: "State transition constraint of memory_word_size" }, location: InRegion { region: Region { index: 6, name: "Execution step" }, offset: 96 }, cell_values: [(VirtualCell { name: "", column: Column { column_type: Advice, index: 23 }, rotation: 0 }, "1")] }])`,
 right: `Ok(())`', zkevm-circuits/src/evm_circuit/execution/calldataload.rs:310:9

---- evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_simple stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 66,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0x000000000000000000000000000000000cafe111,
    address: 0x000000000000000000000000000000000cafe222,
    code_source: Address(
        0x000000000000000000000000000000000cafe222,
    ),
    code_hash: 0x7c24c8c5cf353cbf276d400e57add2dcac99433339c05d294adc5ad036213b82,
    depth: 2,
    value: 0,
    call_data_offset: 64,
    call_data_length: 64,
    return_data_offset: 0,
    return_data_length: 0,
}
thread 'evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_simple' panicked at 'assertion failed: `(left == right)`
  left: `[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, d9, 3e, e7, be, f4, 66, 2e, 5a, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]`,
 right: `[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]`', bus-mapping/src/evm/opcodes.rs:260:17

---- evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_zero_length stdout ----
[bus-mapping/src/circuit_input_builder/input_state_ref.rs:545] &call = Call {
    call_id: 66,
    caller_id: 1,
    kind: Call,
    is_static: false,
    is_root: false,
    is_persistent: true,
    is_success: true,
    rw_counter_end_of_reversion: 0,
    caller_address: 0x000000000000000000000000000000000cafe111,
    address: 0x000000000000000000000000000000000cafe222,
    code_source: Address(
        0x000000000000000000000000000000000cafe222,
    ),
    code_hash: 0x1bda9e953a12a1093f34061ba13196539e7d44c4837d9107368a809e66d2d5a5,
    depth: 2,
    value: 0,
    call_data_offset: 64,
    call_data_length: 64,
    return_data_offset: 0,
    return_data_length: 0,
}
thread 'evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_zero_length' panicked at 'assertion failed: `(left == right)`
  left: `Err([ConstraintNotSatisfied { constraint: Constraint { gate: Gate { index: 48, name: "CALL" }, index: 248, name: "State transition constraint of memory_word_size" }, location: InRegion { region: Region { index: 6, name: "Execution step" }, offset: 96 }, cell_values: [(VirtualCell { name: "", column: Column { column_type: Advice, index: 23 }, rotation: 0 }, "1")] }])`,
 right: `Ok(())`', zkevm-circuits/src/evm_circuit/execution/calldatacopy.rs:329:9

---- evm_circuit::execution::sload::test::sload_gadget_rand stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sload::test::sload_gadget_rand' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sload::test::sload_gadget_simple stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sload::test::sload_gadget_simple' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_delete_slot stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_delete_slot' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_no_refund stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_no_refund' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot_and_reset_inexistent stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot_and_reset_inexistent' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_reset_existing stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_reset_existing' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

---- evm_circuit::execution::sstore::test::sstore_gadget_reset_inexistent stdout ----
[bus-mapping/src/evm/opcodes/return.rs:24] &state.block_ctx.call_map = {
    1: (
        0,
        0,
    ),
}
[bus-mapping/src/evm/opcodes/return.rs:27] &current_call.caller_id = 0
thread 'evm_circuit::execution::sstore::test::sstore_gadget_reset_inexistent' panicked at 'caller id not found in call map', bus-mapping/src/evm/opcodes/return.rs:32:18

failures:
    evm_circuit::execution::begin_tx::test::begin_tx_gadget_rand
    evm_circuit::execution::begin_tx::test::begin_tx_gadget_simple
    evm_circuit::execution::call::test::call_gadget_nested
    evm_circuit::execution::call::test::call_gadget_simple
    evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_multi_step
    evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_out_of_bound
    evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_simple
    evm_circuit::execution::calldatacopy::test::calldatacopy_gadget_zero_length
    evm_circuit::execution::calldataload::test::calldataload_gadget_internal
    evm_circuit::execution::sload::test::sload_gadget_rand
    evm_circuit::execution::sload::test::sload_gadget_simple
    evm_circuit::execution::sstore::test::sstore_gadget_delete_slot
    evm_circuit::execution::sstore::test::sstore_gadget_no_refund
    evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot
    evm_circuit::execution::sstore::test::sstore_gadget_recreate_slot_and_reset_inexistent
    evm_circuit::execution::sstore::test::sstore_gadget_reset_existing
    evm_circuit::execution::sstore::test::sstore_gadget_reset_inexistent

test result: FAILED. 125 passed; 17 failed; 16 ignored; 0 measured; 0 filtered out; finished in 596.15s

i will debug them this afternoon..

add a LoggerConfig in TraceConfig in trace.go. So we can control EnableMemory in rust side.

the current CI is passed. And i saw there the mem trace had already been disabled?

@lightsing backup the branch, then squashed it into one commit. (I will merge this branch into other branch, so better clean the history)

moved to https://github.com/privacy-scaling-explorations/zkevm-circuits/pull/614


Update submissions.json

Evidence can be found here:
Feedback 1: https://github.com/wirednkod/papi-intro-tutorial/issues/5#issue-2642374360
Feedback 2: https://github.com/shawntabrizi/substrate-collectables-workshop/issues/190#issue-2672687717
Request for 1: https://forum.polkadot.network/t/one-year-in-an-education-review/10656/7?u=hippiestank
Request for 2: https://forum.polkadot.network/t/one-year-in-an-education-review/10656/2?u=hippiestank
Additional Context:
My first attempt at bringing something of value to the Polkadot Ecosystem.
While the "value" here is debatable, I am opening this request as an experiment to further develop my understanding of
work-flow within the decentralized ecosystem, hoping to bring real value in the future as I continue to learn.
Polkadot Address: 12sTnkmt99MJE9AcxNGZKFYBo3JMmLHfEJJ1ME8w9WJmQUEk

/tip small


Werror failing due to _LARGEFILE64_SOURCE

Trying to package 3.1.1 for nixpkgs:
/build/source/src/CheckedFile.cpp:47: error: "_LARGEFILE64_SOURCE" redefined [-Werror]
   47 | #define _LARGEFILE64_SOURCE
      |
In file included from /nix/store/14c6s4xzhy14i2b05s00rjns2j93gzz4-gcc-13.2.0/include/c++/13.2.0/x86_64-unknown-linux-gnu/bits/os_defines.h:39,
                 from /nix/store/14c6s4xzhy14i2b05s00rjns2j93gzz4-gcc-13.2.0/include/c++/13.2.0/x86_64-unknown-linux-gnu/bits/c++config.h:679,
                 from /nix/store/14c6s4xzhy14i2b05s00rjns2j93gzz4-gcc-13.2.0/include/c++/13.2.0/cstdint:38,
                 from <command-line>:
/nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/features.h:220: note: this is the location of the previous definition
  220 | # define _LARGEFILE64_SOURCE    1
      |

The CMakeLists.txt sets -Werror here: https://github.com/asmaloney/libE57Format/blob/v3.1.1/CMakeLists.txt#L162
Maybe needs #ifndef like in

https://bugs.launchpad.net/stress-ng/+bug/1800828
https://launchpadlibrarian.net/395441247/0002-stress-ng.h-conditionally-define-_-LARGEFILE-LARGEFI.patch

?

Thanks Niklas. I'll accept a PR for the #ifndef solution.
As I mentioned elsewhere, the whole #ifdef nightmare in this file should be cleaned up since it's been the source of so many problems.
But first someone needs to fix the CI issues...

The immediate workaround is provided by merged PR #299 which disables -Werror.
Full warning fix at my PR #301


How to prevent thumb slider scrolling when thumb count <= slidesToShow?

We have 2 synced sliders with infinite = false
When thumb count is less or equal slidesToShow, thumb slider doesn't work correctly and scrolling away
====================================================================
https://jsfiddle.net/h4mpy/vsw4othf/ - 1.8.1
https://jsfiddle.net/h4mpy/uyce8t6q/ - 1.9.0

I had to fix this recently (last night). What's causing it is the "transform: translate3d(-184px, 0px, 0px);" that is added via javascript to the "slick-track". Not sure where the code is that's adding it to the slick-track but having the CSS set it to "transform: translate3d(0, 0, 0);" does the trick. If that code had a check in place that would be ideal.
Created 2 new fiddles with the CSS override applied.
https://jsfiddle.net/xruvd20p/ - 1.8.1
https://jsfiddle.net/2v15wxry/ - 1.9.0

I had to fix this recently (last night). What's causing it is the "transform: translate3d(-184px, 0px, 0px);" that is added via javascript to the "slick-track". Not sure where the code is that's adding it to the slick-track but having the CSS set it to "transform: translate3d(0, 0, 0);" does the trick. If that code had a check in place that would be ideal.

Unfortunately it's not a good solution. It only works when there's not enough items to fill the slick-list. Otherwise it brakes the carousel and prevents user from accessing all the items because transform3d is used to slide those items into view so it can't be overridden like that.


Update iteratee.io, etc.

Codecov Report

Merging #645 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #645   +/-   ##
=======================================
  Coverage   83.75%   83.75%
=======================================
  Files          70       70
  Lines        2087     2087
  Branches      149      149
=======================================
  Hits         1748     1748
  Misses        339      339

Impacted Files
Coverage Δ

...d/src/main/scala/io/circe/NonEmptySeqDecoder.scala
90.9% <0%> (-9.1%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
90.9% <0%> (+0.36%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a521b2c...1f946ea. Read the comment docs.


10404.5 - add migrations to move to u16 reqproc

Shippable/pm#10404
for any u16 x86_64 runtimeTemplate, we should use drydock/u16reqproc as the "reqprocImage".

existing AMIs should get u14reqproc, new AMIs should get u16reqproc

this will be handled by a different pm


Lock TypeScript to 4.5

Just opening this as another potential resolution to https://github.com/georgealways/lil-gui/issues/93.
Resolves #93.
See https://github.com/georgealways/lil-gui/pull/95 for explanation.

I created a TypeScript issue (https://github.com/microsoft/TypeScript/issues/53051) as well.

Let's keep an eye on this and hopefully un-lock the version if a solve comes around. Thanks for your help


terraform apply errs when MCI feature is already enabled

Background

MCI = multi-cluster ingress
Inside /infra/multi_cluster_service.tf, we enable GKE Fleets' MCI feature using the google_gke_hub_feature Terraform resource.
But this MCI feature is a singleton.
In a non-Terraform world, this enablement is typically done via gcloud container fleet ingress enable.

Problem

If you terraform apply into a project where the MCI feature is already enabled, you will see this error:

Error: Error creating Feature: Resource already exists - apply blocked by lifecycle params: &beta.Feature{Name:(*string)(0xc00145aa10), Labels:map[string]string{}, ResourceState:(*beta.FeatureResourceState)(0xc00139b308), Spec:(*beta.FeatureSpec)(0xc001478010), State:(*beta.FeatureState)(0xc001478060), CreateTime:(*string)(0xc0014780f0), UpdateTime:(*string)(0xc001478100), DeleteTime:(*string)(nil), Project:(*string)(0xc00145aa50), Location:(*string)(0xc00145a9c0)}.
...
Error: running tf apply: terraform apply failed: running terraform failed: exit status 1

When I produced this error on Solutions-in-Console (Jump Start Solutions), the deployment actually worked (but I saw the errors from the logs above in the SiC build logs, and "Failed" on console UI).

Additional info

From cloud.google.com docs on "Fleet host project":

A given Google Cloud project can only have a single fleet (or no fleets) associated with it.

This looks like an issue with the terraform provider, not with this solution


Closes when Open

Every time I launch it says cant load image file. Please help

Could you please give us some more information, like a screenshot of the console, your operating system, and version you are using?


"exec" hangs with a non-existent file in H:

The "exec xxx.bin" command hangs up if file doesn't exists, but only when in H: (mapped to PC directory)

Fixed on master, thanks for reporting this issue!